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 --------------------------------------------------------------------