Subject: [magma] IPv6 Inter-domain Multicasting and Address Assignments

From: "Gibbons, James" <[email-masked]>
Date: Tue, 20 Feb 2007 15:41:33 -0500

Hello,

SI International represents and contracts with DITO (DoD IPv6 Transition
Office) on a number of IPv6 issues.  In this case we are providing DITO
with a white paper on IPv6 Inter-domain multicast address assignments
and issues/problems (expected or realized) regarding IPv6 multicast
implementations.

To begin, I have gone over a number of RFCs (including RFC 3306, 3956,
3307, 2375, 4607, ID draft-ietf-mboned-ipv6-multicast-issues-02.txt
among others) but they are vague as to actual working implementation of
inter-domain multicast address assignments and how they will or might
work proceed.

I wrote to IANA and it was suggested I might contact the IEFT MAGMA and
PIM groups, so I am forwarding this letter; any advice is greatly
appreciated.

=====my questions or issues =====

In IPv4 GLOP was developed but not widely used, where an organizations
ASN is embedded in the 223.0.0.0 / 8 multicast range.  In IPv6 I have
seen V6UPBM (RFC 3306) and "Embedded RP" (RFC 3956) as similar proposals
for IPv6.  

However, I am still not clear of the "reality" of IPv6 multicast address
assignments especially with regards to globally unique (by organization,
domain, site, etc.) inter-domain multicast.  

That is, how far have actual address assignments proceeded?  

What is just proposed versus being implemented or to be implemented?  

Are there actual standards being followed?  

Are there any referential real-world implementations?  

Are there known/expected issues/problems with IPv6 inter-domain
multicast and address assignments?

Maybe a quote from my actual assignment will further clarify what I am
looking for:

"DITO is having some concerns with IPv6 multicast address space and how
it should or should not be provisioned.  You should start the study with
regards to how IPv4 multicast addressing worked in the past.  If you
ever worked with it you would know there was never official group
reservations made with regards to address blocks.  However, this was
never a real issue since its popularity died.  So except for what was
deemed to be the well-known addresses there was never any reservations,
unlike how unicast is reserved.  One thought might be the Army gets a
block of addresses, Navy, and so on."

===============

Again, any help is appreciated.  

Thanks,

James Gibbons

Senior Network Engineer

SI International

Tel: 703.234.6894

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 22 Feb 2007 20:36:39 -0500

Hello;

In my opinion, this should be done on Mboned, and certainly not on
PIM. However, here is my take in this.

On 2/22/07, Tim Chown <[email-masked]> wrote:
> On Tue, Feb 20, 2007 at 03:41:33PM -0500, Gibbons, James wrote:
> >
> >    Hello,
> >
> >
> >    SI   International  represents  and  contracts  with  DITO  (DoD  IPv6
> >    Transition  Office)  on  a number of IPv6 issues.  In this case we are
> >    providing  DITO  with  a  white  paper  on IPv6 Inter-domain multicast
> >    address   assignments   and  issues/problems  (expected  or  realized)
> >    regarding IPv6 multicast implementations.
> >
> >    among  others)  but they are vague as to actual working implementation
> >    of  inter-domain  multicast  address  assignments and how they will or
> >    might work proceed.
>
> RFC3306 lets you create for yourself a globally unique multicast group
> address where your unicast prefix (which is unique by allocation) contributes
> towards the first 96 bits of the group address.
>
> The missing bit is how you manage the last 32 bits, but that could be
> application determined if for example you used a /64 per application.
> Or you can choose your own manually.
>

I disagree with this. Except for going to IANA - or making it up - this is the
only thing that is used in IPv4.

Also, you might be interested that we are working on instantiating eGLOP - see

http://www.apnic.net/docs/policy/proposals/prop-047-v001.html  -

similar proposals have been sent to RIPE and ARIN.

> >    seen  V6UPBM  (RFC  3306)  and  "Embedded  RP"  (RFC  3956) as similar
> >    proposals for IPv6.
>
> Yep.
>
> >    However,  I  am  still  not  clear  of the "reality" of IPv6 multicast
> >    address  assignments  especially  with  regards to globally unique (by
> >    organization, domain, site, etc.) inter-domain multicast.
>
> We're using RFC3306 and Embedded-RP group addresses for international
> IPv6 multicast applications.

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

> For 3306 you don't need an authority to hand it out, it's just there for
> you to use implicitly by the format.
>
> A growing base of routers support Embedded RP... we've run that between
> the UK and US academic networks; all router son path (mainly Cisco and
> Juniper) support it.   No RP required :)
>
> >    "DITO  is  having  some concerns with IPv6 multicast address space and
> >    how  it  should  or  should  not be provisioned.  You should start the
> >    study  with  regards  to  how  IPv4 multicast addressing worked in the
> >    past.   If  you  ever  worked  with  it you would know there was never
> >    official  group  reservations  made  with  regards  to address blocks.
> >    However,  this  was  never a real issue since its popularity died.  So
> >    except  for  what  was deemed to be the well-known addresses there was
> >    never  any  reservations, unlike how unicast is reserved.  One thought
> >    might be the Army gets a block of addresses, Navy, and so on."
>
> 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

> And with a lot of /64's in an IPv6 site, you can (as we have) assign an

Most assignments are /48s

> RFC3306 group range per application if you chose to do so.
>
> The other nice thing about v6 multicast is the explicit scoping bits, which
> make it easier to control where your traffic flows.
>

Yes. I expect more in the future here.

> --
> Tim

Regards
Marshall

> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim
>

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 23 Feb 2007 07:53:17 -0500

Hello;

On 2/23/07, Tim Chown <[email-masked]> wrote:
> On Thu, Feb 22, 2007 at 08:36:39PM -0500, Marshall Eubanks wrote:
> >
> 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.
>
> 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.
>
> 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.)

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
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 23 Feb 2007 00:18:34 +0000

Yep.

>    address  assignments  especially  with  regards to globally unique (bFrom [email-masked] Fri Feb 23 08:13:45 2007
Date: Fri, 23 Feb 2007 00:18:34 +0000
From: Tim Chown <[email-masked]>
To: "Gibbons, James" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [magma] Re: [pim] IPv6 Inter-domain Multicasting and Address
	Assignments

 

Yep.

 

 

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 23 Feb 2007 08:35:06 +0000

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 23 Feb 2007 08:35:06 +0000

-- 
Tim

a4248793
X-Mailman-Approved-At: Fri, 23 Feb 2007 08:13:29 -0500
Cc: [email-masked], [email-masked], "Gibbons,
	James" <[email-masked]>
Subject: [magma] Re: [pim] IPv6 Inter-domain Multicasting and Address
	Assignments
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

 

-- 
Tim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 26 Feb 2007 08:19:43 +0100

> 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