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 <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <int-area@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (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' <draft-ietf-intarea-ipv6-required-01.txt> 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 |