Here is a revelant email.
I haven't seen a different statement on WG consensus on this topic.
Erik
Date: Wed, 09 Apr 2003 15:11:04 -0700
From: "Bob Hinden & Margaret Wasserman" <[EMAIL PROTECTED]>
Subject: Consensus on Site-Local Addressing
To: [EMAIL PROTECTED]
Hi All,
Well, that was fun! :-)
All told, there were over 200 responses to the consensus call on IPv6
site-local addressing, approximately 3-to-1 in favor of deprecating IPv6
site-local unicast addressing. The final count (including the room and the
mailing list) was: 155 YES, 56 NO (211 Total).
There were also a significant number of the people on both sides of this
issue that voiced (in their original responses, or in subsequent messages)
a strong belief that we should investigate alternative mechanisms for local
addressing and local access control.
The chairs have read all of the messages on the list, and based on your
considerable input, we have determined that the IPv6 WG does have rough
consensus to deprecate the usage of IPv6 site-local unicast addressing AND
to investigate alternative mechanisms for local addressing and local access
control.
In particular, the IPv6 WG will work to accomplish the following things in
parallel:
(1) Publish an informational document that explains the issues
encountered with site-local addressing and our reasons
for deprecating IPv6 site-local unicast addresses. This
document will officially deprecate site-local addressing.
(2) Remove site-local unicast addressing from the IPv6
scoped addressing architecture I-D, and publish the
parts of the document on which we do have consensus
(i.e., link local addresses, multicast, etc.). This
will include a note that the IPv6 working group is
investigating other forms of local IPv6 addressing and
that the usage of any new forms of local addresses will be
documented elsewhere.
(3) Update the IPv6 addressing architecture to indicate that the
usage of the FECO::/10 prefix for site-local addressing is
deprecated. To maintain backward compatibility with existing
implementations the prefix should be reserved and should not
be allocated for other purposes.
(4) Define and publish the requirements for a local addressing
mechanism to provide:
- Addresses for disconnected networks.
- Addresses for intermittently connected networks.
- Addresses that support merging of sites.
- Stable local addresses for changing ISPs without
disrupting local communication.
Once we have consensus on the requirements, the IPv6
WG will work on solutions for local addressing that
meet those requirements.
(5) Define and publish the requirements for a local access
control mechanism, then work on a solution that meets
those requirements.
Each of these new work items will need to be added to the IPv6 WG charter
and will go through the normal IETF document processes. For (4) and (5) it
is important to make the rest of the IETF community aware that the IPv6 WG
is undertaking these tasks, so we will consider methods to invite wider
review and discussion of these problems.
IPv6 site-local addressing has been a contentious issue in the IPv6 WG for
some time, and we are both glad to see the WG reach consensus on this
issue. This will allow us to complete and publish the IPv6 scoped
addressing architecture document, an important part of the IPv6 specification.
We hope that people on all sides of this issue will respect the rough
consensus of the WG, and will work with us to achieve the goals outlined above.
Thanks to everyone who expressed an opinion during this discussion.
Bob Hinden & Margaret Wasserman
IPv6 WG Chairs
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
