Re: [Softwires] Fw: I-D Action: draft-mawatari-softwire-464xlat-00.txt

Cameron Byrne <> Thu, 24 November 2011 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E699C21F8C33 for <>; Thu, 24 Nov 2011 06:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.967
X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I17J65I15ltq for <>; Thu, 24 Nov 2011 06:01:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D653421F8C42 for <>; Thu, 24 Nov 2011 06:01:06 -0800 (PST)
Received: by yenl8 with SMTP id l8so21451yen.31 for <>; Thu, 24 Nov 2011 06:01:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WMU04WSotkhzennsop2Xh4uTxJiPikKW6hJ6GbH4dFg=; b=L08mkHggepk49woiTUTWLRcWJYyb0Gyt5+HS2Z2O95W+OYl24yma7/8Tbdn9h+E+YR wB8M2zMXL3j28x2/YYL/pZpvKgRvfzhozFkJtPNa91xJU3H8XSJX9Q3z15A8ID6sgs6m 37WHtZotUHuitoYVdmK8EYzBq0RpIQbYKJXd8=
MIME-Version: 1.0
Received: by with SMTP id x3mr17885286pbi.100.1322143265744; Thu, 24 Nov 2011 06:01:05 -0800 (PST)
Received: by with HTTP; Thu, 24 Nov 2011 06:01:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 24 Nov 2011 06:01:05 -0800
Message-ID: <>
From: Cameron Byrne <>
To: Nejc Škoberne <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Softwires] Fw: I-D Action: draft-mawatari-softwire-464xlat-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Nov 2011 14:01:08 -0000

2011/11/24 Nejc Škoberne <>:
> Dear Masanobu,
>> I would appreciate it if you could comment to our document.
> as I said at IETF 82 in Taipei, I hope you will provide further motivation
> for your solution. As far as I know, the only one now
> is that "RFC6145 is the only thing the CPE has to be compatible with"
> in order to make this work. How is this different from "RFCXXXX
> (eg. RFC 6333) is the only thing the CPE has to be compatible with
> in order to make DS-Lite work?
> Also, it would be great if you expressed effort on trying to merge
> your solution with other proposed solutions in some way. As far as
> I see it at the moment, the idea is to have few final solutions
> which will be pushed forward by this WG.

Merging frequently results in a lose/lose "design by committee" mess.

I would also like to make it clear, that i believe softwires and
behave should both be closed, all in-flight yet-another-transition
mechanism work be abandoned as they are a hindrance and distraction to
IPv6 deployment.  We already have 6 over 4, 4 over 6, and more than
enough forms of translation.  Anything else is just counterproductive
life-support and sends a confusing message from the IETF to the world
that IPv6 is still not ready.

Perhaps the closing of softwire and behave can be followed by a new
group called trans-man which does maintenance similar to 6man.

Anyhow, back to the topic at hand.

This draft overcomes a critical limitation of BIH that I have brought
to the BEHAVE list but has not been resolved.

First, BIH is explicitly discouraged from being combined with a NAT64.
While I believe many folks plan for BIH to be used with NAT64, it is
not acceptable to document one stance in the IETF while openly going
against the written word of the RFC in practice and in promoting BIH.
draft-mawatari-softwire-464xlat explicitly, clearly, and openly
documents a NAT464 architecture.  It does not really propose any new
work, it simply documents clearly the NAT464 architecture by using
RFC6145 and RFC6146 together.

Second, BIH is VERY limited in its technical applicability since the
"mapper" function is only triggered by DNS.  Therefore, BIH cannot
deal with the IPv4 literal challenge of IPv4 addresses being passed in
XML documents that trigger streaming videos, Skype signaling, or the
many other places where IPv4 literals occur.  The case in which BIH
was designed to  work is an IPv4-only application reaching an
IPv6-only server.... which is a case i have never seen in the wild.  I
have seen Skype fail in the wild because it passes IPv4 literals, and
that is the target of this draft-mawatari-softwire-464xlat

In summary, I believe this draft is a true NAT464 architecture that
addresses a substantial gap in other IETF work products and solves a
real problem for end users and network operators who are facing issues
with bridging the gap between NAT44 and NAT64 realities.

Is there running code? YES, NEC has CPE product and open source for
N900 phone here

The N900 worked has fixed / enabled these use cases to work which fail
with straight NAT64/DNS64

MSN - works
Ovi Maps search - works
Ovi Maps coarse accuracy location based on cell tower - works - works (Opera Mini + built-in browser)
The One Ring (Google Voice) - works
geeps and barriosquare (requires libicd2-network-3g-ipv6 v1.4 or higher)

Does this solve a real problem?  YES, the gap of IPv4 socket calls and
IPv4 literals is problematic for NAT64 deployments as listed in the
above applications.

Does this introduce a general case of another layer of NAT?   NO, when
used with DNS64, the general case is just NAT64/DNS64.  This is 1
layer of NAT for  DNS-enabled IPv4 services, while IPv6 native flows
remain native and never pass through a transition mechanism (in
mobile, this can clearly be over 50% of traffic today (assuming google
and facebook whitelist))

The exception case where there is another layer of NAT (2 NATs) is
added  to cover the case of Skype and other protocols that pass IPv4
literals in their signalling layers.  This is an exception and will go
away in time, but we need this NAT464 bridge to keep progressing with
commercial deployments.  Customer expect service parity between IPv4
and IPv6, but that is non-trivial in IPv6-only world (yes, ipv4
(private and public) is already run out from all strategic

As you may or may not know, T-Mobile USA has rolled out IPv6 natively
in the San Francisco area to our general data APN, the rest of our USA
footprint will be completed soon.  We are using NAT64/DNS64 and it
works very very well for 99% of the use cases, but there are these use
cases like Skype that are IPv6 spoilers.  The N900 running-code proves
that we can bridge the functionality gap with NAT464 as described in

We have running code and this draft solves (works around) a real
problem that expedites the deployment of IPv6.

Or, the IETF can block this work and slow down my IPv6 deployment.


ps ... further reading on my deployment and the first UMTS/GSM Android