Well, yes, the "minimal effort" consists of writing an interop report for something that sort of outlaws interoperation :-)
[Brian's standard gripe about RFC2026 being broken fits here.] I still think it would be good to do, but not if it requires non-trivial effort. Brian On 2009-02-12 10:52, Thomas Narten wrote: >> I think that simply reclassifying 3879 as DS would be a Good Thing >> and requires minimal effort. > > Um, what would the interoperability test (required for advancing a > spec) actually contain? > > Right. I thought so. :-) > > 3879 is weird in that implementations don't have to actually do > anything... Partly, it was designed that way, as I recall, so that > existing implementations wouldn't become non-compliant. Also, you > don't "support" site locals, you just support addresses. There isn't > special code to handle them... (That was in fact, one of the problems > with them... you needed special code to handle them "right", which we > didn't fully specified, and no one in their right mind would > implemented anyway...) > > The meat of 3879 (in terms of what is actionable) is: > > 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. 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. > > However, router implementations SHOULD be configured to prevent > routing of this prefix by default. > > The references to site local addresses should be removed as soon as > practical from the revision of the Default Address Selection for > Internet Protocol version 6 [RFC3484], the revision of the Basic > Socket Interface Extensions for IPv6 [RFC3493], and from the revision > of the Internet Protocol Version 6 (IPv6) Addressing Architecture > [RFC3513]. Incidental references to site local addresses should be > removed from other IETF documents if and when they are updated. > These documents include [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, > RFC3177, and RFC3316]. > > Existing implementations and deployments MAY continue to use this > prefix. > > There is work we could do, but it isn't actually with 3879... > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
