Next steps on advancing core IPv6 specifications to full Internet standard

[[e-mail]]

The 6MAN working group has been working on advancing the core IPv6
specifications to Internet Standard.  The next steps to achieve this
goal is described here.

We have now finished the edits on the RFC2460bis, RFC1981bis and
RFC4291bis documents. With the agreement in today's working group
session on the header insertion issue for 2460, the working group last
call is now complete.

The chairs have decided to declare consensus on the following text:
(that includes a small amendment proposed in the meeting).

   The insertion of Extension Headers by any node other than the
   source of the packet causes serious problems.  Two examples include
   breaking the integrity checks provided by the Authentication Header
   Integrity [RFC4302], and breaking Path MTU Discovery which can
   result in ICMP error messages being sent to the source of the
   packet that did not insert the header, rather than the node that
   inserted the header.

   One approach to avoid these problems is to encapsulate the packet
   using another IPv6 header and including the additional extension
   header after the first IPv6 header, for example, as defined in
   [RFC2473]

New revisions of RFC2460bis and RFC4291bis will be published shortly,
and the intention is to have the IESG writeup and the advancement done
by November 22th.

We will send the IESG the following letter to request reclassifying
RFC3596 and RFC4443 in-place as Internet Standards.

The goal is for all five of these documents to be Internet Standards.

Attached is the draft letter to the IESG.

Best regards,
Ole and Bob


------------------------


Dear IESG,

The 6MAN working group requests that the IESG initiate the process to
reclassify the following two draft standard RFCs as Internet Standard.

Following the requirements in RFC6410, section 2.2:

(1) There are at least two independent interoperating implementations
     with widespread deployment and successful operational experience.

(2) There are no errata against the specification that would cause a
    new implementation to fail to interoperate with deployed ones.

(3) There are no unused features in the specification that greatly
    increase implementation complexity.

(4) If the technology required to implement the specification
   requires patented or otherwise controlled technology, then the
   set of implementations must demonstrate at least two independent,
   separate and successful uses of the licensing process.


RFC4443 (https://datatracker.ietf.org/doc/rfc4443/)
  (1) Widely implemented:
      https://www.ipv6ready.org/db/index.php/public/?o=4
  (2) 4 errata, none of which would cause new interoperability
      problems.
      RFC4443 is updated by: RFC4884, but the consensus is that this update
      it’s not an update, it is an extension to the protocol.
  (3) There are no unused features.
  (4)  No known IPR.

RFC3595 (https://datatracker.ietf.org/doc/rfc3596/)
  (1) Widely implemented:
      https://www.ipv6ready.org/db/index.php/public/?o=4
  (2) No errata. No updated by.
  (3) There are no unused features.
  (4) No known IPR.


Bringing IPv6 draft standards to full standard has been worked on in
the 6MAN working group for some time. The documents for
reclassification have been reviewed in multiple face to face working
group sessions and on the mailing list, and there is a strong
consensus in the working group to have these documents reclassified as
Internet Standards.

Best regards,
Ole & Bob - on behalf of the 6man Working group