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

From: [email-masked]
Date: Tue, 14 Feb 2012 17:19:28 -0800

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-00.txt
	Pages           : 15
	Date            : 2012-02-14

   This document describes an architecture (464XLAT) for providing 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 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-00.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-00.txt

---

From: Masanobu Kawashima <[email-masked]>
Date: Wed, 15 Feb 2012 10:42:29 +0900

Dear all,

We have published draft-ietf-v6ops-464xlat-00 as WG draft.
We welcome all your comments.

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: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Feb 2012 19:30:50 +0900

> We welcome all your comments.

I like this, because it makes it relatively easy to provide legacy IPv4
connectivity on a device that has IPv6-only connectivity.

It's a particularly good fit for 3GPP devices like mobile phones because
it's relatively simple, can be implemented entirely in userspace, and
requires no provisioning that isn't already provided by 3GPP (a /64 and a
DNS server). And it's just a combination of existing standards.

By comparison, I think solutions like 4rd require a more complex device
implementation, need the kernel to pick ports in a way that will be
understood by the translator, and require provisioning as to what mapping
algorithm and port ranges to use. I can see why you would use something
like 4rd in a wireline CPE, but on something like a smartphone, which is
already behind an IPv4 NAT today and most applications already support
IPv6, the IPv4 connectivity is only really used for a few apps anyway.

I have one question, though: why does the CLAT require a /96? Wouldn't it
be simpler if it uses just one /128 and performed NAT44 for clients behind
it?

That way, if the CLAT have one /64 like in the 3GPP case, you don't have to
worry about DAD and NDP proxying.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Feb 2012 03:01:17 -0800

On Feb 24, 2012 2:31 AM, "Lorenzo Colitti" <[email-masked]> wrote:
>
> On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima <
>
> That way, if the CLAT have one /64 like in the 3GPP case, you don't have
to worry about DAD and NDP proxying.

Remi and Washam have brought up similar concerns regarding NDP.  Our
thinking was that the /96 allows the CPE to remain stateless.

If the benefits of being stateless at the cpe are not seen as truly
meaningful in all cases, would it be acceptable to the group to offer
implementation options of doing DAD/NDP, proxy NDP, or nat446?

I think  the overall scope of the draft is best served by outlining the
structure of how the architecture works and allowing implementation to make
the appropriate solution selection.

Thoughts?

Cb

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Feb 2012 20:33:11 +0900

> thinking was that the /96 allows the CPE to remain stateless.
Today's CPE are basically never stateless. Your home router is a NAT44 box,
your phone is a NAT44 box, even your enterprise router might be a NAT box
or firewall.

>From the perspective of a mobile phone... if it implements tethering, it
already has a NAT44, so requiring NAT44 doesn't introduce additional
complexity. On the other hand, introducing a requirement for proxy NDP does
add complexity (and I'm not even sure if that behaviour is fully specified).

It's true that an additional NAT44 does slightly degrade the quality of
IPv6 connectivity due to the fact that it does double NAT. However, in
mobile networks tethered devices are already double NATed. And if you're
positioning 464xlat as a legacy IPv4 compatibility method for smartphones
where most applications already support IPv6, then that slight extra
degradation isn't a big concern. After all, if the application developer
wants to, he can always use the native IPv6 path with no NATs in it.

If you still have the test setup running, can you test with a /128 and see
if anything else breaks compared to having a /96?

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Feb 2012 04:37:39 -0800

On Fri, Feb 24, 2012 at 3:33 AM, Lorenzo Colitti <[email-masked]> wrote:
> your phone is a NAT44 box, even your enterprise router might be a NAT box or
> firewall.
>
> It's true that an additional NAT44 does slightly degrade the quality of IPv6

You mean degrade IPv4, right?  In all cases IPv6 is end to end, no
compromises, right?

> connectivity due to the fact that it does double NAT. However, in mobile
> networks tethered devices are already double NATed. And if you're

This is an important point.  IPv4 does not have to be pure and
perfect. If people want pure and perfect, IPv6 is the right solution
and that is available.

> if anything else breaks compared to having a /96?

Well, for my case of 3GPP, it is only tethering that would be impacted
for scenarios where DNS64 is not effective (ie...IPv4 literals, ...)
on a tethered LAN.  So, it is more of a corner case for me, but not a
corner case for others.

I would have to get some code changes to the Android CLAT, as the
tethering is not there yet.  We'll see what we can do.

Regarding draft language, i would like the group to help close this
out since multiple folks have been interested in this.

Today's language is here:

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-7.5

======

Proposed new text:

 In the best case, the CLAT will have a dedicated /64 via DHCPv6 or
   other means to source and receive IPv6 packets associated with the
   [RFC6145] stateless translation of IPv4 packets to the local clients.

   In suboptimal cases where the access network does not allow for a dedicated
   translation prefix, CLAT MAY take ownership of a /96
   from an attached interface's /64 to source and receive translation
   traffic. If this case, the CLAT SHOULD actively avoid LAN address
conflicts for this claimed /96.
   Alternatively, the CLAT MAY do NAT44 such that all private IPv4
sourced LAN packets appears from one private IPv4 address which is
   statelessly translated to one IPv6 address that the CLAT will own
as a host IPv6 address from an IPv6 /64 interface.

========

Thoughts?

Again, the goal is not to be perfect.  The goal is to close the basic
functionality gap the prevents IPv6-only access networks from being
viable.

CB

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 24 Feb 2012 09:16:17 -0600

> complexity. On the other hand, introducing a requirement for proxy NDP
> does add complexity (and I'm not even sure if that behaviour is fully
> specified).

+1.

> degradation isn't a big concern.  

+1.

With Tethering (e.g. mobile router is in play), we are back to MAP
translation variant for legacy IPv4 connectivity, making it
useful/beneficial to both wireline and mobile networks. 

464xlat is a good option for supporting legacy ipv4 only on mobile
networks, when the handsets are not supporting/doing tethering, IMO.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lorenzo Colitti
> Sent: Friday, February 24, 2012 6:33 AM
> To: Cameron Byrne
> Cc: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt
> 
> 	Remi and Washam have brought up similar concerns regarding NDP.
> Our thinking was that the /96 allows the CPE to remain stateless.
> 
> complexity. On the other hand, introducing a requirement for proxy NDP
> does add complexity (and I'm not even sure if that behaviour is fully
> specified).
> 
> degradation isn't a big concern. After all, if the application
developer wants
> to, he can always use the native IPv6 path with no NATs in it.
> 
> If you still have the test setup running, can you test with a /128 and
see if
> anything else breaks compared to having a /96?

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Feb 2012 17:21:34 +0100

Le 2012-02-24 à 11:30, Lorenzo Colitti a écrit :

> On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima <[email-masked]> wrote:
> I like this, because it makes it relatively easy to provide legacy IPv4 connectivity on a device that has IPv6-only connectivity.
> 
> It's a particularly good fit for 3GPP devices like mobile phones because it's relatively simple, can be implemented entirely in userspace, and requires no provisioning that isn't already provided by 3GPP (a /64 and a DNS server). And it's just a combination of existing standards.
> 
> By comparison, I think solutions like 4rd require a more complex device implementation, need the kernel to pick ports in a way that will be understood by the translator, and require provisioning as to what mapping algorithm and port ranges to use. I can see why you would use something like 4rd in a wireline CPE, but on something like a smartphone, which is already behind an IPv4 NAT today and most applications already support IPv6, the IPv4 connectivity is only really used for a few apps anyway.
> 
> I have one question, though: why does the CLAT require a /96?

> Wouldn't it be simpler if it uses just one /128 and performed NAT44 for clients behind it?

+1 for this approach.

Besides being simpler per se, if there is a LAN, it facilitates commonality with 4rd, a subject I am working on right now;

RD

> 
> That way, if the CLAT have one /64 like in the 3GPP case, you don't have to worry about DAD and NDP proxying.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Feb 2012 15:31:14 +0900

On Fri, Feb 24, 2012 at 21:37, Cameron Byrne <[email-masked]> wrote:

> IPv6

Yes, sorry.

> see

Actually, it's not a corner case. Your data says that most Android
applications support IPv6, but we know that in many / most cases the
tethered device will either run IPv4-only apps (e.g., Skype) or be
completely IPv4-only (e.g., if it runs XP). So if you want 464xlat to be
used on smartphones that support tethering, then it needs to provide IPv4
to tethered devices.

On the plus side, tethering is already provided though an IPv4 NAT and is
often behind a carrier operated NAT as well. I'd say that running IPv4-only
tethered devices through NAT4464 (where the 6 is stateless) is not much
worse than through NAT444.