[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
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
>ipv6@ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------