Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

[Cameron Byrne <cb.list6@gmail.com>]

On Tue, Apr 20, 2010 at 1:38 AM, Rémi Després <remi.despres@free.fr> wrote:
>
> Le 19 avr. 2010 à 19:30, Cameron Byrne a écrit :
>
>>>> "In summary, IPv6-only deployments should be encouraged while considering the roaming and applications issues"
>>>
>>> I still can't agree on this because:
>>> - The market of real IPv6-ony is too limited.
>>> - IPv6-only + DNS64-NAT64 is harmful to IPv6 e2e transparency.
>>
>>
>> Why must IPv6 be pure? There is no precedent for IPv6 by nature of its
>> structure being pure or meaning E2E transparency.
>
>
>> NAT-PT has been
>> around in the IPv6 ecosystem for a long time,
>
> ... but deprecated almost as soon as documented,
>
>> so IPv6 addresses
>> representing IPv4 destinations is by no means new.
>
> Not new as an idea, but AKAIK not deployed as a standard service.
> Note that the DS-lite approach, in which IPv6-only access networks maintain IPv4 connectivity with NAT44s rather than NAT64s, doesn't need IPv4-embedded IPv6 addresses.
>
>> I agree that IPv6
>> is the path to E2E transparency,
>
> More than that: users of IPv6 today HAVE e2e transparency in IPv6.
> DNS64-NAT64 in operator infrastructures, if done without serious precautions, is a path to BREAKING IPv6 e2e transparency.
> This may be regrettable, but this in my understanding an inescapable fact.
>
>> but IPv6 does not imply e2e by virtue
>> of the technology.
>
> It just RESTORES e2e transparency, which had been lost when one address per host became impossible.
>
> This happened long ago, and launched the painful complexity of NATs (cone, symmetric, port-resticted symmetric etc.), of their ALGs, of sophisticated tools to make pinholes in traversed NAT like TURN, STUN, Teredo, etc.
>
>
>> IMHO IPv6-only expedites that journey to e2e.
>
> Again, hosts that communicate today with public IPv6 addresses HAVE e2e transparency.
> This journey is therefore already finished... unless a step backward is consciously made to reintroduce complexity where it shouldn't exist :-(.
>

With all due respect,  I don't think you and I will come to an
agreement, we simply have different priorities and values. A major
network that I work at will take this "step backwards" with IPv6-only
and NAT64, it is already deployed in a trial, the trial is going VERY
well.  The customer experience on IPv4 + NAT44 and IPv6 + NAT64 are
identical for the target handsets and users.   IMHO, your arguments
are not strong enough to justify yet another solution and will not
appeal to mobile operators.  Mobile has IPv6 solutions, they were
described in full at the San Francisco 3GPP-IETF meeting, and I
believe operators are moving forward with those solution, the timeline
requires movement now.  A major outcome from that San Francisco
meeting that you need to be very aware of is that there is a very
large resistance to adding new features to the mobile handset.  As
soon as you bring that up, the mobile operator will dismiss 4RD just
as they moved away from PNAT and DS-Lite.

I don't believe you are communicating with IPv6 hosts at NetFlix and
Google, right?  Your e2e is between a host and a stateful load
balancer doing protocol translations.  Like many thing, if it works
today and is inexpensive, it gets deployed.

In any technology decision, trade-offs must be made.  IMHO, NAT64
trades off some E2E (IPv4 is NAT44 anyways today) to expedite the
deployment of IPv6 where all flows will have E2E (aside from content
load balancers).  Given that IPv4 is NAT44 today, going to NAT64 is
steady state, no new downsides and I get the upside of direct e2e for
ipv6.



> Note that NAT64 between a private scope IPv6 address (e.g. a ULA of RFC 4193) and IPv4, doesn't suffer from breaking e2e transparency, because private addresses have to be translated somewhere. This could provide a way for applications to know whether they can rely on e2e transparency or not, but this requires in my understanding more work.
>

Not sure of the value of this.

Thanks for the discussion.

Cameron

> Regards,
> RD