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

[Cameron Byrne <[e-mail]>]

On Fri, Feb 24, 2012 at 3:33 AM, Lorenzo Colitti <[e-mail]> wrote:
> On Fri, Feb 24, 2012 at 20:01, Cameron Byrne <[e-mail]> wrote:
>>
>> Remi and Washam have brought up similar concerns regarding NDP.  Our
>> 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

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

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 you still have the test setup running, can you test with a /128 and see
> 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