Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 UnicastAddresses"

From: Geoff Huston <[email-masked]>
Date: Tue, 04 Nov 2003 13:14:55 +1100

Brian,

>My concern is really to get this in place reasonably quickly, and I think that
>means setting relatively clear guidelines for IANA rather than leaving the
>field open for endless debate.

I believe that you and I are in agreement here Brian in a general sense,
but we possibly differ on what "relatively clear guidelines for IANA".

I do _not_ think that the current draft has these properties, and I am
voicing the view that a further revision of the draft is appropriate
as per my comments already on this topic.

>It's kind of hard to write down "avoid a gold rush" as an intended
>outcome of an RFC, but in fact I agree with the direction of the suggested
>text changes in your message cited above, except that I don't see how to
>avoid a single authority and therefore a natural monopoly... which
>is definitely not an IETF issue.

And I'm advocating the view that the document can be further revised
such that it can provide reasonable guidelines to IANA without getting
into "gold rush" space and without getting into "anti-trust" space, and
I would rather that this document were revised a further cycle to
correct this before its passed to the IESG as a WG output.

regards,

    Geoff

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

---

From: Raul Echeberria <[email-masked]>
Date: Wed, 05 Nov 2003 18:37:15 -0300

At 08:10 22/10/2003, Brian Haberman wrote:
>This is a IPv6 working group last call for comments on advancing the
>following document as an Proposed Standard:
>
>         Title           : Unique Local IPv6 Unicast Addresses
>         Author(s)       : R. Hinden, B. Haberman
>         Filename        : draft-ietf-ipv6-unique-local-01.txt
>         Pages           : 15
>         Date            : 2003-9-24
>
>Please send substantive comments to the ipv6 mailing list, and minor
>editorial comments to the authors.  This last call period will end on 5
>November 2003.

Comments:

- section 3.2 of the document includes recommendations on fees that are not 
appropriated to be included in a Proposed Standard. The document should 
limit to recommend the establishment of a central registry and suggesting a 
fee in a recovery basis fashion.

- section 13.0 is not clear in the requirements under which the IANA should 
design the central authority.

- While my first thought is that unique local IPv6 Unicast Addresses would 
be useful, I have realized that there are still serious doubts on this 
point and the impact of the introduction of them.

Based on these considerations, I think that more discussion on this 
document is necessary.

Regards,

Raul Echeberria
LACNIC

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Nov 2003 14:35:41 +0200 (EET)

> 	Filename	: draft-ietf-ipv6-unique-local-01.txt

FWIW, I have not reviewed the document in detail at this point, but I must
echo the concerns raised by others (Erik, Alain in particular).

Btw. one particular place where the document probably needs a lot of
improvement is the specification or description on _how_ exactly these
packets should be discarded at site borders.  Blackholing ("silent
discard") the packets would be HIGHLY disadvantageous, because an address
leak or similar leads to falling back to something like TCP timeout, and
the apps/stack cannot fail back to use the next address.

Btw.2, the document requires a Table of Contents, it's 15 pages.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sun, 9 Nov 2003 20:49:40 +0900 (JST)

> > 	Filename	: draft-ietf-ipv6-unique-local-01.txt

	i object to publish this document as a standard track document.
	experimental would be more preferable.

	unique local IPv6 unicast address avoids some problems of site-local,
	but not all; there are major problem still remains.
	- it is not expected to be routable, however, it will be treated
	  as if it is a global address.  therefore it is likely to be leak out.
	  1.0 asserts that "even if it leaks out there's no conflict", but
	  "no conflict" is not enough - we do need to be 100% sure there's no
	  leak out, otherwise it is unacceptable.
	- operationally, there's a much easier way to get a block of address
	  which has the features unique local IPv6 unicast address has;
	  it is to use 6to4 address prefix (2002:v4v4:v4v4::/48).  as long as
	  you do not renumber IPv4 address and IPv6 address at the same time,
	  6to4 address will give you enough address for the suggested use of
	  unique local IPv6 unicast address.  moreover, 6to4 address are
	  routable (though there's tunnelling overhead if outsiders are to
	  contact 6to4 address accidentally).  there is no need to define
	  unique local IPv6 unicast address.

	some may object on the 2nd point, like "when I don't have IPv4 address
	what should I do?".  well, IPv6/v4 dual stack operation will continue
	for ages so i do not consider it a problem.

itojun

---

From: Tim Chown <[email-masked]>
Date: Sun, 9 Nov 2003 12:51:37 +0000

> 	  leak out, otherwise it is unacceptable.

I don't think we'd ever get 100% confidence of zero leakage, but that shouldn't
deter us from having a site-local addressing scheme that at least cures the
other major problem of ambiguity in the addresses.  I think the Hinden draft 
can only fix the ambiguity problem.   But if people use Hinden-draft the
leakage is more readily traced.

> 	for ages so i do not consider it a problem.

What about the ambiguity where the network is disconnected or intermittently 
connected and the site only has Net10 IPv4 addresses?   The Hinden draft at 
least allows such networks to merge or temporarily interconnect for IPv6 
with a good assurance of there being no address clash.  Or are you suggesting
you would always have to reconfigure for the Net10 clash anyway?

It is also the case that many networks with an IPv4 address have a dynamic
address, so your local IPv6 addresses would not have the desirable property of
being stable (they are not "provider independent" unless the IPv4 address is
also a PI one).
 
I think any scheme defined now should be designed with IPv6-only operation
also in mind.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 19:52:08 +0100

itojun,

Tim has replied technically.

I would object to this being published as Experimental. That would be
the worst solution, since nobody would have any idea whether it was safe
to use it. I'd rather we simply started misusing PA or, indeed, 6to4 
space to solve the operational problem. In fact, that is simply bound
to happen unless the IETF resolves this quickly.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Sun, 09 Nov 2003 14:40:39 -0800

Itojun,

>         experimental would be more preferable.

I don't agree.  I think this is appropriate for standards track.

>           leak out, otherwise it is unacceptable.

I don't think we have to be 100% sure.  Overall I think it is much better 
to have a well known non-ambiguous prefix that we can have a reasonable 
likely hood that it is filtered.

>           unique local IPv6 unicast address.

This approach doesn't work well for disconnected sites who may not have a 
global IPv4 address.  I suspect they would use Net 10 IPv4 addresses.  This 
would, of course, result in ambiguous prefixes like site-local.  Something 
we are trying to move away from.

Bob

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 10 Nov 2003 15:38:46 -0600

Thus spake "Alain Durand" <[email-masked]>
> Brian E Carpenter wrote:
> >I meant PA because that is all that is in the implementors and
> >registries' hands today. Actually any form of PI would do (they are
> >all equally unrouteable today). I regard the Hinden/Haberman addresses
> >as an easy-to-create form of PI.
>
> I meant traceable, potentially routable PI. Hinden/Haberman addresses
> are not traceable (in the sense that looking at the prefix I can tell
> who it belongs to), and this is a big difference.

I also object to this part of the draft as well.  IMHO, the registry should
list who the registrant is for a particular prefix, but not allow non-exact
searches.  Reverse DNS should also be available if particular registrants
want to list servers.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Nov 2003 22:55:04 +0100

Stephen Sprunk wrote:
> searches.  

I think there are privacy and secrecy-by-hiding reasons why this most
likely won't happen, for *any* form of unrouted organizational addresses.
The escrow proposal is to allow this privacy to be bypassed in extreme
cases.

> ...Reverse DNS should also be available if particular registrants
> want to list servers.

By definition, organizational addresses are not used to "list" servers
outside the organization. Obviously, the organization's internal DNS will
have to treat these addresses as first-class citizens, but I can't see any
reason why we would expect reverse DNS for these things in the global
DNS.

   Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 10 Nov 2003 16:14:15 -0600

Thus spake "Brian E Carpenter" <[email-masked]>
> ...

My case is this: I believe many orgs will use "local" addresses to
interconnect with other orgs via private links, but not via the Internet.
In this case, it would be handy to _optionally_ have reverse DNS entries in
the public servers so that the mesh of private orgs don't have to muck with
adding each others' local address zones into all their DNS servers.  Of
course, this would be an optional feature for orgs registering local
addresses, but I don't see a reason to _prohibit_ it.

S