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

From: Zefram <[email-masked]>
Date: Wed, 22 Oct 2003 14:05:57 +0100

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

That should be draft-ietf-ipv6-unique-local-addr-01.txt.

Section 3.1 is still written from the point of view of having no
definitely determined format prefix, which is appropriate for discussion
but not in a Proposed Standard.  It should be changed to state exactly
what prefix is to be used.  I don't think anyone's objected to fc00::/7.

Section 3.2: "The Global ID is split into two parts for each type of
allocation." should be "The Global ID space is split into two parts,
one for each type of allocation.".

Section 3.2.2/3.2.3: I *think* I understand what is intended by the phrase
"a functionally similar algorithm", but I think it would be worthwhile
giving a second example algorithm, to give some idea of the latitude
that is intended.  My understanding is that "(ntpdate -qd localhost;
ifconfig) | md5sum | cut -c1-10" would be an acceptable implementation,
although it differs in many details from the algorithm of section 3.2.3.

Section 3.2.4: the probabilities quoted such as "4.54**-11" are presumably
intended to be "4.54*10^-11" and so on.

All the top-leve section numbers have a ".0" appended that doesn't
belong there.

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Oct 2003 17:51:37 +0200 (CEST)

> 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

I assume the last call is on the draft named
draft-ietf-ipv6-unique-local-addr-01.txt

>          - In practice, applications may treat these address like global
>         scoped addresses.

I don't see how this can be true in general.
Here is an example using referrals; the three nodes involved are A, B, C.
Node A and B are in the same site, have both local and global addresses,
and C is in a different site.

Node A and B are communicating using these local addresses.
In particular, B contacted A using FQDN(A) and the naming system somehow
so that they ended up communcating with local addresses. (My understanding
is that part of the benefit of these local addresses is that local
communication prefer using local addresses over global addresses.)
As a result the only thing A knows about B is its local address AL(B).

C contacts A using A's global address.
Node A needs to refer C to communicate with B; it sends B's address (AL(B))
to see. But C can't reach that address since it is not in the same site.

This type of problem doesn't appear when using global addresses even
if each node has multiple global addresses.
Thus I don't think the above statement and section 8 in the document are 
incorrect.

The fundamental difference between unique local addresses and global
addresses is that the former are permentently unreachable by design
(except from the local domain) whereas the latter might be temporarily 
unreachable due to some failure.
I believe this means that applications need to be aware of the difference
between the two types. 
Hence not ready for proposed standard IMHO.

BTW: what is the expected interaction between this and mobile IPv6?
Is it different for mobile nodes that move within their home site, and
mobile nodes which move outside their home site?

   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Oct 2003 20:58:50 +0200

On 22 okt 2003, at 17:51, Erik Nordmark wrote:

>>          - In practice, applications may treat these address like 
>> global scoped addresses.

> Here is an example using referrals; the three nodes involved are A, B, 
> C. Node A and B are in the same site, have both local and global 
> addresses, and C is in a different site.

> In particular, B contacted A using FQDN(A) and the naming system 
> somehow so that they ended up communcating with local addresses. (My 
> understanding is that part of the benefit of these local addresses is 
> that local communication prefer using local addresses over global 
> addresses.)

Yes, but how???

A simple method would be to check the first 48 bits of the IP addresses 
that are suspected of having "local" reachability. But this doesn't 
allow for the merging of two sites, which was presented as a rather 
prominent requirement during the site local wars (or at least the part 
I got to witness).

I don't believe two-faced DNS is a solution, because then the DNS 
server must know all the information the hosts are apparently unaware 
of, and know the exact reachability details of each possible pair of 
hosts to boot. I expect both internal information to leak out and 
internal hosts to be presented with external information only in many 
situations.

A solution could be giving hosts access to local routing information. 
Is this something we want? Or do we drop the site merger without 
renumbering thing and work on renumbering instead?

Note that these problems don't disappear once we sprinkle them with 
magic loc/id separation powder: it's still entirely possible for the 
system to choose a locator that doesn't work. But at least this is a 
problem that can be corrected somewhere lower (below the application) 
in the stack and optimized there, rather than dump the problem on 
applications and hope those will do the right thing after TCP times 
out.

> I believe this means that applications need to be aware of the 
> difference between the two types.

There is another problem: the global routability of these addresses is 
completely ambiguous. First the draft says "the scope is global". Then 
"don't expect them to be routable" and finally "filter them".

This is no good. Today, there is no difference between addresses that 
are unroutable by design, and addresses that are unroutable because of 
limitations in the routing system. But as the routing system evolves, 
this is subject to change. Suppose we build a locator/identifier 
separation mechanism, and some people start using these addresses as 
stable identifiers, while others use them as local-only addresses. This 
is going to create a huge mess as part of this address space must now 
(still) be filtered, while another part must be allowed through 
_everywhere_ in the world.

So my question is: are unique local IPv6 unicast addresses unroutable 
by design yes or no?

Iljitsch van Beijnum

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Oct 2003 18:26:12 -0400

Summary:

- I do not think it is appropriate to publish this document as Proposed
  Standard at this time.  

- I believe the structure of these addresses and means of assigning
  prefixes are basically sound.  However, I have several problems with 
  sections 7 on.

- I would support publication of this document as Experimental if it
  were revised to include only the sections on address structure and
  assignment of prefixes, and omit the sections describing how the
  authors expect these addresses to be *used* either in DNS or by
  applications.

----------------------------------------------------------------------

> 7.0 DNS Issues
> 
>    AAAA records for Local IPv6 addresses SHOULD NOT be installed in
>    the global DNS.  

Trying to impose scope on DNS is not technically sound.  Applications,
(including but not limited to DNS) are not aware of scope boundaries
and will leak addresses (including DNS query results) across those
scope boundaries.  Applications operating across scope boundaries need a
consistent view of DNS in order to function properly.  

>    If Local IPv6 address are configured in the global DNS, no harm is
>    done because they are unique and will not create any confusion. 
>    They may not be reachable, but this is a property that is common to
>    all types of global IPv6 unicast addresses.
> 
>    For future study names with Local IPv6 addresses may be resolved
>    inside of the site using dynamic naming systems such as Multicast
>    DNS.

Multicast DNS is a very dubious concept which should not be endorsed
by this document.  In particular, it suffers from the same severe
technical flaw (among others) that this section does - that it
is acceptable for DNS (or a combined system consisting of DNS and mDNS)
to present different views of an RRset or zone to different portions of 
the network, when applications quite reasonably expect DNS to be 
consistent (modulo skew between different versions of a zone at
different servers).

> 8.0 Application and Higher Level Protocol Issues
> 
>    Application and other higher level protocols can treat Local IPv6
>    addresses in the same manner as other types of global unicast
>    addresses.  No special handling is required.  

I do not believe this to be the case; or at the very least, this is a 
gross oversimplification for the case of apps that do referrals
(for instance, any app that uses DNS).  Some apps will need to choose
an address that functions across all peers; use of local addresses
would fail more often than globals.  Some apps are intended for local
use only and are less tolerant of prefix changes; these apps will want
to use local addresses in preference to globals.  

But even this is an oversimplification.

>    This type of addresses
>    may not be reachable, but that is no different from other types of
>    IPv6 global unicast addresses. 

Yes it is different, because the reasons for lack of reachability are
different.  When an app cannot reach peer using a global address, it's
reasonable to assume that this is either due to administrative
prohibition or a temporary routing or link failure.  (Administrative
prohibitions should be signalled with ICMP messages so that the app can
distinguish between these two cases; the fact that router/firewall
configurations often botch this doesn't justify propagation of that
error.)

>    Applications need to be able to
>    handle multiple addresses that may or may not be reachable any
>    point in time.  

This is also an oversimplification.   It's certainly not a reasonable
statement as written, because there are too many cases where expecting
an application to cope with multiple addresses is either onerous
(as in expecting every application to implement its own route 
advertisement, routing, and message forwarding) or infeasable (as in
expecting apps to route messages between pairs of hosts that
may not have any signal path between them).    

A more realistic statement is that applications need to be able to
distinguish between cases where the application can reasonably do the
job (because the network provides adequate connectivity) and  cases
where the application cannot reasonably do the job (because, for
whatever reason, the network fails to provide adequate connectivity). 
And if the connectivity isn't adequate, this needs to be described as a
consequence of network configuration - not a failure of the application.

> In most cases this complexity should be hidden in APIs.

It is naive to assume that this complexity can be hidden in APIs, at
least given facilities currently in the network,  because the decision
of which kind of address to use requires information that is not
available to the hosts.  The apps can supply hints as to their
preferences, but reasonable decisions require knowledge of both
network topology (e.g. which addresses are reachable from which parts of
the network) and the topology of the application (where are the current
and future peers that are part of the application located?)

>    From a host's perspective this difference shows up as different
>    reachability than global unicast and could be handled by default
>    that way.  In some cases it is better for nodes and applications to
>    treat them differently from global unicast addresses.  A starting
>    point might be to give them preference over global unicast, but
>    fall back to global unicast if a particular destination is found to
>    be unreachable. 

This is not a reasonable strategy for many, perhaps most, applications.
It makes assumptions about application behavior that aren't generally
true, and may be even less valid in the future.

>    Much of this behavior can be controlled by how they are
>    allocated to nodes and put into the DNS. 

It is not reasonable to make assumptions about applications' use of DNS;
in particular, it's not reasonable to assume that the scope in which a
DNS query was made is the same scope in which the results will be used.

>    Note that the address selection mechanisms of [ADDSEL], and in
>    particular the policy override mechanism replacing default address
>    selection, are expected to be used on a site where Local IPv6
>    addresses are configured.

Address selection by itself is woefully inadequate, and it cannot be
made adequate given either the existing APIs or the information that
is currently available to hosts about either the app or the network.

----------------------------------------------------------------------

The bottom line is this:

       >>> we don't understand how to make this work yet.  <<<

where "this" is having hosts advertise multiple addresses with varying
reachability.  The potential for "this" has always been there in IPv4,
and it's been tried from time to time, but in general, it never has 
worked well.  The difference is that whereas in IPv4 we could generally
give each host a single address and make it reachable from all points
of interest (modulo administrative prohibition), in IPv6 we're trying to
insist that multiple addressing be used as a matter of course and to
solve a variety of problems.  In other words, we're insisting that
something  that has been tried many times and has never worked before,
be made to work (presumably by pretending that the problem doesn't
exist, or that it's somebody else's - the application writer's -
problem).  

Basically this fails the "no known technical limitations" test.  

A document that defines formats for GUPIs and PUPIs is a good next
step, but it is not sufficient.  What we need to do is to set aside
this document (i.e. assume that it's fine as is, though it might need
tweaking later once we understand how to solve the real problems) 
and start actually trying to define a model that works.  

The model should consist of:

- rules for assignment of addresses to hosts (i.e. when to assign 
  locals, when to assign globals, or both)
- mechanisms to propagate information about which addresses are usable
  that actually do follow scope (e.g. via ND/RA)
- rules for selection of addresses (not merely address selection
  as it's currently thought of, but also considering things like 
  substituting a locally-known alternative for a global address 
  that is advertised in DNS or other referral mechanism)
- rules for address referrals (including but not limited to DNS)

As for what it means for the model to "work" I suggest the following:

- it should be possible to associate a token (or a short list of 
  tokens) with a host, so that the tokens can be used to unambiguously
  identify and reach that host, reliably and efficiently, from any 
  location in the network, provided the host is reachable  

- an application in possession of such tokens should be able to 
  quickly and reliably determine if failure to reach a host is due to
  administrative prohibition or lack of a routing arrangement
  (as opposed to a temporary condition such as a host or link failure)

- this token or list of tokens should be suitable for advertising in DNS
  (probably but not necessarily AAAA records) or via other referral
  mechanisms

- the binding between these tokens and their hosts should have 
  sufficient lifetime to allow them to be cached and to rid hosts
  and most apps of the burden of dealing with changing bindings

- the efficient and reliable use of those tokens or list of tokens 
  to communicate with current and potential peers should rely only on
  information that is easily available to hosts and apps using them.

- there should be a clear separation of function between application 
  responsibility, host responsibility, and network responsibility.

----------------------------------------------------------------------

>    In order for hosts to autoconfigure Local IPv6 addresses, routers
>    have to be configured to advertise Local IPv6 /64 prefixes in
>    router advertisements.  Likewise, a DHCPv6 server must have been
>    configured to assign them.

since when?  none of my v6 boxes require DHCPv6, and that's a Good
Thing.

>    In order for a node to learn the Local IPv6 address
>    of another node, the Local IPv6 address must have been installed in
>    the DNS. 

false.   not all apps use DNS as a means of learning peers' addresses,
nor do apps that do use DNS always use it exclusively.  nor would it be
desirable to impose that constraint.

>   For these reasons, it is straight forward to control their
>    usage in a site.

this does not follow because it's based on a false premise.

In general, I object to section 9 because it assumes (nay, imposes)
split DNS, which is highly undesirable and also nonstandard.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 23 Oct 2003 18:28:04 +1000

>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.

I do not believe that this document is ready for Proposed Standard.

My comments (both as suggested text corrections and as more
substantive comments on content) are as follows:

Section 3.2
-----------

"The centrally assigned global IDs have a much higher probability that
they are unique"

The intent of the central assignment function is to ensure uniqueness.
Therefore the wording should be:

"The centrally assigned global IDs are uniquely assigned"

Also:

"It is recommended that sites planning to use Local IPv6 addresses for
extensive inter-site communication use a centrally assigned prefix as the
possibility of any conflicts is lower."

should be re-worded as:

"It is recommended that sites planning to use Local IPv6 addresses for
extensive inter-site communication use a centrally assigned prefix as
there is no possibility of prefix assignment conflicts."

Section 3.2.1
-------------

"This to ensure that there is not any relationship between allocations and
to help clarify that these prefixes are not intended to be routed
globally."

Clumsy grammar and perhaps additional words are appropriate. Suggest
change to:

"This to ensure that there is no relationship between allocations and to
help clarify that these prefixes are not intended to be routed globally by
eliminating aggregation possibilities."

Also:

"This is easiest to accomplish if there is a single source of the
assignments."

and

"One time non-refundable allocation fee in the order of 10 Euros (at
January 1, 2004 exchange rates) per allocation."

I question the validity of specifying a single source coupled with service
fees in a document such as this. This appears to be creating regulatory
issues of establishing a global monopoly coupled with price fixing. An
alternate wording that may mitigate this to some extent is to change the
second sentence to remove this item from requirements, and instead phrase
this as a recommendation, namely:

"It is recommended that the registry operate using a service regime of a
single service fee per allocation bearing in mind that the service should
be accessible and affordable to small sites in all parts of the world."

Also:

"The reason for the one time 10 Euro charge for each prefix is to provide
a barrier to any hoarding of the these allocations but at the same time
keep the cost low enough to not create a barrier to anyone needing one.
The charge is one time to eliminate the need for an ongoing relationship
with the allocation authority.  The charge is non-refundable in order to
keep overhead low."

change to:

"The reason for the per-prefix allocation service fee is to allow the
service to operate on a financially sustainable basis. A service fee also
creates an externality of a barrier to any hoarding of the these
allocations. The fee should be low enough to not create a barrier to
anyone needing one.  The charge is one time to eliminate the need for an
ongoing relationship with the allocation authority.  The charge is non-
refundable as the allocation is irrevocable."

Also:

"It is escrowed to insure there are no duplicate allocations and in case
it is needed in the future (e.g., to resolve duplicate allocation
disputes).

add the case of a potential change in allocation registry operator. i.e.

"It is escrowed to insure there are no duplicate allocations and in case
it is needed in the future (e.g., to resolve duplicate allocation
disputes, or to support a change of central allocation registry operator).

Also:

"This document directs the IANA, in section 13.0, to delegate the FC00::/8
prefix to an allocation authority to allocate centrally assigned /48
prefixes consistent with the requirements defined in this section."

change requirements to requirements and recommendations

"This document directs the IANA, in section 13.0, to delegate the FC00::/8
prefix to an allocation authority to allocate centrally assigned /48
prefixes consistent with the requirements and recommendations listed in
this section."

Section 3.3
-----------

"Rather, these prefixes are globally unique, and as such, their
applicability exceeds the current site-local addresses."

Should the word "current" be used in this context? Perhaps:

"Rather, these prefixes are globally unique, and as such, their
applicability exceeds the previously defined site-local addresses."

Section 7.0
-----------

It may be worth mentioning that DNS systems should be configured to
prevent queries relating to such addresses to be passed into the public
DNS system.

To quote the AS112 project home page: "Because most answers generated by
the Internet's root name server system are negative, and many of those
negative answers are in response to PTR queries for RFC1918 and other
ambiguous addresses" (http://www.as112.net/)

Section 13.0
------------

"This allocation authority shall comply with the requirements described in
section 3.2 of this document, including in particular the charging of a
modest one-time fee, with any profit being used for the public good in
connection with the Internet."

It is noted that there are significant problems with this proposed
approach to directions to IANA, particularly with the noted concept that
this is a for-profit activity and IANA is, in effect, being directed to be
in the position of selecting a global monopoly operator. The indeterminate
nature of a fair, open and reasonable definition of "the public good" is
also a problem in the context of these instructions to IANA. Some of the
lessons learned from DNS administration over the past decade would
indicate that this is not a sensible directive to pass to IANA, as it is
unlikely to be reasonably implemented in this precise form.

Additional Comments
--------------------

draft-huston-ipv6-local-use-comments-01.txt contains a number of
additional comments that are not addressed in this draft. In particular,
section 5 of that draft raises issues concerning

- the structure of an allocation fee being a form of monopoly rental. (a
   service fee would be more viable from a regulatory perspective) (section
   5.1 of the comments draft)

- the recording of allocations (section 5.4 of the comments draft)

- reverse mapping of such addresses in ip6.arpa (section 5.5 of the
   comments draft)

regards,

   Geoff Huston

---

From: Hans Kruse <[email-masked]>
Date: Fri, 24 Oct 2003 12:14:09 -0400

Some notes on the draft as well as some of the comments on the list:

1.  I think this draft is appropriately being prepared as Proposed 
Standard.  Trying to side-line local addressing to Experimental is not in 
keeping with the declared consensus on work towards a "replacement for 
site-locals" (which after all are on the standards track now).  Also, this 
document IMHO can be tweaked in pretty short order to qualify for Proposed 
Standard status.

2.  Several folks stumbled over the wording (in section 1.0) that 
"applications may treat these address[sic] like global scoped addresses". 
How about:

"Applications may treat these addresses like global scoped addresses; such 
applications will function correctly within the reach of the local 
addresses.  Sites using a mixture of Globally Routable and Local addresses 
may experience sub-optimal application behaviour, see sections 8.0-10.0 for 
further discussion".

If that sounds better I am willing to volunteer wording/edits to tighten up 
those sections (regarding applications in mixed environments).

3.  Section 9.0 regarding DHCP6; suggest: "In order for hosts to 
autoconfigure Local IPv6 addresses, routers have to be configured to 
advertise Local IPv6 /64 prefixes in router advertisements, or DHCP6 must 
have been configured to assign them."

4.  Regarding DNS; there were some comments regarding RFC1918-style 
lookups.  I assume the concern was regarding reverse lookups (the 1918 root 
server load issue).  However, the Local addresses in this draft are unique 
(FC00::/8) or nearly unique (FD00::/8).  As such there is really no reason 
not to allow reverse lookups for FC00::/8 in the global DNS.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Oct 2003 23:35:47 +0200

Exactly. Either we put this solution on the standards track, 
eliminating many of the problems of both RFC 1918 and FEC0::/10,
and meeting a range of needs, or we continue searching for
the perfect solution. If we take the latter approach, we will
surely see PA space used for these needs instead, or NAT6
devices, or both.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 26 Oct 2003 17:06:59 +0100

On 24 okt 2003, at 18:14, Hans Kruse wrote:

> "applications may treat these address[sic] like global scoped 
> addresses". How about:

> "Applications may treat these addresses like global scoped addresses; 
> such applications will function correctly within the reach of the 
> local addresses.  Sites using a mixture of Globally Routable and Local 
> addresses may experience sub-optimal application behaviour, see 
> sections 8.0-10.0 for further discussion".

I think this will only confuse people who aren't aware of all the 
details. But the problem is more fundamental than wording issues 
anyway. The problem is that there are two types of uses for local 
addresses:

1. To number systems/interfaces that are only accessible from withing 
the local network.

2. To have stable addresses for systems/interfaces regardless of 
intermittant external connectivity and renumbering.

In the case of 1. the scope is site local, although the difinition of 
"site" may be subject to change. Being able to route these addresses 
throughout the internet would be more of a drawback than a usable 
feature, as packets using these addresses may not enter or leave the 
network. In the case of 2. having the addresses be globally routable 
throughout the internet would be extremely desirable: having addresses 
that are stable within the site is good, having addresses that are 
stable throughout the net is even better.

If we recognize that unique local addresses will be used in both 
capacities and there is a significant chance that a locator/identifier 
separation mechanism could make these addresses globally usable (if not 
immediately routable), then it's obvious there are going to be 
problems. For instance, coming up with relatively simple filters that 
accommodate both uses of the addresses at the same time would be a big 
challenge. Having to change the default filtering policies that come 
with the OS for huge numbers of boxes would be another issue.

I think that either it must be explicitly stated which type of 
addresses we're talking about here. It would probably be best to only 
specify type 1 and see what can be done for type 2 with 
locator/identifier separation mechanisms.

> lookups.  I assume the concern was regarding reverse lookups (the 1918 
> root server load issue).  However, the Local addresses in this draft 
> are unique (FC00::/8) or nearly unique (FD00::/8).  As such there is 
> really no reason not to allow reverse lookups for FC00::/8 in the 
> global DNS.

It would make sense to delegate authority for the "nearly unique" type 
to a set of anycast addresses so that people can provide reverse 
mapping information for their own local address ranges through DNS 
servers listening to those anycast addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2003 17:54:04 +0100

> intermittant external connectivity and renumbering.

It's true that we *know* these addresses will be good for 1., and we
don't know whether they will be useful for all aspects of 2. So the
draft could indicate this.

> with the OS for huge numbers of boxes would be another issue.

Maybe, but it's what people operating Net 10 VPNs do today (assuming the
boxes you mean are routers).

> locator/identifier separation mechanisms.

Let's exclude nothing. We don't need to be categorical about "type 2".

   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Oct 2003 14:28:03 -0500

> > The problem is that there are two types of uses for local
> > addresses:
> > 

There is at least one other potential use:

3. to number systems/interfaces that are attached to networks that don't
   have connectivity to the public internet

Note that this is not the same as #1, since such networks can still 
talk with other networks, and some of the other networks might have
public internet connectivity.  Whether my #3 is just a more accurate
way of expressing the intent behind #1, I cannot tell.  (#1 could
be interpreted as "to number systems/interfaces that are only intended
to be accessible from within the local network", but that might or 
might not be what was intended.)

> draft could indicate this.

Actually I'm not sure that it's even reasonable to say this, at least
given the way #1 is worded.   Before we can really say that it's 
reasonable to assign local addresses to hosts that are only accessible
on a local network (while allowing the possibility that other hosts
on that local network have external connectivity) we need to understand
how applications that perform address referrals will work.  If those
apps need to treat local addresses differently than global addresses,
it might not be appropriate to assign local addresses to hosts attached
to networks that have external connectivity, even if those hosts aren't
intended to communicate externally, since that would affect the
ability of applications on those hosts to interoperate with other hosts
on the same network that did have external connectivity.

Keith

---

From: Alain Durand <[email-masked]>
Date: Wed, 29 Oct 2003 11:40:47 -0800

I think that this effort is not ready for prime time.

This document is creating a explosive cocktail made of:

	- policy: creation of a new authority to perform address assignment 
outside of the regular channels
	- economy: imposition of a fixed one time fee model, preventing 
competition
                               and creating a swamp of untraceable 
registrations
	- politics: dangerous instructions to IANA, see Geofff Houston comments
	- technology: half baked ideas that do not analyze seriously their 
impact:
		- what about reverse DNS?
		- what about address selection rules?
		- what about address leakage?
		- how to debug those networks when they will leak?
		  and it is impossible to map those prefixes back to their owner?

All this is designed to address what is mostly a perception/social 
problem which justification only resides in
a self serving companion document that fails to demonstrate that such 
local addresses
are actually needed/required.

In a rush to create something to replace the Site Local addresses,
I'm afraid this document is playing the apprentice sorcerer and will 
create more
long term damage than its author think.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2003 22:46:06 +0100

Alain,

Do you think it is better to let the RIRs develop a policy for
allocating PA space for local use, i.e. create a swamp like IPv4?

In detail...

> outside of the regular channels

That is a matter for IANA. I don't see why it is intrinsically dangerous,
but IANA could perfectly well designate one of the existing RIRs, if that
looked like a good idea.

>         - economy: imposition of a fixed one time fee model, preventing

Yes, that's a *good* thing. It also prevents commercial exploitation of this 
address space as a rental asset. That's a good thing too.

>                                and creating a swamp of untraceable

That is the reason for the escrow proposal.

>         - politics: dangerous instructions to IANA, see Geofff Houston comments

I don't see where "dangerous" comes from, and I think the current draft responds
to Geoff adequately.

>                 - what about reverse DNS?

Suggestions? Is reverse DNS needed for these addresses? You're correct that
this needs analysis.

>                 - what about address selection rules?

These addresses behave like global scope for that purpose.

>                 - what about address leakage?

These addresses are unique, so leakage is nothing like as harmful
as with RFC 1918. They are also known to be unrouteable globally, so
can be blackholed at domain boundaries. I thought that was discussed in
the draft.

>                 - how to debug those networks when they will leak?

You don't need to. If you see one of these addresses out of its intended
domain, you only need to drop it. I'm not saying this lightly - I really
think this is not an issue. There is nothing to debug. You just don't care.

>                   and it is impossible to map those prefixes back to their owner?

Doesn't matter. You just drop them.

> are actually needed/required.

I'm sorry, that is just wrong. It is far from a social problem and the Hain/Templin
draft is far from self-serving. 

> In a rush to create something to replace the Site Local addresses,

It isn't replacing site-local. It's filling a widely perceived need that
has emerged (with our better understanding of the needs of enterprise and
inter-enterprise networking) since site-local was invented. The rush, as I
said at the top, is to prevent widespread misuse of PA prefixes and to give
us a chance of preventing NAT6.

If this doesn't get done soon, I think the emphasis will rapidly change to
working with the RIRs to get a rough and ready policy in place for
private use of PA space.

> long term damage than its author think.

On the contrary, IMHO, *not* doing this will create long term damage.

   Brian

---

From: Alain Durand <[email-masked]>
Date: Wed, 29 Oct 2003 17:13:28 -0800

>allocating PA space for local use, i.e. create a swamp like IPv4?
PA... Do you PI for Provider Independant?
If it is the case, yes I think it would be less damaging to do that.
See below.

>In detail..
[Focusing on technology as I think that the other dicussions will
 simply not go anywhere in this forum]

>Suggestions? Is reverse DNS needed for these addresses? You're correct that
A valid enough reason to get a -02 published.

>These addresses behave like global scope for that purpose.
In terms of scope, you're right. Now take the multi-party
communication example that was described by Erik earlier on,
there is a problem. So you need to add an extra selection rule
and an API to reverse that choice for the cases it does not make
sense.
Note: you cannot do that just by adding entries in the preference
table, this table is global and you need a per-socket oprtion.

>think this is not an issue. There is nothing to debug. You just don't care.
I disagree. You cannot say that. Examples:
- you're under security attack from one of those addresses,
   you'd like to trace it back. Any tiny bit helps.

- you're doing a complex merge of several local address spaces
   and things get ugly. You'd like to have a simple way (like whois)
   to know who those prefixes belongs to.

>Doesn't matter. You just drop them.
No. see above.

>inter-enterprise networking) since site-local was invented. 
>
>The rush, as I
The real requirement is to have addresses that are not bound to any 
provider,
as this because renumbering will never be painless and multi-homing solution
a la Multi6 will take years to be developped.

So the question is what to do in the meantine. 3 alternatives:
1- Give a limited amount of PI to those who really want it and let
     them pay $$$ to get their ISP to route them
2- Create this 'local address' kludge that will stay for a long time
3- Speed up the work in Multi6.

None of this comes for free, however my take is that the combination
of 1 and 3 is much less expensive that 2.

    - Alain.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Oct 2003 12:17:12 +1100

Brian,

>allocating PA space for local use, i.e. create a swamp like IPv4?

It appears to me that you see this as being an either / or situation,
where we accept the document as is or we defer to an RIR-lead
process to undertake this form of address distribution.

I do not agree with such an interpretation of the situation. My comments
on the weakness of the document as being ready for prime time are
based in part on over-specification of the proposed distribution function.

The IPv6 working group wish to alter the IPv6 address architecture
to define a unicast address block that is intended to be accessible
for use in a particular context. For this purpose the document is an
appropriate and necessary vehicle.

The IPv6 working group wish to then set a price for consumers of this
service and indicate that this price generates profits, and specify how 
such profits should be disbursed. My comments have been that this
is not consistent with the role of the IETF, nor may it be possible for the IANA
to implement, and I've suggested some modifications to the document
that could address such concerns, based on removing such overly
prescriptive sections of the draft.

To answer you question posed to Alain, then, I'd offer the view that
it is entirely possible that the RIRs are positioned to be able to fulfil the
role of the central registry function within the base requirements of this
particular draft, and to preclude such an option is imho, not an IETF
role.

You also note that 
"I think the current draft responds to Geoff adequately."

I posted a note to this list 
(https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00456.html)
indicating that I did not believe that this document was ready for
Proposed Standard, and indicating where I saw deficiencies in the
document, so I do not believe that this draft provides an adequate
response to the concerns that I've raised, and my impressions of
the document at this stage are largely similar to those of Alain.

To attempt to be constructive here,  I'd be happier with a document
that  was far less prescriptive about the precise nature of the
distribution function, yet retained the description of the intended
outcomes of the function, and instructed IANA to delegate this
distribution function such that the intended outcomes are attained.

regards,

  Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2003 17:05:14 +0100

> If it is the case, yes I think it would be less damaging to do that.

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.

> A valid enough reason to get a -02 published.

Sure. That's why we do WG last calls...
> and an API to reverse that choice for the cases it does not make

Well, in a sense I think these problems are unsolvable - I think whatever
scope semantics we try to impose on the address syntax, there will always
be cases where reachability is an experimental question and any algorthmic
selection rule will fail. 

> table, this table is global and you need a per-socket oprtion.

It may even be worse. If A is trying to decide which address for B
to refer to C, the correct choice may be a complicated function of both 
B and C, and A may have no way to determine which of B's addresses
are accessible to C. And I believe we have that problem whatever we
do (including doing nothing), so I don't see how the current draft
makes it worse.

>    you'd like to trace it back. Any tiny bit helps.

This in theory of course should be prevented by ingress filtering. It's
true (as for RFC 1918) that if they aren't dropped at ingress, tracing
back will be very hard.

>    to know who those prefixes belongs to.

I would think that in such a merger you would have that information.
Certainly when you merge two networks today you generally know the
address prefixes.

> a la Multi6 will take years to be developped.

Yes. And don't these addresses have exactly that property?
> 2- Create this 'local address' kludge that will stay for a long time

I don't believe it's a kludge. I believe it's simply a straightforward
version of PI. The $$$ argument applies, in fact.

> 3- Speed up the work in Multi6.

A bit optimistic. Multi6 is still very hard.

> of 1 and 3 is much less expensive that 2.

I can't agree, since I think 2 is a form of 1.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2003 17:24:43 +0100

Geoff,

> based in part on over-specification of the proposed distribution function.

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. 

> prescriptive sections of the draft.

But if we leave too much unspecified, we risk this being perceived as another
gold rush opportunity with all the negative consequences that we know. That's
really the extent of my concern.

> particular draft, and to preclude such an option is imho, not an IETF

Correct. I don't think the draft does that. It just asks the IANA to give the
job to an authority. There is a technical reason given in the draft why it
has to be a single authority (but it could perfectly well be operated by
the RIRs in collaboration; that's not the IETF's business.)

> the document at this stage are largely similar to those of Alain.

You're fully entitled to that opinion... I was just saying that IMHO
the draft *did* respond to the concerns you've expressed.

> distribution function such that the intended outcomes are attained.

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.

     Brian

---

From: Alain Durand <[email-masked]>
Date: Fri, 31 Oct 2003 10:19:11 -0800

>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.

>do (including doing nothing), so I don't see how the current draft
if the only thing out there was globally reachable addresses, this problem
will go away. I understand that some of those addresses may not be
reachable because of firewall, but this is a case of misconfiguration.
So I argue that the hinden/haberman draft makes things more complex
as it creates two family of addresses, those who are potentially unreachable
by design and those who are potentially unreacable by configuration.

>>>as with RFC 1918. 
I disagree. They share many issues, like the one addressed by the AS112 
project
http://www.as112.net/

>true (as for RFC 1918) that if they aren't dropped at ingress, tracing
This is exactly my point: this proposal will make debugging the global 
Internet
more difficult.

>Certainly when you merge two networks today you generally know the
2 is easy. more than 2 gets difficult. Picture the situation:
"oh, we have merged so many times, we now have tens of prefixes
advertized and we do not know/remember which one is which..."
All this because those addresses are untraceable.

>version of PI. The $$$ argument applies, in fact.
Difference of opinion. IMHO, it is not that straightforward,
there are many side effects. See above.

    - Alain.