Enterprise Dual Stack without IPv6 Transit

[Jeroen Massar]

On 2014-12-09 17:59, Steve Housego wrote:
[..]
>> On 2014-12-09 17:27, Steve Housego wrote:
>>> First a bit of background, a client of mine is looking to deploy
>>> Microsoft DirectAccess and as part of that we are planning to
>>> Dual Stack IPv6 the path between the direct access clients (who are
>>> IPv6 only) [..]
>>
>> Do you mean that the underlying network is IPv6-only while in the
>> DirectAccess tunnel (read: IPSEC tunnel) you run both IPv4 + IPv6?
>>
>> What are you expecting clients to contact, only IPv4 or also IPv6
>> destinations?
>>
>> Also, watch out for leaks from such tunnels (See RFC7359)
> 
> DirectAccess is essentially an IPv6 tunnel between two IPv4 endpoints, the
> DA server and a remote user who could be anywhere home/train etc. These
> ŒVPN users¹ are only given an IPv6 address.

Almost. It uses either native-IPv6 or 6to4/Teredo/IP-HTTPS to get an
IPv6 address, then it just does IPSEC-AH+ESP using that IPv6 address.

Clients will thus not have an address out of your own PI range.

(unless something really heavily changed in Direct Access that I am not
aware about; you could IPv6 NAT them on the DA, but that breaks
end-to-end and then why would one bother with this; hmm I suddenly
wonder how the return traffic gets forced through the DA to IPSEC-sign
that traffic again, maybe route-jacking?)

> The DirectAccess server then NAT64/DNS64¹s all the clients traffic into
> the IPv4 Œserver LAN¹. Which is effectively a ŒPAT¹ so all the VPN users
> appear to come from the DA servers LAN IPv4 address.
>
> Which.. Is horrible, so we want to enable IPv6 for the path from the
> Direct Access clients to the Œserver LAN¹ so nothing is NAT¹d.

That is only horrible because you are trying to solve your problem with
the wrong tool (the NAT64/DNS64 part at minimum).

You clearly want each client to have their own IPv4 and IPv6 addresses.

This (NAT64/DNS64 portion) was made to avoid this whole IPv4 address
assignment.

You either have to configure it so that each IPv6 address gets a
separate outbound IPv4 address (no idea if that is possible) or use a
completely different tunneling method (OpenVPN comes to mind) that puts
both an IPv4 and IPv6 address on the box, which is likely better in the
short term as then you don't need any hacks any more with NAT64/DNS64.


>> [..]
>>> They do not however (yet) have an IPv6 internet connection.
>>
>> Why not? :)
> 
> ISP doesn¹t support it yet (even for business customers), we have already
> asked to be part of their trials.

Only answer: vote with your money. It is 2014.

Any ISP that is willing to route IP prefixes should be able to do IPv6.
If they cannot do that today then take your business elsewhere.


>>> i.e. as it has a global unicast address will it prefer IPv6 and try to
>>> reach it
>>> with IPv6 first which will obviously fail and then use IPv4?
>>
>> As long as you do not filter ICMPv6 and your routers return !N you
>> should be fine. All dual-stacked applications should try other addresses
>> and fall back. Happy Eyeballs typically makes this 'better'.
> 
> This is interesting, I hadn¹t came across ŒHappy Eyeballs¹ essentially
> they attempt both connections simultaneously - this is great.

It is 'great' till you have to debug why something is 'slow' and you
forget about this and are looking at IPv4 or IPv6 and sometimes it does
and sometimes it does not work.

Determinism is a good thing. Be happy that you are in a Windows
environment at that point as OSX is far less deterministic (and there is
no switch to turn that behavior off).

>>> My second question which is a bit more Microsoft centric ­ but worth
>>> asking ­ Is there likely to be some issue¹s with the DirectAccess
>>> clients trying to access the IPv4 internet (which is all tunneled
>>> through the DA server).. as the DNS server will likely return a 'true'
>>> IPv6 address in the DNS response to the client, this bit further boggles
>>> me as it needs to be DNS64/NAT64 for this traffic.
>>
>> The issues are the same for any other tunneled setup where you NAT
>> outbound.
>>
>>
>> What is actually the use-case for DirectAccess? Do you want to force
>> corporate devices to always use the corporate network and never the
>> locally available connectivity? Or do you just use it to access the
>> resources in the corporate network?
> 
> Yeah $company really likes the idea of whenever a laptop is switched on
> and on the internet that it¹s part of the corporate network

Direct Access does not make that like that.

The address that the client has will be a IPv6 address that is local.
eg, if the user has no native IPv6 and uses Teredo they will come from a
2001::/32 address.

The only reason why you can 'trust' that address is because it is IPSEC
signed. The DA server just strips that authentication after validating it.

> they also
> want to control web browsing through the corporate network proxy¹s which
> to be honest kind of answers my own question, the proxy will hopefully be
> IPv6 enabled available in the Œserver LAN¹ on IPv6 addressing anyway,
> worst case I suppose they could live with NAT64 for access to the proxy.

Sounds like you want good old SOCKS.

I would personally never bother with anything NAT, be that NAT64 or IPv4
NAT, in such an environment.

Greets,
 Jeroen