Pros and Cons of IPv6 Transition Technologies for IPv4aaS
draft-ietf-v6ops-transition-comparison-03
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-04-21
|
03 | (System) | Changed action holders to Jordi Palet Martinez, Lee Howard, Warren Kumari, Ian Farrer, Gábor Lencse, Richard Patterson (IESG state changed) |
|
2022-04-21
|
03 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2022-04-21
|
03 | Cindy Morgan | Changed consensus to Yes from Unknown |
|
2022-04-21
|
03 | Martin Duke | [Ballot comment] Thanks to Brian Trammell for the tsvart review. It would be nice to at least point to draft-ietf-tsvwg-natsupp-23 to discuss the issues with … [Ballot comment] Thanks to Brian Trammell for the tsvart review. It would be nice to at least point to draft-ietf-tsvwg-natsupp-23 to discuss the issues with SCTP and NAT. |
|
2022-04-21
|
03 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
|
2022-04-21
|
03 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. The comparison between the IPv4aaS technologies is well done. Please find below some blocking … [Ballot discuss] Thank you for the work put into this document. The comparison between the IPv4aaS technologies is well done. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Ron Bonica for the shepherd's write-up and the justification for the intended status, I would have appreciated a little more text about the WG consensus though. Authors may also expect an internet directorate review by Dave Lawrence, the delay in the review should not hinder the publication process though. Finally, I would like to apologise for not sending those comments earlier (just before telechat! there is NO need to reply immediately) but also during the WG process as I try to follow closely the V6OPS work. I hope that this helps to improve the document, Regards, -éric As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ## Section 2.2 A important and trivial to fix "translates the IPv4 payload to public IPv4 source address using a stateful NAPT44" => "translates the IPv4 source address in the payload to public IPv4 source address using a stateful NAPT44" ## Section 3.3 "Here, the centralized network function (lwAFTR or BR) only needs to perform stateless encapsulation/decapsulation or NAT64", actually in MAP-T, BR does translation. ## Section 3.4 I am afraid that the number of IPv4 public addresses that are required goes beyond this "simple" computation. There are also other constraints such as laws, MoU, rules and operators BCP, see: - https://bipt.be/operators/publication/consultation-of-11-october-2016-regarding-the-conditions-of-use-of-ipv4cgn (alas in French/Dutch) but meaning that in my country, Belgium, an IP address can be shared by 16 subscribers max - https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online |
|
2022-04-21
|
03 | Éric Vyncke | [Ballot comment] # COMMENTS Note for the shepherding AD: missing consensus boilerplate. Generally, I would have appreciated some text about the difference between a residential … [Ballot comment] # COMMENTS Note for the shepherding AD: missing consensus boilerplate. Generally, I would have appreciated some text about the difference between a residential CE (serving multiple hosts) and a mobile hand-set (serving usually a single host -- except when tethering) ## Section 1 "As the deployment of IPv6 becomes more prevalent", I hope that this sentence is a little outdated in 2022... s/The following IPv6 transition technologies are covered:/The following IPv4aaS technologies are covered:/ ? ## Section 2.1 s/it performs stateless NAT64 translation/it performs stateless NAT46 translation/ ? About "64:ff9b::/96 Well-Known Prefix", suggest adding a reference to RFC 8215. s/In the operator's network, the provider-side translator/At the edge the operator's network, the provider-side translator/ ? Hummm "when a dedicated /64 "... RFC 8215 is a /48, the text above is /96 and now it is a /64 ? While I appreciate the text "When an IPv6-only client or application communicates with an IPv4-only server", the reader may benefit of the dual text for IPv4-only client app communicates with IPv4-only server. Should figure 1 use "IPv4-only app" rather than "IPv4-only device" ? Especially when the actual device/handset is IPv6 only ? ## Section 2.3 Please explain / expand what is "only performs A+P routing" at the first use. I like the last paragraph about hair-pinning the IPv4 traffic BUT this should also be explained in all sub-sections of section 2. ## Section 3.1 Is it worth mentioning whether the tunnels require any control plane ? How can a tunnel not require additional header ? While I understand what the authors mean, I suggest to use the word "overhead". "to implement buffering and fragment re-assembly in the BR node" but "BR node" is only applicable to MAP-[ET]. ## Section 3.2 The 3rd paragraph is more on multicast and deserves a section on its own (or added in section 3.6). Especially the last sentence, which is about encapsulation in a NAT section ;-) The 4th paragraph has also little to do with NAT but more with L4 visibility for ECMP/ACL, suggest to make its own section. ## Section 3.3 Should "CGN" be introduced before ? (at least expanded ?) Please expand "EAMT" even if a reference is given. ## Section 3.4 Even if somehow obvious, please prefix "port" with "TCP/UDP" Please provide references to the numbers of 300 ports and 4 devices. Does the above also apply to 464XLAT ? ## Section 4.1.1 A little strange to see a 3-row table associated to "on the basis of two aspects"... Suggest to have a single row indicating T/E. ## Section 4.2 This section would benefit from version / date for the browser data and for Netfilter implementation. A reference to Netfilter would be another plus. ## Section 4.4.1 Please add version for the miscellaneous OS and add a date for "at the time of writing is not available in MacOS." ## Section 8 Should DNSSEC interactions with translation (and not with encapsulation) be discussed ? # NITS ## Section 2.1 Figure 1, mostly cosmetic the "stateless/stateful" qualification is once before xLAT once after ;-) Let's try to be consistent. ## Section 2.2 "Basic Broadband Bridging' (B4)" while RFC 6333 uses "Basic Bridging BroadBand (B4)" ;-) ## Section 2.4 "The CE (Customer-Edge)", CE has already been expanded before. s/The client address/port allocation size is a design parameter/The client address/port allocation size is a configuration parameter/ ## Section 4.4.2 A table would be easier to read rather than a list ;-) ## Section 4.5.2 and 4.5.3 Do the authors have more recent data than in 2018 and 2020 ? |
|
2022-04-21
|
03 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
|
2022-04-21
|
03 | Robert Wilton | [Ballot comment] Thanks Dan for the OPSDIR review. I support Roman's discuss comment regarding comparing security based on the binary object size - I think … [Ballot comment] Thanks Dan for the OPSDIR review. I support Roman's discuss comment regarding comparing security based on the binary object size - I think that there are many more significant factors that come into play (source language, LOC in source, how widely is the technology used/deployed, experience of the developers, is the code being actively maintained, what level of regression/fuzz testing exists) ... Thank you for this document, I think that it is useful. Some minor comments/suggestions: 2.1. 464XLAT The customer-side translator (CLAT) is located in the customer's device, and it performs stateless NAT64 translation [RFC7915] (more precisely, Is NAT64 definitely right here, and not NAT46? 3.4. IPv4 Pool Size Considerations Often it is assumed that each user-device (computer, tablet, smartphone) behind a NAT, could simultaneously use about 300 ports. Typically, in the case of a residential subscriber, there will be a maximum of 4 of those devices in use simultaneously, which means a total of 1,200 ports. Is a maximum of 4 devices in simultaneous use on a residential internet connection realistic? This feels low to me, and potentially this is likely to be increasing over time. If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E and MAP-T) make use of a 5-tuple for tracking the NAT connections, the number of ports required per subscriber can be limited as low as 4 ports per subscriber. However, the practical limit depends on the desired limit for parallel connections that any single host behind the NAT can have to the same address and port in Internet. Note that it is becoming more common that applications use AJAX and similar mechanisms, so taking that extreme limit is probably not a very a safe choice. Previously we were talking about 300 - 1200 ports/subscriber. It wasn't really clear to me how this goes down to just 4 ports per subscriber. If QUIC/HTTP3 deployment continues to pick up then I would expect that may reduce the number of ports required since it handled better multiplexing of streams. Finally, I think that having some sort of high level summary (maybe in tabular form) may be beneficial, e.g., comparing relative MTU overheads of the approaches, stateful vs stateless, IPv4 address scalability/usage. Thanks, Rob |
|
2022-04-21
|
03 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2022-04-20
|
03 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this informational document. It helps to get an overview of IPv4aaS technologies and I learned + got reminded number … [Ballot comment] Thanks for working on this informational document. It helps to get an overview of IPv4aaS technologies and I learned + got reminded number of stuffs while reading this document. I have following comments/observations, I think addressing them would help improving this document even more. - Section 2.1: it has a note regarding mobile network and CLAT. It would be great if this references to some appropriate document ( any architectural description document should do the job here). - Section 3.1 : it strongly recommends the MTU in the IPv6-only domain to be "well managed". First, can the "strongly recommends" be replaced by normative text? second and more important, where is the definition of "well managed"? is there any description available or BCP's that we can refer to? To me, the "well managed" here is that we have sufficiently large MTU to support the tunneling and translation. if we are only meaning that feature the we can very well write it instead of asking them to be "well managed". If we mean more then I would recommend to either define what we mean by "well managed" or refer to where this is described. - Section 4.5.2 and section 4.5.3: these sections refers to some figures from existing deployments. what are the sources of such figures? did the WG run some analysis or tests to derive those data? were they published somewhere? I think it is necessary to refer to the data source or describe the methods on how those data were collected and comprehended to be included here if those figures supposed to help the reader to understand and influence their decisions. |
|
2022-04-20
|
03 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2022-04-20
|
03 | Lars Eggert | [Ballot comment] Section 3.4, paragraph 1, comment: > Often it is assumed that each user-device (computer, tablet, > smartphone) behind a NAT, could … [Ballot comment] Section 3.4, paragraph 1, comment: > Often it is assumed that each user-device (computer, tablet, > smartphone) behind a NAT, could simultaneously use about 300 ports. > Typically, in the case of a residential subscriber, there will be a > maximum of 4 of those devices in use simultaneously, which means a > total of 1,200 ports. Is there a reference for these numbers? They seem awfully low. Section 4.2, paragraph 1, comment: > 4.2. Tradeoff between Port Number Efficiency and Stateless Operation I'm missing some text in this section that clearly describes the bad and hard to debug consequences of assigning too few ports to an end user, and ideally a recommendation to assign a conservatively large number of ports. Section 5, paragraph 1, comment: > 5. Performance Comparison This section is entirely about future work, which could IMO be removed before the RFC is published. (This should go into I-D.lencse-v6ops-transition-benchmarking.) The datatracker state does not indicate whether the consensus boilerplate should be included in this document. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "native"; alternatives might be "built-in", "fundamental", "ingrained", "intrinsic", "original" Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/0LD7N9OxJR4KupJKbaISQ9518ng). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Uncited references: [RFC2119] and [RFC8174]. Paragraph 683, nit: > rovide network operators with an easy to use reference to assist in selecting > ^^^^^^^^^^^ It appears that two hyphens are missing. Paragraph 2448, nit: > t have been developed makes it time consuming for a network operator to iden > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Paragraph 6866, nit: > 275,000 subscribers being served with a only a /22. In the other IPv4aaS tec > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Paragraph 7145, nit: > t extreme limit is probably not a very a safe choice. This extremely reduced > ^^^^^^^^^^^^^ It seems like one article is redundant in this context. Paragraph 10011, nit: > time of writing is not available in MacOS. The remaining four solutions are > ^^^^^ The operating system from Apple is written "macOS". Paragraph 10205, nit: > ar networks, as they are neither standardised nor implemented in UE devices. > ^^^^^^^^^^^^ Do not mix variants of the same word ("standardise" and "standardize") within a single text. Paragraph 11483, nit: > with a stateless technology alone. Thus a centralized NAPT44 model may be th > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". Paragraph 11593, nit: > ns that the traffic flow will cross thru the AFTR, lwAFTR or BR, depending o > ^^^^ The word "thru" is informal. Consider replacing it with "through". Paragraph 11654, nit: > head. However, in the case of those mechanism that use a NAT46 function, in > ^^^^^^^^^^^^^^^ The plural demonstrative "those" does not agree with the singular noun "mechanism". Paragraph 12129, nit: > e format of [RFC2544] including "hard wired" source and destination port num > ^^^^^^^^^^ This expression is normally spelled as one or with a hyphen. |
|
2022-04-20
|
03 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2022-04-20
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2022-04-19
|
03 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2022-04-19
|
03 | Erik Kline | [Ballot comment] # Internet AD comments for {draft-ietf-v6ops-transition-comparison-03} CC @ekline ## Comments An note throughout: consider preferring "transport layer" over "layer-4". ### S2.3, … [Ballot comment] # Internet AD comments for {draft-ietf-v6ops-transition-comparison-03} CC @ekline ## Comments An note throughout: consider preferring "transport layer" over "layer-4". ### S2.3, S4.3 * Suggest: s/layer-4 ports/transport layer ports/. ### S3.2 * Suggest: s/layer-4 next-header/transport layer next-header/. ### S3.4 * With respect to the 300 ports x ~4 devices numbers: I think it would be an improvement if there were some study that could be cited to back up these numbers. * You might consider noting here that in some jurisdictions the number of available ports per subscriber for CGNAT/Large-scale NAT could be set by a relevant authority. I tried to find a reference to the Belgian ISP regulation limited CGNAT deployments to 16 subscribers per public IPv4 address, but I couldn't easily find it. Maybe I'm misremembering something. (update) Aha, I see you mention something in S4.2. Thanks. * Some text from RFC 6888 might be useful, in terms of requirements for sizing CGNATs. ### S4.5.2, S4.5.3 * Probably best to have a citation here for where these numbers come from. ### S4.7 * You might see if RFC 6888 section 4 is worth referring to here. ### S5 * Since the text raises the point, you might explain what sorts of "tricks" are needed, and why. ### S8 * I support Roman's recommendation to remove the "bugs proportional to code size" text altogether. |
|
2022-04-19
|
03 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2022-04-18
|
03 | Roman Danyliw | [Ballot discuss] ** Section 4.7 notes detailed connection level logging of user behaviors. Please discuss the privacy and security implications – securing these logs at … [Ballot discuss] ** Section 4.7 notes detailed connection level logging of user behaviors. Please discuss the privacy and security implications – securing these logs at rest from unauthorized access, retention, etc. ** Section 8. According to the simplest model, the number of bugs is proportional to the number of code lines. Please refer to Section 4.4.3 for code sizes of CE implementations. What is the intent of this text and how should the reader use it to choose a IPv4aaS? Taking the simple model above and the text from Section 4.4.3 (“… 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6 …”), is it suggesting that 464XLAT the most “secure” protocol because it’s code size the smallest? How does that metric work across different implementation? I recommend removing this text. |
|
2022-04-18
|
03 | Roman Danyliw | [Ballot comment] Thank you to Joe Salowey for the SECDIR review. I too would have found it useful for a comparative security analysis across the … [Ballot comment] Thank you to Joe Salowey for the SECDIR review. I too would have found it useful for a comparative security analysis across the different IPv4aaS techniques. ** Section 3.2 For encapsulation, there is an IPv6 header followed by an IPv4 header. This results in less entropy for hashing algorithms, and may mean that devices in the traffic path that perform header inspection (e.g. router ACLs or firewalls) require the functionality to look into the payload header. Can this text please be clarified. What is the link between less entropy and payload inspection. ** Section 3.4. Often it is assumed that each user-device (computer, tablet, smartphone) behind a NAT, could simultaneously use about 300 ports. Typically, in the case of a residential subscriber, there will be a maximum of 4 of those devices in use simultaneously, which means a total of 1,200 ports. These text starts of with “often it is assumed” – who makes that assumption? What is the basis of this model and where does the assumption about the number of devices comes from? Is there a reference that can be provided? ** Section 3.4 An alternative approximation for the other IPv4aaS technologies, when dynamically assignment of addresses is not possible, must ensure sufficient number of ports per subscriber. That means 1,200 ports, and typically, it comes to 2,000 ports in many deployments. What is the basis of these values? ** Section 4.4.1. Can anything be said about commercial implementations of the “operator side functionality”? ** Section 4.4.1 ...but at the time of writing is not available in MacOS. To ensure this assessment ages well and future readers don’t have to check the publication date of the RFC against MacOS version numbers, consider adding a MacOS version number. ** Section 4.4.2. In broadband networks, there are some deployments of 464XLAT, MAP-E and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite being the most common, but lw4o6 taking over in the last years. Please refer to Table 2 and Table 3 of [LEN2019] for a limited set of deployment information. Is there a reference for these trends? They don’t appear to fall out of Table 2 or 3 of [LEN2019]. ** Section 4.5.2 and 4.5.3. Both sections appear to cite real work measurement. Can a reference or a more detailed explanation of the source be provided. For example, is the 3/4 vs. 1/4 split in Section 4.5.2 a representative pattern of some kind? ** Section 5. I don’t follow the intent of this section. There are no performance results to share. This text appears to be foreshadowing another draft (draft-lencse-v6ops-transition-benchmarking). However, this draft is -00 and contains no results. I recommend removing this section. ** Section 8. Please state that the implementers of any of the fives IPv4aaS should consult the Security Considerations of the respective RFCs documenting them. Editorial ** idnits returned: == Unused Reference: 'RFC2119' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 1220, but no explicit reference was found in the text ** Section 2.1. Editorial OLD In general, state close to the end-user network (i.e. at the CE - Customer Edge router) is not perceived as problematic as state in the operators network. NEW In general, keeping state in devices close to the end-user network (i.e. at the CE - Customer Edge router) is not perceived as problematic as keeping state in the operator’s network. ** Section 3.4. Please expand or cite “EAMT entries”. ** Section 3.4. Please expand AJAX. ** Section 3. Table 2. Please provide a reference for TR-069. |
|
2022-04-18
|
03 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
|
2022-04-17
|
03 | Warren Kumari | Manually placed in IESG Eval (it is on the 2022-04-21 Telechat) |
|
2022-04-17
|
03 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2022-04-05
|
03 | Cindy Morgan | Placed on agenda for telechat - 2022-04-21 |
|
2022-04-05
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2022-04-05
|
03 | Jordi Palet Martinez | New version available: draft-ietf-v6ops-transition-comparison-03.txt |
|
2022-04-05
|
03 | (System) | New version accepted (logged-in submitter: Jordi Palet Martinez) |
|
2022-04-05
|
03 | Jordi Palet Martinez | Uploaded new revision |
|
2022-03-19
|
02 | Joseph Salowey | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. Sent review to list. |
|
2022-03-18
|
02 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
|
2022-03-16
|
02 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2022-03-16
|
02 | (System) | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-v6ops-transition-comparison-02, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-v6ops-transition-comparison-02, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Michelle Thangtamsatid IANA Services Specialist |
|
2022-03-15
|
02 | Brian Trammell | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Brian Trammell. Sent review to list. |
|
2022-03-15
|
02 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Dan Romascanu. Sent review to list. |
|
2022-03-15
|
02 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list. |
|
2022-03-11
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
|
2022-03-11
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
|
2022-03-10
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
|
2022-03-10
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
|
2022-03-09
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
|
2022-03-09
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
|
2022-03-07
|
02 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Brian Trammell |
|
2022-03-07
|
02 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Brian Trammell |
|
2022-03-04
|
02 | Bernie Volz | Request for Last Call review by INTDIR is assigned to David Lawrence |
|
2022-03-04
|
02 | Bernie Volz | Request for Last Call review by INTDIR is assigned to David Lawrence |
|
2022-03-04
|
02 | Éric Vyncke | Requested Last Call review by INTDIR |
|
2022-03-04
|
02 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2022-03-04
|
02 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-03-18):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-v6ops-transition-comparison@ietf.org, rbonica@juniper.net, … The following Last Call announcement was sent out (ends 2022-03-18):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-v6ops-transition-comparison@ietf.org, rbonica@juniper.net, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-v6ops-transition-comparison-02.txt> (Pros and Cons of IPv6 Transition Technologies for IPv4aaS) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Pros and Cons of IPv6 Transition Technologies for IPv4aaS' <draft-ietf-v6ops-transition-comparison-02.txt> as Informational RFC 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 last-call@ietf.org mailing lists by 2022-03-18. 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 Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/ No IPR declarations have been submitted directly on this I-D. |
|
2022-03-04
|
02 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2022-03-04
|
02 | Warren Kumari | Last call was requested |
|
2022-03-04
|
02 | Warren Kumari | Last call announcement was generated |
|
2022-03-04
|
02 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
|
2022-03-04
|
02 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
|
2022-03-04
|
02 | Warren Kumari | Ballot has been issued |
|
2022-03-04
|
02 | Warren Kumari | Ballot approval text was generated |
|
2022-03-04
|
02 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
|
2022-03-04
|
02 | Warren Kumari | Created "Approve" ballot |
|
2022-03-04
|
02 | Warren Kumari | Ballot writeup was changed |
|
2022-03-03
|
02 | Gábor Lencse | New version available: draft-ietf-v6ops-transition-comparison-02.txt |
|
2022-03-03
|
02 | (System) | New version approved |
|
2022-03-03
|
02 | (System) | Request for posting confirmation emailed to previous authors: Gabor Lencse <lencse@hit.bme.hu>, Ian Farrer <ian.farrer@telekom.de>, Jordi Martinez <jordi.palet@theipv6company.com>, Lee Howard … Request for posting confirmation emailed to previous authors: Gabor Lencse <lencse@hit.bme.hu>, Ian Farrer <ian.farrer@telekom.de>, Jordi Martinez <jordi.palet@theipv6company.com>, Lee Howard <lee@asgard.org>, Richard Patterson <richard.patterson@sky.uk> |
|
2022-03-03
|
02 | Gábor Lencse | Uploaded new revision |
|
2022-01-13
|
01 | Ron Bonica | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? INFORMATIONAL. This is appropriate because it does not define any new standard or best practice. (2) 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: Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. 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? No Document Quality: The document compares transition technologies that have been deployed. It appears to draw upon operational experience. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Ron Bonica is the Document Shepherd. Warren Kumari is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read several versions of this draft (including the current version) and believe that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. This document is essentially a review of several transition mechanisms. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No issues (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) 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? Many WG participants have reviewed and supported the draft. There was no significant opposition. (10) 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 publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Requirements Language section should be removed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? Yes (14) 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 plan for their completion? No (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not request anything of IANA (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
|
2022-01-13
|
01 | Ron Bonica | Responsible AD changed to Warren Kumari |
|
2022-01-13
|
01 | Ron Bonica | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2022-01-13
|
01 | Ron Bonica | IESG state changed to Publication Requested from I-D Exists |
|
2022-01-13
|
01 | Ron Bonica | IESG process started in state Publication Requested |
|
2022-01-13
|
01 | Ron Bonica | Intended Status changed to Informational from None |
|
2022-01-13
|
01 | Ron Bonica | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? INFORMATIONAL. This is appropriate because it does not define any new standard or best practice. (2) 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: Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. 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? No Document Quality: The document compares transition technologies that have been deployed. It appears to draw upon operational experience. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Ron Bonica is the Document Shepherd. Warren Kumari is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read several versions of this draft (including the current version) and believe that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. This document is essentially a review of several transition mechanisms. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No issues (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) 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? Many WG participants have reviewed and supported the draft. There was no significant opposition. (10) 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 publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Requirements Language section should be removed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? Yes (14) 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 plan for their completion? No (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not request anything of IANA (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
|
2022-01-13
|
01 | Ron Bonica | Tag Doc Shepherd Follow-up Underway set. |
|
2022-01-13
|
01 | Ron Bonica | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
|
2022-01-04
|
01 | Ron Bonica | Notification list changed to rbonica@juniper.net because the document shepherd was set |
|
2022-01-04
|
01 | Ron Bonica | Document shepherd changed to Ron Bonica |
|
2021-10-16
|
01 | Gábor Lencse | New version available: draft-ietf-v6ops-transition-comparison-01.txt |
|
2021-10-16
|
01 | (System) | New version approved |
|
2021-10-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: Gabor Lencse <lencse@hit.bme.hu>, Ian Farrer <ian.farrer@telekom.de>, Jordi Martinez <jordi.palet@theipv6company.com>, Lee Howard … Request for posting confirmation emailed to previous authors: Gabor Lencse <lencse@hit.bme.hu>, Ian Farrer <ian.farrer@telekom.de>, Jordi Martinez <jordi.palet@theipv6company.com>, Lee Howard <lee@asgard.org>, Richard Patterson <richard.patterson@sky.uk> |
|
2021-10-16
|
01 | Gábor Lencse | Uploaded new revision |
|
2021-04-15
|
00 | (System) | This document now replaces draft-lmhp-v6ops-transition-comparison instead of None |
|
2021-04-15
|
00 | Gábor Lencse | New version available: draft-ietf-v6ops-transition-comparison-00.txt |
|
2021-04-15
|
00 | (System) | New version approved |
|
2021-04-15
|
00 | Gábor Lencse | Request for posting confirmation emailed to submitter and authors: =?utf-8?q?G=C3=A1bor_Lencse?= <lencse@hit.bme.hu>, Ian Farrer <ian.farrer@telekom.de>, Jordi Palet Martinez <jordi.palet@theipv6company.com>, Lee … Request for posting confirmation emailed to submitter and authors: =?utf-8?q?G=C3=A1bor_Lencse?= <lencse@hit.bme.hu>, Ian Farrer <ian.farrer@telekom.de>, Jordi Palet Martinez <jordi.palet@theipv6company.com>, Lee Howard <lee@asgard.org>, Richard Patterson <richard.patterson@sky.uk> |
|
2021-04-15
|
00 | Gábor Lencse | Uploaded new revision |