> > 4 Deprecation > > > > 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. > > I think this section is not ready yet. Couple comments: > > 1) This is not the IETF job to mandate what an implemention choose > to support or not.
Sure. An implementation may choose to give a special meaning to a special prefix, say "DEAD:BEEF::/32", and the IETF cannot do anything about it. However, the whole purpose of the deprecation draft is, well, to deprecate site local addresses. These addresses use to have a special meaning, an expectation that they can only reach "on site" nodes. The special meaning is not supported any more. Applications must not expect it to be supported. Do you have an alternative writing? > 2) What constitute a "new implementation"? > For example, we shipped IPv6 in Solaris 8. Same bits plus extra > features in Solaris 9, more coming in newer relases, but fundamentally > the same code fundation. Would Solaris 10, 11, 12, 13, 14.... > or what ever new name we come up with be considered as "new > implemtations"? > This is confusing... Alternative text for "new implementation" would be welcome. I guess that the intent is clear. > 3) What does section 4 exactly means with regard to default address > selection RFC3484? > Does this obsolete the rules about scope? Well, we still have link local scope, so there is still that. Do you suggest that we write a line for each of the RFC that currently mention site local and explain how to change them? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
