464XLAT: Combination of Stateful and Stateless Translation
draft-ietf-v6ops-464xlat-10

[Ballot comment]
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"?

[Ballot comment]
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

[Ballot comment]
Updated 1/10.
I support the addition of Barry's suggested text as an introduction to
section 2.  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"?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
This is a placeholder DISCUSS. The IPR statement troubles me. I will remove this DISCUSS when the chairs clarify the WG's position regarding the IPR

[Ballot comment]
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?

[Ballot 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"?

[Ballot comment]

- 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

[Ballot comment]
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"

[Ballot comment]

  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.

[Ballot comment]
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?

IANA has reviewed draft-ietf-v6ops-464xlat-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (464XLAT: Combination of Stateful and Stateless Translation) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- '464XLAT: Combination of Stateful and Stateless Translation'
  as Best Current Practice

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 2012-12-21. 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


  This document describes an architecture (464XLAT) for providing
  limited IPv4 connectivity across an IPv6-only network by combining
  existing and well-known stateful protocol translation RFC 6146 in the
  core and stateless protocol translation RFC 6145 at the edge. 464XLAT
  is a simple and scalable technique to quickly deploy limited IPv4
  access service to IPv6-only edge networks without encapsulation.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1730/

> (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?

draft-ietf-v6ops-464xlat is requesting, and says it is requesting, BCP status.

There was significant discussion of this in the WG. One way to interpret this is "this is how to deploy an IPv6-only core in a mobile network", which the softwire MAP folks would heartily dispute. The other way, which the working group chose to consider, was "this is *a* way that has been identified to deploy an IPv6-only core, and is the recommended way to offer the 464xlat service." The chairs take no position. The best way to over IPv6-only networking as a service is to deploy an IPv6-only network, and for economic reasons mobile networks that offer services prior to 3GPP release 9 are forced to deploy one of IPv4 or IPv6, as a true dual stack network doubles their per-APN costs. Hence, the question surrounding an IPv6-only core is either about tunneling or about translation. If one chooses translation, and if one specifically chooses this type of service, this document describes how to build it. It is the "Best Current Practice" for building this type of service.

> (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:

  This document describes an architecture (464XLAT) for providing
  limited IPv4 connectivity across an IPv6-only network by combining
  existing and well-known stateful protocol translation RFC 6146 in the
  core and stateless protocol translation RFC 6145 at the edge. 464XLAT
  is a simple and scalable technique to quickly deploy limited IPv4
  access service to IPv6-only edge networks without encapsulation.

> Working Group Summary:

The working group, for the most part, the working group found this uncontroversial; it is a way to deploy an IPv6-only core in a mobile network and use translation to provide access to IPv4 content. The folks working on the software "MAP" technology objected to it as it is a deployment technology simpler than MAP and takes shortcuts that may hobble such deployments in the long term. R?mi Despr?s made suggestions on the list and had some support. However, the suggested approaches were more "different" than "better", and neither built consensus nor demonstrated issues requiring changes to the document.

> Document Quality:

The document is a description of how to build a certain service offering. There are ways to build other service offerings, and they may or may not be better. However, the service offering described has been implemented and in fact works.

> Personnel:
>
> Who is the Document Shepherd? Who is the Responsible Area Director?

The document shepherd is Fred Baker. The area director is Ron Bonica.

> (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.

The working group chairs contributed comments to the review.

> (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

> (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.

There was discussion in the working group, which was addressed in the document. There was one primary person submitting comments, whom the chairs considered "in the rough".

> (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.

http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-v6ops-464xlat indicates that China Mobile has filed an IPR notice. The working group was advised and did not comment.

> (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?

There is general support for the document as "a way to deploy an IPv6-only core to a mobile network".

> (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.)

Nobody has threatened an appeal. I don't think R?mi Despr?s, who is also losing his "MAP" argument in softwire, appreciates approval of a document that competes with his.

> (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.

None identified.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

It contains no formal language.

> (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?

The normative references are all to RFCs.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

The normative references are all to RFCs, and are all current.

> (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.

It does not change the status of existing RFCs.

> (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 5226).

The IANA section calls for no new parameters, and the document calls for no new parameters.

> (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.
>
> (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, etc.

Really?