<Short Reasoning>
Politically A. will deprecate site locals and strand their replacement in the WG forever -- the result will be prefix hijacking -- not good.
C. seems too ambitious given that a group of folks urgently feel that continued SL deployment will be harmful.
<Longer Reasoning>
The consensus reached by this WG is tenuous at best. The essence of the discussions seems to pretty clearly combine the need to remove SLs and to introduce a "replacement". A subset of the group just wants SLs gone. Another subset points out (correctly I think) that circumstances exist where a provider-based prefix won't work.
Folks, this is not rocket science. IPv6 needs a known prefix that can be distinguished from provider-based addressing, and a mechanism to uniquely (or almost-uniquely) assign addresses out of this prefix. I won't rehash all the reasons why -- check the list archives. There really are only two down-sides -- someone could start routing these prefixes and someone could try to NAT them. These need to be addressed in the appropriate documents (e.g., node requirements that prohibit address replacement in the header, etc.). IMHO the dynamics that initially created IPv4 NAT are not present in IPv6, but that is another discussion.
There is real danger here; I have already started to see mailing list discussion going something like:
Q. What address prefix do I use for this network before I get my provider prefix?
A1. Use FECO (Site Local).
A2. No, No, FECO has been outlawed by the IETF, just invent a prefix!
I have seen the 2002 mapping of RFC 1918 suggested.
"Private" space will appear -- I want a version that is thought out, that is well documented and understood, not a mish-mash of hijacked prefixes and IPv6'afied RFC1918 stuff.
--On Monday, August 04, 2003 11:06 -0700 Bob Hinden <[EMAIL PROTECTED]> wrote:
B) Deprecate Site-Local addresses at the same time as a alternative solution is agreed to. This would mean advancing both documents at the same time and making them include normative references to each other to insure that they were published at the same time. This would result in the deprecation only happening if a consensus was reached on an alternative.
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 IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
