Subject: Re: RFC 2529 (6over4)

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 5 Aug 1999 10:49:10 -0400 (EDT)

>From: Brian E Carpenter <[email-masked]>
>
>Apart from that I think Cyndi has replied just about as I would
>have done, if she hadn't got there first. Sowmini, do you think
>there is any urgency to revise the RFC?

I think some fixing is called for, before it goes to Draft Standard. 

One concern though  is the dependancy on RFC 2365- as Cyndi points out

cmj> I think TTL scoping for multicast has been found to be unworkable - but
cmj> is still a poor man's scooping tool.  There is still work being done in
cmj> deploying the admin scoping, ...

But, until 2365 is widely deployed, all testing will have to rely on 
TTL scoping of multicasts, and this has ramifications on product planning. 

What do you think? 

--Sowmini
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Aug 1999 17:07:40 -0500

Sowmini Varadhan wrote:
...
> TTL scoping of multicasts, and this has ramifications on product planning.

Frankly, multicast itself is not that widely deployed. I'd be
reluctant to specify a bad solution on the grounds that the good
solution is too new.

  Brian

---

From: Cyndi Jung <[email-masked]>
Date: Fri, 06 Aug 1999 11:44:48 -0700

There are many myths about the actual deployment of IP multicast.
It is difficult for me to assess he true extent of deployment.
Our corporate network has been multicast enabled for years, and
we periodically blast the face of the president (or some other
executive) across the network for people world-wide to witness
from the comforts of their office - I don't know if that counts 
for you.

It is clearly having a major struggle in the inter-domain - those
problems are not going to be solved easily.  However, 6over4 is
probably not an inter-domain solution, rather an intra-domain, which
is why the admin scope of organization-local was chosen.

As to the deployment of admin scoping, it is deployable via filters
in reasonable implementations of IP multicast, and is independent
of any particular multicast routing protocol.  Even if you are using
simply DVMRP and MOSPF the filters can be configured.

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Fri, 06 Aug 1999 16:23:56 -0400

Cyndi,

Here is the bottom line.  If 2365 is not on the street now after some
time.  We have to make choices as vendors which transition mechanisms we
deploy first, next, and next++++.  If we can use 6over4 with the
multicast that is out there today then I think it has a good chance to
hit deployment for "first" or "next" if it requires 2365 as the spec
says now with no statements other than that then its "next++++" we are
better off letting customers  use configured tunnels and using natpt,
siit and other mecahanisms intially.

I will not support using 6over4 to get 2365 deployed either.

/jim

---

From: Cyndi Jung <[email-masked]>
Date: Mon, 09 Aug 1999 16:38:04 -0700

Jim,

2365 is not a protocol - it is a "best common practise", an agreement
on the division of the class-D address space into scopes.  The part
that does work already is organization-local, because IP multicast works
already within an organization - it is the global scope, the inter-domain
part, that is still a mess. Fortunately, organization-local scope
multicast addresses do not require global coordination like the
global scope addresses do - they are sort of a "net10" of the class-D
address space.

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 00:06:07 -0400

hi Cyndi,

>global scope addresses do - they are sort of a "net10" of the class-D

I understood that.  But until folks support the inter-domain whats the
default?  I think its based on the TTL?

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 20:55:08 -0400

Cyndi,

>global scope addresses do - they are sort of a "net10" of the class-D

I think my point was missed and I let it go in my last response to this
but decided to put a bit more energy into this specific issue:

In rfc2529:

>6. Address Mapping -- Multicast
>
>   IPv4 multicast MUST be available. An IPv6 packet with a multicast
>   destination address DST MUST be transmitted to the IPv4 multicast
>   address of Organization-Local Scope using the mapping below.  These
>   IPv4 multicast addresses SHOULD be taken from the block
>   239.192.0.0/16, a sub-block of the Organization-Local Scope address
>   block, or, if all of those are not available, from the expansion
>   blocks defined in [ADMIN].  Note that when they are formed using the
>   expansion blocks, they use only a /16 sized block.
>
>        +-------+-------+-------+-------+
>        |  239  |  OLS  | DST14 | DST15 |
>        +-------+-------+-------+-------+
>
>        DST14, DST15        last two bytes of IPv6 multicast address.
>
>        OLS                 from the configured Organization-Local
>                            Scope address block.  SHOULD be 192,
>                            see [ADMIN] for details.
>
>   No new IANA registration procedures are required for the above.  See
>  appendix A. for a list of all the multicast groups that must be
>   joined to support Neighbor Discovery.

If I send a 6over4 packet to 239.OLS.DST14.DST15 (above) will the
multicast router implementations today forward that packet past the IPv4
subnet the message went out on based on the administrative scoping
suggested in 6over4 via rfc2365.txt.

If not what is the point of putting this mechanism into my IPv6 product
today, vs other items on the plate, if it can't be used.

thanks
/jim

---

From: Cyndi Jung <[email-masked]>
Date: Tue, 10 Aug 1999 19:13:13 -0700

>suggested in 6over4 via rfc2365.txt.

Yes - they will forward it to all subnets towards all members of that
group 239.OLS.DST14.DST15 on the 6over4 subnet.  This means, to receive
NS frames, the V6 node with V6 address ending in DST14.DST15 must join
the V4 group 239.OLS.DST14.DST15, then for all the IP multicast routing
protocols I know of (DVMRP, MOSPF, CBT, PIM), any NS packet sent by
another system will get delivered to that node.

If the admin scoping is not enforced, then these V4 multicast addresses
would get forwarded further than you might want, rather than not forwarded.
It is the 224.0.0.X class-D addresses that do not get forwarded past the
subnet they were transmitted on.

Does this help?

Cyndi

>today, vs other items on the plate, if it can't be used.

I think that without scoping these become global, though I think that the
current MBONE rules will at least confine this to your intra-domain.  The
issue of non-enforcement within your intra-domain means that you can have
only one 6over4 subnet, and I think that at the point where you have so
many systems on it that you want to break it into multiple 6over4 subnets,
you can probably "go native".

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 22:47:41 -0400

Cyndi,

helps me alot.  If 239.OLS.DST14.DST15 will get to the IPv6 router via
intradomain based on products deployed today that is very good.

The inter-domain leaking would be a problem once this got deployed.
Probably need a fix for that? 

thanks
/jim