enterprise IPv6 only client computers and IPv4 connectivity

Martin Millnert martin at millnert.se
Tue Apr 30 10:54:26 CEST 2013


On Tue, 2013-04-30 at 16:06 +0900, Lorenzo Colitti wrote:
> On Tue, Apr 30, 2013 at 4:03 PM, Mikael Abrahamsson <swmike at swm.pp.se>
> wrote:
>         If an enterprise today would decide that they're going to run
>         IPv6 only on their LAN, they would have recent Win7|Win8|OSX|
>         Ubuntu clients on their client computers, what mechanism would
>         they use to access IPv4 Internet?
> 
> 
> "None, and good luck"?

Within the "good luck" segment, you can work to cover as much ground as
possible but there is obviously no 100%-covering solution:

 - NAT64/DNS64 (or a more recent name if there is any) in the resolvers
 - dual-stacked proxy, handing out to clients either via group
policies/puppet/etc, and/or WPAD.

If "enterprise" means normal "user" VLANs, rather than all server VLANs
etc of a bank or process control environments with tons of legacy apps,
it should be generally and on average manageable to handle the odd cases
who cannot access their whatever-service.

While a proxy isn't very sexy, it would take care of literals.
Depending on admin skills, it could be configured only on client
machines with trouble.  Myself, I would have made it the default
setting.  Non-abiding clients would still get DNS64/NAT64.

At $previousjob we used WPAD to distribute proxy information via DNS and
DHCP to our clients in advance of a planned service outage, to give a
backup service to our 2k clients over some 1Mbps link.
Deployed it, and requests started (flooding) in. Proxy did its job
though.
This was like 8 years ago.  Today support in OS'es and browsers is only
much better, especially with the DNS method - all browsers by default
check for it.

/M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130430/c0e2b3b5/attachment.sig>


More information about the ipv6-ops mailing list