Re: RFC3484-revise and NAT64 Well-Known Prefix

On Sun, Mar 27, 2011 at 12:53 PM, Teemu Kiviniemi <tekivini@csc.fi> wrote:
> On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote:
>
>> I discussed shortly with Arifumi about RFC3484 default policy table
>> updates and NAT64 WKP, i.e. whether the default policy table should take a
>> stand on 64:ff9b::/96 preference.
>>
>> It seemed to us that default policy table does not necessarily have to, as
>> it could be ok to handle addresses with WKP similarly to global IPv6
>> addresses. Furthermore, the default policy table anyway cannot cover
>> Network-Specific Prefixes.
>>
>> Hence prefixes used for protocol translation would be handled like global
>> IPv6 addresses unless something different is configured via policy
>> distribution mechanism? And this should perhaps be documented into the
>> RFC3484-revised.
>
> I believe native IPv4 should always be preferred over NAT64. Even if native
> IPv4 was using NAT, it is likely to work better with current applications
> than NAT64.
>

I strongly disagree.

Let's not keep changing things, and please leave well enough alone.
We can't keep changing the rules of the game, we just end up with
inconsistent implementations that cannot be changed easily once
deployed.

What data do you have to show that NAT44 experience is better than
NAT64?  As someone who has deployed and operated NAT44 at very large
scale and NAT64 (small scale, for over a year, but the largest i know
of) there is not a service difference that i am aware of between NAT64
and NAT44.

I see this, like happy eyeballs, as a threat to growing IPv6 traffic
volumes.  If we cannot grow traffic volumes on IPv6, the relevant
planning people (google's now famous graph ... and others) will not
put resources to growing IPv6.  IPv6 remains a second class half-way
implemented / RFP checkbox protocol that is not fit for production....
and over time looses the ground it has gained like ... Symbian^3 now
not working with IPv6.

T-Mobile USA just launched the Nokia C7, and it less IPv6
functionality than last year's Nokia phones ...

Network planners see the CGN NAT44 growing, so they put time and money
on that ... Yet CGN NAT44 is a dead end.  CGN NAT64 is not a dead end,
it gets the protocol right and ENABLES one end of the connection to
have the opportunity to have native IPv6 and that pressures the other
end to support IPv6 to avoid CGN issues....

What you are suggesting just ensures the status quo while injecting
additional entropy across the install base.  With IPv6 preferred and
going via NAT64, network planners and application folks can see the
latent IPv6 opportunity that would be available if both ends of the
connection were IPv6.

> Preferring IPv4 over the NAT64 well-known prefix does not fix the problem

Please make your cogent case for that there is a problem first.

> for network-specific NAT64 prefixes. However, I see no reasons why the NAT64
> WKP should not be given a lower preference than IPv4 by default.
>

No reason to not do it != reason to do it.

Let's not keep changing the rules of the game.

Cameron

> --
> Teemu
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>