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

[Cameron Byrne <[e-mail]>]

2011/11/24 Nejc Škoberne <[e-mail]>:
> 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.

http://www.ietf.org/mail-archive/web/behave/current/msg09478.html

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 http://code.google.com/p/n900ipv6/wiki/Nat64D

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
http://72.249.45.87 - works (Opera Mini + built-in browser)
The One Ring (Google Voice) - works
geeps and barriosquare (requires libicd2-network-3g-ipv6 v1.4 or higher)
Sophia-sip
Skype

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
perspectives)

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
draft-mawatari-softwire-464xlat

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.

CB

ps ... further reading on my deployment and the first UMTS/GSM Android
phone https://sites.google.com/site/tmoipv6/lg-mytouch