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

"Heatley, Nick" <nick.heatley@ee.co.uk> Fri, 08 November 2013 17:10 UTC

Return-Path: <nick.heatley@ee.co.uk>
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 D96D111E80DC for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2013 09:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level:
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 ZKCHAYpPP4hX for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2013 09:10:51 -0800 (PST)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9590111E8239 for <v6ops@ietf.org>; Fri, 8 Nov 2013 09:10:42 -0800 (PST)
Received: from [194.106.220.35:48066] by server-3.bemta-14.messagelabs.com id 2C/37-03488-11B1D725; Fri, 08 Nov 2013 17:10:41 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-7.tower-91.messagelabs.com!1383930640!9740929!1
X-Originating-IP: [193.36.79.210]
X-StarScan-Received:
X-StarScan-Version: 6.9.13; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 8 Nov 2013 17:10:40 -0000
Received: from unknown (HELO aphex) (193.36.79.210) by server-7.tower-91.messagelabs.com with SMTP; 8 Nov 2013 17:10:40 -0000
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id <B527d1c4e0000>; Fri, 08 Nov 2013 17:15:58 +0000
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([fe80::5093:62a6:6ee3:7198%11]) with mapi id 14.02.0318.004; Fri, 8 Nov 2013 17:10:39 +0000
From: "Heatley, Nick" <nick.heatley@ee.co.uk>
To: GangChen <phdgang@gmail.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
Thread-Index: AQHOyHB1/aS13ASbK0O9Jy+4NHt/ApoWDEUAgAAA1wCAAASNgIAAB+OAgAVLKMA=
Date: Fri, 8 Nov 2013 17:10:39 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303A137B3@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>
In-Reply-To: <CAM+vMES=xhq7VF8SvqEZEz3ZCRN8p1zWiabkNnU6ucKVya6KQQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Fri, 08 Nov 2013 17:10:57 -0000

Talking further about coexistence of NAT64 and NAT44.
If NAT64 is good enough for IPv6-only clients then it's good enough for all NAT-based clients, right?

A thought experiment.
A network runs subscribers based on:
- IPv4 private addressing only, via NAT44
- IPv6 native, but IPv6-only devices pass via NAT64 to access v4 only content
- The NAT44 and NAT64 is provided by the same platform, the platform capacity is unchanged by v4 and v6 mixes, and the vendor aims to reach parity on ALGs (for the sake of argument, let's say this has been achieved)

The dual stack hosts could all prioritise AAAA and take the v6 path by default.
Happy Eyeballs could override this, and prioritise the v4 path in cases where  based on the client.

I understand the troubleshooting argument of knowing to which NAT path your traffic goes, (but hey, that's Happy Eyeballs).
Other than that, why would this network operator care whether traffic to IPv4 content from dual stack clients goes via NAT64 or NAT44?
If the scope of DNS64 effectively pushes all dual stack clients to favour NAT64, why not?

Regards,
Nick


-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of GangChen
Sent: 05 November 2013 03:15
To: Eric Vyncke (evyncke)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

2013/11/5, Eric Vyncke (evyncke) <evyncke@cisco.com>om>:
> OK, understood, thanks :-) Your (and Victor's one) should be added to 
> the document to make it clearer IMHO

Yes. In the draft, we have following description:

   The
   coexistence has already appeared in mobile networks, in which dual
   stack mobile phones normally initiate some dual-stack PDN/PDP
   Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated
   addresses are very often private ones.

-Gang

>
> -éric
>
>> -----Original Message-----
>> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
>> Sent: lundi 4 novembre 2013 18:31
>> To: Eric Vyncke (evyncke)
>> Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] I-D Action: 
>> draft-ietf-v6ops-nat64-experience-04.txt
>>
>> On Tue, 5 Nov 2013, Eric Vyncke (evyncke) wrote:
>>
>> > I have hard time to understand the case described in section 3.1.4 
>> > "co-existence of NAT44 and NAT64". Why would a provider use both at 
>> > the same time? Using NAT44 + native IPv6 is sensible, using 
>> > IPv6-only
>> > +
>> > NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 
>> > could be use together for the same subscribers.
>>
>> Mobile.
>>
>> It's up to the terminal to initiate a connection in the APN, and you 
>> don't know if it'll be IPv4 only, IPv6 only or dual stack.
>>
>> --
>> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

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