(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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
