464XLAT: Combination of Stateful and Stateless Translation
RFC 6877

Note: This ballot was opened for revision 08 and is now closed.

(Ron Bonica) (was Discuss, Yes) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

Comment (2013-01-10 for -08)
No email
send info
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"?

(Adrian Farrel) No Objection

Comment (2013-01-09 for -08)
No email
send info
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?

(Stephen Farrell) No Objection

Comment (2013-01-08 for -08)
No email
send info
- 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

(Russ Housley) (was No Record, No Objection) No Objection

Comment (2013-01-07 for -08)
No email
send info
  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.

Barry Leiba No Objection

Comment (2012-12-27 for -08)
No email
send info
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?

(Robert Sparks) No Objection

Comment (2013-01-09 for -08)
No email
send info
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?

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-01-07 for -08)
No email
send info
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"

(Wesley Eddy) Abstain

Comment (2013-01-09 for -08)
No email
send info
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.

(Brian Haberman) (was No Record, No Objection) Abstain

Comment (2013-01-10 for -08)
No email
send info
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