IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
RFC 5969
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16 |
10 | (System) | Changed document authors from "Ole Troan" to "Ole Troan, Mark Townsley" |
2015-10-14 |
10 | (System) | Notify list changed from softwire-chairs@ietf.org, draft-ietf-softwire-ipv6-6rd@ietf.org to (None) |
2012-08-22 |
10 | (System) | post-migration administrative database adjustment to the No Objection position for David Harrington |
2010-08-10 |
10 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2010-08-10 |
10 | Cindy Morgan | [Note]: 'RFC 5969' added by Cindy Morgan |
2010-08-10 |
10 | (System) | RFC published |
2010-05-25 |
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-05-25 |
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-05-25 |
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-05-25 |
10 | Ralph Droms | [Note]: 'Alain Durand (adurand@juniper.net) and Dave Ward (dward@juniper.net) are the document shepherds. Note that Alain Durand''s e-mail address was updated on 5/25/2010.' added by Ralph ... [Note]: 'Alain Durand (adurand@juniper.net) and Dave Ward (dward@juniper.net) are the document shepherds. Note that Alain Durand''s e-mail address was updated on 5/25/2010.' added by Ralph Droms |
2010-05-25 |
10 | Ralph Droms | [Note]: 'Alain Durand (adurand@juniper.net) and Dave Ward (dward@juniper.net) are the document shepherds.' added by Ralph Droms |
2010-05-24 |
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-05-24 |
10 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-05-24 |
10 | (System) | IANA Action state changed to In Progress |
2010-05-24 |
10 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-05-24 |
10 | Amy Vezza | IESG has approved the document |
2010-05-24 |
10 | Amy Vezza | Closed "Approve" ballot |
2010-05-21 |
10 | (System) | Removed from agenda for telechat - 2010-05-20 |
2010-05-20 |
10 | Cindy Morgan | State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan |
2010-05-20 |
10 | Cindy Morgan | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cindy Morgan |
2010-05-20 |
10 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-05-20 |
10 | Dan Romascanu | [Ballot comment] The following comment made by Joel Jaeggli in his OPS-DIR review should be addresed: Once a mapping between ip4 addresses and /64 or ... [Ballot comment] The following comment made by Joel Jaeggli in his OPS-DIR review should be addresed: Once a mapping between ip4 addresses and /64 or shorter prefixes is established within a service provider, it's not going away for a long time. If used with frequency by ISPs (and customers of ISPS that use them as lirs) this will soak up sufficient ipv6 address space to move the requirements for direct assignments and ISP/LIR operations around considerably. This proposal if widely deployed therefore has impact on current prefix assignment policies for ipv6 in the RIRs. |
2010-05-20 |
10 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
2010-05-20 |
10 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded by Adrian Farrel |
2010-05-20 |
10 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-05-20 |
10 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
2010-05-20 |
10 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-05-20 |
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2010-05-20 |
10 | Dan Romascanu | [Ballot comment] |
2010-05-20 |
10 | Dan Romascanu | [Ballot discuss] |
2010-05-20 |
10 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2010-05-20 |
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-05-19 |
10 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
2010-05-19 |
10 | Russ Housley | [Ballot comment] Please consider the minor issues raised in the Gen-ART Review by Pete McCann on 17 May 2010. Section 7: ... [Ballot comment] Please consider the minor issues raised in the Gen-ART Review by Pete McCann on 17 May 2010. Section 7: The configured values for these four 6rd elements are identical for all CEs and BRs within a given 6rd domain. ... 6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a given 6rd domain. Taken together, these statements seem to imply that there can only be one BR for a given domain, or at least that all CEs must be configured to have the same set of BRs. I note that in section 7.1.1 it is possible to provision more than one BR address. Can this set be different for different CEs? I can imagine a situation where different CEs are homed on different BRs. Section 9.2: In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. This seems to say that the CE should match the source IPv4 address of the BR to the source address of the encapsulated IPv6 packet, when receiving traffic from a BR. I assume that isn't what you meant. |
2010-05-19 |
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-05-19 |
10 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington |
2010-05-19 |
10 | David Harrington | [Ballot comment] COMMENTS: some RFC2119 keywords are not capitalized; I think it would be clearer if they were. (lots of "may" that might be better ... [Ballot comment] COMMENTS: some RFC2119 keywords are not capitalized; I think it would be clearer if they were. (lots of "may" that might be better as "might") idnits in verbose mode reported a number of problems, but that might be the result of my saved version from the datatracker. Please check using the verbose options for idnits. |
2010-05-19 |
10 | David Harrington | [Ballot discuss] DISCUSSES cleared. |
2010-05-19 |
10 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-10.txt |
2010-05-18 |
10 | Tim Polk | [Ballot comment] I support issues 11) and 12) in Dave's discuss. With regard to 11), is there any scenario where the BR IPv4 address needs ... [Ballot comment] I support issues 11) and 12) in Dave's discuss. With regard to 11), is there any scenario where the BR IPv4 address needs to be reachable from outside the SP's 6rd domain? |
2010-05-18 |
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2010-05-17 |
10 | Dan Romascanu | [Ballot comment] 1. Broadband Forum's TR-69 Residential Gateway management interface should be an Informational Reference 2. The corect terminology for MIB modules is 'SMIv2 MIB ... [Ballot comment] 1. Broadband Forum's TR-69 Residential Gateway management interface should be an Informational Reference 2. The corect terminology for MIB modules is 'SMIv2 MIB module' and not 'SNMP MIB'. There is however one more aspect here - I do not think that configuration by SNMP can be seen as an automatic provisioning method - it should rather belong to (manual) configuration by operator, as CE is the server (agent) to be configured by SNMP commands. |
2010-05-17 |
10 | Dan Romascanu | [Ballot discuss] I support the comments made by David Harrington, and I have to add one more issue which strikes me as an omission that ... [Ballot discuss] I support the comments made by David Harrington, and I have to add one more issue which strikes me as an omission that needs to be clarified before I can approve this document. In Section 7.1: The four 6rd elements are set to values which are the same across all CEs within a 6rd domain. The values may be configured in a variety of manners, including automatic provisioning methods such as the Broadband Forum's "TR-69" Residential Gateway management interface, an XML-based object retrieved after IPv4 connectivity is established, a DNS record, an SNMP MIB, PPP IPCP, or manual configuration by an end-user or operator. This document describes how to configure the necessary parameters via a single DHCP option. In order to guarantee interoperability, a CE SHOULD implement this DHCP option. For consistency and convenience, this option format may be used by other automatic configuration methods by normative reference to this document. I do not see how interoperability of configuration can be guranteed without the implementation by a CE being a MUST. |
2010-05-17 |
10 | Dan Romascanu | [Ballot comment] 1. Broadband Forum's TR-69 Residential Gateway management interface should be an Informational Reference 2. The corect terminology for MIB modules is 'SMIv2 MIB ... [Ballot comment] 1. Broadband Forum's TR-69 Residential Gateway management interface should be an Informational Reference 2. The corect terminology for MIB modules is 'SMIv2 MIB module' and not 'SNMP MIB'. There is however one more aspect here - I do not think that configuration by SNMP can be seen as an automatic provisioning method - it should rather belong to (manual) configuration by operator, as CE is the server (agent) to be configured by SNMP commands. |
2010-05-17 |
10 | Dan Romascanu | [Ballot discuss] I support the comments made by David Harrington, and I have to add one more issue which trikes me as an omission that ... [Ballot discuss] I support the comments made by David Harrington, and I have to add one more issue which trikes me as an omission that needs to be clarified before I can approve this document. In Section 7.1: The four 6rd elements are set to values which are the same across all CEs within a 6rd domain. The values may be configured in a variety of manners, including automatic provisioning methods such as the Broadband Forum's "TR-69" Residential Gateway management interface, an XML-based object retrieved after IPv4 connectivity is established, a DNS record, an SNMP MIB, PPP IPCP, or manual configuration by an end-user or operator. This document describes how to configure the necessary parameters via a single DHCP option. In order to guarantee interoperability, a CE SHOULD implement this DHCP option. For consistency and convenience, this option format may be used by other automatic configuration methods by normative reference to this document. I do not see how interoperability of configuration can be guranteed without the implementation by a CE being a MUST. |
2010-05-17 |
10 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2010-05-11 |
10 | Amanda Baber | IANA comments: QUESTION: - what, if anything, do you want to put in the Data Length and Meaning portions of the DHCP Option Registry? Upon ... IANA comments: QUESTION: - what, if anything, do you want to put in the Data Length and Meaning portions of the DHCP Option Registry? Upon approval of this document, IANA will make the following assignment in the "BOOTP Vendor Extensions and DHCP Options" registry at http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml Tag Name Data Length Meaning Reference --- ---- ----------- ------- --------- [TBD] OPTION_6RD [RFC-softwire-ipv6-6rd-09] We understand the above to be the only IANA Action for this document. |
2010-05-11 |
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2010-05-11 |
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2010-05-10 |
10 | David Harrington | [Ballot comment] I recommend expanding 6rd in the title section 1: reference at first use of NBMA s/aside of/simultaneously with/ "can be made with 6rd" ... [Ballot comment] I recommend expanding 6rd in the title section 1: reference at first use of NBMA s/aside of/simultaneously with/ "can be made with 6rd" - I think changing to a different wording woudl be clearer than "made with" section 8, bullet 2. I found the sentence ill-formed. I think "will process" should have an object; I recommend rewording to improve the English. section 9.1: s/absent of/absent/ section 9.2 s/allow packets/allow forwarding of packets/ section 11. the second paragraph gives a number of examples; are they all needed? Could this be made more concise? Does the last paragraph of 11 belong more logically in section 10? section 12. "sink route" - reference on first use? |
2010-05-10 |
10 | David Harrington | [Ballot discuss] I thought this was a well-written document. I have a few COMMENTS where I think the text could be clearer, and a few ... [Ballot discuss] I thought this was a well-written document. I have a few COMMENTS where I think the text could be clearer, and a few questions on RFC2119 usage. 1) some RFC2119 keywords are not capitalized; I think it would be clearer if they were. 2) I think it is important to understand the deployemnt and operational considerations, so saying in section 1 that such consdierations is out of scope strikes me the wrong way. And the document does discuss operational considerations in a number of places, so I recommend removing the last paragraph of section 1. 3) 7.1.1 6rdPrefix - "SHOULD be set to zero" - why not MUST? When is it acceptable to not set them to zero? 4) 7.1.1 reference for first use of RIB 5) section 8 s/not recommended/NOT RECOMMENDED/ 6) in 9.1, s/may/might/ or s/may/could/ 7) 9.2 "SHOULD drop packets" - why not MUST? when is it acceptable to not drop the packets? 8) 10. s/may migrate/can migrate/ s/In the event native IPv6 connectivity is also available, the CE MAY disable 6rd./When native IPv6 connectivity is available, an administrator can choose to disable 6rd./ 9) 10. "Further considerations ... are not covered in this protocol specification." - where are they discussed? 10) the third paragraph of section 11 discusses leaving out redundant bits. Should this be written using MAY, and should this be discussed elesewhere, such as where the bit patterns are shown in 7? 11) section 12 discusses one possible mitigation. Shouldn't a standard mechanism for mitigation be defined so behaviors can be predicted? The description uses "may"; is MAY called for, or "might"? 12) I am unclear what "embeds" means in the two bullets in section 12, and the construction of "if ... but ..." seems ambiguous. I think this should be reworded. |
2010-05-10 |
10 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded by David Harrington |
2010-05-09 |
10 | Alexey Melnikov | [Ballot comment] 7. 6rd Configuration For a given 6rd domain, the BR and CE MUST be configured with the following four 6rd elements. ... [Ballot comment] 7. 6rd Configuration For a given 6rd domain, the BR and CE MUST be configured with the following four 6rd elements. The configured values for these four 6rd elements are identical for all CEs and BRs within a given 6rd domain. IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. For example, if there are no identical bits, IPv4MaskLen is 0 and the entire CE IPv4 address is used to create the 6rd delegated prefix. If there are 8 identical bits (e.g., the Private IPv4 address range 10.0.0.0/8 is being used), IPv4MaskLen is equal to 8. This might be obvious to other readers, but it wasn't obvious to me until I saw the example at the end of Section 7.1.1: you should say that the IPv4MaskLen high-order bits are stripped from the IPv4 address before constructing the corresponding 6rd delegated prefix. 6rdPrefix The 6rd IPv6 prefix for the given 6rd domain. 6rdPrefixLen The length of the 6rd IPv6 prefix for the given 6rd domain. Does this include the IPv4 part? I don't think it does, but you should clarify. |
2010-05-09 |
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2010-05-06 |
10 | Cindy Morgan | Last call sent |
2010-05-06 |
10 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2010-05-06 |
10 | Ralph Droms | Placed on agenda for telechat - 2010-05-20 by Ralph Droms |
2010-05-06 |
10 | Ralph Droms | State Changes to Last Call Requested from AD Evaluation by Ralph Droms |
2010-05-06 |
10 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-05-06 |
10 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2010-05-06 |
10 | Ralph Droms | Ballot has been issued by Ralph Droms |
2010-05-06 |
10 | Ralph Droms | Created "Approve" ballot |
2010-05-06 |
10 | (System) | Ballot writeup text was added |
2010-05-06 |
10 | (System) | Last call text was added |
2010-05-06 |
10 | (System) | Ballot approval text was added |
2010-05-06 |
10 | Ralph Droms | State Changes to AD Evaluation from Publication Requested by Ralph Droms |
2010-05-06 |
10 | Ralph Droms | [Note]: 'Alain Durand (adurand76@comcast.net) and Dave Ward (dward@juniper.net) are the document shepherds.' added by Ralph Droms |
2010-05-06 |
09 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-09.txt |
2010-05-05 |
10 | Cindy Morgan | [Note]: 'Alain Durand (adurand76@comcast.net) and Dave Ward (dward@juniper.net) are the document shepherds.' added by Cindy Morgan |
2010-05-05 |
10 | 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? Alain Durand and Dave Ward are the Shepherds. Both shepherds have reviewed the document and believe it ready 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? We saw evidence of extensive review on the mailing list. The document has been presented in softwires, v6ops, and dhc working groups. (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? No 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. This is strictly a protocol specification. We believe that an operational document discussing some of the various tradeoffs and choices when deploying 6rd, particularly in the presence of native IPv6 as well, is necessary. Such a document will be part of the Softwires WG deliverables. We know of no IPR disclosures related to this document. (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? Some individuals have expressed concern that the document doesn't go into enough depth on certain subjects like MTU discovery/adaptation, but in the chair's opinion most of those subject are general issues, not specific to 6rd. Aside of this, the document has strong support in the WG. (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 theInternet-Drafts Checklist <http://www.ietf.org/id-info/checklist.html> andhttp://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? no need for doctor reviews. Few very minor nits (the most important one in a reference to move from normative to informative). The authors have agreed to fix those during the final review process. (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]. See above, the reference to RFC 3964 should be moved from the normative section to the informative section. (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? There is a request for one dhcp option code point in the IANA considerations section. (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 is no formal language in the document. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a Service Provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service which is equivalent to native IPv6 at the sites which are served by the mechanism. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document was discussed in depth and well-reviewed. There is some disagreement over small details, but overall WG consensus is strong to publish this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are multiple, independent, interoperable implementations of this protocol today. One service provider has a large deployment of this protocol, several other service providers have announced plans to deploy or interest in deploying. |
2010-05-05 |
10 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-03-23 |
08 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-08.txt |
2010-02-23 |
06 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-06.txt |
2010-02-22 |
07 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-07.txt |
2010-02-15 |
05 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-05.txt |
2010-02-03 |
04 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-04.txt |
2010-01-06 |
03 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-03.txt |
2010-01-05 |
02 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-02.txt |
2009-10-26 |
01 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-01.txt |
2009-08-27 |
00 | (System) | New version available: draft-ietf-softwire-ipv6-6rd-00.txt |