Subject: RFC3484-revise and NAT64 Well-Known Prefix

From: <[email-masked]>
Date: Sun, 27 Mar 2011 13:20:34 +0000

Hi,

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.

Best regards,

                Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 27 Mar 2011 08:15:24 -0700

On Sun, Mar 27, 2011 at 6:20 AM,  <[email-masked]> wrote:
> Hi,
>
>
>
> 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 agree that prefixes used for protocol translation should be treated
as normal IPv6.  I do not believe the policy table needs to be updated
.... seems like the policy table has been the target of trying to fix
various things (or the table was implemented wrong ...), but relying
on that static host level logic is very difficult in the real world to
solve dynamic problems.

Cameron
>
>
> Best regards,
>
>
>
>                 Teemu
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Teemu Kiviniemi <[email-masked]>
Date: Sun, 27 Mar 2011 22:53:13 +0300

On Sun, 27 Mar 2011, [email-masked] 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 
> 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.

Preferring IPv4 over the NAT64 well-known prefix does not fix the problem 
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.

-- 
Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 27 Mar 2011 14:17:10 -0700

On Sun, Mar 27, 2011 at 12:53 PM, Teemu Kiviniemi <[email-masked]> wrote:
>> updates and NAT64 WKP, i.e. whether the default policy table should take a
>> stand on 64:ff9b::/96 preference.
>>
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Mar 2011 18:55:02 +1300

> On Sun, 27 Mar 2011, [email-masked] wrote:
...
> I believe native IPv4 should always be preferred over NAT64. 

That is just irrelevant and of no importance, since the only hosts
that use DNS64 and NAT64 in normal life are IPv6-only hosts.

There is a side issue of what happens if a synthetic IPv6 address
is referred to a non-IPv6-only host, but that is a whole other
problem that cannot be solved at the RFC3484bis level.

See draft-carpenter-referral-ps-02.txt...

    Brian

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 07:19:00 +0000

Multi-interfaced host might have one network interface IPv6-only with NAT64 (e.g. cellular) and another network interface IPv4-only (e.g. WLAN).

Teemu

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 28. maaliskuuta 2011 07:55
> To: Teemu Kiviniemi
> Cc: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]; [email-masked]
> Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Mar 2011 20:52:53 +1300

Yes. The MIF model seems to me to be fairly broken
from an architectural point of view. Maybe you have to
forbid exporting certain information from one stack to another
on a MIF host.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Mar 2011 14:48:18 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Teemu Kiviniemi
> Sent: Sunday, March 27, 2011 9:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

One reason is that it changes behavior for a network using the well-known
NAT64 prefix versus using their own network's NAT64 prefix.  Not to 
mention they won't know if/when their IPv6 devices are using the new
RFC3484 default table, and will thus start shifting their preference
away from IPv6 (and a NAT64) and towards IPv4 (and a NAPT44, because 
let's be real, everyone will have a NAPT44 if we're talking about an
RFC3484 change).

Personally, I don't see any benefit to changing RFC3484 table to 
accomodate NAT64, assuming there is a way for the host to learn
its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis).  
Assuming there is no standard way to learn the prefix by the time
we would want to standardize rfc3484bis, I see harm in adding 
the NAT64 well known prefix 64:ff9b::/96 to the default policy 
table.

-d

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 29 Mar 2011 06:47:15 -0400

Hi Dan/Teemu(s)/Cameron,
  I am afraid there is no single right answer here. There will be networks that will prefer NAT44 over NAT64 and those that prefer NAT64 over NAT44. For this reason, I think this is better left as a site-specific policy decision for distribution using a mechanism such as draft-ietf-6man-addr-select-opt. So, I agree with Dan and Cameron that we should not add an entry to the default table for the NAT64 prefix.

Cheers
Suresh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: Monday, March 28, 2011 2:48 PM
> To: 'Teemu Kiviniemi'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Teemu Kiviniemi
> > > updates and NAT64 WKP, i.e. whether the default policy 
> table should
> > take
> > > It seemed to us that default policy table does not 
> necessarily have
> > to,
> > Preferring IPv4 over the NAT64 well-known prefix does not fix the 
> > problem for network-specific NAT64 prefixes. However, I see 
> no reasons 
> > why the
> NAT64 prefix versus using their own network's NAT64 prefix.  
> Not to mention they won't know if/when their IPv6 devices are 
> using the new
> RFC3484 default table, and will thus start shifting their 
> preference away from IPv6 (and a NAT64) and towards IPv4 (and 
> a NAPT44, because let's be real, everyone will have a NAPT44 
> if we're talking about an
> RFC3484 change).
> 
> Personally, I don't see any benefit to changing RFC3484 table 
> to accomodate NAT64, assuming there is a way for the host to 
> learn its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis).  
> Assuming there is no standard way to learn the prefix by the 
> time we would want to standardize rfc3484bis, I see harm in 
> adding the NAT64 well known prefix 64:ff9b::/96 to the 
> default policy table.
> 
> -d
> 
> 
> > --
> > Teemu
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 30 Mar 2011 00:24:33 +0900

Hi,

thank you for insightful comments on this issue, all.
I'll put some texts in the next version to note discussions about it.

Best regards,

---

From: Hui Deng <[email-masked]>
Date: Tue, 29 Mar 2011 13:39:12 +0200

make sense

-Hui

2011/3/29 Suresh Krishnan <[email-masked]>

> Hi Dan/Teemu(s)/Cameron,
>  I am afraid there is no single right answer here. There will be networks
> that will prefer NAT44 over NAT64 and those that prefer NAT64 over NAT44.
> For this reason, I think this is better left as a site-specific policy
> decision for distribution using a mechanism such as
> draft-ietf-6man-addr-select-opt. So, I agree with Dan and Cameron that we
> should not add an entry to the default table for the NAT64 prefix.
>
> Cheers
> Suresh
>