[sunset4] ietf-nat64 - Internet VPN clients

[Heatley, Nick]

To learn on VPNs it would be good to record:

· VPN client, sw version

· Whether it is clear on whether IPsec is the protocol (some resort to SSL, some continue with IPsec)

· Is the destination VPN gateway IPv4-only or dualstack

· Is the VPN invoked by URL or by IP address
Only the person performing the test will discern the last 2 aspects, it is particular to their intranet.

The VPN I am most familiar with is IPsec, is stuck to an IP address destination.
If the VPN gateway is IPv4-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 URLs have been ok AFAIK.
My expectation is that a significant # of users fall into the IPsec to IPv4-only destination category, enough to callout IPv6-only + NAT64/DNS64 as deficient. Better consensus would be good.
Nick


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

I tried for a couple of hours; neither of my two VPN clients works properly. I haven't noticed anything else so far.

Bill


On Wed, Nov 16, 2016 at 3:39 PM, Lee Howard <***@asgard.org<mailto:***@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¹t access my POP mail account
when I¹m 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" <***@gmail.com<mailto:***@gmail.com>> wrote:

>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 with Jari and
>>> Jim, and they're only reluctant if doing this impedes participants
>>> 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 during
>> the plenary.
>>
>> Marc.
>>
>>>
>>> On this list, I'd like to hear ideas about how to structure
>>> work/followup on #5 and #6.
>>>
>>> Are there other topics we should discuss?
>>>
>>> Thanks,
>>>
>>> Lee
>>
>>> _______________________________________________
>>> sunset4 mailing list
>>> ***@ietf.org<mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/sunset4
>>
>> _______________________________________________
>> sunset4 mailing list
>> ***@ietf.org<mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sunset4
>


_______________________________________________
sunset4 mailing list
***@ietf.org<mailto:***@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

[Eric Vyncke (evyncke)]

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

-éric

From: sunset4 <sunset4-***@ietf.org<mailto:sunset4-***@ietf.org>> on behalf of "Heatley, Nick" <***@ee.co.uk<mailto:***@ee.co.uk>>
Date: Wednesday 16 November 2016 at 18:24
To: Bill Fenner <***@fenron.com<mailto:***@fenron.com>>, Lee Howard <***@asgard.org<mailto:***@asgard.org>>
Cc: "Carlos M. Martinez" <***@gmail.com<mailto:***@gmail.com>>, Marc Blanchet <***@viagenie.ca<mailto:***@viagenie.ca>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients

To learn on VPNs it would be good to record:

· VPN client, sw version

· Whether it is clear on whether IPsec is the protocol (some resort to SSL, some continue with IPsec)

· Is the destination VPN gateway IPv4-only or dualstack

· Is the VPN invoked by URL or by IP address
Only the person performing the test will discern the last 2 aspects, it is particular to their intranet.

The VPN I am most familiar with is IPsec, is stuck to an IP address destination.
If the VPN gateway is IPv4-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 URLs have been ok AFAIK.
My expectation is that a significant # of users fall into the IPsec to IPv4-only destination category, enough to callout IPv6-only + NAT64/DNS64 as deficient. Better consensus would be good.
Nick


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

I tried for a couple of hours; neither of my two VPN clients works properly. I haven't noticed anything else so far.

Bill


On Wed, Nov 16, 2016 at 3:39 PM, Lee Howard <***@asgard.org<mailto:***@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¹t access my POP mail account
when I¹m 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" <***@gmail.com<mailto:***@gmail.com>> wrote:

>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 with Jari and
>>> Jim, and they're only reluctant if doing this impedes participants
>>> 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 during
>> the plenary.
>>
>> Marc.
>>
>>>
>>> On this list, I'd like to hear ideas about how to structure
>>> work/followup on #5 and #6.
>>>
>>> Are there other topics we should discuss?
>>>
>>> Thanks,
>>>
>>> Lee
>>
>>> _______________________________________________
>>> sunset4 mailing list
>>> ***@ietf.org<mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/sunset4
>>
>> _______________________________________________
>> sunset4 mailing list
>> ***@ietf.org<mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sunset4
>


_______________________________________________
sunset4 mailing list
***@ietf.org<mailto:***@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

[Heatley, Nick]

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?
Or anything like a post event report on the experience of the NAT64 in general?
Thanks,
Nick

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

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

-éric

From: sunset4 <sunset4-***@ietf.org<mailto:sunset4-***@ietf.org>> on behalf of "Heatley, Nick" <***@ee.co.uk<mailto:***@ee.co.uk>>
Date: Wednesday 16 November 2016 at 18:24
To: Bill Fenner <***@fenron.com<mailto:***@fenron.com>>, Lee Howard <***@asgard.org<mailto:***@asgard.org>>
Cc: "Carlos M. Martinez" <***@gmail.com<mailto:***@gmail.com>>, Marc Blanchet <***@viagenie.ca<mailto:***@viagenie.ca>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients

To learn on VPNs it would be good to record:

· VPN client, sw version

· Whether it is clear on whether IPsec is the protocol (some resort to SSL, some continue with IPsec)

· Is the destination VPN gateway IPv4-only or dualstack

· Is the VPN invoked by URL or by IP address
Only the person performing the test will discern the last 2 aspects, it is particular to their intranet.

The VPN I am most familiar with is IPsec, is stuck to an IP address destination.
If the VPN gateway is IPv4-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 URLs have been ok AFAIK.
My expectation is that a significant # of users fall into the IPsec to IPv4-only destination category, enough to callout IPv6-only + NAT64/DNS64 as deficient. Better consensus would be good.
Nick


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

I tried for a couple of hours; neither of my two VPN clients works properly. I haven't noticed anything else so far.

Bill


On Wed, Nov 16, 2016 at 3:39 PM, Lee Howard <***@asgard.org<mailto:***@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¹t access my POP mail account
when I¹m 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" <***@gmail.com<mailto:***@gmail.com>> wrote:

>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 with Jari and
>>> Jim, and they're only reluctant if doing this impedes participants
>>> 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 during
>> the plenary.
>>
>> Marc.
>>
>>>
>>> On this list, I'd like to hear ideas about how to structure
>>> work/followup on #5 and #6.
>>>
>>> Are there other topics we should discuss?
>>>
>>> Thanks,
>>>
>>> Lee
>>
>>> _______________________________________________
>>> sunset4 mailing list
>>> ***@ietf.org<mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/sunset4
>>
>> _______________________________________________
>> sunset4 mailing list
>> ***@ietf.org<mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sunset4
>


_______________________________________________
sunset4 mailing list
***@ietf.org<mailto:***@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

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

[Bill Fenner]

On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <***@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.

Bill


Or anything like a post event report on the experience of the NAT64 in
> general?
>
> Thanks,
>
> Nick
>
>
>
> *From:* Eric Vyncke (evyncke) [mailto:***@cisco.com]
> *Sent:* 17 November 2016 01:17
> *To:* Heatley, Nick; Bill Fenner; Lee Howard
> *Cc:* Carlos M. Martinez; Marc Blanchet; ***@ietf.org
> *Subject:* Re: [sunset4] ietf-nat64 - Internet VPN clients
>
>
>
> Indeed, SSL VPN are usually OK (such as the one I am currently using)
>
>
>
> -éric
>
>
>
> *From: *sunset4 <sunset4-***@ietf.org> on behalf of "Heatley, Nick" <
> ***@ee.co.uk>
> *Date: *Wednesday 16 November 2016 at 18:24
> *To: *Bill Fenner <***@fenron.com>, Lee Howard <***@asgard.org>
> *Cc: *"Carlos M. Martinez" <***@gmail.com>, Marc Blanchet <
> ***@viagenie.ca>, "***@ietf.org" <***@ietf.org>
> *Subject: *Re: [sunset4] ietf-nat64 - Internet VPN clients
>
>
>
> To learn on VPNs it would be good to record:
>
> · VPN client, sw version
>
> · Whether it is clear on whether IPsec is the protocol (some
> resort to SSL, some continue with IPsec)
>
> · Is the destination VPN gateway IPv4-only or dualstack
>
> · Is the VPN invoked by URL or by IP address
>
> Only the person performing the test will discern the last 2 aspects, it is
> particular to their intranet.
>
>
>
> The VPN I am most familiar with is IPsec, is stuck to an IP address
> destination.
>
> If the VPN gateway is IPv4-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 URLs have been ok AFAIK.
>
> My expectation is that a significant # of users fall into the IPsec to
> IPv4-only destination category, enough to callout IPv6-only + NAT64/DNS64
> as deficient. Better consensus would be good.
>
> Nick
>
>
>
>
>
> *From:* sunset4 [mailto:sunset4-***@ietf.org
> <sunset4-***@ietf.org>] *On Behalf Of *Bill Fenner
> *Sent:* 16 November 2016 08:36
> *To:* Lee Howard
> *Cc:* Carlos M. Martinez; Marc Blanchet; ***@ietf.org
> *Subject:* Re: [sunset4] ietf-nat64
>
>
>
> I tried for a couple of hours; neither of my two VPN clients works
> properly. I haven't noticed anything else so far.
>
>
>
> Bill
>
>
>
>
>
> On Wed, Nov 16, 2016 at 3:39 PM, Lee Howard <***@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¹t access my POP mail account
> when I¹m 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" <***@gmail.com> wrote:
>
> >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 with Jari and
> >>> Jim, and they're only reluctant if doing this impedes participants
> >>> 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 during
> >> the plenary.
> >>
> >> Marc.
> >>
> >>>
> >>> On this list, I'd like to hear ideas about how to structure
> >>> work/followup on #5 and #6.
> >>>
> >>> Are there other topics we should discuss?
> >>>
> >>> Thanks,
> >>>
> >>> Lee
> >>
> >>> _______________________________________________
> >>> sunset4 mailing list
> >>> ***@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/sunset4
> >>
> >> _______________________________________________
> >> sunset4 mailing list
> >> ***@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sunset4
> >
>
>
> _______________________________________________
> sunset4 mailing list
> ***@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
>
> 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
>

[Bjoern A. Zeeb]

On 9 Dec 2016, at 16:07, Bill Fenner wrote:

> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <***@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’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

[Heatley, Nick]

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-***@ietf.org] On Behalf Of Bjoern A. Zeeb
Sent: 09 December 2016 16:33
To: Bill Fenner
Cc: ***@ietf.org; ***@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 <***@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’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

_______________________________________________
sunset4 mailing list
***@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

[Tommy Pauly]

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.

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 or knowledge on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, at 9:03 AM, Heatley, Nick <***@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-***@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ***@ietf.org; ***@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 <***@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’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
>
> _______________________________________________
> sunset4 mailing list
> ***@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
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

[Heatley, Nick]

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 <***@apple.com>
Date: 09/12/2016 17:32 (GMT+00:00)
To: "Heatley, Nick" <***@ee.co.uk>
Cc: "Bjoern A. Zeeb" <bzeeb-***@lists.zabbadoz.net>, Bill Fenner <***@fenron.com>, ***@ietf.org, ***@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.

>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 or knowledge on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, at 9:03 AM, Heatley, Nick <***@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-***@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ***@ietf.org; ***@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 <***@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’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
>
> _______________________________________________
> sunset4 mailing list
> ***@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
> ***@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

[Tommy Pauly]

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 <***@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 <***@apple.com <mailto:***@apple.com>>
> Date: 09/12/2016 17:32 (GMT+00:00)
> To: "Heatley, Nick" <***@ee.co.uk <mailto:***@ee.co.uk>>
> Cc: "Bjoern A. Zeeb" <bzeeb-***@lists.zabbadoz.net <mailto:bzeeb-***@lists.zabbadoz.net>>, Bill Fenner <***@fenron.com <mailto:***@fenron.com>>, ***@ietf.org <mailto:***@ietf.org>, ***@ietf.org <mailto:***@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.
>
> >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 or knowledge on the server side.
>
> Thanks,
> Tommy Pauly
>
> > On Dec 9, 2016, at 9:03 AM, Heatley, Nick <***@ee.co.uk <mailto:***@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-***@ietf.org <mailto:sunset4-***@ietf.org>] On Behalf Of Bjoern A. Zeeb
> > Sent: 09 December 2016 16:33
> > To: Bill Fenner
> > Cc: ***@ietf.org <mailto:***@ietf.org>; ***@ietf.org <mailto:***@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 <***@ee.co.uk <mailto:***@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’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
> >
> > _______________________________________________
> > sunset4 mailing list
> > ***@ietf.org <mailto:***@ietf.org>
> > https://www.ietf.org/mailman/listinfo/sunset4 <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
> > ***@ietf.org <mailto:***@ietf.org>
> > https://www.ietf.org/mailman/listinfo/ipsec <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
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

[Yoav Nir]

> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb <bzeeb-***@lists.zabbadoz.net> wrote:
>
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
>
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <***@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’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?

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’s 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’s IPsec implementation doesn’t do all that. Neither does my employer’s.

Yoav

[Michael Richardson]

Yoav Nir <***@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’s IPsec implementation doesn’t do all
> that. Neither does my employer’s.

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.

In an IPv6 world, we have better ways to build walled gardens.


--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Tommy Pauly]

> On Dec 9, 2016, at 1:43 PM, Michael Richardson <mcr+***@sandelman.ca> wrote:
>
>
> Yoav Nir <***@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’s IPsec implementation doesn’t do all
>> that. Neither does my employer’s.
>
> 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—don'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

>
> In an IPv6 world, we have better ways to build walled gardens.
>
>
> --
> Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> IPsec mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

[Yoav Nir]

> On 9 Dec 2016, at 23:43, Michael Richardson <mcr+***@sandelman.ca> wrote:
>
>
> Yoav Nir <***@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’s IPsec implementation doesn’t do all
>> that. Neither does my employer’s.
>
> 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’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’s CFG, Cisco’s 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’t give it to you. And you don’t need any DNS games to do it.

Yoav

[David Schinazi]

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 <***@gmail.com> wrote:
>
>>
>> On 9 Dec 2016, at 23:43, Michael Richardson <mcr+***@sandelman.ca> wrote:
>>
>>
>> Yoav Nir <***@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’s IPsec implementation doesn’t do all
>>> that. Neither does my employer’s.
>>
>> 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’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’s CFG, Cisco’s 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’t give it to you. And you don’t need any DNS games to do it.
>
> Yoav
>
> _______________________________________________
> IPsec mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

[Michael Richardson]

Bjoern A. Zeeb <bzeeb-***@lists.zabbadoz.net> wrote:
> 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

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 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?

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.

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Bill Fenner]

On Fri, Dec 9, 2016 at 4:39 PM, Michael Richardson <mcr+***@sandelman.ca>
wrote:

>
> Bjoern A. Zeeb <bzeeb-***@lists.zabbadoz.net> wrote:
> > 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
>
> 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.
>

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 DNS
> to
> find his gateway, and he doesn't do DNSSEC on that, then it ought to work.
>

That is what I have configured.

Bill