464XLAT: Combination of Stateful and Stateless Translation
draft-ietf-v6ops-464xlat-10
Yes
(Ron Bonica)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Stewart Bryant)
Abstain
Note: This ballot was opened for revision 08 and is now closed.
Ron Bonica Former IESG member
(was Discuss, Yes)
Yes
Yes
(for -09)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-01-09 for -08)
Unknown
I found this document surprisingly easy to read and understand. Thank you. One small point to consider if you are revising the document... Section 5 point 3 3. IPv6-only networks are simpler and therefore less expensive to operate. Simpler and less expensive than what?
Barry Leiba Former IESG member
No Objection
No Objection
(2012-12-27 for -08)
Unknown
Thanks, Fred, for the excellent shepherd writeup, which heads off a number of questions. I'd like to see the document capture some of the points in the shepherd writeup a bit more clearly, and I think that's easily done by adding a paragraph to the beginning of Section 2. This is a non-blocking comment, but I'd very much like to see something like the following (please wordsmith as appropriate; I've written this by paraphrasing things from the shepherd writeup) inserted at the beginning of Section 2: "This document describes one way to deploy an IPv6-only core, built on a 464XLAT architecture. For economic reasons, certain networks, including some 3GPP-based networks, must choose between deploying IPv4 or IPv6: a true dual-stack network is far more costly. Providing an IPv6-only core involves either tunneling or translation. This document describes how to build one type of solution based on translation. What is described herein has been implemented and shown to work well, and is the best current practice for building a service based on 464XLAT architecture." Are the authors willing to consider that? Does what I've written above seem reasonable, or is it at least something you can start with?
Benoît Claise Former IESG member
No Objection
No Objection
(for -08)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -08)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -08)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2013-01-10 for -08)
Unknown
Updated 1/10. I support the addition of Barry's suggested text as an introduction to section 2. Please confirm that this sentence in that text is true: "For economic reasons, certain networks, including some 3GPP-based networks, must choose between deploying IPv4 or IPv6: a true dual-stack network is far more costly." I have been advised that there is no longer an economic penalty for dual-stack in 3GPP. I suggest section 2 be renamed "Applicability Statement" or something similar. Following up on my earlier comment 3, here is suggested text for an additional list item in section 2: 3. The use of encapsulation based methods such as DS-Lite and MAP-E is not possible in the network due to requirements for traffic engineering and policy enforcement constructs that preclude encapsulated packets. Thanks to Cameron for the prompt followup to my earlier comments. ===== (original comment) I have some comments regarding the readability and presentation of the specification. I think the specification is correct as written, and many network admins would be ablt to figure out the details, but it could some additional explicit details and clarifications would be helpful. 1. In the definition of "CLAT" (section 4), what does the phrase "perform router function" mean? 2. The last sentence in the definition of "CLAT" could be clarified. 3. Isn't item 1 in the list in section 9.1 a motivation for 464XLAT in addition to those listed in section 5? 4. If it's true that the IPv4 hosts behind the CLAT cannot commnicate with hosts on the IPv6 Internet, it might be helpful to add a short statement noting that constraint. 5. In section 6.2, is NAT44 always required for tethering? If the CLAT is provided an IPv6 prefix, can't it use stateless translation directly without NAT44? 6. In section 8.1, does it make a difference which of the address formats from RFC 6052 are used? 7. I think it would be helpful, in the diagram in section 8.1, to give more details of the various address translations; e.g., what prefixes and address formats are used for the the stateless translations in the CLAT; are both the destination and source addresses translated using stateful N:1 translation in the PLAT? 8. Section 8.3 would be clearer if there was a short explanation of the two address translations in the CLAT (CLAT-local-IPv4->IPv6 and IPv6-with-embedded-globalIPv4->IPv4) and how the existing text about NAT64 prefix discovery ties in with those translations. I think it would also help if the third paragraph immeidately followed the first paragraph, as they both deal with CLAT-local-IPv4->IPv6 translation. 9. Section 8.4 would be clearer if the last sentence included an explanation that DNS queries from the client that are not sent to the CLAT DNS proxy SHOULD be allowed and are translated and forwarded just like any other IP traffic. 10. The CLAT and IPv6 router functions seem a little conflated in section 8.5. DHCPv6 would be a gateway function, not a CLAT function; sending RAs should be mentioned in DHCPv6 is mentioned. 11. I think I understand that section 8.6 explains that 464XLAT does not support direct communication between IPv4 hosts behind different CLATs. Does "IPv4-only services" means "IPv4-only hosts on the Internet"?
Robert Sparks Former IESG member
No Objection
No Objection
(2013-01-09 for -08)
Unknown
I would also like to see the extra context Barry is suggesting adding. A question for Fred - (not a request for change) - which 2026 characterization were you looking at when choosing BCP for this document? I don't think it matches any of them. It looks like it's one of the documents 2026 argues _against_ using BCP with "Specifically, BCPs should not be viewed simply as stronger Informational RFCs, but rather should be viewed as documents suitable for a content different from Informational RFCs.". What is it about this document that makes Informational inappropriate?
Russ Housley Former IESG member
(was No Record, No Objection)
No Objection
No Objection
(2013-01-07 for -08)
Unknown
Please consider the comment from the Gen-ART Review by Miguel Garcia on 5-Jan-2013: > > Expand acronyms at first occurrence. This includes: > GGSN (used in Figure 2), PDP (used in Figure 2, but not expanded > until Section 7.2 later), ISP, 3GPP, GSM, and UMTS.
Sean Turner Former IESG member
No Objection
No Objection
(2013-01-07 for -08)
Unknown
A couple of nits in s1 from the secdir review: "a explanation" should be "an explanation" "using combination" should be "using a combination" "is delegated IPv6 prefix" should be "is delegated an IPv6 prefix"
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-01-08 for -08)
Unknown
- I wondered how this impacts on or work with DNSSEC? Be nice if you said. - 8.4: Why doesn't it say that the CLAT MUST allow a client to use any DNS server? It says SHOULD, in fact 8.4 seems to say SHOULD for all the options here with no MUST at all, so I wonder if a CLAT implementation is guaranteed to work with any client at all. - 9.1: What does "traffic monitoring for each destination IPv4 address" mean here? - The apps-dir review [1] seems to have generated some agreed changes that are yet to be made. [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08293.html
Stewart Bryant Former IESG member
No Objection
No Objection
(for -08)
Unknown
Brian Haberman Former IESG member
(was No Record, No Objection)
Abstain
Abstain
(2013-01-10 for -08)
Unknown
I very much agree with Wes' commentary on calling this a Best Current Practice. Additionally, I am very troubled by the presence of an IPR claim (RAND with possible royalty/fee, no less) given that one of the authors publicly stated that this document defines nothing new and only describes how to use two existing standards... From a message to the v6ops list[1]: "464XLAT does not define any new standards. It is an informational document that simply describes how to use RFC6145 and RFC6146 to achieve the desired result of making IPv6-only network acceptable for subscribers today." Therefore, I am balloting Abstain. [1] : https://www.ietf.org/mail-archive/web/v6ops/current/msg11988.html
Wesley Eddy Former IESG member
Abstain
Abstain
(2013-01-09 for -08)
Unknown
I don't think deploying this type of service is good for Internet users, as it only supports a limited type of application flows, and it would be depressing if it looks like the IETF finds this acceptable and even calls it a "Best Current Practice". It should really be Informational, in my opinion, and bear strong words saying it's not advocated as a service model to be pursued.