RE: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48 and ULA multicast scope matching ...

["John Spence" <spence@commandinformation.com>]

Comments inline Gunter.

-----Original Message-----
From: Gunter Van de Velde (gvandeve) [mailto:gvandeve@cisco.com] 
Sent: Friday, March 09, 2007 1:37 AM
To: John Spence; v6ops@ops.ietf.org
Subject: RE: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48
and ULA multicast scope matching ...

Many thanks for your words and to read the -addcon- document again.

>> Hey - fun to participate.  Good document too - nice work (et. al.)! 

Comment #1:

We can add a phrase saying that different masks could be generated. That
is assuming the WG agrees that a statement needs to be added in the
document. As Fred mentioned earlier today there is no restriction in
using ULA and generating the # of prefixes that are needed for a private
network.

>> I think it would have been better for the ULA spec to have a sentence
saying there is nothing to keep an enterprise from modifying the process
in order to generate a shorter ULA prefix, if that is what they want.
Since they didn't, then I think it reasonable that we point that out
here, as well as pointing out that they can also generate multiple /48s
following the documented process if they don't mind them not
summarizing.  Seems like reasonable guidance.

>> How about something like:

"ULAs are, per the specification, normally /48 prefixes.  Note that a
larger organization with, for example, a /44 allocation, that wanted to
be able to map ULAs one-to-one with global prefixes, could generate 16
ULAs.  These would not summarize, however.  It seems reasonable that the
organization could also simply generate a /44 ULA, by using fewer than
40 bits (36 bits in this example) of the "Global ID" specified in RFC
4193."

Comment #2:

You are exactly pointing at one of the issues with ULA's. ULA's did not
exist before some RFC's came out, there could be issues as the one
specified in the text. Do you think that fact should be made more clear
in the text?

>> I don't know how these things are usually handled.  Is it safe to
assume that implementers reading RFC 3484 will all build their
implementations to give ULAs similar treatment to site-locals?  Will the
IETF start a "3484bis" in order to address ULA?

>> It seems like, for guidance, adding one or two more sentences would
make it a bit more clear.  Perhaps something like this added to the back
of the paragraph beginning "As an example of the problems ...":

"Note that scope matching of unicast source and multicast destinations
is done properly for (now deprecated) site-local addresses, as described
in RFC 3484.  It is expected that, over time, this feature will also be
afforded to ULA scope matching.  In the near term, however, implementers
are cautioned that many deployed devices do not distinguish ULA from
global-scope addresses, leading to the deployment issue cited above."

Groetjes,
G/

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of John Spence
Sent: Thursday, March 08, 2007 7:33 PM
To: v6ops@ops.ietf.org
Subject: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48 and
ULA multicast scope matching ...


Hello Gunter, et. al.;  two comments:

1) Section 2.2, regarding ULAs, they are indeed defined as /48.  I
suggested to the ULA RFC writers that the length be relaxed, allowing
for ULAs of any prefix length, such that an organization that had, say,
a /44 routable could also generate a /44 ULA.  The only impact would be
to increase the odds of collisions later if two organizations merged.
The writing team decided not to put that into the RFC, but did say on
the mailing list that since ULAs are internal, there is nothing to stop
an organization from doing just that.

Perhaps in the addconn draft we might make a statement to the effect
that an organization could choose to self-allocate a shorter-than-/48
ULA to match a shorter-than-/48 global allocation, if they chose,
subject to the caution on collisions noted above.

We did discuss this back in March 2006
(http://psg.com/lists/v6ops/v6ops.2006/msg00137.html), and thought
perhaps a note in the text would be appropriate as background, but leave
the emphasis on /48 since that is "per spec".  Just wanted to mention it
again to make sure it was not lost.

2) also Section 2.2, regarding multicast, the text states that:

"As an example of the problems ULAs may cause, when using IPv6 multicast
within the network, the IPv6 default address selection algorithm prefers
the ULA address as the source address for the IPv6 multicast streams. "

Looking at RFC 3484, it says:

"We map unicast link-local to multicast link-local, unicast site-local
to multicast site- local, and unicast global scope to multicast global
scope.  For example, unicast site-local is equal to multicast
site-local, which is smaller than multicast organization-local, which is
smaller than unicast global, which is equal to multicast global."

The RFC does not mention ULA because ULA definition came later, and
site-locals were deprecated.  I would expect that an update of 3484
would apply the same logic for ULA, and, hopefully, implementers today
are implementing scope matching based on ULAs.

Is there another reference that states that ULA unicast source is always
preferred for multicast addresses, where the sending interface has both
ULA and global unicast addresses?

John Spence