Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
RFC 6333
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-08-27 |
11 | (System) | Received changes through RFC Editor sync (added Errata tag) |
2015-10-14 |
11 | (System) | Notify list changed from softwire-chairs@ietf.org, draft-ietf-softwire-dual-stack-lite@ietf.org to (None) |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Wesley Eddy |
2011-08-09 |
11 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2011-08-08 |
11 | (System) | RFC published |
2011-06-13 |
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-06-10 |
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-06-10 |
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-06-10 |
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-05-31 |
11 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-05-31 |
11 | (System) | IANA Action state changed to In Progress |
2011-05-31 |
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-05-31 |
11 | Amy Vezza | IESG has approved the document |
2011-05-31 |
11 | Amy Vezza | Closed "Approve" ballot |
2011-05-31 |
11 | Amy Vezza | Approval announcement text regenerated |
2011-05-31 |
11 | Amy Vezza | Ballot writeup text changed |
2011-05-27 |
11 | Jari Arkko | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2011-05-27 |
11 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-11.txt |
2011-05-18 |
11 | David Harrington | Request for Last Call review by TSVDIR Completed. Reviewer: Dan Wing. |
2011-05-18 |
11 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
2011-05-17 |
11 | Wesley Eddy | [Ballot Position Update] Position for Wesley Eddy has been changed to No Objection from Discuss |
2011-05-13 |
10 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-10.txt |
2011-05-13 |
11 | Stephen Farrell | [Ballot comment] (3) 8.1 - ought that say "the address ranges in the pools"? (Instead of the "the address range in the pools") |
2011-05-13 |
11 | Stephen Farrell | [Ballot discuss] |
2011-05-13 |
11 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2011-05-12 |
09 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-09.txt |
2011-05-02 |
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-05-02 |
08 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-08.txt |
2011-04-28 |
11 | Cindy Morgan | Removed from agenda for telechat |
2011-04-28 |
11 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-04-28 |
11 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27 |
11 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27 |
11 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27 |
11 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26 |
11 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26 |
11 | Sean Turner | [Ballot comment] The reference for 1918 should be normative based on the following: However, it SHOULD operate its own DHCP(v4) server handing out … [Ballot comment] The reference for 1918 should be normative based on the following: However, it SHOULD operate its own DHCP(v4) server handing out [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home. |
2011-04-26 |
11 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26 |
11 | Robert Sparks | [Ballot comment] Consider adding a short discussion or perhaps an example of how services that sit on the Internet side of an AFTR (especially those … [Ballot comment] Consider adding a short discussion or perhaps an example of how services that sit on the Internet side of an AFTR (especially those in the same administrative domain of the AFTR) that need to know which B4 IPv4 traffic came through might get that information from the AFTR (perhaps using the information in the extended binding table described in section 6.6). Showing how a location query in a protocol like HELD (RFC5985) would be answered would be a good example. |
2011-04-26 |
11 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26 |
11 | Stephen Farrell | [Ballot comment] 8.3: s/require ALG to work properly/require ALGs to work properly/ (maybe) There are a few other English language issues (mainly improper singluar/plurals). |
2011-04-26 |
11 | Stephen Farrell | [Ballot discuss] (1) Where's it say that DNSSEC needs to work through the B4 thing? I don't know if that's problematic or not but RFC4033 … [Ballot discuss] (1) Where's it say that DNSSEC needs to work through the B4 thing? I don't know if that's problematic or not but RFC4033 does say the DNS proxies need to be security aware for DNSSEC to work (section 6 of 4033) so that may be worth repeating here. (2) Is the "SHOULD NOT interfere" language in 7.2 sufficient? I don't know but it seems awfully short. Is there anything similar that needs to be said about TLS or DTLS? (3) 8.1 - ought that say "the address ranges in the pools"? (Instead of the "the address range in the pools") (4) How would the AFTR impact on anti-spam solutions such as DNSRBLs? I think that may warrant a mention. |
2011-04-26 |
11 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-25 |
11 | Wesley Eddy | [Ballot comment] In section 5.2, the final paragraph should be slightly more clear that it's saying to fragment the IPv6 tunnel packet into multiple IPv6 … [Ballot comment] In section 5.2, the final paragraph should be slightly more clear that it's saying to fragment the IPv6 tunnel packet into multiple IPv6 fragments, and not the inner IPv4 packet into multiple tunnelled IPv6 packets. It may be worth mentioning here also that fragmenting the IPv4 packet instead is not a good idea or alternative. Typos: - in Section 6.4, "a B4 elements" -> "a B4 element" |
2011-04-25 |
11 | Wesley Eddy | [Ballot discuss] Section 5.6 is a little strange, since it says that the topic is out of scope, but doesn't give any hint as to … [Ballot discuss] Section 5.6 is a little strange, since it says that the topic is out of scope, but doesn't give any hint as to where this information might be found, why it's deemed out of scope, or who it would be in-scope for. I would think this should be easy to clarify. |
2011-04-25 |
11 | Wesley Eddy | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-25 |
11 | David Harrington | [Ballot comment] There are a few places where I feel the document could be improved, if the document is revised. section 4.1 what is horizontal … [Ballot comment] There are a few places where I feel the document could be improved, if the document is revised. section 4.1 what is horizontal scaling? 4.2 last sentence duplicates section 1 diagrams would help 6.3 discusses clients, but clients are not defined. 6.4 the English is a little weak; 8.5 carrier-grade nat is not defined B.1 s/DCHP/DHCP/ figure 1 uses 10.0 addresses, while the text talks about 192.168 addresses. are the addresses used consistent with reserved example addresses? s/concentrartor/concentrator/ B.1.2 SE not defined on first use. B.2.1 why a.b.c.d rather than 192.0.0.2? |
2011-04-25 |
11 | David Harrington | [Ballot discuss] There are a few question I would like to discuss before approving this document. 1) 6.3 makes assumptions, but doesn't prescribe behavior if … [Ballot discuss] There are a few question I would like to discuss before approving this document. 1) 6.3 makes assumptions, but doesn't prescribe behavior if the assumption is false. what should happen if an AFTR runs out of resources due to reassembly? 2) 6.5 why MAY, and not SHOULD or MUST? 3) 7.1 why SHOULD and not MUST? what are the acceptable exceptions to SHOULD? 4) 7.2 why SHOULD NOT rather than MUST NOT? what are the acceptable exceptions, what types of interference are expected/allowed, and how should implementations handle the interference? 5) 7.3 why is this out of scope? 6) 8.1 s/must not/MUST NOT/ 7) 8.2 why SHOULD rather than MUST? acceptable exceptions? how should implementations respond to the exceptional case for interoperability? |
2011-04-25 |
11 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-24 |
11 | Adrian Farrel | [Ballot comment] Thanks for a fine and readble document. Herewith, a few minor points you might like to look at to improve the document. --- … [Ballot comment] Thanks for a fine and readble document. Herewith, a few minor points you might like to look at to improve the document. --- I was surprised that the following statements use a weak "MAY" The B4 element MAY use any other addresses within the 192.0.0.0/29 range. The AFTR MAY use the well-known IPv4 address 192.0.0.1 "MAY" is usually used when there is some other more normal behavior, but you don't say what that is. --- 7.2. VPN Dual-stack lite implementations SHOULD NOT interfere with the functioning of IPv4 or IPv6 VPNs. Seems a bit of an odd use of "SHOULD NOT". I'm not clear whether you are commentng that "in your view the DS-Lite technology should not cause anything to break" or observing that it would be a broken implementation that *chose* to interfere with VPN function. --- 8.4. Sharing global IPv4 addresses AFTR shares a single IP to multiple users. s/to/address with/ --- 8.5. Port forwarding / keep alive Work on a control plane to the carrier-grade NAT is done in the PCP working group at IETF. The PCP protocol enables What does the second 'P' in "PCP" stand for? |
2011-04-24 |
11 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-22 |
11 | Ralph Droms | [Ballot Position Update] New position, Recuse, has been recorded |
2011-04-22 |
11 | Russ Housley | [Ballot comment] Please consider the editorial comments from the Gen-ART Review by Roni Even on 9-Apr-2011. |
2011-04-22 |
11 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-22 |
11 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2011-04-22 |
11 | Jari Arkko | Ballot has been issued |
2011-04-22 |
11 | Jari Arkko | Created "Approve" ballot |
2011-04-15 |
11 | Jari Arkko | Placed on agenda for telechat - 2011-04-28 |
2011-04-15 |
11 | Jari Arkko | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-04-12 |
11 | Amanda Baber | IANA has a question about the IANA Actions in this document. IANA understands that, upon approval of this document, the authors have requested a single … IANA has a question about the IANA Actions in this document. IANA understands that, upon approval of this document, the authors have requested a single IANA Action as follows: "Allocate a well know IPv4 192.0.0.0/29 network prefix." "Reserving a /29 allows for 6 possible interfaces on a multi-home node. The IPv4 address 192.0.0.1 is reserved as the IPv4 address of the default router for such dual- stack lite hosts." IANA Question --> IANA needs to clarify the routing scope of the assignment requested by the authors, so that IANA can record it in the registry: http://www.iana.org/assignments/iana-ipv4-special-registry As an example of what the IANA is looking for, please examine: http://www.iana.org/assignments/iana-ipv6-special-registry |
2011-04-12 |
11 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-04-11 |
11 | Wesley Eddy | Request for Last Call review by TSVDIR is assigned to Dan Wing |
2011-04-11 |
11 | Wesley Eddy | Request for Last Call review by TSVDIR is assigned to Dan Wing |
2011-04-06 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2011-04-06 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2011-03-29 |
11 | Amy Vezza | Last call sent |
2011-03-29 |
11 | Amy Vezza | 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> … 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: <softwires@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-softwire-dual-stack-lite-07.txt> (Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion' <draft-ietf-softwire-dual-stack-lite-07.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-04-12. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-dual-stack-lite/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-dual-stack-lite/ |
2011-03-29 |
11 | Jari Arkko | Last Call was requested |
2011-03-29 |
11 | (System) | Ballot writeup text was added |
2011-03-29 |
11 | (System) | Last call text was added |
2011-03-29 |
11 | (System) | Ballot approval text was added |
2011-03-29 |
11 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2011-03-29 |
11 | Jari Arkko | Last Call text changed |
2011-03-03 |
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-03-03 |
07 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-07.txt |
2010-08-17 |
11 | Jari Arkko | I have now completed my review of the draft. Here are the remaining comments: Overall: The draft is in relatively good shape. I saw a … I have now completed my review of the draft. Here are the remaining comments: Overall: The draft is in relatively good shape. I saw a number of cases where you should have been more precise in the specification, but those cases can definitely be corrected. There are a few missing things, but again something that can be taken care of. I am expecting a new revision. Technical: Shouldn't the draft talk about how a service provider AFTR makes it less likely that the user can exert control with protocols like UPnP-IGD? You should bring up this issue up early in the document, and then you can point to Appendix C for possible future work around that limitation. What happens if two B4s are chained together, both using the reserved address range? > However, moving the NAT functionality from the home gateway to the > core of the service provider network and sharing IPv4 addresses among > customers create additional requirements when logging data for abuse > usage. With any architecture where an IPv4 address does not uniquely > represent an end host, IPv4 addresses and a timestamps are no longer > sufficient to identify a particular broadband customer. Additional > information such as transport protocol information will be required > for that purpose. For example, we suggest to log the transport port > number for TCP and UDP connections. What needs to be logged depends on the element that you are in. A peer would log the other side's transport port number, an AFTR would log the line/tunnel ID and the transport port number. > The AFTR performs translation functions for interior IPv4 hosts at > RFC 1918 addresses or at the IANA reserved address range (TBA by > IANA). How do we know which address range is being used? > If the interior host is properly using the authorized IPv4 > address with the authorized transport protocol port range such as A+P > semantic for the tunnel, the AFTR can simply forward without > translation to permit the authorized address and port range to > function properly. All packets with unauthorized interior IPv4 > addresses or with authorized interior IPv4 address but unauthorized > port range MUST NOT be forwarded by the AFTR. This prevents rogue > devices from launching denial of service attacks using unauthorized > public IPv4 addresses in the IPv4 source header field or unauthorized > transport port range in the IPv4 transport header field. For > example, rogue devices could bombard a public web server by launching > TCP SYN ACK attack. The victim will receive TCP SYN from random IPv4 > source addresses at a rapid rate and deny TCP services to legitimate > users. What is a properly authorized IPv4 address? What about an authorized transport protocol? > If IPv6 address spoofing prevention is not in place, the AFTR should > perform further sanity checks on the IPv6 address of incoming IPv6 > packets. For example, it should check if the address has really been > allocated to an authorized customer. How? Isn't address checking of this kind really just another form of spoofing prevention? Editorial: > The source IPv4 is the RFC1918 addressed > assigned by the Dual-Stack home router which is unique to each host > behind the home gateway. ... address assigned ... > or > example, rogue devices could bombard a public web server by launching > TCP SYN ACK attack. The victim will receive TCP SYN from random IPv4 > source addresses at a rapid rate and deny TCP services to legitimate > users. Should this be ... launching *a* TCP SYN ACK attack? And maybe add a reference hree. Also, ... receive a TCP SYN packet from random ... |
2010-08-17 |
11 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko |
2010-08-17 |
11 | Jari Arkko | Part 2 of my review. Technical: I wonder if the draft should say something more about MTU handling. In particular, should it attempt to inform … Part 2 of my review. Technical: I wonder if the draft should say something more about MTU handling. In particular, should it attempt to inform clients on its inner interface of the real MTU so that fragmentation is not needed. Here's what RFC 5844 said in a very similar situation. o The DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Interface MTU option [RFC2132]. The DHCP servers in the Proxy Mobile IPv6 domain MUST be configured to include the Interface MTU option. The MTU value SHOULD reflect the tunnel MTU for the bidirectional tunnel between the mobile access gateway and the local mobility anchor. (Though I wonder if this text is right either, as presumably you have to ask for options before handing them out...) > 8.1. NAT pool > > > AFTRs MAY operate distinct, non overlapping NAT pools. Those NAT > pools do not have to be continuous. This text is unclear. Are you talking about different AFTRs operating with different sets of public address pools? Or one AFTR running for some set of clients, using a number of different address pools? Or assigning a public address for one client from different pools for different connections? These are all different, and I think you mean the second alternative but I'm not sure. Please specify. > The AFTR should only perform a minimum number of ALG for the classic > applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through > and enable the users to use their own ALG on statically or > dynamically reserved ports instead. First off, shouldn't this be written as "... should only implement a minimum ..." The more substantial comment is that the recommendation is very weak. I do not know if the application list above is complete or if I am expected to implement additional ALGs. Secondly, are there RFCs that we can point to for these ALGs? Finally, I do not know how to provide the use-own-alg functionality. But I'm reading on, maybe its described later in the document. > There is an important operational difference if those N ports are > pre-allocated in a cookie-cutter fashion versus allocated on demand > by incoming connections. This is a difference between an average of > N ports and a maximum of N ports. Several service providers have > reported an average number of connections per customer in the single > digits. At the opposite end, thousands or tens of thousands of ports > could be use in a peak by any single customer browsing a number of > AJAX/Web 2.0 sites. Is your argument assuming a traditional web browsing usage model, i.e.., that users actively use an application and that the computer sits idle at other times? I am not sure this the model we have going forward. Many popular applications are starting to update content and perform various actions even when the browser sits idle, for instance. I think there will still be a difference between average and maximum, though it is perhaps not as pronounced over the time dimension but could still be very visible between users. > In order to achieve higher address space reduction ratios, it is > recommended that service provider do not use this cookie-cutter > approach, and, on the contrary, allocate ports as dynamically as > possible, just like on a regular NAT. Given the above, perhaps the text should warn that in order for this trick to work at all, there really has to be a difference either in the between-users or the time dimension, and that trends in networking may easily reduce either one. > When dynamic port assignment is used to maximize the number of > subscribers sharing the AFTR global IPv4 addresses, the AFTR should > implement checks to avoid DOS attack through exhaustion of available > ports. How? Editorial: > In broadband home networks, sometime devices are directly connected Sometimes? Some devices? > Under this scenario, the customer device is a dual-stack capable host > that is only provisioned by the service provider only with IPv6. Would this be better: "... is provisioned by the service provider only with IPv6"? |
2010-08-10 |
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-08-10 |
06 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-06.txt |
2010-08-09 |
11 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2010-08-09 |
11 | Jari Arkko | I am reviewing this draft. Please find the first batch of my comments below: Technical: > The common thinking for more than 10 years has … I am reviewing this draft. Please find the first batch of my comments below: Technical: > The common thinking for more than 10 years has been that the > transition to IPv6 will be based on the dual stack model and that > most things would be converted this way before we ran out of IPv4. > > However, this has not happened. The IANA free pool of IPv4 addresses > will be depleted soon, well before any significant IPv6 deployment > will have occurred. > > This document revisits the dual-stack model and introduces the dual- > stack lite technology aimed at better aligning the costs and benefits > of deploying IPv6. Dual-stack lite will provide the necessary bridge > between the two protocols, offering an evolution path of the Internet > post IANA IPv4 depletion. I would partially rewrite this. The claims are strong, but at least from my point of view, while dual stack lite solves specific problems it is not a general replacement for dual stack. Here's my suggested new text: The common thinking for more than 10 years has been that the transition to IPv6 will be based solely on the dual stack model and that most things would be converted this way before we ran out of IPv4. However, this has not happened. The IANA free pool of IPv4 addresses will be depleted soon, well before sufficient IPv6 deployment will exist. As a result, many IPv4 services have to continue to be provided even under severely limited address space. This document specifies the dual-stack lite technology which is aimed at better aligning the costs and benefits in service provider networks. Dual-stack lite will enable both continued support for IPv4 services and incentives for the deployment of IPv6. It also de-couples IPv6 deployment in the service provider network from the rest of the Internet, making incremental deployment easier. At the same I would also rewrite parts of the abstract: OLD: This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6. NEW: This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. > A DS-Lite home gateway SHOULD NOT operate a NAT function on a B4 > interface, as the NAT function will be performed by the AFTR in the > service provider's network. I am not sure what it means to operate a NAT function on an interface. Presumably it would be operated between two interfaces. Perhaps you wanted to say that "the GW SHOULD NOT operate a NAT function". > It SHOULD also advertise itself as a DNS server in the DHCP > Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy > to accept DNS IPv4 requests from home hosts and send them using IPv6 > to the service provider DNS servers, as described in Section 5.5. It is unclear to me why you need to make these recommendations (but I'm reading on). This material in general seems more suited to a homegateway RFC than DS-Lite RFC. Also, I do not understand why the usual passing of service provider DNS server addresses is unsuitable in this configuration. I see the comment later that says a large number of DNS requests might create a lot of unnecessary state. But there seems to be complexity that the text glosses over. Operating a real DNS server might be more than what simple gateways want to implement or configure. Its not clear that proxied requests from the gateway are in any way less taxing for the NAT (at least my Linux box uses a different source port on every request, so I might as well have all hosts send their own requests). And I'm not sure if you wanted to say "in addition" or "alternatively" for the DNS proxy. > 3. Terminology I am pretty sure there should be other terms as well, starting from dual stack (RFC 4213), NAT, CPE/home gateway, etc. Editorial: > == Outdated reference: A later version (-04) exists of > draft-cheshire-nat-pmp-03 > > == Outdated reference: A later version (-02) exists of > draft-droms-softwires-snat-01 > > == Outdated reference: A later version (-01) exists of > draft-durand-dual-stack-lite-00 > > == Outdated reference: A later version (-05) exists of > draft-nishitani-cgn-04 > > == Outdated reference: draft-templin-seal has been published as RFC 5320 Idnits reports that some of the references are outdated. Please correct these. Section 1 would benefit from an overview of what the remaining sections will cover. The document talks about home gateways and CPEs. Is there a difference, or should you be using the same term? |
2010-08-09 |
11 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2010-07-12 |
11 | 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? Dave Ward is the Shepherd. He has reviewed the documents and believes they 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 documents 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 DS-Lite would be valuable. 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, such as MTU handling, but in the chair's opinion most of those subject are general issues, not specific to DS-lite. 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? Passes nits, no need for doctor reviews. (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]. Clean. (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 of the DHCP option document and a request for a well known IPv4 prefix in the DS-Lite document. (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. DHCP option This document specifies two DHCPv6 options which are meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. DS-Lite This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6. Dual-stack lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). 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. Several service providers have announced plans to deploy or interest in deploying. |
2010-07-12 |
11 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-07-12 |
11 | Cindy Morgan | [Note]: 'Dave Ward (dward@juniper.net) is the document shepherd.' added by Cindy Morgan |
2010-07-10 |
05 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-05.txt |
2010-03-08 |
04 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-04.txt |
2010-02-03 |
03 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-03.txt |
2009-10-26 |
02 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-02.txt |
2009-07-13 |
01 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-01.txt |
2009-03-04 |
00 | (System) | New version available: draft-ietf-softwire-dual-stack-lite-00.txt |