Re: Re: [pim] IPv6 Inter-domain Multicasting and Address Assignments

Marshall Eubanks wrote:
> Hello;
> 
> 
> On 2/23/07, Tim Chown <[email protected]> wrote:
>> On Thu, Feb 22, 2007 at 08:36:39PM -0500, Marshall Eubanks wrote:
>> >
>> > On 2/22/07, Tim Chown <[email protected]> wrote:
>> >
>> > This has been used since at least early 2003; it was first presented
>> > at the Summer 2003
>> > IETF in Vienna - see
>> >
>> > http://www.6net.org/events/workshop-2004/durand.pdf
>>
>> Yes, Embedded-RP came out of 6NET work.    There was a lot of early IPv6
>> multicast development and testing done in 6NET and on the m6bone which
>> emerged from TF-NGN just before 6NET started.
>>
>> > >A big win for v6 is that you dont need an ASN for GLOP like v4, you 
>> can
>> > >just form multicast groups from your unicast allocated prefix(es).
>> > >
>> >
>> > Note that there has been a big discussion about assignment of IPv6
>> > addresses - see
>> >
>> > http://www.arin.net/policy/proposals/2005_1.html
>>
>> This is a good point - if you want provider independent multicats group
>> addresses you need provider independent unicast space to base the 3306
>> or embedded-rp group address upon.
>>
>> > >And with a lot of /64's in an IPv6 site, you can (as we have) 
>> assign an
>> >
>> > Most assignments are /48s
>>
>> To sites, yes, but if you want to allow more unique multicast group
>> addresses to be used, what we decided to do was issue a /64 per 
>> application.
>> By doing that the application can determine how to utilise the multicast
>> group bits and they won't clash with other groups as they would if your
>> 3306 addresses were purely generated from a /48.   Well, we're trying 
>> this
>> at the moment to see how it works.   An allocation service would 
>> certainly
>> be useful, something to respond to a request to 'please allocate me a 32
>> bit group ID for this 96 bit group prefix' would be nice.
> 
> My point was just that once you get v6 PI space you have lots of
> addresses to play with, but this is very interesting.
> 
> Should this allocation service be done by an RIR ? (This could be
> assigned for "Multicast Applications" for each RIR and then they could
> hand them out to requestors.
> That would require a RFC first, of course.)

I don't believe in getting separate unicast addresses from registries
just for multicast usage if that is what you're suggesting. I'm not
sure if I like the /64 per application either, although I can see the
need for it since we don't have any proper allocation mechanisms. And
as you said Tim, there is nothing preventing this. I also think that 
embedded-RP has all the benefits of unicast-prefix based addresses as 
well as several other, so I would generally expect people to use those,
at least for inter-domain.

One solution for allocation could be to use MADCAP or DHCP (yes I
think DHCP might be sufficient) for allocating individual addresses.

Another and simpler solution would be to have some way for an
application to learn which /96 prefix to use, and then randomly pick
a group id, ideally combined with some mechanism for finding duplicate
group id's on the link.

Both the above have been discussed before, e.g. drafts from
Jerome Durand.

First about the prefix. If you simply use unicast-prefix based
addresses, then one possibility could be for the application to
derive the /96 from a unicast address used by the host. For
embedded-RP this is not possible, unless one could assume every
edge router to be an RP perhaps... One option might be DHCP for
learning the /96 prefix, or it could be configured on the host
in some other way. Using DHCP to tell the hosts/applications
what prefix to use is much easier than address assignment, and
could be done with so-called stateless DHCP.

For the last 32 bits (or it's actually 31) it might be sufficient
to pick them at random. It could be useful to have a way of
checking that it is unique on the line however. To check that the
group-id and hence the MAC address is unique might be useful in
other cases as well. One possible idea that was briefly discussed
was some extension of the IPv6 DAD. Making the group id locally
unique might even be useful for SSM.

Stig

> 
> Marshall
> 
>>
>> Another thing we're tinkering with is organisational SAP style 
>> advertisements
>> where an application has a /64 based 3306 prefix and then uses group 
>> ID zero
>> for the announcements.   For that example p2p app, it allows a site's
>> available services to be discovered anywhere via a 'well known' group.
>>
>> But the point is that v6 multicast has the big win of allowing a site to
>> create its own globally unique multicast group addresses (lots of them!)
>> from just its unicast prefix.    No need for an ASN.    And thus to be 
>> able
>> to also try new creative schemes to use that address space.   
>> Something you
>> just can't do in v4.
>>
>> -- 
>> Tim
>>
> 
> _______________________________________________
> magma mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/magma