Skip to main content

IPv6 Support Required for All IP-Capable Nodes
RFC 6540

Revision differences

Document history

Date Rev. By Action
2017-05-16
02 (System) Changed document authors from "Lee Howard, Chris Donley, Wesley George" to "Lee Howard, Chris Donley, Wesley George, Christopher Liljenstolpe"
2015-10-14
02 (System) Notify list changed from intarea-chairs@ietf.org, draft-ietf-intarea-ipv6-required@ietf.org to (None)
2012-08-22
02 (System) post-migration administrative database adjustment to the Yes position for David Harrington
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Ronald Bonica
2012-04-13
02 (System) RFC published
2012-01-17
02 (System) IANA Action state changed to No IC
2012-01-13
02 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2012-01-13
02 Amy Vezza IESG state changed to Approved-announcement sent
2012-01-13
02 Amy Vezza IESG has approved the document
2012-01-13
02 Amy Vezza Closed "Approve" ballot
2012-01-13
02 Amy Vezza Approval announcement text regenerated
2012-01-13
02 Amy Vezza Ballot writeup text changed
2012-01-13
02 Jari Arkko State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2012-01-12
02 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss
2012-01-11
02 Jari Arkko Document placed on today's informal IESG telechat to try to clear the remaining issues.
2011-12-14
02 David Harrington [Ballot comment]
I cleared
2011-12-14
02 David Harrington [Ballot discuss]
2011-12-14
02 David Harrington [Ballot Position Update] Position for David Harrington has been changed to Yes from Discuss
2011-12-08
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-12-08
02 (System) New version available: draft-ietf-intarea-ipv6-required-02.txt
2011-10-11
02 David Harrington
[Ballot discuss]
1) This document uses RFC2119 keywords in a way that I think violates the spirit, if not the requirements, of RFC2119. I …
[Ballot discuss]
1) This document uses RFC2119 keywords in a way that I think violates the spirit, if not the requirements, of RFC2119. I think RFC2119 keywords are not really meant to be used for what we wish the industry would do, expressed as MUSTs and SHOULDs. As Ron points out in his reviews, you cannot apply new requirements to existing implementations - they cannot be changed except by developing a new implementation (which might be a modified current implementation).

I think my concerns about the RFC2119 usage could be addressed by modifying the text.
2011-10-07
02 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Ondřej Surý.
2011-09-08
02 Cindy Morgan Removed from agenda for telechat
2011-09-08
02 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead.
2011-09-08
02 David Harrington
[Ballot comment]
My real concern is that publishing this document a Proposed Standard  RFC might actually be damaging.

IPv4 is being exhausted, and will no …
[Ballot comment]
My real concern is that publishing this document a Proposed Standard  RFC might actually be damaging.

IPv4 is being exhausted, and will no longer be suitable as *the* IP protocol underlying the Internet. The IETF mission is to make the Internet run better. We have in some ways been amiss in adding on lots of hacks to IPv4, such as NATs, and we are in the process of adding more.

I believe that we have now reached a point where we are applying life-sustaining efforts to IPv4 that have exceeded the benefits/cost tradeoff threshold. Many of these hacks make the Internet run worse, not better. I think it may be time to declare IPv4 Historic, and stop trying to save it by piling on more detrimental hacks.

We should **rewrite** documents like RFC1122 to reflect IPv6-only or dual stack options, to make it clear that an implementation that only supports IPv4 does not make the Internet run better; By supporting IPv4-only and the needed hacks, these implementations make the Internet run worse.

This document is a just a band-aid that might make the authors feel good, like an opinion piece does, but it gives the impression that it might actually accomplish something. I fear the only thing it will accomplish is to delay the work of actually rewriting RFC1122 and other documents to recognize that IPv4-only is no longer adequate for use in the Internet.
2011-09-08
02 David Harrington
[Ballot discuss]
1) This document uses RFC2119 keywords in a way that I think violates the spirit, if not the requirements, of RFC2119. I …
[Ballot discuss]
1) This document uses RFC2119 keywords in a way that I think violates the spirit, if not the requirements, of RFC2119. I think RFC2119 keywords are not really meant to be used for what we wish the industry would do, expressed as MUSTs and SHOULDs. As Ron points out in his reviews, you cannot apply new requirements to existing implementations - they cannot be changed except by developing a new implementation (which might be a modified current implementation).

I think my concerns about the RFC2119 usage could be addressed by modifying the text.
2011-09-07
02 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded
2011-09-07
02 Dan Romascanu
[Ballot comment]
1. I support Ron's DISCUSS.

2. I do not understand why this document aims to be a Proposed Standard. There are no testable …
[Ballot comment]
1. I support Ron's DISCUSS.

2. I do not understand why this document aims to be a Proposed Standard. There are no testable requirements to allow this document to progress on the standards track.

3. Jouni Korhonen made the following comment in the OPS-DIR review:

The I-D is standards track and updates 1812, 1122 & 4084.
However, the I-D states:

  "...Therefore, the above-listed
  standards are not being updated to include the complete technical
  details of IPv6, but to identify that a distinction must be made
  between IPv4 and IPv6 in some places where IP is used generically."

I am pointing at this because the current I-D text regarding updates to these specifications is not detailed enough. Just giving few "for example"s is not enough. What I think is needed is a clear (bullet) list of affected sections for each document separately also detailing what is the exact text that gets affected/updated and how. Now too much is left for the reader..

I suggest that this comment is addressed before the document is published.
2011-09-07
02 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-09-07
02 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-09-07
02 David Harrington
[Ballot discuss]
I think this would make a wonderful "letter to the editor" opinion piece. I would love to ballot "Yes" on this document,m because …
[Ballot discuss]
I think this would make a wonderful "letter to the editor" opinion piece. I would love to ballot "Yes" on this document,m because I share the authors' opinions. But I don't feel I can do that. I have two major issues with the document - one is an editorial concern that can be addressed by the authors; the second is a discuss-discuss.

1) This document uses RFC2119 keywords in a way that I think violates the spirit, if not the requirements, of RFC2119. I think RFC2119 keywords are not really meant to be used for what we wish the industry would do, expressed as MUSTs and SHOULDs. As Ron points out in his reviews, you cannot apply new requirements to existing implementations - they cannot be changed except by developing a new implementation (which might be a modified current implementation).

I think my concerns about the RFC2119 usage could be addressed by modifying the text.

2) My real concern is that publishing this document a Proposed Standard  RFC might actually be damaging.

IPv4 is being exhausted, and will no longer be suitable as *the* IP protocol underlying the Internet. The IETF mission is to make the Internet run better. We have in some ways been amiss in adding on lots of hacks to IPv4, such as NATs, and we are in the process of adding more.

I believe that we have now reached a point where we are applying life-sustaining efforts to IPv4 that have exceeded the benefits/cost tradeoff threshold. Many of these hacks make the Internet run worse, not better. I think it may be time to declare IPv4 Historic, and stop trying to save it by piling on more detrimental hacks.

We should **rewrite** documents like RFC1122 to reflect IPv6-only or dual stack options, to make it clear that an implementation that only supports IPv4 does not make the Internet run better; By supporting IPv4-only and the needed hacks, these implementations make the Internet run worse.

This document is a just a band-aid that might make the authors feel good, like an opinion piece does, but it gives the impression that it might actually accomplish something. I fear the only thing it will accomplish is to delay the work of actually rewriting RFC1122 and other documents to recognize that IPv4-only is no longer adequate for use in the Internet.
2011-09-07
02 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2011-09-07
02 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-09-06
02 Wesley Eddy
[Ballot comment]
Section 2 says "IP is redefined to mean IPv4 + IPv6", but I think to be consistent with the rest of the document …
[Ballot comment]
Section 2 says "IP is redefined to mean IPv4 + IPv6", but I think to be consistent with the rest of the document it should say "IP is redefined to mean IPv6 or IPv4+IPv6"?
2011-09-06
02 Wesley Eddy [Ballot Position Update] New position, Yes, has been recorded
2011-09-06
02 Sean Turner [Ballot Position Update] New position, Yes, has been recorded
2011-09-05
02 Ron Bonica
[Ballot discuss]
I am not sure what this document adds to the RFC series. Before this document was written, if an implementation didn't support IPv6, …
[Ballot discuss]
I am not sure what this document adds to the RFC series. Before this document was written, if an implementation didn't support IPv6, it wasn't compliant with RFC 2460. Now, if an implementation doesn't support IPv6, it isn't compliant with RFC 2460 or this document.

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

The meat of this document is in the bullet list at the bottom of Section 2. The following are comments regarding that bullet list:

1) It is meaningless to levy a new requirement against a "current implementation". The current implementation has already been implemented. It can't change.

2) It is meaningless to say that an implementations IPv6 quality must be better or equal to its IPv4 quality. Since vendors don't produce buggy code intentionally, it would be impossible to control the distribution of bugs among features.

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

The discussion of how this document updates RFC 1812 is distracting. It should be condensed as follows:

RFC 1812 defines requirements for IP Version 4 Routers, but uses the generic terms IP and ICMP. In RFC 1812, the generic terms IP and ICMP should be replaced with the specific terms IPv4 and ICMPv4.
2011-09-05
02 Ron Bonica [Ballot Position Update] New position, Discuss, has been recorded
2011-09-05
02 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2011-09-04
02 Adrian Farrel
[Ballot comment]
I think I am missing the point of this document. It is not that I
disagree with it, but I don't see what …
[Ballot comment]
I think I am missing the point of this document. It is not that I
disagree with it, but I don't see what it hopes to achieve. Is it the
intention that any node that claims to be "IP-capable" must support
IPv6? Will this document achieve that?

The statement that a user wants an "Internet caable" device and will
not select specifically for IPv6 is fair. But redefining a term that
is current usage will not fix this.

---

There is a slight contradiction between the language in the abstract
where "IP-capable" is redefined to make IPv6 mandatory, and that in
Section 2 where you have "SHOULD not support IPv4 only".

---

Section 2

      It is expected that many existing devices and implementations will
      not be able to support IPv6 for one or more valid technical
      reasons, but for maximum flexibility and compatibility, a best
      effort SHOULD be made to update existing hardware and software to
      enable IPv6 support.

I think "will not be able to" might better read "cannot be updated to"
because "will not" conveys a confusing future tense regarding existing
implementations.

Does the update intend to be made in the field, or for future shipments?
Is there a statement here about not continuing to ship existing products?
2011-09-04
02 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-09-04
02 Pete Resnick [Ballot comment]
I see nothing harmful about this document, but I also don't see that it will have any real-world impact.
2011-09-04
02 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-09-03
02 Stewart Bryant
[Ballot comment]
I support the document and it's intent, but would ask the authors to think about the following:

These two statements seem contradictory:

  …
[Ballot comment]
I support the document and it's intent, but would ask the authors to think about the following:

These two statements seem contradictory:

    IPv6 support MUST be equivalent or better in quality and
      functionality when compared to IPv4 support in an IP
      implementation.

      It is expected that many existing devices and implementations will
      not be able to support IPv6 for one or more valid technical
      reasons, but for maximum flexibility and compatibility, a best
      effort SHOULD be made to update existing hardware and software to
      enable IPv6 support.

Do the authors mean in the first para : IPv6 support in NEW equipment and software .......

Also is there any danger that the demand for immediate equivalence
will introduce unintended delays in the deployment of more IPv6?
2011-09-03
02 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-09-02
02 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-09-02
02 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-08-31
02 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-08-29
02 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-08-26
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Ondřej Surý
2011-08-26
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Ondřej Surý
2011-08-19
02 Cindy Morgan Last call sent
2011-08-19
02 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 Support Required for all IP-capable nodes) to Proposed Standard


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'IPv6 Support Required for all IP-capable nodes'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Given the global lack of available IPv4 space, and limitations in
  IPv4 extension and transition technologies, this document deprecates
  the concept that an IP-capable node MAY support IPv4 _only_, and
  redefines an IP-capable node as one which supports either IPv6 _only_
  or IPv4/IPv6 dual-stack.  This document updates RFC1812, RFC1122 and
  RFC4084 to reflect the change in requirements.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv6-required/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv6-required/


No IPR declarations have been submitted directly on this I-D.


2011-08-19
02 Jari Arkko Placed on agenda for telechat - 2011-09-08
2011-08-19
02 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2011-08-19
02 Jari Arkko Ballot has been issued
2011-08-19
02 Jari Arkko Created "Approve" ballot
2011-08-19
02 Jari Arkko Last Call was requested
2011-08-19
02 (System) Ballot writeup text was added
2011-08-19
02 (System) Last call text was added
2011-08-19
02 (System) Ballot approval text was added
2011-08-19
02 Jari Arkko State changed to Last Call Requested from AD Evaluation.
2011-08-19
02 Jari Arkko Last Call text changed
2011-08-19
02 Jari Arkko
I have reviewed this draft, found it ready to move forward, and sent it to IETF Last Call. Thanks for writing this draft.

I only …
I have reviewed this draft, found it ready to move forward, and sent it to IETF Last Call. Thanks for writing this draft.

I only had a very minor editorial comment:

> IPv6 [RFC1883] was proposed in 1995 as, among other things, a
> solution to the limitations on globally unique addressing that IPv4's
> 32-bit addressing space represented, and has been under continuous
> refinement and deployment ever since.  [RFC2460].

s/.  [RFC2460]/ [RFC2460]/

(I think, it was not clear to me why you placed a reference here.)

Jari
2011-08-19
02 Jari Arkko State changed to AD Evaluation from Publication Requested.
2011-07-15
02 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is Julien Laganier, INTAREA co-chair. He
        has personally done a thorough review of the document. He
        believe the document is ready for forwarding to IESG for
        publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        The document was given adequate reviews. The Document Shepherd has
        no concerns about the depth or breadth of these reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The Document Shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The Document Shepherd has no such concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is WG consensus behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and
        informative. There are neither normative references in an unclear
        state, nor downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        The document has an IANA considerations sections that correctly
state that the document does not need IANA actions.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  Given the global lack of available IPv4 space, and limitations in
  IPv4 extension and transition technologies, this document deprecates
  the concept that an IP-capable node MAY support IPv4 _only_, and
  redefines an IP-capable node as one which supports either IPv6 _only_
  or IPv4/IPv6 dual-stack.  This document updates RFC1812, RFC1122 and
  RFC4084 to reflect the change in requirements.

    Working Group Summary

  The normal WG process was followed and the document as it stands now
  reflects WG consensus with nothing special worth mentioning.

    Document Quality

  The document was given adequate reviews. The Document Shepherd has
  no concerns about the depth or breadth of these reviews.
2011-07-15
02 Cindy Morgan Draft added in state Publication Requested
2011-07-15
02 Cindy Morgan [Note]: 'Julien Laganier (julien.ietf@gmail.com) is the document shepherd.' added
2011-07-15
02 Julien Laganier sent to secretariat for publication request
2011-07-15
02 Julien Laganier IETF state changed to Submitted to IESG for Publication from In WG Last Call
2011-07-11
01 (System) New version available: draft-ietf-intarea-ipv6-required-01.txt
2011-06-23
02 Julien Laganier Short 2.25 pages doc, can go into WGLC now.
2011-06-23
02 Julien Laganier IETF state changed to In WG Last Call from WG Document
2011-06-17
00 (System) New version available: draft-ietf-intarea-ipv6-required-00.txt