Subject: RE: uni-based-mcast and malloc-ipv6-guide

From: "Dave Thaler" <[email-masked]>
Date: Tue, 18 Sep 2001 10:22:23 -0700

Erik Nordmark asks:
> I fail to understand why routing might fail. Could you explain?
> I do understand that there is a different probability of allocating
> duplicate
> uni-based mcast addresses should the unicast prefix be assigned to
another
> entity, but this doesn't lead to routing failing unless you are
assuming
> that routing will do something it doesn't currently do.

Just like providers do source ingress filtering, there might be
something similar that providers would do here.  (Maybe, maybe not.)

-Dave
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Sep 2001 11:25:30 +0200 (CEST)

> something similar that providers would do here.  (Maybe, maybe not.)

Dave,

I'm trying to understand exactly what operational practises that you
are suggesting and how they would effect the multicast "service".

For SSM it is clear that providers might do filtering.
But since uni-based mcast doesn't contain a prefix for SSM addresses
the nature of filtering will be no different than with IPv4 SSM i.e.
verify that the source address is in some access list for using the
SSM address or something of that nature. Point is that uni-based-multicast
doesn't change anything in this space.

For non-SSM (I assume this is what Brian called "ASM") one could
envision having checks that somehow compare the unicast prefix in the multicast
address with the IP source address. But assuming that ASM really should
provide a service where anybody can send, such checks seem quite determintal
to the service. Thus if there ever will be reasons for providers or other
entities to perform filtering on ASM packets it seems like they need the
ability to have access lists with arbitrary IP source addresses associated
with the group. Hence the unicast prefix in the group doesn't make filtering
any simpler.

So I don't understand what operational practise you are hinting at.
What am I missing?

  Erik