Subject: Re: IESG review comments on ULA draft

From: Tim Chown <[email-masked]>
Date: Fri, 2 Jul 2004 01:44:18 +0100

On Thu, Jul 01, 2004 at 07:48:29AM +1000, Geoff Huston wrote:
> 
> As this is a working group document I would like to understand on what 
> basis this decision was taken. I could be mistaken here but I would've 
> thought that it would be reasonable for the working group chairs to seek 
> the views of the working group before making changes to a working group 
> document. The basis for my concern here is that I see this splitting of the 
> document into two as an action that appears to take a fundamental problem 
> of assured address uniqueness and turns it into what could be loosely 
> characterized as a random free-for-all. I'm personally unconvinced that 
> what appears from the outside to be short term expediency on the part of 
> the WG Chairs should be an acceptable substitute for, at the very least, 
> seeking the views of the working group prior to making such decisions.

Geoff,

The pre-split draft had both unique ("registry assured") and probabilisticly
unique ("random") prefix generation methods, so I don't think the split of
the draft is creating a new problem as such.   As one of the people who was
in favour of the split (back at Minneapolis) I didn't like a draft titled
"Unique Local" having a method included that might not offer a unique local
prefix.  So I think the split is useful in that respect.

If it stayed as one draft, a title change would have been appropriate (e.g.
Obtaining IPv6 Prefixes for Local Address Domains" or something like that).

Tim

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 2 Jul 2004 08:06:43 -0400

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
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Jul 2004 17:20:41 +0200

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.
> 
> enterprises considering the deployment of IPv6.  Enterprises need some 
> form of stable addressing for internal use, for example on VPN networks.
> 
> replace those addresses with a (probabilistically) unique form of local 
> addressing.
> 
> 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.
> 
> (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
> 
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Jul 2004 12:56:56 -0400

Hi Brian.

A little more background:

> provided comments on the ULA draft.

This feedback came as a response to some specific questions I
forwarded to the RIRs. The response came from Paul Wilson, of APNIC,
but was from the RIRs as a whole. Specifically, he said:

"Paul Wilson" <[email-masked]> writes:

> Thanks for passing these questions to the RIRs.  I am answering in the name
> of the Number Resource Organisation (NRO), representing the RIRs
> collectively.

More info on the NRO can be found at http://www.nro.net/

Thomas

---

From: Geoff Huston <[email-masked]>
Date: Sat, 03 Jul 2004 07:53:23 +1000

Thanks for your comments Margaret  - I have a clearer understanding of the 
line of thinking here after reading your note.

One  comment I have here relates to the DNS section of the draft includes 
the provision of inclusion of PTR entries in the global 0.0.d.f.ip6.arpa 
(reverse)  DNS domain. Presumably this is a First Come First Served open 
delegation process that allows anyone to enter a delegation record into the 
parent zone file for their self-drawn prefix - yes? Are there any concerns 
regarding potential abuse of such an open delegation process, and, if so, 
what form of operational management of this domain would be appropriate here?

regards,

   Geoff

---

From: Brian Haberman <[email-masked]>
Date: Tue, 06 Jul 2004 06:32:10 -0400

Geoff Huston wrote:

> Thanks for your comments Margaret  - I have a clearer understanding of 
> the line of thinking here after reading your note.
> 
> One  comment I have here relates to the DNS section of the draft 
> includes the provision of inclusion of PTR entries in the global 
> 0.0.d.f.ip6.arpa (reverse)  DNS domain. Presumably this is a First Come 
> First Served open delegation process that allows anyone to enter a 
> delegation record into the parent zone file for their self-drawn prefix 
> - yes? Are there any concerns regarding potential abuse of such an open 
> delegation process, and, if so, what form of operational management of 
> this domain would be appropriate here?

The reference to PTR entries was originally added to the combined draft
for the centrally allocated addresses.  I am not sure if they are
appropriate for the locally-allocated prefixes.

If someone with more operational DNS experience has suggestions, I am
more than willing to listen to them. :)

Regards,
Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 6 Jul 2004 10:25:10 -0500

Thus spake "Brian Haberman" <[email-masked]>
> appropriate for the locally-allocated prefixes.

When I made the suggestion, my intent was that centrally-assigned prefixes
could be (optionally) added to the global reverse tree, but locally-assigned
prefixes would only be added to a local reverse tree.  Given the
inevitability of collisions in the locally-assigned space, it doesn't seem
logical to allow them in the global reverse tree.

> more than willing to listen to them. :)

Particularly someone with experience doing split-horizon DNS service for
RFC1918 addresses.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Jul 2004 08:56:00 +1000

> CCIE #3723         are a great annoyance to those of us who do."

	Well I don't know where those zeros are coming from.  The
	DNS suffix is D.F.IP6.ARPA.  I would actually recommend
	that every nameserver be configured to swallow this suffix
	with the ability to override if needed.

	This will stop the IP6.ARPA servers being swamped by leaking
	queries in the way the IN-ADDR.ARPA servers were being swamped
	by reverse queries for RFC 1918 space.

	A simple empty zone (SOA and NS records only) will do this.
 
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Jul 2004 09:52:57 +0200

Stephen Sprunk wrote:
...
 > ... Given the

There is no inevitability - on the contrary, there is a very low
probability. But I agree with the conclusion, since I don't think
either kind of ULA has any business in the global DNS.

   Brian

---

From: Geoff Huston <[email-masked]>
Date: Mon, 12 Jul 2004 15:49:25 +1000

>either kind of ULA has any business in the global DNS.

But we appear to be on last call with a document that recommends
all flavours of ULA can have PTR records in the global DNS.
(and the collision probability for locally assigned ULA's PTR records
is the birthday probability, which exceeds 0.5 for 1.24 million entries.)
i.e.  at least for the local assigned ULAs global DNS PTRs appears to
me to be something you don;t want to put in the global DNS.

  Geoff

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 12 Jul 2004 10:39:17 -0500

Thus spake "Geoff Huston" <[email-masked]>
> me to be something you don;t want to put in the global DNS.

I never intended locally-generated addresses to be in the global DNS, either
forward or reverse, but there is nothing wrong with them being in a local
DNS (via split horizon) if desired.  At least some of the text applying to
centrally-assigned addresses is only in the locally-generated draft and
should have been moved, copied, or modified.

Did I miss the split drafts being circulated on this list before they were
sent for Last Call?

S