Subject: Re: Standard status of RFC 3879

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Feb 2009 16:52:13 -0500

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Feb 2009 11:36:11 +1300

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