[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IESG review comments on ULA draft

Hi All,

I support the idea of splitting this draft into two portions for 
several reasons.

First, some facts as I understand them:

(1) The uncertainty regarding the status of unicast site-local 
addressing and its eventual deprecation has caused concerns for 
enterprises considering the deployment of IPv6.  Enterprises need 
some form of stable addressing for internal use, for example on VPN 

(2) Over a year ago, the IPv6 WG reached consensus to deprecate the 
non-unique ("scoped") form of unicast site-local addresses and to 
replace those addresses with a (probabilistically) unique form of 
local addressing.

(3) The randomly generated form of ULA addresses provides a super-set 
replacement for unicast site-local addresses.  It allows local 
addressing without the need to obtain addresses from any registration 
authority, and those addresses can be used throughout the site.  It 
has three advantages over the scoped form of unicast site-local 
addressing:  (a) There is a vanishingly low probability of collision 
when two organizations merge and combine local networks, (b) a host 
can belong to two local networks at the same time (for example, home 
and VPN) without the need to change application-level software, and 
(c) the probable uniqueness of these addresses makes them convenient 
for secure "extranet" deployments -- VPNs shared between 

(4) It will take a long time to finalize the document that defines 
the registered ULA addresses.  Due to lack of experience, I didn't 
understand this fact originally or I would have suggested splitting 
the draft earlier.  It was you (Geoff) and Thomas who raised my 
awareness of the complexity of standardizing any type of registered 
addressing -- both of you pointed this out to me in Seoul, indicating 
that it would take at least six months to a year to get a document 
that includes registered addresses approved, but it took me a couple 
of months to realize that you were correct.

Now some conclusions:

While I consider the registered form of ULA addresses to be useful 
and I think that we should standardize them, they are completely 
separable from the randomly allocated form of ULA addresses (each 
uses one half of a 7-bit prefix, AKA a separate 8-bit prefix).

IMO, it would be a shame for the randomly selected ULA addresses to 
be held up in IESG approval for a long time, just because the same 
document contains a registered form of addressing.

By separating these two portions of the document, we can achieve two 
good things:

(1) The randomly assigned ULA addresses (which offer a full 
replacement for scoped unicast site-local addresses) can be approved 
soon. I'm hopeful that we can get this approved before San Diego if 
the document is ready to go at the end of IETF Last Call.  If not, 
then soon after San Diego.

(2) The registered ULA addresses can proceed on their own schedule. 
We can consult with the IAB and registries and get this document 
right, without the pressure to approve this document quickly in order 
to replace scoped site-local addresses.


At 4:49 PM -0400 6/29/04, Brian Haberman wrote:
>      As a part of the IESG review, a member of the RIR community has
>provided comments on the ULA draft.  I will posting those comments to
>the mailing list as separate notes shortly.  As a part of that review,
>Bob & I made the decision to split the ULA draft into two drafts.  One
>draft discusses only the locally allocated addresses.  The second draft
>discusses the centrally-allocated addresses.  This was done to allow
>the locally-allocated addresses to move through the review process
>without getting hung-up on comments/issues with the central allocation
>      The comments to follow are focused on the central allocation of ULA
>addresses.  So, the local allocation draft will continue through the
>IESG review process.
>Brian & Bob
>IETF IPv6 working group mailing list
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6