Protocol Action: 'Internet Protocol, Version 6 (IPv6) Specification' to Internet Standard (draft-ietf-6man-rfc2460bis-13.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Internet Protocol, Version 6 (IPv6) Specification'
  (draft-ietf-6man-rfc2460bis-13.txt) as Internet Standard

This document is the product of the IPv6 Maintenance Working Group.

The IESG contact persons are Suresh Krishnan and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/





Technical Summary

  This document specifies the version of the IPv6 protocol that is being 
  elevated to Internet Standard. This will obsolete RFC2460 that is the
  Draft Standard version of the protocol. This version incorporates fixes
  for Errata as well as updates to RFC2460.

Working Group Summary

   The 6MAN working started working on advancing the IPv6 core
   specifications to Internet Standard at IETF93 July 2015.  See:
   https://www.ietf.org/proceedings/93/slides/slides-93-6man-3.pdf The
   working group identified three RFCs to update (RFC2460, RFC4291, and
   RFC1981) by incorporating updates from other RFCs and Errata, and
   three to advance in place RFC4443, RFC3596, and RFC4941.  After
   further analysis, the w.g. decided to not reclassify RFC4941 at this
   time.

   The working followed the requirements in RFC6410 for advancing a Draft
   Standard to Internet Standard.  While RFC6410 describes how to handle
   Errata, it doesn't say anything about Updated-By RFCs.  The working
   group, with the advice of our AD, incorporated the changes from the
   the Updated-By RFC and verified there was interoperability of the
   updates.

   All of the Updated-By and errata were brought into the new draft in
   small steps to allow thorough review of all of the changes.  A summary
   and link to diff from the previous version was sent to the mailing
   list.  All of the changes to each draft were also discussed in detail
   at IETF94, IETF95, IETF96, and IETF97.  All of the changes from
   RFC2460 are summarized in Appendix B and are ordered by the Internet
   Draft that brought the change in.

   A working group last call for moving this and the other two documents
   to Internet Standard was started on 30 May 2016.  Reviews were also
   requested.  Issues found during the last call and reviews were entered
   into the 6MAN ticket system.  These are now closed.

   The biggest issue raised was how to handle the issue of Extension
   Header insertion in this document.  After many discussion on the
   mailing list and face to face meeting, there wasn’t a clear consensus.
   The chairs conducted an online survey that provided three choices: Ban
   header insertion, describe the problems with header insertion, or say
   nothing.  The result of the survey was to describe the solution.  The
   results and methodology used to evaluate the results can be seen at:

     https://mailarchive.ietf.org/arch/msg/ipv6/_gG2foiugk5B7w3TpnPvBbjHDzs

   This was discussed at the 6MAN session at IETF97 and on the mailing
   list after the meeting.  The chairs believe there is a consensus to go
   forward with the text that is in draft-ietf-6man-rfc2460bis-08.

AD's comment on IETF Last Call:

   The IETF last call discussion for this draft was mainly focused around the text 
   in Section 4 that discusses the handling of extension headers. The biggest concern
   raised was that the current text is ambiguous on whether header insertion is
   allowed on intermediate nodes or not. There were some people arguing that an 
   explicit prohibition is not necessary as the text is already clear, while others believed
   that explicitly listing the prohibitions will minimize any misunderstandings in the
   future. There was also a small number of people who wanted to explicitly allow
   header insertion and describe how to do it, but this was clearly out of scope for this
   draft (but may be in scope for future work in 6man). Overall, no one argued against
   the fact that the intent of the text in RFC2460 was to forbid insertion of extension 
   headers on any other node but the source of the packet.  The only argument made 
   against adding clarifying text was that the text was already clear. Given this, I believe
   there is consensus to add explicit text about header insertion into the draft before it
   progresses further. This change has been done in version -09.

Document Quality

   IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
   including proprietary and open source.  A list of products that have
   received the IPV6 Ready logo can be found at:
   https://www.ipv6ready.org/db/index.php/public/?o=4

   Most major ISP now support IPv6, as well as many mobile
   operators.

   Google’s IPv6 stats at
   https://www.google.com/intl/en/ipv6/statistics.html show they are
   seeing now about 15% of their overall user traffic is IPv6. Country
   adoption is 29% in the US, Germany 27%, Finland 12%, Japan 14%, Brazil
   11%.  IPv6 users per AS can be found at
   http://stats.labs.apnic.net/aspop

   The University of New Hampshire InterOperability Laboratory (UNH)
   analyzed the incorporated updates to insure they were implemented and
   interoperable.  No problems were found.  Their report can be found at:
   https://www.ietf.org/proceedings/95/slides/slides-95-6man-2.pdf

Personnel

  The  document shepherd is Ole Trøan. The responsible AD is Suresh Krishnan.