On F= ri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heatley@ee.co.uk&g= t; wrote:

Hi All,

The sunset4 minutes sugge= st NAT64 SSID to become the default?

Just checking, is there a= ny summary on how VPN clients behaved on the nat64 SSID following the event= ?

Just an anecdote, = not actual information: I have two different ways to contact my office VPN = server (SSL VPN and IPSEC); neither one worked from NAT64.=C2=A0 The vendor= documentation says that they don't support IPv6 transport for the SSL = VPN; I do not know what went wrong with the IPSEC VPN.=C2=A0 The vendor int= roduced support for IPSEC with v6 transport in their newest software, to wh= ich we'll upgrade soon; perhaps that upgrade will include whatever is r= equired for it to work through NAT64 too.=C2=A0 Their support matrix still = says that even the newest software does not support SSL VPN over IPv6.

=C2=A0 Bill

Or anything like a post e= vent report on the experience of the NAT64 in general?=

Thanks,

Nick=

=C2=A0

From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]
Sent: 17 November 2016 01:17
To: Heatley, Nick; Bill Fenner; Lee Howard
Cc: Carlos M. Martinez; Marc Blanchet; sunset4@ietf.org
Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients

=C2=A0

Indeed, SSL VPN are usually= OK (such as the one I am currently using)

=C2=A0=

-=C3=A9ric

=C2=A0=

From: sunset4 <sunset4-bounces@ietf.org> on beha= lf of "Heatley, Nick" <nick.heatley@ee.co.uk>
Date: Wednesday 16 November 2016 at 18:24
To: Bill Fenner <fenner@fenron.com>, Lee Howard <lee@asgard.org>
Cc: "Carlos M. Martinez" <carlosm3011@gmail.com>, Marc Blanchet = <marc.bla= nchet@viagenie.ca>, "sunset4@ietf.org" <sunset4@ietf.org>
Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients

=C2=A0=

To learn on VPNs it would= be good to record:=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VPN client, sw versi= on

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Whether it is clear = on whether IPsec is the protocol (some resort to SSL, some continue with IP= sec)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the destination V= PN gateway IPv4-only or dualstack=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the VPN invoked b= y URL or by IP address

Only the person performin= g the test will discern the last 2 aspects, it is particular to their intra= net.

=C2=A0

The VPN I am most familia= r with is IPsec, is stuck to an IP address destination.

If the VPN gateway is IPv= 4-only and you are on an IPv6-only network (without a transition tech that = fixes this, for example, allowing a 192.0.0.X source) then it breaks.

This is not a NAT64 issue= , this is a reachability issue.

SSL VPNs connecting via U= RLs have been ok AFAIK.

My expectation is that a = significant # of users fall into the IPsec to IPv4-only destination categor= y, enough to callout IPv6-only + NAT64/DNS64 as deficient. Better consensus would be good.<= u>

Nick

=C2=A0

=C2=A0

From: sunset4 [mailto:sunset4-bounces@ietf.= org] On Behalf Of Bill Fenner
Sent: 16 November 2016 08:36
To: Lee Howard
Cc: Carlos M. Martinez; Marc Blanchet; sunset4@ietf.org
Subject: Re: [sunset4] ietf-nat64=

=C2=A0

I tried for a couple of = hours; neither of my two VPN clients works properly.=C2=A0 I haven't no= ticed anything else so far.

=C2=A0

=C2=A0 Bill

=C2=A0

=C2=A0

On Wed, Nov 16, 2016 at = 3:39 PM, Lee Howard <lee@asgard.org> wrote:

Good question. It is not= on the agenda, but it could be raised at open
mike.

However, I just opened a ticket because I can=C2=B9t access my POP mail acc= ount
when I=C2=B9m on ietf-nat64. Works fine on ietf.

Have other folks been living on ietf-nat64 this week? Any issues?

Lee

On 11/16/16, 1:24 AM, "Carlos M. Martinez" <carlosm3011@gmail.com> wrot= e:

>Hi all,
>
>do you know if this hum is happening ?
>
>-Carlos
>
>On 7 Oct 2016, at 4:12, Marc Blanchet wrote:
>
>> On 6 Oct 2016, at 15:03, Lee Howard wrote:
>>
>>> Run IPv6+NAT64 as the default IETF SSID. I've discussed wi= th Jari and
>>> Jim, and they're only reluctant if doing this impedes part= icipants
>>> getting work done. Does anyone have any ideas for how to show = this?
>>> Volunteers?
>>
>> I would suggest to have the IETF Chair to take a humm on this duri= ng
>> the plenary.
>>
>> Marc.
>>
>>>
>>> On this list, I'd like to hear ideas about how to structur= e
>>> work/followup on #5 and #6.
>>>
>>> Are there other topics we should discuss?
>>>
>>> Thanks,
>>>
>>> Lee
>>
>>> _______________________________________________
>>> sunset4 mailing list
>>> sunset4@= ietf.org
>>> https://www.ietf.org/mailman/listinfo/sunset4
>>
>> _______________________________________________
>> sunset4 mailing list
>> sunset4@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sunset4
>

_______________________________________________
sunset4 mailing list
sunset4@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sunset4

=C2=A0

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above.
If you're not the intended recipient, note that disclosing, copying, di= stributing or using this information is prohibited.
If you've received this email in error, please let me know immediately = on the email address above. Thank you.

We monitor our email system, and may record you= r emails.

EE Limited
Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL1= 0 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:<= /u>

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

NOTICE AND DISCLAIMER
This email contains BT information, which may b= e=20 privileged or confidential. It's meant only for the individual(s) or en= tity=20 named above.
If you're not the intended recipient, note that disclo= sing,=20 copying, distributing or using this information is prohibited.
If you&#= 39;ve=20 received this email in error, please let me know immediately on the email= =20 address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited
Registered office:Trident Place, Mosquito Way, Hatfield,= =20 Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street L= ondon=20 EC1A 7AJ
Registered in England no: 1800000

--94eb2c04515cfdcd2205433bf24a-- From nobody Fri Dec 9 08:32:45 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7017412940D; Fri, 9 Dec 2016 08:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqpbo3h85UWc; Fri, 9 Dec 2016 08:32:42 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D54129485; Fri, 9 Dec 2016 08:32:41 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D0DCF25D387C; Fri, 9 Dec 2016 16:32:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 092FFD1F7EE; Fri, 9 Dec 2016 16:32:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id uWRbqjhMdrq7; Fri, 9 Dec 2016 16:32:37 +0000 (UTC) Received: from [10.248.108.210] (fresh-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4920:2ef0:eeff:fe03:ee34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C446FD1F7E3; Fri, 9 Dec 2016 16:32:35 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Bill Fenner" Date: Fri, 09 Dec 2016 16:32:34 +0000 Message-ID: In-Reply-To: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6069) Archived-At: Cc: ipsec@ietf.org, "sunset4@ietf.org" Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:32:44 -0000 On 9 Dec 2016, at 16:07, Bill Fenner wrote: > On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick > wrote: > >> Hi All, >> >> The sunset4 minutes suggest NAT64 SSID to become the default? >> >> Just checking, is there any summary on how VPN clients behaved on the >> nat64 SSID following the event? >> > > Just an anecdote, not actual information: I have two different ways to > contact my office VPN server (SSL VPN and IPSEC); neither one worked > from > NAT64. The vendor documentation says that they don't support IPv6 > transport for the SSL VPN; I do not know what went wrong with the > IPSEC > VPN. The vendor introduced support for IPSEC with v6 transport in > their > newest software, to which we'll upgrade soon; perhaps that upgrade > will > include whatever is required for it to work through NAT64 too. Their > support matrix still says that even the newest software does not > support > SSL VPN over IPv6. That’s maybe for the ipsec wg but while native IPv6 VPN has been working fine for me for ages, how would a NAT64 policy exchange actually look like (I am thinking about what is done for IPv4 NAT or double NAT within the same address family); I doubt that different AFs on each end as part of the policy are specified to work, so I’d not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 endpoint); someone surprise me and say with IKEv2 you can? Someone surprise me and say with a double NAT64 it can work? /bz From nobody Fri Dec 9 09:04:17 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294AF1298C3; Fri, 9 Dec 2016 09:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45ntKxN2R7hi; Fri, 9 Dec 2016 09:04:11 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905991298CE; Fri, 9 Dec 2016 09:03:42 -0800 (PST) Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id B4/53-23231-CE3EA485; Fri, 09 Dec 2016 17:03:40 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRWlGSWpSXmKPExsUy9d9HH903j70 iDF4+VLe4vszd4v2tPWwW+7e8YLNYuWc/uwOLR/v2b6weS5b8ZPLo/u8dwBzFmpmXlF+RwJrR sHc/U8E72Yq9PfOYGxj3yHYxcnEICWxhlLjbfY4NwjnAKNH+ZhKUc5xR4l3XL/YuRk4ONgFdi fZZq5i7GDk4RATCJY5+0QQJMwv4SKx9vosRxBYWsJDon7mYBcQWEbCUePZvOSuE7Scx+c1Jdp BWFgEViZWdxiBhXoFQiQvrp4JNFxI4yiQxd4sXiM0p4Cbxo+Um2BhGAVmJL42rmSFWiUvcejK fCcSWEBCQWLLnPDOELSrx8vE/VghbQeLSoi5WkFXMApoS63fpQ7QqSkzpfsgOsVZQ4uTMJywT GEVnIZk6C6FjFpKOWUg6FjCyrGLUKE4tKkst0jU00EsqykzPKMlNzMwB8oz1clOLixPTU3MSk 4r1kvNzNzECI6uegYFxB+O2LudDjJIcTEqivMVMXhFCfEn5KZUZicUZ8UWlOanFhxhlODiUJH i3PALKCRalpqdWpGXmAGMcJi3BwaMkwpsOkuYtLkjMLc5Mh0idYtTlOLZy7VMmIZa8/LxUKXH etSBFAiBFGaV5cCNg6eYSo6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWFeB5ApPJl5JXCbXgEd wQR0xLwb7iBHlCQipKQaGJuve11n//T+o4RmSe6xmWlzo5l+u0T9vBulJzxV4E+EU8vOPR3BT MuaHsp46riYHgq9OONHyK4JmRW/98uqZv7vLbx9c9qC2VvVZ+i931gfoDlDW2Oy9ss3F7KUbs Y1brlre+TzfH8d56sZvZ93Nb74unjHmhOmBrGyT+fNcO7f6n7Rfrar+CElluKMREMt5qLiRAD PA3vsMgMAAA== X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-6.tower-31.messagelabs.com!1481303020!49023496!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 9.0.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 41616 invoked from network); 9 Dec 2016 17:03:40 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Dec 2016 17:03:40 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with Trustwave SEG (v7, 5, 6, 8438) id ; Fri, 09 Dec 2016 17:03:33 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Fri, 09 Dec 2016 17:03:39 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0279.002; Fri, 9 Dec 2016 17:03:39 +0000 From: "Heatley, Nick" To: "Bjoern A. Zeeb" , Bill Fenner Thread-Topic: [sunset4] ietf-nat64 - Internet VPN clients Thread-Index: AdI/6iAEvrsPebvKTxeJBoeibdeeOgA+3NGABE2iavAABo1YgAAA4XQAAADgjeA= Date: Fri, 9 Dec 2016 17:03:38 +0000 Message-ID: <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

In-Reply-To: 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 Archived-At: Cc: "ipsec@ietf.org" , "sunset4@ietf.org" Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:04:13 -0000 SXQgaXMganVzdCB0aGUgc2luZ2xlIE5BVDY0IHRoYXQgaXMgaW4gcXVlc3Rpb24gKEkgYWxzbyB0 ZW5kIHRvIHRoaW5rIHRoYXQgaXMgYnJva2VuIGZvciBJUHNlYyBjbGllbnRzPykuDQoNClBvcHVs YXIgSVBzZWMgY2xpZW50cyB3b3JrIHBlcmZlY3RseSB2aWEgNDY0eGxhdCAoZG91YmxlIE5BVDY0 KS4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzdW5zZXQ0IFttYWls dG86c3Vuc2V0NC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmpvZXJuIEEuIFplZWIN ClNlbnQ6IDA5IERlY2VtYmVyIDIwMTYgMTY6MzMNClRvOiBCaWxsIEZlbm5lcg0KQ2M6IGlwc2Vj QGlldGYub3JnOyBzdW5zZXQ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N1bnNldDRdIGlldGYt bmF0NjQgLSBJbnRlcm5ldCBWUE4gY2xpZW50cw0KDQpPbiA5IERlYyAyMDE2LCBhdCAxNjowNywg QmlsbCBGZW5uZXIgd3JvdGU6DQoNCj4gT24gRnJpLCBEZWMgOSwgMjAxNiBhdCA4OjQxIEFNLCBI ZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs+DQo+IHdyb3RlOg0KPg0KPj4gSGkg QWxsLA0KPj4NCj4+IFRoZSBzdW5zZXQ0IG1pbnV0ZXMgc3VnZ2VzdCBOQVQ2NCBTU0lEIHRvIGJl Y29tZSB0aGUgZGVmYXVsdD8NCj4+DQo+PiBKdXN0IGNoZWNraW5nLCBpcyB0aGVyZSBhbnkgc3Vt bWFyeSBvbiBob3cgVlBOIGNsaWVudHMgYmVoYXZlZCBvbiB0aGUNCj4+IG5hdDY0IFNTSUQgZm9s bG93aW5nIHRoZSBldmVudD8NCj4+DQo+DQo+IEp1c3QgYW4gYW5lY2RvdGUsIG5vdCBhY3R1YWwg aW5mb3JtYXRpb246IEkgaGF2ZSB0d28gZGlmZmVyZW50IHdheXMgdG8gDQo+IGNvbnRhY3QgbXkg b2ZmaWNlIFZQTiBzZXJ2ZXIgKFNTTCBWUE4gYW5kIElQU0VDKTsgbmVpdGhlciBvbmUgd29ya2Vk IA0KPiBmcm9tIE5BVDY0LiAgVGhlIHZlbmRvciBkb2N1bWVudGF0aW9uIHNheXMgdGhhdCB0aGV5 IGRvbid0IHN1cHBvcnQgDQo+IElQdjYgdHJhbnNwb3J0IGZvciB0aGUgU1NMIFZQTjsgSSBkbyBu b3Qga25vdyB3aGF0IHdlbnQgd3Jvbmcgd2l0aCB0aGUgDQo+IElQU0VDIFZQTi4gIFRoZSB2ZW5k b3IgaW50cm9kdWNlZCBzdXBwb3J0IGZvciBJUFNFQyB3aXRoIHY2IHRyYW5zcG9ydCANCj4gaW4g dGhlaXIgbmV3ZXN0IHNvZnR3YXJlLCB0byB3aGljaCB3ZSdsbCB1cGdyYWRlIHNvb247IHBlcmhh cHMgdGhhdCANCj4gdXBncmFkZSB3aWxsIGluY2x1ZGUgd2hhdGV2ZXIgaXMgcmVxdWlyZWQgZm9y IGl0IHRvIHdvcmsgdGhyb3VnaCBOQVQ2NCANCj4gdG9vLiAgVGhlaXIgc3VwcG9ydCBtYXRyaXgg c3RpbGwgc2F5cyB0aGF0IGV2ZW4gdGhlIG5ld2VzdCBzb2Z0d2FyZSANCj4gZG9lcyBub3Qgc3Vw cG9ydCBTU0wgVlBOIG92ZXIgSVB2Ni4NCg0KVGhhdOKAmXMgbWF5YmUgZm9yIHRoZSBpcHNlYyB3 ZyBidXQgd2hpbGUgbmF0aXZlIElQdjYgVlBOIGhhcyBiZWVuIHdvcmtpbmcgZmluZSBmb3IgbWUg Zm9yIGFnZXMsIGhvdyB3b3VsZCBhIE5BVDY0IHBvbGljeSBleGNoYW5nZSBhY3R1YWxseSBsb29r IGxpa2UgKEkgYW0gdGhpbmtpbmcgYWJvdXQgd2hhdCBpcyBkb25lIGZvciBJUHY0IE5BVCBvciBk b3VibGUgTkFUIHdpdGhpbiB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSk7ICBJIGRvdWJ0IHRoYXQg ZGlmZmVyZW50IEFGcyBvbiBlYWNoIGVuZCBhcyBwYXJ0IG9mIHRoZSBwb2xpY3kgYXJlIHNwZWNp ZmllZCB0byB3b3JrLCBzbyBJ4oCZZCBub3QgZXhwZWN0IElQc2VjIFZQTnMgdG8gd29yayBhY3Jv c3MgYSBOQVQ2NCAoZnJvbSBhIHY2IHRvIGEgdjQgZW5kcG9pbnQpOyAgc29tZW9uZSBzdXJwcmlz ZSBtZSBhbmQgc2F5IHdpdGggSUtFdjIgeW91IGNhbj8gIFNvbWVvbmUgc3VycHJpc2UgbWUgYW5k IHNheSB3aXRoIGEgZG91YmxlIE5BVDY0IGl0IGNhbiB3b3JrPw0KDQovYnoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN1bnNldDQgbWFpbGluZyBs aXN0DQpzdW5zZXQ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N1bnNldDQNCg0KTk9USUNFIEFORCBESVNDTEFJTUVSDQpUaGlzIGVtYWlsIGNvbnRhaW5z IEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwu IEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiANCklmIHlvdSdyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRp c2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9u IGlzIHByb2hpYml0ZWQuIA0KSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92 ZS4gVGhhbmsgeW91Lg0KDQpXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVj b3JkIHlvdXIgZW1haWxzLg0KDQpFRSBMaW1pdGVkIA0KUmVnaXN0ZXJlZCBvZmZpY2U6VHJpZGVu dCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMDIzODIxNjENCg0KRUUgTGltaXRlZCBpcyBhIHdo b2xseSBvd25lZCBzdWJzaWRpYXJ5IG9mOg0KDQpCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBw bGMNClJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0K From nobody Fri Dec 9 09:30:38 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4196E12997C; Fri, 9 Dec 2016 09:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8OR0CfG09Ci; Fri, 9 Dec 2016 09:30:33 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E7012996A; Fri, 9 Dec 2016 09:30:33 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id a20so5092915wme.2; Fri, 09 Dec 2016 09:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t/PSCh/WjPM6TghgeQvOddsSnWAMMROks+rIVvkLQOw=; b=i3ccMloq7cgeIA0WBlbzWUQJYlmrS+mjUAJ9iXHhCZrdHvjC1I8+JxG0PY3OQY3x7b 2WKU3hECTB9t0q4fjNMxVAHF7IQJKbzkgBUQCYhYtd4QXula7jkfBORfRUGZieUQWd4O PyOsSLGIuzLr5HoIBY882dlAE7qSX6o9M0qWmKOrTeCKwRLgvPZG24uiZ0d+1Jf9zFmy Haa6FrgS06sahMKhEsNA0knhIFWTkVaHPNCc77p6rKMlidEcBp96HZbCFmuRmZXOpfMX 6lOVY9rQ0p9lcgkwrkCFw0AG7Y1IwTqz8k/S8ASMxwpgAD+wyczKBgDfAenDEeiZfKjS 4q7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t/PSCh/WjPM6TghgeQvOddsSnWAMMROks+rIVvkLQOw=; b=CDSLQ3Ge+FQNU5VvHpseF8nujyB/mcC3BOx8kBamlgQYsH1tEAbeuz4Fk2z9qz1fDO F5VN3Vn0VkpZF+ralxEMaR08UXkflZhjw17Pl1tlNVRVuLFLlE90hgecMGbgBevJTNmt WvnyYrG1aRT8zIbJ4wFmOP7FeqAX7ZSZBx420jM+5sN5U9YhVWsPYKG/jXKWYJ0WOEdC ar67/Ie1Iu+quD47FCPYDzmHJ9ltgOGkzHx7BRWtva9n0p8vDbHGEGYAoS2+eSXdlMS/ bGGpeeFlkEqdldnqgyeG2I9gCcnjmNvyx3hx0oFi3mlz6OWTJs2bBsDXBaeBW72Jt50P QY/Q== X-Gm-Message-State: AKaTC014gmSRNTkHBkDT40kk9XGGZedmSou8frmpvWE0U+7n6d6OCuqv3Vko+FxlRxR5SA== X-Received: by 10.28.26.80 with SMTP id a77mr7523929wma.31.1481304631797; Fri, 09 Dec 2016 09:30:31 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id a13sm21653096wma.18.2016.12.09.09.30.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 09:30:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 $3251$) From: Yoav Nir In-Reply-To: Date: Fri, 9 Dec 2016 19:30:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: ipsec@ietf.org, Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:30:35 -0000 > On 9 Dec 2016, at 18:32, Bjoern A. Zeeb = wrote: >=20 > On 9 Dec 2016, at 16:07, Bill Fenner wrote: >=20 >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick = wrote: >>=20 >>> Hi All, >>>=20 >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>>=20 >>> Just checking, is there any summary on how VPN clients behaved on = the >>> nat64 SSID following the event? >>>=20 >>=20 >> Just an anecdote, not actual information: I have two different ways = to >> contact my office VPN server (SSL VPN and IPSEC); neither one worked = from >> NAT64. The vendor documentation says that they don't support IPv6 >> transport for the SSL VPN; I do not know what went wrong with the = IPSEC >> VPN. The vendor introduced support for IPSEC with v6 transport in = their >> newest software, to which we'll upgrade soon; perhaps that upgrade = will >> include whatever is required for it to work through NAT64 too. Their >> support matrix still says that even the newest software does not = support >> SSL VPN over IPv6. >=20 > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has = been working fine for me for ages, how would a NAT64 policy exchange = actually look like (I am thinking about what is done for IPv4 NAT or = double NAT within the same address family); I doubt that different AFs = on each end as part of the policy are specified to work, so I=E2=80=99d = not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 = endpoint); someone surprise me and say with IKEv2 you can? Someone = surprise me and say with a double NAT64 it can work? Regardless of IKE version, an IPsec client (and SSL-VPN client as well) = will encapsulate the v6 packet within the tunnel. The internal v6 packet = will never reach the NAT in any form that the NAT can do anything about. The encapsulating packet (for IPsec) or stream (for SSL) will get = translated correctly by the NAT64, but when the other side decrypts the = packet, it=E2=80=99s going to be an IPv6 packet. The problem is the = destination address, which is the NAT64 address invented by the DNS64. = The tunnel endpoint will not know how to deal with that. To get this working, the DNS64 should be on the remote tunnel endpoint = or behind it. And this will require that it has an IPv6 address and = knows to do the NAT64 translation in cooperation with the tunnel = endpoint. I guess this vendor=E2=80=99s IPsec implementation doesn=E2=80=99= t do all that. Neither does my employer=E2=80=99s. Yoav From nobody Fri Dec 9 09:32:46 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87EB129989 for ; Fri, 9 Dec 2016 09:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1a6yBRqmBDe for ; Fri, 9 Dec 2016 09:32:42 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7CC1296F0 for ; Fri, 9 Dec 2016 09:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481304761; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wbr0kzvitGcbqBd4bAblE60J8P63KX6/qn/lxDVFjU0=; b=HoXVX10gemaJHLcCdUP2TM6pChu8SHudCmFmd7Sei2NnoZzvct915WMOThVRTQ8o skOafm48dN4jN1HNdnERImipd1MSWQsyjkxB0LcsiYaqpP4FFzG90NSvG+BImYns nKaWuOfsWXCKR8dN/tTTX5+rGnH1DOo4bmbrvjZ6ufFV8eXJQ9E13h9EQSpcZFkn BCQnxIJSRgZp5xiCnTX5ahK4uJVET+Ib6MwV55m8NQk+NoPgfZwtjI0YCelXxGvW 9iFGlTLWsJ71ae5NXHJJmsPBr22pNUsw+cegLq7aJnpOG/tRk/nsiz8L6AhRoKJd 3Q9YiuIFY8l33eU5InwLIA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B7.8E.19113.9BAEA485; Fri, 9 Dec 2016 09:32:41 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-05-584aeab99168 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 59.EF.23613.9BAEA485; Fri, 9 Dec 2016 09:32:41 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHX0026NI2H6V40@nwk-mmpp-sz07.apple.com>; Fri, 09 Dec 2016 09:32:41 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Fri, 09 Dec 2016 09:32:41 -0800 Content-transfer-encoding: quoted-printable Message-id: <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> To: "Heatley, Nick" X-Mailer: Apple Mail (2.3300) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FAYpbvzlVeEQft/A4vry9wt3t/aw2ax f8sLNotnXyezWazcs5/dgdXj4hMTj/bt31g9liz5yeTR/d87gCWKyyYlNSezLLVI3y6BK+PS 8vSCr/IVp/epNzA+kuxi5OSQEDCRmLfxKnMXIxeHkMBeRonms7NYuxg5wBJr/mlDxA8xStz6 +JkJpIFXQFDix+R7LCA1zALqElOm5ELUdDBJrN5xiQkkLiwgIbF5TyJIubCAg0TbkbusIDab gIrE8W8bmEFsToEIiTmHesFGsgioSiycvIIVZA6zwBJGiaM3VrGDJJgFtCWevLvACrHXRmLr uzPsEMumM0vcOv4DLCECVNQ85xcjxDeyEodPPmUDKZIQuM4m0fZpJdMERuFZSA6fhXD4LCQ7 FjAyr2IUyk3MzNHNzDPXSywoyEnVS87P3cQIioHpdmI7GB+usjrEKMDBqMTD63DIK0KINbGs uDL3EKM0B4uSOG/sF88IIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYynNXKs9lXkO1xx2lj9 +9OLWX5x/8+2mE65f/zdxxxpl+mCHsZfjkt37xY3LfJKqn1/qojj/cKCPd9u/0rItVgXEK// Oq6tP1xMqfguf9SvP/f+eM6dGPMkobHF1zxYfP6Tu3N/zjf2PJqmuVu9/Izh0XI7Vuljhjdu 3rv6NPnjmsbH6S136l8psRRnJBpqMRcVJwIAclmMymICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUi2FD8QXfnK68Ig/tTdSyuL3O3eH9rD5vF /i0v2CyefZ3MZrFyz352B1aPi09MPNq3f2P1WLLkJ5NH93/vAJYoLpuU1JzMstQifbsEroxL y9MLvspXnN6n3sD4SLKLkYNDQsBEYs0/7S5GTiBTTOLCvfVsXYxcHEIChxglbn38zASS4BUQ lPgx+R4LSD2zgLrElCm5EDUdTBKrd1xiAokLC0hIbN6TCFIuLOAg0XbkLiuIzSagInH82wZm EJtTIEJizqFesJEsAqoSCyevYAWZwyywhFHi6I1V7CAJZgFtiSfvLrBC7LWR2PruDDvEsunM EreO/wBLiAAVNc/5xQhxtazE4ZNP2SYwCs5CcusshFtnIRm7gJF5FaNAUWpOYqWZXmJBQU6q XnJ+7iZGcCgXRu1gbFhudYhRgINRiYfX4ZBXhBBrYllxZS4wMDiYlUR4Dz0HCvGmJFZWpRbl xxeV5qQWH2JMBvpmIrOUaHI+MM7ySuINTUwMTIyNzYyNzU3MSRNWEudNWugRISSQnliSmp2a WpBaBLOFiYNTqoGRs1FFXG5twLW7N9z3R598eHZZypYYDZEPXvGB6r9KU1XaVXff5Pbkz1xz i7Vjqosne9bZkLKIWZ3zj+11ad44yfysw4bdpaf/ZTHEs2cytrEndDR5vZj9922C4UXrmodC nXIuCs8nFj8QtZ8rff1w3M2Cj78LVtmKiO/lcV2Rl+DsXfChukuJpTgj0VCLuag4EQCe7Oza qQIAAA== Archived-At: Cc: "ipsec@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:32:44 -0000 With our push to support NAT64 networks (without 464xlat) for Apple's = devices, we added support for NAT64 networks to both our IKEv1 and IKEv2 = clients a few releases ago. It was a fairly straightforward change. The = main parts are making sure any IPv4 literals meant to be use outside the = tunnel that come across in the IKE exchange are synthesized into IPv6 = addresses; and making sure that the ESP layer is happy encapsulating = IPv4 in IPv6 for tunnels. Historically, many implementations only = supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4. =46rom an interop perspective, this is just a change that needs to be = made on the client behind the NAT64, and requires no protocol changes in = IKE or knowledge on the server side. Thanks, Tommy Pauly > On Dec 9, 2016, at 9:03 AM, Heatley, Nick = wrote: >=20 > It is just the single NAT64 that is in question (I also tend to think = that is broken for IPsec clients?). >=20 > Popular IPsec clients work perfectly via 464xlat (double NAT64). >=20 >=20 >=20 > -----Original Message----- > From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Bjoern A. = Zeeb > Sent: 09 December 2016 16:33 > To: Bill Fenner > Cc: ipsec@ietf.org; sunset4@ietf.org > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients >=20 > On 9 Dec 2016, at 16:07, Bill Fenner wrote: >=20 >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick >> wrote: >>=20 >>> Hi All, >>>=20 >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>>=20 >>> Just checking, is there any summary on how VPN clients behaved on = the >>> nat64 SSID following the event? >>>=20 >>=20 >> Just an anecdote, not actual information: I have two different ways = to=20 >> contact my office VPN server (SSL VPN and IPSEC); neither one worked=20= >> from NAT64. The vendor documentation says that they don't support=20 >> IPv6 transport for the SSL VPN; I do not know what went wrong with = the=20 >> IPSEC VPN. The vendor introduced support for IPSEC with v6 transport=20= >> in their newest software, to which we'll upgrade soon; perhaps that=20= >> upgrade will include whatever is required for it to work through = NAT64=20 >> too. Their support matrix still says that even the newest software=20= >> does not support SSL VPN over IPv6. >=20 > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has = been working fine for me for ages, how would a NAT64 policy exchange = actually look like (I am thinking about what is done for IPv4 NAT or = double NAT within the same address family); I doubt that different AFs = on each end as part of the policy are specified to work, so I=E2=80=99d = not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 = endpoint); someone surprise me and say with IKEv2 you can? Someone = surprise me and say with a double NAT64 it can work? >=20 > /bz >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >=20 > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above.=20 > If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.=20 > If you've received this email in error, please let me know immediately = on the email address above. Thank you. >=20 > We monitor our email system, and may record your emails. >=20 > EE Limited=20 > Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW > Registered in England no: 02382161 >=20 > EE Limited is a wholly owned subsidiary of: >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Dec 9 13:39:20 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87E61294AB; Fri, 9 Dec 2016 13:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke7-im_wSpnE; Fri, 9 Dec 2016 13:39:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C9C129541; Fri, 9 Dec 2016 13:39:13 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F352E007; Fri, 9 Dec 2016 16:56:46 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4C8563782; Fri, 9 Dec 2016 16:39:11 -0500 (EST) From: Michael Richardson To: "Bjoern A. Zeeb" In-Reply-To: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipsec@ietf.org, Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:39:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bjoern A. Zeeb wrote: > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has b= een working fine > for me for ages, how would a NAT64 policy exchange actually look like= (I am > thinking about what is done for IPv4 NAT or double NAT within the same NAT64 depends upon DNS64 to provide a fake IPv6 target for the application = to connect to. So, for IPsec to work over NAT64 would require: 1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6). 2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so that it can be lied to about the returned AAAA record. In Bill's case, he hasn't got (1), so it's not going to work. Once he has (1) (the upgrade he mentioned), if his policy lets him use DNS = to find his gateway, and he doesn't do DNSSEC on that, then it ought to work. Of course, once he has the upgrade, if his gateway would just have an IPv6, he wouldn't need NAT64. And he can tunnel his company 10.x v4 network over things as much as he likes... but there is the question about where his Internet bound v4 traffic will go... likely if his company's VPN wants to inspect his traffic, the v4 will go through the tunnel, not using the NAT64 at all, and causing him higher latency. But, that's what would happen in a pure v4 situation anyway. > address family); I doubt that different AFs on each end as part of t= he > policy are specified to work, so I=E2=80=99d not expect IPsec VPNs to= work across a > NAT64 (from a v6 to a v4 endpoint); someone surprise me and say with= IKEv2 > you can? Someone surprise me and say with a double NAT64 it can work? I'm not sure IKEv2 even knows or cares how the port-500 packets get there. I use v6 over X tunnels (where X is usually v4) in order to get v6 to my laptop from coffee shops regularly. I haven't tried this over NAT64, but I will change this to use DNS. Of course, I wouldn't need this tunnel in a NAT64 network, since I'd have v6, so I'll setup some v4 IPsec too for the next IETF and try it out. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhLJH8ACgkQgItw+93Q 3WX0pggAt//dqVBJw1I2UDRct44iMOI/k2tZjlk1j2CKC4zvH0dWcjzFhQt6/Pv6 CbvN3p01vBVZk+6G+TjE6T0qd8EdR9plIzEPJAOlvMW+DrQN5tRQEebRxHXc3jHS ynVVNQHkK5Qwu5uHJsNiSuECdqLeAg1Lkant9Uc4VUbiY/OthToOFCydniDODnjm v0R5pEsX/G5eYp74J4aFO0hMPActElIU5mE6KXbk7GtbiOiIc/ecmJoWdYUEhrVA hfaUvJqEr6HbNJ8/kQRb5d2LrBpdA+lgpQV4W92hO3vajPiyth62B6H/tkkEjbBS W7Rw36vhQEPOIt+W3PAvROTeS0iDIA== =StiN -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 9 13:43:13 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C555212957E; Fri, 9 Dec 2016 13:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFF6jG7gG1n0; Fri, 9 Dec 2016 13:43:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F27012955D; Fri, 9 Dec 2016 13:43:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 733D0E1AB; Fri, 9 Dec 2016 17:00:41 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA76563782; Fri, 9 Dec 2016 16:43:06 -0500 (EST) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipsec@ietf.org, "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:43:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > To get this working, the DNS64 should be on the remote tunnel endpoint > or behind it. And this will require that it has an IPv6 address and > knows to do the NAT64 translation in cooperation with the tunnel > endpoint. I guess this vendor=E2=80=99s IPsec implementation doesn=E2= =80=99t do all > that. Neither does my employer=E2=80=99s. So, I think that you are saying that if the client does DNS through the tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess peop= le need to do DNS through the tunnel because of needing to resolv internal addresses. It's the whole MIF/split-horizon DNS problem, and I think it's all a bad IPv4-specific idea, and we should be trying to kill it. In an IPv6 world, we have better ways to build walled gardens. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhLJWoACgkQgItw+93Q 3WUovwgAukHN4r4g0GerYHIg/KN0T/iAiZ7GwFYofCfoHmeIANQ6ZUoHCf7OraWl GBD2PH7BEBtgINqdc0VbuJaWMVolzZUes1gUBcBGAa6vpgnLzdpJPLpRXU1703Kn 1LxUN3jWddAc+IR1AdtgLBbxXdZmhrs685GUOWsYPyegi+OtWCZ3s3kW/mYHbePX Hm2J27q2vh0qSK0bw3MGV+mKR0wJEDsyp9E5TTWfWYTizuaQ4vKRvenzU0fmmsdV TIgeH1SVKbLMesjjaNi7rCfSsfhWr5PuehQ+ib6WGd9SSDPIXM12dNNQ3Fly08bs wdnuqlWL6iU9jdW+/CReiWgbUjLAtg== =kqOh -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 9 13:47:01 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881FD12955D for ; Fri, 9 Dec 2016 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoLqEDw7L1q9 for ; Fri, 9 Dec 2016 13:46:57 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0A8129679 for ; Fri, 9 Dec 2016 13:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481320007; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1a7Z5PD0cnx01wQ21mttSiYGscHj/b6Ij/Jysy7P54U=; b=aDMKKucRJvxJiP3Ycl1BoUndraRhhRJy0zCxpAz8VXMFJVcK97GH9DMV82CSXi0c tt682p4S0A2dYQ2i2BdVfopDr5Bd41cohn07nuHPKP3ChNJCPUe86JOnHghvhLow 0uB8hiQ4fiUd5mPeQtcOZdtVzEr/B37+bJlHu6xMN+KNVC92m80bbvvQJWEeBX/p pmbTX3lxCVBVr27F3c34XOJj5H283SQQshaBQHmBUUKza4WpV7LtFRrP6NR5083l OXb7AR5aAc0uXxtzgYn0kD0nkVDwVX40kHDbZ5EOhcicPOXp/pc+qanZXIJvcFRs tuOzX5WNngOrcMqIHgIuiw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 02.8E.19113.7462B485; Fri, 9 Dec 2016 13:46:47 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-db-584b264729c6 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 7E.56.23613.7462B485; Fri, 9 Dec 2016 13:46:47 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHX00EFETTZSH00@nwk-mmpp-sz07.apple.com>; Fri, 09 Dec 2016 13:46:47 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <7107.1481319786@obiwan.sandelman.ca> Date: Fri, 09 Dec 2016 13:46:46 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<7107.1481319786@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3300) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYpeuu5h1h8P++usX1Ze4W72/tYbPY v+UFm0XPoX52i5V79rNbLD32gcmBzaN9+zdWj52z7rJ7LFnyk8mj+7+3R8ucPcwBrFFcNimp OZllqUX6dglcGV82rmEreMNbcaaphbGBsYe7i5GDQ0LARGLDZq4uRi4OIYG9jBI3pl1j7mLk BIsfmfKZGSJxiFGi61o7WIJXQFDix+R7LCDNzALqElOm5ELUdDBJfLjxmxkkLiwgIbF5TyJI ubCAg0TbkbusIDabgIrE8W8bwMZwChhJdJ/bDmazCKhKtM1azQhiMwtsZJQ4diQKwtaWePLu AivEWhuJ1k2bWSF2LWOW2Ni6mwUkISKgJ7H8yDNGiKNlJQ6ffMoGUiQh8JhN4sXN08wTGIVn Ibl7FsLds5DsWMDIvIpRKDcxM0c3M89cL7GgICdVLzk/dxMjKDam24ntYHy4yuoQowAHoxIP r8Mhrwgh1sSy4srcQ4zSHCxK4rxTPgCFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MCYd8F5o 4eR0qK/uz/actXMNj908+pN/0pt1zpzq+QdXTzY5kM9Y4FnQxPZkgtv3DTnqtU1V9S/3MDo1 nr/p/Wy7bGQ6S5Fx7M1LySrGi6vi/559JyDZePJNzOpJzSHlx+z2364vvGl86//n3KZjD3QX ybluTbKXMud77SSsktsk901obXbVHiWW4oxEQy3mouJEABnd0MxuAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUi2FD8QdddzTvCYPpRRYvry9wt3t/aw2ax f8sLNoueQ/3sFiv37Ge3WHrsA5MDm0f79m+sHjtn3WX3WLLkJ5NH939vj5Y5e5gDWKO4bFJS czLLUov07RK4Mr5sXMNW8Ia34kxTC2MDYw93FyMnh4SAicSRKZ+ZIWwxiQv31rN1MXJxCAkc YpToutYOluAVEJT4MfkeSxcjBwezgLrElCm5EDUdTBIfbvxmBokLC0hIbN6TCFIuLOAg0Xbk LiuIzSagInH82wawMZwCRhLd57aD2SwCqhJts1YzgtjMAhsZJY4diYKwtSWevLvACrHWRqJ1 02ZWiF3LmCU2tu5mAUmICOhJLD/yjBHiaFmJwyefsk1gFJyF5NRZCKfOQjJ2ASPzKkaBotSc xEozvcSCgpxUveT83E2M4CAvjNrB2LDc6hCjAAejEg+vwyGvCCHWxLLiylxgWHAwK4nwPlDx jhDiTUmsrEotyo8vKs1JLT7EmAz0zERmKdHkfGAE5pXEG5qYGJgYG5sZG5ubmJMmrCTOqysP tEIgPbEkNTs1tSC1CGYLEwenVAMjQ6BBY4TgtVOrZbZu2cu4+9LJjwu+JfScN83XnLLa6V6r 3qJdz06duzlB4Z/YPCPNKKFPTW9EFA1XSc1KiFh42j2u8vqER4u6NPcuesqQdLNQt+RZWPeF tN1LhLxMQl5V3FSc0vbop0Z2mJuMQV299DPZIy9/veXYFPt6kt/iLxLfNqSqRK7wV2Ipzkg0 1GIuKk4EAASdUqS2AgAA Archived-At: Cc: ipsec@ietf.org, "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" , Yoav Nir Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:46:58 -0000 > On Dec 9, 2016, at 1:43 PM, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel = endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation in cooperation with the tunnel >> endpoint. I guess this vendor=E2=80=99s IPsec implementation = doesn=E2=80=99t do all >> that. Neither does my employer=E2=80=99s. >=20 > So, I think that you are saying that if the client does DNS through = the > tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess = people > need to do DNS through the tunnel because of needing to resolv = internal > addresses. It's the whole MIF/split-horizon DNS problem, and I think = it's > all a bad IPv4-specific idea, and we should be trying to kill it. The VPN's DNS should never have to know about DNS64 or support it. The = client can solve the issue independently=E2=80=94don't add it at the = server end! If I have a IPv4-only split-tunnel VPN over a NAT64 network, with DNS = configured such that some hostnames that need to get routed outside the = VPN are resolved only inside the VPN (and thus only get A records), the = client can take the IPv4 literal result and synthesize the correct IPv6 = address using the prefix of the NAT64 network. Thanks, Tommy >=20 > In an IPv6 world, we have better ways to build walled gardens. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Dec 9 14:06:27 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1865A129531; Fri, 9 Dec 2016 14:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZrRuZ7UDyQP; Fri, 9 Dec 2016 14:06:20 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F5012950C; Fri, 9 Dec 2016 14:06:19 -0800 (PST) Received: from [85.158.143.35] by server-1.bemta-6.messagelabs.com id 58/F5-22836-9DA2B485; Fri, 09 Dec 2016 22:06:17 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRWlGSWpSXmKPExsUy9d9HH90bWt4 RBtNvmVpcX+Zu8f7WHjaL/VtesFms3LOf3WLiiYOsDqweW0/+YPNo3/6N1WPJkp9MHt3/vQNY olgz85LyKxJYM44tbGEqOBBfcenbXsYGxpWBXYxcHEICWxgl9j9vZYRwDjBK/L2znxnCOc4os XHuVJYuRk4ONgFdifZZq5hBbBEBJYmOlZvBipgFFjFKNM85DVYkLOAg0XbkLitEkaPEx6frGS HsKIljV9+zgdgsAioSGzbsAavhFXCT+LLtB9S2g8wSuzumM4EkOAVsJf6sfwI2lFFAVuJL42q wzcwC4hJNX1aCNUsICEgs2XOeGcIWlXj5+B8rRE22xPpDHxkhFghKnJz5hGUCo/AsJO2zkJTN QlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4zI4gsY2VcxahSnFpWlFukaWeglFWWmZ5TkJmbm6 BoamOnlphYXJ6an5iQmFesl5+duYgRGJAMQ7GA8vzbwEKMkB5OSKG8xk1eEEF9SfkplRmJxRn xRaU5q8SFGGQ4OJQnevZreEUKCRanpqRVpmTnA1ACTluDgURLhvQ6S5i0uSMwtzkyHSJ1i1OU 4tnLtUyYhlrz8vFQpcd6TIEUCIEUZpXlwI2Bp6hKjrJQwLyPQUUI8BalFuZklqPKvGMU5GJWE eaWBSU+IJzOvBG7TK6AjmICOmHfDHeSIkkSElFQD4zTmdIunbXkzrp5dG2m7fzXDskKmmQkX3 eef8K0V/Jwm6y7DmvVnStuiAmNzofPF3/jvRPK3fp2/65pYXL5E0ckFd9dN7U3o7w9etfx3tG TA+uINh2bOXXx53VmrGd9MuVraXQSksks5Vk5xN3J5qLHsnOTboM9hjF/zGzx3Sl4J/zjh5jS vDCWW4oxEQy3mouJEAGw6/WROAwAA X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-21.messagelabs.com!1481321176!47434734!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 64623 invoked from network); 9 Dec 2016 22:06:16 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Dec 2016 22:06:16 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with Trustwave SEG (v7, 5, 6, 8438) id ; Fri, 09 Dec 2016 22:06:09 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Fri, 09 Dec 2016 22:06:16 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0279.002; Fri, 9 Dec 2016 22:06:16 +0000 From: "Heatley, Nick" To: Tommy Pauly Thread-Topic: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients Thread-Index: AdI/6iAEvrsPebvKTxeJBoeibdeeOgA+3NGABE2iavAABo1YgAAA4XQAAADgjeAAATjwgAAJjgq/ Date: Fri, 9 Dec 2016 22:06:16 +0000 Message-ID: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK>, <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> In-Reply-To: <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 22:06:23 -0000 --_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for this, very useful. Is the vpn client also discovering the well known prefix for v6 address s= ynthesis itself, or relying on the OS to provide that? -------- Original message -------- From: Tommy Pauly Date: 09/12/2016 17:32 (GMT+00:00) To: "Heatley, Nick" Cc: "Bjoern A. Zeeb" , Bill Fenner , ipsec@ietf.org, sunset4@ietf.org Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients With our push to support NAT64 networks (without 464xlat) for Apple's dev= ices, we added support for NAT64 networks to both our IKEv1 and IKEv2 cli= ents a few releases ago. It was a fairly straightforward change. The main= =20parts are making sure any IPv4 literals meant to be use outside the tu= nnel that come across in the IKE exchange are synthesized into IPv6 addre= sses; and making sure that the ESP layer is happy encapsulating IPv4 in I= Pv6 for tunnels. Historically, many implementations only supported IPv4-i= n-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4. >From an interop perspective, this is just a change that needs to be made = on the client behind the NAT64, and requires no protocol changes in IKE o= r knowledge on the server side. Thanks, Tommy Pauly > On Dec 9, 2016, at 9:03 AM, Heatley, Nick wrote= : > > It is just the single NAT64 that is in question (I also tend to think t= hat is broken for IPsec clients?). > > Popular IPsec clients work perfectly via 464xlat (double NAT64). > > > > -----Original Message----- > From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Bjoern A. = Zeeb > Sent: 09 December 2016 16:33 > To: Bill Fenner > Cc: ipsec@ietf.org; sunset4@ietf.org > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick >> wrote: >> >>> Hi All, >>> >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>> >>> Just checking, is there any summary on how VPN clients behaved on the= >>> nat64 SSID following the event? >>> >> >> Just an anecdote, not actual information: I have two different ways to= >> contact my office VPN server (SSL VPN and IPSEC); neither one worked >> from NAT64. The vendor documentation says that they don't support >> IPv6 transport for the SSL VPN; I do not know what went wrong with the= >> IPSEC VPN. The vendor introduced support for IPSEC with v6 transport >> in their newest software, to which we'll upgrade soon; perhaps that >> upgrade will include whatever is required for it to work through NAT64= >> too. Their support matrix still says that even the newest software >> does not support SSL VPN over IPv6. > > That=92s maybe for the ipsec wg but while native IPv6 VPN has been work= ing fine for me for ages, how would a NAT64 policy exchange actually look= =20like (I am thinking about what is done for IPv4 NAT or double NAT with= in the same address family); I doubt that different AFs on each end as p= art of the policy are specified to work, so I=92d not expect IPsec VPNs t= o work across a NAT64 (from a v6 to a v4 endpoint); someone surprise me = and say with IKEv2 you can? Someone surprise me and say with a double NA= T64 it can work? > > /bz > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or confiden= tial. It's meant only for the individual(s) or entity named above. > If you're not the intended recipient, note that disclosing, copying, di= stributing or using this information is prohibited. > If you've received this email in error, please let me know immediately = on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > EE Limited > Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire,= =20AL10 9BW > Registered in England no: 02382161 > > EE Limited is a wholly owned subsidiary of: > > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above.=20 If you're not the intended recipient, note that disclosing, copying, dist= ributing or using this information is prohibited.=20 If you've received this email in error, please let me know immediately on= =20the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited=20 Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, A= L10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 --_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks for this, very useful.

Is the vpn client also discovering the well known prefix for v6 addr= ess synthesis itself, or relying on the OS to provide that?

-------- Original message --------

From: Tommy Pauly <tpauly@apple.com>

Date: 09/12/2016 17:32 (GMT+00:00)

To: "Heatley, Nick" <Nick.Heatley@ee.co.uk>

Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>= ;, Bill Fenner <fenner@fenron.com>, ipsec@ietf.org, sunset4@ietf.or= g

Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

With our push to support NAT64 networks (without= =20464xlat) for Apple's devices, we added support for NAT64 networks to b= oth our IKEv1 and IKEv2 clients a few releases ago. It was a fairly strai= ghtforward change. The main parts are making =20sure any IPv4 literals meant to be use outside the tunnel that come ac= ross in the IKE exchange are synthesized into IPv6 addresses; and making = sure that the ESP layer is happy encapsulating IPv4 in IPv6 for tunnels. = Historically, many implementations only =20supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4.

>From an interop perspective, this is just a change that needs to be made = on the client behind the NAT64, and requires no protocol changes in IKE o= r knowledge on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, at 9:03 AM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:
>
> It is just the single NAT64 that is in question (I also tend to thin= k that is broken for IPsec clients?).
>
> Popular IPsec clients work perfectly via 464xlat (double NAT64).
= >
>
>
> -----Original Message-----
> From: sunset4 [mailto:su= nset4-bounces@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ipsec@ietf.org; sunset4@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
>
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
>
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heatley@e= e.co.uk>
>> wrote:
>>
>>> Hi All,
>>>
>>> The sunset4 minutes suggest NAT64 SSID to become the default= ?
>>>
>>> Just checking, is there any summary on how VPN clients behav= ed on the
>>> nat64 SSID following the event?
>>>
>>
>> Just an anecdote, not actual information: I have two different w= ays to
>> contact my office VPN server (SSL VPN and IPSEC); neither one wo= rked
>> from NAT64. The vendor documentation says that they don't = support
>> IPv6 transport for the SSL VPN; I do not know what went wrong wi= th the
>> IPSEC VPN. The vendor introduced support for IPSEC with v6= =20transport
>> in their newest software, to which we'll upgrade soon; perhaps t= hat
>> upgrade will include whatever is required for it to work through= =20NAT64
>> too. Their support matrix still says that even the newest = software
>> does not support SSL VPN over IPv6.
>
> That=92s maybe for the ipsec wg but while native IPv6 VPN has been w= orking fine for me for ages, how would a NAT64 policy exchange actually l= ook like (I am thinking about what is done for IPv4 NAT or double NAT wit= hin the same address family); I doubt that =20different AFs on each end as part of the policy are specified to work,= =20so I=92d not expect IPsec VPNs to work across a NAT64 (from a v6 to a = v4 endpoint); someone surprise me and say with IKEv2 you can? = =20Someone surprise me and say with a double NAT64 it can =20work?
>
> /bz
>
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/sunset4
>
> NOTICE AND DISCLAIMER
> This email contains BT information, which may be privileged or confi= dential. It's meant only for the individual(s) or entity named above.
> If you're not the intended recipient, note that disclosing, copying,= =20distributing or using this information is prohibited.
> If you've received this email in error, please let me know immediate= ly on the email address above. Thank you.
>
> We monitor our email system, and may record your emails.
>
> EE Limited
> Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshi= re, AL10 9BW
> Registered in England no: 02382161
>
> EE Limited is a wholly owned subsidiary of:
>
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.= ietf.org/mailman/listinfo/ipsec

NOTICE AND DISCLAIMER
This email contains BT information, which may= =20be=20 privileged or confidential. It's meant only for the individual(s) or enti= ty=20 named above.
If you're not the intended recipient, note that disclosi= ng,=20 copying, distributing or using this information is prohibited.
If you= 've=20 received this email in error, please let me know immediately on the email= =20 address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited
Registered office:Trident Place, Mosquito Way, Hatfield= ,=20 Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street= =20London=20 EC1A 7AJ
Registered in England no: 1800000

--_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_-- From nobody Fri Dec 9 14:35:33 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45B412950C; Fri, 9 Dec 2016 14:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx3GiUkS8Msd; Fri, 9 Dec 2016 14:35:29 -0800 (PST) Received: from mail-wj0-x244.google.com (mail-wj0-x244.google.com [IPv6:2a00:1450:400c:c01::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30AC129557; Fri, 9 Dec 2016 14:35:27 -0800 (PST) Received: by mail-wj0-x244.google.com with SMTP id xy5so4091853wjc.1; Fri, 09 Dec 2016 14:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LGNIMm6H0bbhGd34yRqzrtcpZXEI0KsoMBW5ehYxZhc=; b=B49vuuadFbVPRyXS0zg61cJ3hCdx0XdV7KGnVJoGUhETG5H5ZNk/QdmfUx4q5RyfPy blCUn/JKScjnnGvGoa1ffq6C/v0Rrw75XUacn/Gwiii6F52pcrhTbGT+oTuM7U8DPJLx UjxyKis9eiQIv1BnhJ5vlKuIFVmuAJOZ0dvFr6n/nskVoionn/hAf0nRD2fvrUg9ulsL UzZEd8BkbQV4oZ8IlJzQXK/kzLw9zPurLoKE+qCNbTe0RZTrdgKiCDq84asPuDzX00jq 7leX7gaaEOEK4LJQ3oldWc49wQggxYNMHRr45rvp0/VRYxSpqlvxnfSRuOTz59f9cGSC AbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LGNIMm6H0bbhGd34yRqzrtcpZXEI0KsoMBW5ehYxZhc=; b=iJd1jvcnP6jsN/+JE+XexFZl3tlNYuZSlCjfYp4FUeD64xHiBopRNyOWQm3iLMbqV5 7GjutPirRmgW7ImtEGxtSyPLN5jJsevu29vWGgfXDwtvuSrd8ihCnnda09SBM2RH+j3r E7UrhnMkD8rHAsjLEcjDbGZi77gV6w8lHbjXx3ZsJb9KlNGYpaQDfmttYRoatN3dgLQu QqSO68BspH2RHCCEmifTUdcX7bCBy8BhfwJOzZEiqKkp/CvvsStKycRxwnzeYW9zLfEY QpDexSPnk1NoPRQphMy/8dCh/0lNJVZ29RK5H28LL/MFDg/V1kLo4skKbFnj67h599tB eZxw== X-Gm-Message-State: AKaTC008HN/PJ44oqz2mffxebhWHchsSy57CnWbWmaLzTwmm+LZMbbuk16ZYmz6MK+3L8g== X-Received: by 10.194.90.83 with SMTP id bu19mr70324685wjb.68.1481322926287; Fri, 09 Dec 2016 14:35:26 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i132sm22722094wmf.14.2016.12.09.14.35.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 14:35:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 $3251$) From: Yoav Nir In-Reply-To: <7107.1481319786@obiwan.sandelman.ca> Date: Sat, 10 Dec 2016 00:35:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <565C6512-ACDB-4BF6-9C73-A7D13028F81C@gmail.com> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<7107.1481319786@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "IPsecme WG $ipsec@ietf.org$" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 22:35:32 -0000 > On 9 Dec 2016, at 23:43, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel = endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation in cooperation with the tunnel >> endpoint. I guess this vendor=E2=80=99s IPsec implementation = doesn=E2=80=99t do all >> that. Neither does my employer=E2=80=99s. >=20 > So, I think that you are saying that if the client does DNS through = the > tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess = people > need to do DNS through the tunnel because of needing to resolv = internal > addresses. It's the whole MIF/split-horizon DNS problem, and I think = it's > all a bad IPv4-specific idea, and we should be trying to kill it. That was what I said, but then I realized Tommy is right. It doesn=E2=80=99= t really matter that the ISP / Wifi / whatever is providing me with only = IPv6 access. Most IPsec clients have their own virtual interface (with = IKEv2=E2=80=99s CFG, Cisco=E2=80=99s IKEv1 extension or (gasp!) L2TP) so = that has no issue being dual-stack or even IPv4-only. The IPv4 packets = never make it onto the access network - they get encapsulated in = ESP/IPv6, or TLS/TCP/IPv6. So with IPsec you can get IPv4 connectivity even when the access network = doesn=E2=80=99t give it to you. And you don=E2=80=99t need any DNS games = to do it. Yoav From nobody Fri Dec 9 18:28:51 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD0C1295B7 for ; Fri, 9 Dec 2016 18:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LQ5YFZHONWh for ; Fri, 9 Dec 2016 18:28:47 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47305128BA2 for ; Fri, 9 Dec 2016 18:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481336927; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XeWDsADtml7t2x+7dJ1j76lEbhlLGeb7zTdHXnGCo6w=; b=huJZE/O4uSPQ7GKCzv39i8COJSeofQKtRCM10ROc4JODxFnbEaVpVqB2wtMtsY3e NaT8pjaH502vjRL2XpOf0aI2XAldTEi1jxv8xyK/eS9fZDcJB7KtwiefvqYmxfBD 7NTTLnENuC1ON1Kn9SmV+LUzAn8Ivl8q085WoxJboozp1Z5SuNLCZZavU2bkm19P CmrCQ3hWJkF+lS/uOE/Lyp4bZOqfmLkwt7GTTe30TNdOFeNzIcQJ+FvGuB7neZuS QAmCHXD5iJEnBzAOaeeluHbrsHADxMkFIfxtN1bu9LsUyXpYaaXcAWlX43IGX7vm ZglASXMBKrXAKh64cvbYDg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 81.EE.18170.F586B485; Fri, 9 Dec 2016 18:28:47 -0800 (PST) X-AuditID: 11973e15-459e39a0000046fa-05-584b685f8fa4 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id 0D.0D.09148.E586B485; Fri, 9 Dec 2016 18:28:46 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg)" Received: from da0602a-dhcp105.apple.com (da0602a-dhcp105.apple.com [17.226.23.105]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHY009UJ6VYXX20@nwk-mmpp-sz12.apple.com>; Fri, 09 Dec 2016 18:28:46 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Fri, 09 Dec 2016 18:28:45 -0800 In-reply-to: To: "Heatley, Nick" References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUi2FDorBuf4R1hMPseq8X1Ze4W72/tYbPY v+UFm8Wzr5PZLFbu2c/uwOpx8YmJR/v2b6weS5b8ZPLo/u8dwBLFZZOSmpNZllqkb5fAlXFj 1UO2gtd7GStedDczNzA+WsLYxcjJISFgInGubQdrFyMXh5DAXkaJzkkHmGASO9cthkocYpT4 s64TLMErICjxY/I9FhCbWSBM4vLlRkaIomVMEhNvHwJKcHAIC0hIbN6TCFLDJqAicfzbBmaI XhuJf1vvg9nCAg4SbUfusoLYLAKqEvtezQObzyngLvHiwQxmkJnMAksYJf7t3swGkhAR0JZo nvMLalk7i8TyjTehTpWVWPl0I9ipEgKf2STOTLrENIFRaBaSa2chuXYW0IHMAuoSU6bkQoS1 JZ68u8AKYatJLPy9iAlZfAEj2ypGodzEzBzdzDwzvcSCgpxUveT83E2MoPiZbie6g/HMKqtD jAIcjEo8vA6HvCKEWBPLiitzDzFKc7AoifN2OnlHCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amDs8HsUesZk+tM//Eun6RzjrVV2ErCuaJO9tGhl8dKHRw7Ordon/4x75rElT8/w9PjvW/VW +OVZ76ICAXEHgZtCJ2N/tH7RX1wxTWn6vllHuGf7uc78wCZf66uot+TanRVsaXKaSSsnLQ5V 4Dmy0uGjvllIeJ55Tfj6VyLJJ4/+DDHZ6TplpX2WEktxRqKhFnNRcSIARZl00IACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUi2FB8RjcuwzvCYOZuK4vry9wt3t/aw2ax f8sLNotnXyezWazcs5/dgdXj4hMTj/bt31g9liz5yeTR/d87gCWKyyYlNSezLLVI3y6BK+PG qodsBa/3Mla86G5mbmB8tISxi5GTQ0LARGLnusWsELaYxIV769m6GLk4hAQOMUr8WdfJBJLg FRCU+DH5HguIzSwQJnH5ciMjRNEyJomJtw8BJTg4hAUkJDbvSQSpYRNQkTj+bQMzRK+NxL+t 98FsYQEHibYjd8GWsQioSux7NQ9sPqeAu8SLBzOYQWYyCyxhlPi3ezMbSEJEQFuiec4vqGXt LBLLN95kgjhVVmLl042sExgFZiE5cBaSA2cB3cQsoC4xZUouRFhb4sm7C6wQtprEwt+LmJDF FzCyrWIUKErNSaw00kssKMhJ1UvOz93ECI6DQucdjMeWWR1iFOBgVOLhdTjkFSHEmlhWXJkL DCUOZiURXpYk7wgh3pTEyqrUovz4otKc1OJDjBMZgd6cyCwlmpwPjNK8knhDExMDE2NjM2Nj cxNzWgorifNaOgNdJJCeWJKanZpakFoEcxQTB6dUA6M10xb5Ngbpde38v9q/veZv9k8+MNc9 9Ijtv0pHrqhGr80mC6/2hIVUNfx+4MbM0p51+eFhgS1y9zI7eWJ2BQt8WO1tkx9y0W52+u81 9YUPmkp3bzvL+OjtDo+idY+eC3Vf5V9Tu0/I0uTMkqnPTW6pqv3/WtO4ZBX/J4X82JQzHIGG 0euu2yixFGckGmoxFxUnAgBRXNLw9gIAAA== Archived-At: Cc: "ipsec@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 02:28:49 -0000 --Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable The VPN client can do the synthesis themselves using RFC 6052 = (https://tools.ietf.org/html/rfc6052) and RFC 7050 = (https://tools.ietf.org/html/rfc7050), querying ipv4only.arpa over the = DNS. macOS and iOS also support synthesis in the OS by calling getaddrinfo() = with the IPv4 address as a string, and returning an IPv6 sockaddr when = on a NAT64 network. Thanks, Tommy > On Dec 9, 2016, at 2:06 PM, Heatley, Nick = wrote: >=20 > Thanks for this, very useful. > Is the vpn client also discovering the well known prefix for v6 = address synthesis itself, or relying on the OS to provide that? >=20 >=20 >=20 > -------- Original message -------- > From: Tommy Pauly >=20 > Date: 09/12/2016 17:32 (GMT+00:00) > To: "Heatley, Nick" >=20 > Cc: "Bjoern A. Zeeb" >, Bill Fenner >, ipsec@ietf.org , = sunset4@ietf.org > Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients >=20 > With our push to support NAT64 networks (without 464xlat) for Apple's = devices, we added support for NAT64 networks to both our IKEv1 and IKEv2 = clients a few releases ago. It was a fairly straightforward change. The = main parts are making sure any IPv4 literals meant to be use outside the = tunnel that come across in the IKE exchange are synthesized into IPv6 = addresses; and making sure that the ESP layer is happy encapsulating = IPv4 in IPv6 for tunnels. Historically, many implementations only = supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4. >=20 > >=46rom an interop perspective, this is just a change that needs to be = made on the client behind the NAT64, and requires no protocol changes in = IKE or knowledge on the server side. >=20 > Thanks, > Tommy Pauly >=20 > > On Dec 9, 2016, at 9:03 AM, Heatley, Nick > wrote: > >=20 > > It is just the single NAT64 that is in question (I also tend to = think that is broken for IPsec clients?). > >=20 > > Popular IPsec clients work perfectly via 464xlat (double NAT64). > >=20 > >=20 > >=20 > > -----Original Message----- > > From: sunset4 [mailto:sunset4-bounces@ietf.org = ] On Behalf Of Bjoern A. Zeeb > > Sent: 09 December 2016 16:33 > > To: Bill Fenner > > Cc: ipsec@ietf.org ; sunset4@ietf.org = > > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients > >=20 > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >=20 > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick = > > >> wrote: > >>=20 > >>> Hi All, > >>>=20 > >>> The sunset4 minutes suggest NAT64 SSID to become the default? > >>>=20 > >>> Just checking, is there any summary on how VPN clients behaved on = the > >>> nat64 SSID following the event? > >>>=20 > >>=20 > >> Just an anecdote, not actual information: I have two different ways = to=20 > >> contact my office VPN server (SSL VPN and IPSEC); neither one = worked=20 > >> from NAT64. The vendor documentation says that they don't support=20= > >> IPv6 transport for the SSL VPN; I do not know what went wrong with = the=20 > >> IPSEC VPN. The vendor introduced support for IPSEC with v6 = transport=20 > >> in their newest software, to which we'll upgrade soon; perhaps that=20= > >> upgrade will include whatever is required for it to work through = NAT64=20 > >> too. Their support matrix still says that even the newest software=20= > >> does not support SSL VPN over IPv6. > >=20 > > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has = been working fine for me for ages, how would a NAT64 policy exchange = actually look like (I am thinking about what is done for IPv4 NAT or = double NAT within the same address family); I doubt that different AFs = on each end as part of the policy are specified to work, so I=E2=80=99d = not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 = endpoint); someone surprise me and say with IKEv2 you can? Someone = surprise me and say with a double NAT64 it can work? > >=20 > > /bz > >=20 > > _______________________________________________ > > sunset4 mailing list > > sunset4@ietf.org > > https://www.ietf.org/mailman/listinfo/sunset4 = > >=20 > > NOTICE AND DISCLAIMER > > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above.=20 > > If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.=20 > > If you've received this email in error, please let me know = immediately on the email address above. Thank you. > >=20 > > We monitor our email system, and may record your emails. > >=20 > > EE Limited=20 > > Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW > > Registered in England no: 02382161 > >=20 > > EE Limited is a wholly owned subsidiary of: > >=20 > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec = >=20 > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above.=20 > If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.=20 > If you've received this email in error, please let me know immediately = on the email address above. Thank you. >=20 > We monitor our email system, and may record your emails. >=20 > EE Limited=20 > Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW > Registered in England no: 02382161 >=20 > EE Limited is a wholly owned subsidiary of: >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

The VPN client can do the synthesis = themselves using RFC 6052 (https://tools.ietf.org/html/rfc6052) and RFC 7050 (https://tools.ietf.org/html/rfc7050), = querying ipv4only.arpa over the DNS.

macOS and iOS also support synthesis in = the OS by calling getaddrinfo() with the IPv4 address as a string, = and returning an IPv6 sockaddr when on a NAT64 network.

Thanks,

Tommy

On Dec 9, 2016, at 2:06 PM, Heatley, Nick = <nick.heatley@ee.co.uk> wrote:

Thanks for = this, very useful.
Is the vpn client also = discovering the well known prefix for v6 address synthesis itself, or = relying on the OS to provide that?

-------- Original message = --------
From: Tommy Pauly <tpauly@apple.com>
Date: = 09/12/2016 17:32 (GMT+00:00)
To: "Heatley, Nick" = <Nick.Heatley@ee.co.uk>
Cc: = "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Bill Fenner <fenner@fenron.com>, ipsec@ietf.org, sunset4@ietf.org
Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN = clients

With our push to support NAT64 networks (without = 464xlat) for Apple's devices, we added support for NAT64 networks to = both our IKEv1 and IKEv2 clients a few releases ago. It was a fairly = straightforward change. The main parts are making sure any IPv4 literals = meant to be use outside the tunnel that come across in the IKE exchange = are synthesized into IPv6 addresses; and making sure that the ESP layer = is happy encapsulating IPv4 in IPv6 for tunnels. Historically, many = implementations only supported IPv4-in-IPv4, IPv6-in-IPv6, and = IPv6-in-IPv4.

>=46rom an interop = perspective, this is just a change that needs to be made on the client = behind the NAT64, and requires no protocol changes in IKE or knowledge = on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, = at 9:03 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:
>
> It is = just the single NAT64 that is in question (I also tend to think that is = broken for IPsec clients?).
>
> Popular = IPsec clients work perfectly via 464xlat (double NAT64).
>
>
>
> -----Original Message-----
> From: = sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Bjoern A. = Zeeb
> Sent: 09 December 2016 16:33
> = To: Bill Fenner
> Cc: ipsec@ietf.org; sunset4@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN = clients
>
> On 9 = Dec 2016, at 16:07, Bill Fenner wrote:
>
>> On = Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heatley@ee.co.uk>
>> = wrote:
>>
>>> = Hi All,
>>>
>>> = The sunset4 minutes suggest NAT64 SSID to become the default?
>>>
>>> = Just checking, is there any summary on how VPN clients behaved on the
>>> nat64 SSID following the event?
>>>
>>
>> = Just an anecdote, not actual information: I have two different ways = to
>> contact my office VPN server (SSL VPN and IPSEC); = neither one worked
>> from NAT64. The vendor documentation says that = they don't support
>> IPv6 transport for the SSL VPN; I do not know what = went wrong with the
>> IPSEC VPN. The vendor introduced support for = IPSEC with v6 transport
>> in = their newest software, to which we'll upgrade soon; perhaps that
>> = upgrade will include whatever is required for it to work through = NAT64
>> too. Their support matrix still says that even = the newest software
>> does not support SSL VPN over IPv6.
>
> That=E2=80=99s maybe for the ipsec wg but while native = IPv6 VPN has been working fine for me for ages, how would a NAT64 policy = exchange actually look like (I am thinking about what is done for IPv4 = NAT or double NAT within the same address family); I doubt that = different AFs on each end as part of the policy are specified to work, = so I=E2=80=99d not expect IPsec VPNs to work across a NAT64 (from a v6 = to a v4 endpoint); someone surprise me and say with IKEv2 you = can? Someone surprise me and say with a double NAT64 it can = work?
>
> /bz
>
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>
> NOTICE AND DISCLAIMER
> This email = contains BT information, which may be privileged or confidential. It's = meant only for the individual(s) or entity named above.
> If = you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.
> If = you've received this email in error, please let me know immediately on = the email address above. Thank you.
>
> We = monitor our email system, and may record your emails.
>
> EE Limited
> = Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, = AL10 9BW
> Registered in England no: 02382161
>
> EE Limited is a wholly owned subsidiary of:
>
> British Telecommunications plc
> = Registered office: 81 Newgate Street London EC1A 7AJ
> = Registered in England no: 1800000
> = _______________________________________________
> IPsec = mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged = or confidential. It's meant only for the individual(s) or entity named = above.
If= you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.
If you've = received this email in error, please let me know immediately on the = email address above. Thank you.
We monitor our email system, and may record your = emails.
EE = Limited
Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW
Registered in England no: = 02382161
EE = Limited is a wholly owned subsidiary of:
British Telecommunications plc
Registered = office: 81 Newgate Street London EC1A 7AJ
Registered in = England no: 1800000
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg)-- From nobody Fri Dec 9 18:33:10 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9A41295CB for ; Fri, 9 Dec 2016 18:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJaZTj8Z4GXw for ; Fri, 9 Dec 2016 18:33:07 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23996128BA2 for ; Fri, 9 Dec 2016 18:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481337187; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TSS8MX7ie0a/LTab6UIkMdU8iy622c2cLXEULVZvoDc=; b=RiSNMggIZ+rfVu80QAYBR1bTaJbNM9J5Z/K7tx9Sd5e/YKm6+kvFdBUHnowEMYny 8MOG6e1tC1818zRkb96VLqb0FVL00W5wZt7Y9QoHbJfxe1pHya6znIit56aoTrG4 g5ik4Mv5AeYSeXHSSMECTcIzV3lVZ8lRdsaYeZCcZ0lJ2An3WhuSCIduhjt97g85 LoEDWD2ubPYRzgsm13kdh49orFV+GPkMXXz8Qa1kv745M+BkKIADwWB0P0ctNUVN OPY5LKc4FcZsR0BSw5SbZgORUhaIkC4MWgPxmhsd69k9EveGxRMWVqtZIdRPXrLG nmQU0KyO/3STCV8bTUI8eA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id DE.A9.19113.2696B485; Fri, 9 Dec 2016 18:33:07 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-d1-584b6962c3cc Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id A0.DE.23613.2696B485; Fri, 9 Dec 2016 18:33:06 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw)" Received: from [17.153.58.87] (unknown [17.153.58.87]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OHY00GQ772YAM60@nwk-phonehomebzp-sz01.apple.com>; Fri, 09 Dec 2016 18:33:06 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Fri, 09 Dec 2016 18:32:57 -0800 In-reply-to: <565C6512-ACDB-4BF6-9C73-A7D13028F81C@gmail.com> To: Yoav Nir References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<7107.1481319786@obiwan.sandelman.ca> <565C6512-ACDB-4BF6-9C73-A7D13028F81C@gmail.com> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUi2FAYpZuc6R1hcKbe4voyd4v3t/awWezf 8oLNoudQP7vFyj372S2WHvvA5MDm0b79G6vHzll32T2WLPnJ5NH939ujZc4e5gDWKC6blNSc zLLUIn27BK6ML41LmArmJVd03l3M1MD4LLSLkZNDQsBE4tbWPtYuRi4OIYG9jBKd2ycywyTu 35vGBGILCRxjlFg2LxDE5hUQlPgx+R4LiM0sECYxZWsnC0TzDCaJ+0/OsYIkhAWkJbou3AWy OTjYBLQkDqwxgui1kdh66zkbRImDRNuRu2DlLAKqEu1/ToLt5RSwlbiycwPYQcwCjUwSR7vW gDWICChJHL7ylRli2U1miU0X+5kgLpWV+PT8JztIQkLgN5tE66q5jBMYhWYhuXYWkmtnAR3F LKAuMWVKLkRYW+LJuwusELaaxMLfi5iQxRcwsq1iFMpNzMzRzcwz10ssKMhJ1UvOz93ECIqm 6XZiOxgfrrI6xCjAwajEw+twyCtCiDWxrLgy9xCjNAeLkjhvh5N3hJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGCaZBSf7eE2bkrg/ofH9xT2eCa8yd92niLEpV0e/NDRQmLe0+b6G1R/Aa z8ucXOn/1w4+ulTNvunTMWlX2ee7upSONsT3HLowY+GnlTr3KtP3flFYdjpT8ItTXfjWTT83 /90gLLnQVX9S8z32/a/3fbN6OGF5zzuzOL8tcycl6h215b0m673uhhJLcUaioRZzUXEiAKCD IH2HAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUiON3OQTcp0zvC4O9pdYvry9wt3t/aw2ax f8sLNoueQ/3sFiv37Ge3WHrsA5MDm0f79m+sHjtn3WX3WLLkJ5NH939vj5Y5e5gDWKO4bFJS czLLUov07RK4Mr40LmEqmJdc0Xl3MVMD47PQLkZODgkBE4n796YxQdhiEhfurWcDsYUEjjFK LJsXCGLzCghK/Jh8jwXEZhYIk5iytRPI5gKqmcEkcf/JOVaQhLCAtETXhbtANgcHm4CWxIE1 RhC9NhJbbz1ngyhxkGg7chesnEVAVaL9z0lmEJtTwFbiys4NrCAzmQUamSSOdq0BaxARUJI4 fOUrM8Sym8wSmy72Q10qK/Hp+U/2CYwCs5AcOAvJgbOA7mAWUJeYMiUXIqwt8eTdBVYIW01i 4e9FTMjiCxjZVjEKFKXmJFaa6SUWFOSk6iXn525iBMVFQ2HUDsaG5VaHGAU4GJV4eB0OeUUI sSaWFVfmHmKU4GBWEuFlSfKOEOJNSaysSi3Kjy8qzUktPsQ4kRHozYnMUqLJ+cCozSuJNzQx MTAxNjYzNjY3MaelsJI4r6Uz0EUC6YklqdmpqQWpRTBHMXFwSjUwsrWUve74abh1Ve+KdgHj OWeuRnOFrAznqgwvtup+ovq21HXvy8N/bA0erkhZqLUkR/tD8qH2OwuXp8Q6Wvec6/J2/2Yf f3e5qtMJEynhO07Pz/+Q2badU1vePTur6b/klsXBi7bNWbtz/93azRwL5/wJi9x55MkpoTd+ wXXaTkv3H7Ow/O9frcRSnJFoqMVcVJwIAO/0mqL+AgAA Archived-At: Cc: Michael Richardson , "IPsecme WG $ipsec@ietf.org$" , "sunset4@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , Tommy Pauly Subject: Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 02:33:09 -0000 --Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable You'll need to play DNS games if the VPN server if IPv4-only (or if your VPN config gives you a server IPv4 address to connect to). In that case you'll need to query the DNS64 server for the NAT64 prefix. Apple's IKEv2 client uses an OS-provided API to synthesize an IPv6 = address from the configured IPv4 address. This allows our client to work even if the VPN server does not speak = IPv6 at all. It's always better, simpler, and more efficient to support IPv6 = server-side, but if you don't control the server this can be made to work = client-side. David > On Dec 9, 2016, at 14:35, Yoav Nir wrote: >=20 >>=20 >> On 9 Dec 2016, at 23:43, Michael Richardson = wrote: >>=20 >>=20 >> Yoav Nir wrote: >>> To get this working, the DNS64 should be on the remote tunnel = endpoint >>> or behind it. And this will require that it has an IPv6 address and >>> knows to do the NAT64 translation in cooperation with the tunnel >>> endpoint. I guess this vendor=E2=80=99s IPsec implementation = doesn=E2=80=99t do all >>> that. Neither does my employer=E2=80=99s. >>=20 >> So, I think that you are saying that if the client does DNS through = the >> tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I = guess people >> need to do DNS through the tunnel because of needing to resolv = internal >> addresses. It's the whole MIF/split-horizon DNS problem, and I think = it's >> all a bad IPv4-specific idea, and we should be trying to kill it. >=20 > That was what I said, but then I realized Tommy is right. It doesn=E2=80= =99t really matter that the ISP / Wifi / whatever is providing me with = only IPv6 access. Most IPsec clients have their own virtual interface = (with IKEv2=E2=80=99s CFG, Cisco=E2=80=99s IKEv1 extension or (gasp!) = L2TP) so that has no issue being dual-stack or even IPv4-only. The IPv4 = packets never make it onto the access network - they get encapsulated in = ESP/IPv6, or TLS/TCP/IPv6. >=20 > So with IPsec you can get IPv4 connectivity even when the access = network doesn=E2=80=99t give it to you. And you don=E2=80=99t need any = DNS games to do it. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable You'll need to play DNS games if the VPN server if = IPv4-only

(or if your VPN config gives you a server IPv4 = address to connect to).

In that case you'll need to = query the DNS64 server for the NAT64 prefix.

Apple's = IKEv2 client uses an OS-provided API to synthesize an IPv6 = address

from the configured IPv4 address.

This allows our client to work even if the VPN server does = not speak IPv6 at all.

It's always better, simpler, = and more efficient to support IPv6 server-side,

but = if you don't control the server this can be made to work client-side.

David

On Dec 9, 2016, at 14:35, Yoav Nir <ynir.ietf@gmail.com>= wrote:

On 9 Dec 2016, at 23:43, Michael = Richardson <mcr+ietf@sandelman.ca> wrote:

Yoav Nir <ynir.ietf@gmail.com>= wrote:
To get this = working, the DNS64 should be on the remote tunnel endpoint
or behind it. And this will require that it has an IPv6 = address and
knows to do the NAT64 translation in = cooperation with the tunnel
endpoint. I guess this = vendor=E2=80=99s IPsec implementation doesn=E2=80=99t do all
that. Neither does my employer=E2=80=99s.

So, I think that you are saying = that if the client does DNS through the
tunnel, then the = HQ's DNS servers have to do DNS64 synthesis? I guess people
need to do DNS through the tunnel because of needing to = resolv internal
addresses. It's the whole = MIF/split-horizon DNS problem, and I think it's
all a bad = IPv4-specific idea, and we should be trying to kill it.

That was what I said, but then I realized Tommy = is right. It doesn=E2=80=99t really matter that the ISP / Wifi / = whatever is providing me with only IPv6 access. Most IPsec clients have = their own virtual interface (with IKEv2=E2=80=99s CFG, Cisco=E2=80=99s = IKEv1 extension or (gasp!) L2TP) so that has no issue being dual-stack = or even IPv4-only. The IPv4 packets never make it onto the access = network - they get encapsulated in ESP/IPv6, or TLS/TCP/IPv6.

So with IPsec you can get IPv4 = connectivity even when the access network doesn=E2=80=99t give it to = you. And you don=E2=80=99t need any DNS games to do it.

Yoav

_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw)-- From nobody Mon Dec 12 08:45:24 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F386A129D24 for ; Mon, 12 Dec 2016 08:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fenron.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCpxYPU9TzGr for ; Mon, 12 Dec 2016 08:45:16 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A09B129DF1 for ; Mon, 12 Dec 2016 08:40:52 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 12so86673391uas.2 for ; Mon, 12 Dec 2016 08:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fenron.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jD51K4V7+bNvrWanQSCAfr4bGjD2jq8gb2p8cD7kU6k=; b=Uvu5P59M+Mnrod9XcYrfArO59W3x8xEZRR7ED2QdxAzh6Q9b0+W+qSK1Y1apjtQJRG KhfniEtD8crARlaN6qnYptFJeQ+2LZmCCOVsHaZyJwkKzOrCcufX9ugVJS9RYZ04CQSz xHSkHwLt5urODi50t1K+GwjHZQFsIbNx42zk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jD51K4V7+bNvrWanQSCAfr4bGjD2jq8gb2p8cD7kU6k=; b=cLot4EmeWvL/y04QGHD7xpm3q0ir4Oq1BunX4+dkaxWx02f3ukB3bfIElv5sruUEeA s4BrfT3ynR8pKRmU98iaRquYqTjwhbWfkbhcCRj+wPEbC1AyJ/+qgwC0s/WfVTodp0KY ZVA3Cden2vmrkOBYLC2e6+JBlXJcTdJi3ay2NTKYBr5e4il3lYen/rsjnVzmh55XuV0k jXcJGc3gFi9sDRwH+X7A1ZY2qDJnyG2zPVhBVagUJx2hpRbgJv0SZ+ChYaQoiRRqXvwm SS+drrZLCx4ZyMUjkLmjhrTcBSRWqAU82vsD3BkEm0LVVf1/skrQ90K5SNlsHgVfTwyy i8kw== X-Gm-Message-State: AKaTC01ynkvUXysiuto7kqTlyeX1c873duG7xsYNLPSE32UBLXtyxojsb87aHLC8ROKPtgtl1nHcy6T3wrwNXg== X-Received: by 10.176.2.167 with SMTP id 36mr58640834uah.41.1481560851638; Mon, 12 Dec 2016 08:40:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.168 with HTTP; Mon, 12 Dec 2016 08:40:51 -0800 (PST) In-Reply-To: <6205.1481319551@obiwan.sandelman.ca> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK>

<6205.1481319551@obiwan.sandelman.ca> From: Bill Fenner Date: Mon, 12 Dec 2016 11:40:51 -0500 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a113acf724674fc054378c466 Archived-At: Cc: ipsec@ietf.org, "Bjoern A. Zeeb" , "sunset4@ietf.org" Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:45:20 -0000 --001a113acf724674fc054378c466 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2016 at 4:39 PM, Michael Richardson wrote: > > Bjoern A. Zeeb wrote: > > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has= been > working fine > > for me for ages, how would a NAT64 policy exchange actually look > like (I am > > thinking about what is done for IPv4 NAT or double NAT within the > same > > NAT64 depends upon DNS64 to provide a fake IPv6 target for the applicatio= n > to > connect to. > > So, for IPsec to work over NAT64 would require: > > 1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6)= . > 2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so that = it > can be lied to about the returned AAAA record. > > In Bill's case, he hasn't got (1), so it's not going to work. > Well, I was using Apple's "Cisco IPSec" client for OSX 10.11.5, and it's the server side implementation that says that IPv6 transport is not supported. So, perhaps, I have a client that would support it. > Once he has (1) (the upgrade he mentioned), if his policy lets him use DN= S > to > find his gateway, and he doesn't do DNSSEC on that, then it ought to work= . > That is what I have configured. Bill --001a113acf724674fc054378c466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On F= ri, Dec 9, 2016 at 4:39 PM, Michael Richardson <mcr+ietf@sandelman.ca<= /a>> wrote:

Bjoern A. Zeeb <bzeeb-= lists@lists.zabbadoz.net> wrote:
=C2=A0 =C2=A0 > That=E2=80=99s maybe for the ips= ec wg but while native IPv6 VPN has been working fine
=C2=A0 =C2=A0 > for me for ages, how would a NAT64 policy exchange actua= lly look like (I am
=C2=A0 =C2=A0 > thinking about what is done for IPv4 NAT or double NAT w= ithin the same

NAT64 depends upon DNS64 to provide a fake IPv6 target for the appli= cation to
connect to.

So, for IPsec to work over NAT64 would require:

1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6).<= br> 2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so tha= t it
=C2=A0 =C2=A0can be lied to about the returned AAAA record.

In Bill's case, he hasn't got (1), so it's not going to work.

Well, I was using Apple's "Cisc= o IPSec" client for OSX 10.11.5, and it's the server side implemen= tation that says that IPv6 transport is not supported.=C2=A0 So, perhaps, I= have a client that would support it.

=C2=A0

Once he has (1) (the upgrade he mentioned), if his policy lets him use DNS = to
find his gateway, and he doesn't do DNSSEC on that, then it ought to wo= rk.

That is what I have configured.

=C2=A0 Bill

--001a113acf724674fc054378c466--