IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
RFC 6127
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20 |
06 | (System) | Received changes through RFC Editor sync (changed abstract to 'When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur … Received changes through RFC Editor sync (changed abstract to 'When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.') |
2015-10-14 |
06 | (System) | Notify list changed from jari.arkko@piuha.net, townsley@cisco.com, draft-arkko-townsley-coexistence@ietf.org to (None) |
2012-08-22 |
06 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22 |
06 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
2011-05-26 |
06 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2011-05-25 |
06 | (System) | RFC published |
2010-10-25 |
06 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-10-25 |
06 | (System) | IANA Action state changed to No IC from In Progress |
2010-10-25 |
06 | (System) | IANA Action state changed to In Progress |
2010-10-25 |
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-10-25 |
06 | Amy Vezza | IESG has approved the document |
2010-10-25 |
06 | Amy Vezza | Closed "Approve" ballot |
2010-10-25 |
06 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2010-10-22 |
06 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner |
2010-10-22 |
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-10-22 |
06 | (System) | New version available: draft-arkko-townsley-coexistence-06.txt |
2010-10-22 |
06 | (System) | Removed from agenda for telechat - 2010-10-21 |
2010-10-21 |
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-10-21 |
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-10-21 |
06 | Sean Turner | [Ballot discuss] This is a discuss-discuss (nothing for the authors for the authors to do) From the secdir review: It would be nice if either … [Ballot discuss] This is a discuss-discuss (nothing for the authors for the authors to do) From the secdir review: It would be nice if either this draft or the one referenced [wing-nat-pt-replacement-comparison] would prescribe techniques to mitigate [DoS and spoofing] attacks. I understand this draft just documents what the thinking was back then, but is there a reason it shouldn't document techniques to mitigate DoS and spoofing attacks? |
2010-10-21 |
06 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner |
2010-10-21 |
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-10-20 |
06 | Adrian Farrel | [Ballot comment] I like this document and find it useful *now*. However, the Abstract and the start of Section 1 make a strong statement about … [Ballot comment] I like this document and find it useful *now*. However, the Abstract and the start of Section 1 make a strong statement about this being a historical record of the thinking over two years ago. I find that detracts from the value of the document. Maybe this is just a statement that I would have prefered the I-D to have been published sooner. --- I don't find the Security section very strong or helpful. I think that rather than pointing to an example (non-normative) I-D, you should actually set out generic the security issues for the solutions to consider. In other words, a little general security guidance in line with the other guidance about the solutions in the document. After all, you don't say in Section 2 "Description of solutions can be found elsewhere, for instance in [I-D.durand-dual-stack-lite]." And a couple of nits I found along the way... --- Section 1 page 5 s/public addresses and on the IPv4/public addresses, and on the IPv4/ --- Section 2.1 more hosts behind the gateway (GW) as there are IPv4 s/as/than/ |
2010-10-20 |
06 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel |
2010-10-20 |
06 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
2010-10-20 |
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2010-10-20 |
06 | Adrian Farrel | [Ballot comment] I don't find the Security section very strong or helpful. I think that rather than pointing to an example (non-normative) And a couple … [Ballot comment] I don't find the Security section very strong or helpful. I think that rather than pointing to an example (non-normative) And a couple of nits I found along the way... --- Section 1 page 5 s/public addresses and on the IPv4/public addresses, and on the IPv4/ --- Section 2.1 more hosts behind the gateway (GW) as there are IPv4 s/as/than/ |
2010-10-20 |
06 | Adrian Farrel | [Ballot discuss] It's a tiny, pettifogging Discuss, but... I like this document and find it useful *now*. That suggests that its classification as Informational is … [Ballot discuss] It's a tiny, pettifogging Discuss, but... I like this document and find it useful *now*. That suggests that its classification as Informational is correct. However, the Abstract and the start of Section 1 make a strong statement about this being a historical record of the thinking over two years ago. That would make this a Historic RFC. I would prefer to remove the text about history, and keep the document Informational |
2010-10-20 |
06 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel |
2010-10-19 |
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-10-18 |
06 | Stewart Bryant | [Ballot comment] A well written document. nit: old The tunnel could created in any number of new The tunnel could be created in any number … [Ballot comment] A well written document. nit: old The tunnel could created in any number of new The tunnel could be created in any number of |
2010-10-18 |
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-10-18 |
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-10-18 |
06 | Ralph Droms | [Ballot comment] From the Security Directorate review: The security considerations section does exist and defers to wing-nat-pt-replacement-comparison for some of the solutions. … [Ballot comment] From the Security Directorate review: The security considerations section does exist and defers to wing-nat-pt-replacement-comparison for some of the solutions. wing-nat-pt-replacement-comparison discusses possible DoS and spoofing attacks when sharing an IPv4 amongst multiple subscribers. Though it would be nice if either this draft or the one referenced would prescribe techniques to mitigate such attacks. General comments: None. Editorial comments: s/reader to be consider/reader to consider/ This sentence should be restructured for readability purposes: For deployments where the GW is owned and operated by the customer, this becomes operational overhead for the Internet Service Provider (ISP) that it will no longer be able to rely on the customer and the seller of the GW device for. s/of NAT444 need/of NAT444 needs/ s/tunnel could created/tunnel could be created/ |
2010-10-18 |
06 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms |
2010-10-14 |
06 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-10-12 |
06 | Amy Vezza | State changed to Waiting for AD Go-Ahead from In Last Call by Amy Vezza |
2010-10-11 |
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Shawn Emery. |
2010-09-29 |
05 | (System) | New version available: draft-arkko-townsley-coexistence-05.txt |
2010-09-29 |
06 | Jari Arkko | [Ballot Position Update] New position, Recuse, has been recorded by Jari Arkko |
2010-09-17 |
06 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2010-09-15 |
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2010-09-15 |
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2010-09-13 |
06 | Amy Vezza | Last call sent |
2010-09-13 |
06 | Amy Vezza | State changed to In Last Call from Last Call Requested by Amy Vezza |
2010-09-13 |
06 | Ralph Droms | Placed on agenda for telechat - 2010-10-21 by Ralph Droms |
2010-09-13 |
06 | Ralph Droms | Status Date has been changed to 2010-09-15 from None by Ralph Droms |
2010-09-13 |
06 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-09-13 |
06 | Ralph Droms | State changed to Last Call Requested from AD Evaluation::AD Followup by Ralph Droms |
2010-09-13 |
06 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2010-09-13 |
06 | Ralph Droms | Ballot has been issued by Ralph Droms |
2010-09-13 |
06 | Ralph Droms | Created "Approve" ballot |
2010-09-13 |
06 | (System) | Ballot writeup text was added |
2010-09-13 |
06 | (System) | Last call text was added |
2010-09-13 |
06 | (System) | Ballot approval text was added |
2010-09-06 |
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-09-06 |
04 | (System) | New version available: draft-arkko-townsley-coexistence-04.txt |
2009-11-17 |
06 | Ralph Droms | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Ralph Droms |
2009-08-18 |
06 | Ralph Droms | State Changes to AD Evaluation::AD Followup from AD Evaluation by Ralph Droms |
2009-07-15 |
06 | Ralph Droms | State Changes to AD Evaluation from Publication Requested by Ralph Droms |
2009-07-15 |
06 | Ralph Droms | Note field has been cleared by Ralph Droms |
2009-07-13 |
06 | Cindy Morgan | (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 … (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? There is no shepherd. Jari Arkko has reviewed the draft in its entirety in July 2009 and made small updates where necessary. The authors believe the draft is ready to be published as a historical record of the thinking in late 2008 when various new work items for IPv6 - IPv4 coexistence were taken on by the IETF. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There has been discussion of both the document itself, and its recommendations for new work. To a large extent those recommendations have already been adopted. (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? It is obvious that the community interested in the co-existence issue needs to review this in Last Call before we publish this. But other than that, there are no specific concerns or specific review needs. (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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? We believe that the community in general agrees with the position that the document takes. It is possible that the port based routing parts are controversial. However, the document does not that those parts have not yet been adopted by the IETF. So in this sense the document seems to reflect the real state of affairs. (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 http://www.ietf.org/ID-Checklist.html 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, no concerns. (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]. Yes, no downref concerns. (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 suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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? Yes, no problems. (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? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. Working Group Summary This document was originally created as input to the Montreal co-existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time. Document Quality At least some of the recommendations from the document have been adopted through rechartering of the Behave and Softwire working groups. |
2009-07-13 |
06 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2009-07-13 |
03 | (System) | New version available: draft-arkko-townsley-coexistence-03.txt |
2009-07-13 |
02 | (System) | New version available: draft-arkko-townsley-coexistence-02.txt |
2009-07-06 |
01 | (System) | New version available: draft-arkko-townsley-coexistence-01.txt |
2009-03-23 |
06 | (System) | Document has expired |
2008-09-19 |
00 | (System) | New version available: draft-arkko-townsley-coexistence-00.txt |