Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-03.txt

From: [email-masked]
Date: Mon, 07 May 2012 18:21:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : 464XLAT: Combination of Stateful and Stateless Translation
	Author(s)       : Masataka Mawatari
                          Masanobu Kawashima
                          Cameron Byrne
	Filename        : draft-ietf-v6ops-464xlat-03.txt
	Pages           : 15
	Date            : 2012-05-07

   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 mobile and wireline IPv6-only edge networks without
   encapsulation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-03.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 8 May 2012 10:24:22 +0900

Folks,

We have published draft-ietf-v6ops-464xlat-03.
Can we move forward to WGLC?

Changes are:

- Section 7.5. IPv6 Prefix Handling
  - Clarified the language.

- Added new section "7.6. Relationship between CLAT and NAT44"

Regards,
Masanobu

>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 [email-masked]               
 http://www.necat.co.jp/                
========================================

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 12:07:51 +0200

> Can we move forward to WGLC?

The new draft has none of the following, discussed on the mailing list, and IMHO still worth dealing with before WGLC: 
(1) NAT44 should be a MUST in all cases where the CE node acts as a router.
(2) A well-known 464XLAT interface ID should better be used in CLAT addresses. With it, CLATs never need dedicated prefixes (=> only one case in sections 7.2 and 7.5).
(3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a substance to "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts.")

Besides, some detail suggestions:
In Figures:
- Below PLAT, add NAT64 to clarify that PLAT is no more than a new name for a NAT64 of RFC6146.
In 4.1:
- Replace "one IPv4 address can support millions of simultaneous translations" by "one IPv4 address can support more simultaneous translations than with stateless solutions".
- Replace "stateless address sharing... are simply not IPv4-efficient enough to solve...", by "stateless address sharing... are not IPv4-efficient enough to solve in all cases...". 
In 4.3:
- Replace "especially cost-effective in wireless 3GPP...", by "especially cost-effective in Pre-Release 9 wireless 3GPP...". 
In 6.1: 
- Replace "the ISP can provide IPv4 service" by "the ISP can provide outgoing IPv4 service".

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 May 2012 05:35:14 -0700

Rémi,

Thanks for the review

> (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a substance to "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv…

I believe the discussion lead to these outcomes:

1.  NAT44 does not add any utility in case where there can be a
dedicated transition prefix.  We took Ole's suggestion for resolving
this matter by including both methods and leave it to implementation
based on the implementer's circumstances. If the implementer chooses
to do NAT44 in all cases, so be it.   But we see no harm in providing
choice here.  It does not force any additional complexity.

2.  The OUI idea was clever, but as you pointed out earlier today on
the original thread, it did not gain much steam beyond the initial
conversation. Using a dedicated prefix is not a bad thing, IPv6
addresses are plentiful.  While reserving the OUI seems simple enough,
i am concerned about the added confusion this somewhat unconventional
method will create.

3.  A reference to BIH does not seem required.  I am not opposed to
it, but this document is not required to enumerate all possible
solutions, it is to describe one solution summarized in the
introduction.  We also do not include references to DS-lite ....

> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new name for a NAT64 of RFC6146.

PLAT is clearly defined in section 3.

> - Replace "one IPv4 address can support millions of simultaneous translations" by "one IPv4 address can support more simultaneous translations than with stateless solutions".

The focus of this sentence is not to compare with stateless solution,
the focus of this sentence is on "port overloading".  Most people
think of stateful NAT44 allows for 64,000 translation sessions, but we
explicitly state that port overloading allows for millions of sessions
per 1 IPv4 address.  I believe this is a meaningful point to make in
an IPv4 constrained world.

> - Replace "stateless address sharing... are simply not IPv4-efficient enough to solve...", by "stateless address sharing... are not IPv4-efficient enough to solve in all cases...".

OK

> - Replace "especially cost-effective in wireless 3GPP...", by "especially cost-effective in Pre-Release 9 wireless 3GPP...".

OK

> - Replace "the ISP can provide IPv4 service" by "the ISP can provide outgoing IPv4 service".

In section 1 we state:

"The 464XLAT IPv4 service is limited to application
   that function in a client server model and is not fit for IPv4 peer-
   to-peer communication or inbound IPv4 connections."

CB

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 15:42:08 +0200

Cameron,

Please understand that the goal of comments below is to improve your proposal (which AKAIK not so many people have studied in details).
  
2012-05-08  14:35, Cameron Byrne:

> choice here.  

> It does not force any additional complexity.

It permits the CLAT to always have only one IPv6 address.
This is in my understanding a non negligible simplification, not compensated by any loss of useful function.

> conversation.

The reaction I saw was favorable, with an intent to validate it, but no more comment after that. 

Besides, a reference to RFC6052 for both the CLAT and the CLAT addresses, CLAT translators need to work with TWO IPv6 prefixes instead of just one (that of the CLAT and that of the PLAT). This is a requirement that AFAIK exists in no existing RFC (=> the solution is more than a BCP). 

> Using a dedicated prefix is not a bad thing, IPv6

Getting simplicity by using an available mechanism IMHO the right way to go. 
Reserving an interface IDs is not "unconventional" since RFC5342 section 2.2.2 and http://www.iana.org/assignments/ethernet-numbers have provisions for that. (Which value to choose remains open AFAIAC, but provided one is reserved.) 

> 3.  A reference to BIH does not seem required.

>  I am not opposed to
> it,

Good.
(*) Without it, can you clarify the meaning of "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts."?
 
> but this document is not required to enumerate all possible

Sure, but see (*) above.

> PLAT is clearly defined in section 3.

Yes, ... as a ordinary NAT64 (very minor point anyway).

>   to-peer communication or inbound IPv4 connections."

Right, but repeating one word where it is clarifying shouldn't be a problem (IMHO).

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 15:46:44 +0200

Le 2012-05-08 à 15:42, Rémi Després a écrit :
> ...

Typo: a reference to RFC6052 for CLAT and PLAT addresses ...
                                          ^^^^
RD

---

From: Maoke <[email-masked]>
Date: Wed, 9 May 2012 10:42:27 +0900

Remi,

one point of an observer.

2012/5/8 Rémi Després <[email-masked]>

> Yes, ... as a ordinary NAT64 (very minor point anyway).
please note rfc6146 is about "stateful NAT64". without the *stateful*, the
meaning of *NAT64* is a little fuzzy.

so personally i like PLAT rather than NAT64. otherwise, i suggest to say it
"stateful NAT64" or "NAT64 of RFC6146", or call it NAT64 but with a
statement, saying "throughout this document, the term *NAT64* refers to the
stateful NAT64 defined in RFC6146"... but anyway, as you mentioned, it is a
very minor point. i suggest we (the community) respect the choice of the
authors.

- maoke