Thoughts on the draft-hinden last call

[Hans Kruse <kruse@ohio.edu>]

Here are my current thoughts on the last-call discussion going on regarding 
the unique local addressing:  It seems to me that three subjects are going 
around:

(1) There have been a few comments of the "we just don't need this type of 
address" kind.  I respect that point of few, and firmly disagree.  Further, 
I cannot agree with any of the scenarios that attempt to attach "they will 
cause damage" labels to local addresses; here is why:  We have sufficient 
needs/requirements/scenario descriptions to reasonably deduce that network 
managers today, tomorrow, and in the foreseeable future will be faced with 
requirements that they will choose to satisfy with some form of local 
addressing.  (The fact that many requirements can at some point in the 
future be addressed by better technical means does not change this 
statement).  The strength of the Internet is its flexibility and the fact 
that there is no "design police" constraining deployments.

If the WG defines a unique/near-unique address format for this purpose, we 
will at least know that the risk of prefix collisions is minimized, and we 
can recognize (and filter) these addresses if they leak.

Without this definition, one of two things will happen:  If we are really 
lucky, the network manager will pick the old site-local prefix.  Some 
applications will still "know" these as different, and may behave in 
unexpected ways, but we can at least recognize these addresses for what 
they are and filter them.  They cannot be traced back, and they are very 
likely not unique, creating all sorts of additional problems.

If the network manager instead hijacks a prefix, things get really bad.  If 
the hijacked addresses leak, you have to deal with them on a case-by-case 
basis, and they may collide with a legitimately assigned prefix, making 
debugging and filtering a nightmare.

All in all, I prefer to have a recognized prefix.

(2) The only technical issue seems to be address selection.  (BTW, if you 
are tempted to reply with "we don't know how to do this so we should not 
create this type of address", see (1) above).  We could attempt to write up 
suggestions for special handling of local addresses  in APIs and apps, 
mostly based on MAY and SHOULD.  On the other hand, if apps treat local 
addresses as global (which they are, just not routable beyond some point), 
these will work fine in the majority of the deployment scenarios where 
hosts have only one address.  The mixed/multiple addressing case is where 
failures will happen, but we may want to simply outline the issues and let 
network managers and/or app designers decide if/how they want to handle 
these cases. In any case, lets pick an approach, write the text, and move 
on.

(3) The registry setup seems to be the third issue.  I have very little 
expertise in this area, but from the technical end, I think the draft needs 
to at a minimum:

* require that IANA delegate the local prefix to one and only one registry;
* require that the agreement with the registry contain an escrow provision
* require that the agreement with the registry mandates a one-time fee 
structure
* require that the agreement with the registry cap the one-time fee at a 
level considered by IANA to be reasonable and non-descriminatory
* require that the agreement with the registry require a non-zero one time 
fee or an IANA-approved anti-hording mechanism if the fee is zero.

Do we need anything else from a technical perspective?

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------