Re: RFC3484-revise and NAT64 Well-Known Prefix

Cameron Byrne <> Sun, 27 March 2011 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CE3E3A6950; Sun, 27 Mar 2011 14:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.547
X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uxi1tgTRkTY5; Sun, 27 Mar 2011 14:15:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CEEA43A6955; Sun, 27 Mar 2011 14:15:34 -0700 (PDT)
Received: by eye13 with SMTP id 13so1106434eye.31 for <multiple recipients>; Sun, 27 Mar 2011 14:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+g7/FZNB3bMFTbhfiT09vzmK6bSQuMKo5GaRF8/kuYI=; b=uir+9+pZPfw/k+ODENgAWife4Opqi4V2u3wvJ8EqqFxgSTMcd17qHLwc6N74J9yuYH bNTwSJN0vqEhURQM+5NBxHN4oyhTc92WgKltWcspFYwHtVcslE7t7Va7g4Ueu55H1iIr UnPx4yesQqNJigandQIYrJUJi/dfB+8+65InI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xeZxERPDKif76xfmSb7NrfeM+D28CBalXyH+WT/hXpX6rqLqFPerLUEad0o9Y0dQEC IJh9uJqBwkSP8JZ0VB6SpfL1lgzAXqI2dmjK0ZvAHQZcABcdn251RJWqFSOqo/vOgatc jF4aZlYVBhatBCQHFTc/0YWebQO8fjRA0usNE=
MIME-Version: 1.0
Received: by with SMTP id a20mr1365590ebc.106.1301260630983; Sun, 27 Mar 2011 14:17:10 -0700 (PDT)
Received: by with HTTP; Sun, 27 Mar 2011 14:17:10 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sun, 27 Mar 2011 14:17:10 -0700
Message-ID: <>
Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix
From: Cameron Byrne <>
To: Teemu Kiviniemi <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>, "" <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Mar 2011 21:15:36 -0000

On Sun, Mar 27, 2011 at 12:53 PM, Teemu Kiviniemi <>; wrote:
> On Sun, 27 Mar 2011, 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

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.


> --
> Teemu
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------