Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

GangChen <phdgang@gmail.com> Mon, 11 November 2013 14:46 UTC

Return-Path: <phdgang@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A7421E8091 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2013 06:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.015
X-Spam-Level:
X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
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 CKV9Qb0fsWZ5 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2013 06:46:43 -0800 (PST)
Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB6A921E8064 for <v6ops@ietf.org>; Mon, 11 Nov 2013 06:46:42 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id d4so4538854qej.35 for <v6ops@ietf.org>; Mon, 11 Nov 2013 06:46:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4MZlEPpoEHQ/wHu+0A3g11W7RxyuCeFZmo6to3MVXO0=; b=O9SI0AZLRC/P1mEaMcsN8h6bwyz5opZapJlkxx7vUKiIoU1ustyeOikDY80r7GkMi8 KzJOTSHNWQHvSWVNVjGJLrLcvqUL/It/EDGpLHh4XklIi9JDNO3Nx6ZB93B9QkMSypMl P1FjIwggV60CxK5ki0nBtWcIuq+H2hnwBy4hn/vebfi0h4cXz6Q0cGNNgRJfBTX6L3Fh LVek3Bp8RA5sB/6pJI0UqTblYLlxok7niKtDZox5lPZ8emspwyaWAGAxsqGkMWdXsuMG IiHIc0+8lHC0Dbo0JHF1BNIHLGKIb742LZK/dWS9umnzvr1rDI4xczAruLF0RCGk0kjb CZ6w==
MIME-Version: 1.0
X-Received: by 10.229.13.69 with SMTP id b5mr47959723qca.13.1384181202262; Mon, 11 Nov 2013 06:46:42 -0800 (PST)
Received: by 10.224.172.135 with HTTP; Mon, 11 Nov 2013 06:46:42 -0800 (PST)
In-Reply-To: <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK>
References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <alpine.DEB.2.02.1311050329470.26054@uplift.swm.pp.se> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <CAM+vMES=xhq7VF8SvqEZEz3ZCRN8p1zWiabkNnU6ucKVya6KQQ@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <alpine.DEB.2.02.1311090926500.26054@uplift.swm.pp.se> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK>
Date: Mon, 11 Nov 2013 22:46:42 +0800
Message-ID: <CAM+vMET6mqVQOm4GVnfkvNEGYuVSvTBVnrPOgFvj86Kmx8rnfw@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: "Heatley, Nick" <nick.heatley@ee.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2013 14:46:44 -0000

2013/11/11, Heatley, Nick <nick.heatley@ee.co.uk>:
> Agree, the questions seem only relevant to the mobile use case (with a
> normal baseline of IPv4 privates + NAT44).
> Hopefully you can see that the questions are valid now.
> I seek arguments why, in an access network dominated by NAT why to prefer
> one flavour over another?  - other than pushing my NAT vendor to achieve
> parity NAT64 <--> NAT44 (they claim both translations are in hardware). If
> NAT64 is good enough for IPv6-only clients its good enough for Dual Stack
> NAT?
the argument here is to let:

dual-stack UEs go to NAT44+IPv6 or native IPv4+IPv6
IPv6-only UEs go to NAT64/DNS64
IPv4-only UEs go to NAT44 or native IPv4

It doesn't expect that dual-stack UEs go to NAT64, because IPv4 native
connections are preferred over  IPv6+NAT64

BRs

Gang



> Nick
>
>
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
> Gert Doering
> Sent: 09 November 2013 13:26
> To: Mikael Abrahamsson
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
>
> Hi,
>
> On Sat, Nov 09, 2013 at 09:27:32AM +0100, Mikael Abrahamsson wrote:
>> On Fri, 8 Nov 2013, Gert Doering wrote:
>>
>> > If you have NAT44 and native IPv6, I can't see why you would want to
>> > add
>> > DNS64+NAT64 to the mix.
>> >
>> > NAT64 is good when you do *not* want IPv4 at the customer edge.
>>
>> Mobile. You don't know if the client is v4 only, v6 only, or dual stack.
>> This is up to the client.
>
> Understood, and I see your issue here - you would want to announce a
> "normal" DNS server to a dual-stack client, not a DNS64 server, and you
> can't do that because you don't know whether he's v6 only or dual-stack.
>
> This is somewhat easier in other types of large-scale customer deployments,
> where you can control what the client can get - which will mostly be
> something like "NAT44+IPv6" for many subscribers for the time to come, so
> adding DNS64/NAT64 really does not have much benefit here.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
> NOTICE AND DISCLAIMER
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited
> Registered in England and Wales
> Company Registered Number: 02382161
> Registered Office Address: Trident Place, Mosquito Way, Hatfield,
> Hertfordshire, AL10 9BW
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>