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

"Heatley, Nick" <> Mon, 18 November 2013 13:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98D0811E841B for <>; Mon, 18 Nov 2013 05:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o1lz04fJzC3r for <>; Mon, 18 Nov 2013 05:32:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5AC3A11E8628 for <>; Mon, 18 Nov 2013 05:32:00 -0800 (PST)
Received: from [] by id 8F/47-29838-DC61A825; Mon, 18 Nov 2013 13:31:57 +0000
X-Originating-IP: []
X-StarScan-Version: 6.9.13; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10009 invoked from network); 18 Nov 2013 13:31:57 -0000
Received: from unknown (HELO autechre) ( by with SMTP; 18 Nov 2013 13:31:57 -0000
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[]) by autechre with MailMarshal (v6, 8, 2, 9371) id <B528a18980000>; Mon, 18 Nov 2013 13:39:36 +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; Mon, 18 Nov 2013 13:31:56 +0000
From: "Heatley, Nick" <>
To: GangChen <>, Gert Doering <>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
Date: Mon, 18 Nov 2013 13:31:56 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303A246E4@UK30S005EXS06.EEAD.EEINT.CO.UK>
References: <> <> <> <> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <20131111145452.GF81676@Space.Net> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Nov 2013 13:32:42 -0000

In summary of this thread, as best I understand it:
We agree that a mixed environment with IPv6-only and dual stack clients with NAT64 and NAT44 gateways is a "mobile RFC1918 host " use case.
There appear valid concerns about 1) performance on different paths (and clients picking those paths dynamically), 2) traceability for Operations, 3) the relative state of NAT44 and NAT64 ALGs, and 4) capacity or running NAT44 and NAT64 gateways.

How to provide connectivity to IPv4-only content in such a mixed NAT44/NAT64 environment?
- one approach is to try to keep dual stack hosts unchanged / on a pure NAT44 path (the recommendation of the draft)
- another documented approach is to add more sophisticated functionality to steer the different clients to suitable DNS as per draft

I am thinking I will trial another approach for the NAT44/NAT64 environment; to let RFC1918 dual stack hosts prefer the NAT64 path.
To address the concerns above, this approach would rely on:
a) parity of NAT44 and NAT64 ALGs (I need to push my vendor)
and b) from a capacity and traceability perspective, will run on a combined NAT44/NAT64 platform.

A trial will be in a mobile environment, it will be a mix of IPv4-only UEs, dual stack UEs and IPv6-only + 464xlat UEs (hats off to Cameron there).
Any other pointers/concerns would be gratefully received.

-----Original Message-----
From: GangChen [] 
Sent: 12 November 2013 14:36
To: Gert Doering
Cc: Heatley, Nick; Mikael Abrahamsson;
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

2013/11/11, Gert Doering <>et>:
> Hi,
> On Mon, Nov 11, 2013 at 10:46:42PM +0800, GangChen wrote:
>> It doesn't expect that dual-stack UEs go to NAT64, because IPv4 
>> native connections are preferred over  IPv6+NAT64
> How does the UE know that a target can be reached by native IPv4 if
> DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4?

UE may not can determine the existence of IPv4 native connections.
However, an network side may could serve the right DNS address according to the UE connection status, for example the solution described at


> 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

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