Hi,
A bit late, but I wanted to contribute too ... :)
On 11/04/10 12:08, V, Raman K (MCBS-UPEL) wrote:
A portion of Section 4 of this RFC (the crux, really) is reproduced below:
This document formally deprecates the IPv6 site-local unicast prefix
defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10. The
special behavior of this prefix MUST no longer be supported in new
implementations. The prefix MUST NOT be reassigned for other use
except by a future IETF standards action. Future versions of the
addressing architecture [RFC3513] will include this information.
It seems to clearly say that an IPv6 stack must no longer support site-local addresses,
to be able to conform this RFC. So, would I be right in assuming that our stack should
simply drop the support for site-local addresses? Or should I put more emphasis on the
words "new implementations" and say that mine isn't a new implementations (we
have had our IPv6 stack in the market for a while), so we should continue to support
site-local addresses?
In my opinion, you should keep the code for site-local addresses,
because it may come in handy with e.g. ULA addresses (fc00::/7).
However, you shouldn't automatically detect fec0::/10 or anything else
as site-local. For future and backward compatibility, you may want to
have some ifconfig flag or other similar method for marking an address
as site local scope.
Of course, modern thinking prefers usage of labels and/or preferences
over scopes for proper address selection.
Just a couple of cents from,
--
Aleksi Suhonen, Researcher
Department of Communications Engineering
Tampere University of Technology
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
