Re: [Softwires] Fw: I-D Action: draft-mawatari-softwire-464xlat-00.txt
Cameron Byrne <cb.list6@gmail.com> Thu, 24 November 2011 14:01 UTC
Return-Path: <cb.list6@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E699C21F8C33 for <softwires@ietfa.amsl.com>; Thu, 24 Nov 2011 06:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.967
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I17J65I15ltq for <softwires@ietfa.amsl.com>; Thu, 24 Nov 2011 06:01:07 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D653421F8C42 for <softwires@ietf.org>; Thu, 24 Nov 2011 06:01:06 -0800 (PST)
Received: by yenl8 with SMTP id l8so21451yen.31 for <softwires@ietf.org>; Thu, 24 Nov 2011 06:01:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.68.34.67 with SMTP id x3mr17885286pbi.100.1322143265744; Thu, 24 Nov 2011 06:01:05 -0800 (PST)
Received: by 10.142.51.19 with HTTP; Thu, 24 Nov 2011 06:01:05 -0800 (PST)
In-Reply-To: <4ECE3B3C.8070703@skoberne.net>
References: <20111016084011.28691.24648.idtracker@ietfa.amsl.com> <20111016175357kawashimam@mail.jp.nec.com> <4ECE3B3C.8070703@skoberne.net>
Date: Thu, 24 Nov 2011 06:01:05 -0800
Message-ID: <CAD6AjGT4s1HUrcmy+79=Y45zsHuN_b4A5xpDP9Q2uQ7CM2s+Kg@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Nejc Škoberne <nejc@skoberne.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: softwires@ietf.org
Subject: Re: [Softwires] Fw: I-D Action: draft-mawatari-softwire-464xlat-00.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2011 14:01:08 -0000
2011/11/24 Nejc Škoberne <nejc@skoberne.net>: > 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
- [Softwires] Fw: I-D Action: draft-mawatari-softwi… Masanobu Kawashima
- Re: [Softwires] Fw: I-D Action: draft-mawatari-so… Jan Zorz @ go6.si
- Re: [Softwires] Fw: I-D Action:draft-mawatari-sof… Masanobu Kawashima
- Re: [Softwires] Fw: I-D Action: draft-mawatari-so… Nejc Škoberne
- Re: [Softwires] Fw: I-D Action: draft-mawatari-so… Cameron Byrne
- Re: [Softwires] Fw: I-D Action: draft-mawatari-so… MAWATARI Masataka
- Re: [Softwires] Fw: I-D Action: draft-mawatari-so… Jan Zorz @ go6.si