Subject: RE: IESG review comments on ULA draft

From: "Christian Huitema" <[email-masked]>
Date: Fri, 2 Jul 2004 09:05:13 -0700

Me too. Let's ship this draft.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Brian E Carpenter
> Sent: Friday, July 02, 2004 8:21 AM
> To: [email-masked]
> Subject: Re: IESG review comments on ULA draft
> 
> I concur. The split is goodness.
> 
>     Brian
> 
> Margaret Wasserman wrote:
> >
> > 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
networks.
> >
> > (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 organizations.
> >
> > (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.
> >
> > Margaret
> >
> >
> >
> > At 4:49 PM -0400 6/29/04, Brian Haberman wrote:
> >
> >> All,
> >>      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
> >> scheme.
> >>
> >>      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.
> >> Regards,
> >> Brian & Bob
--------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------