Print

[tjhinternetsp]

I recently went through the HE ipv6 certification process and got as far as "guru".

This means that I am now serving web and mail via IPv6 from most of the machines on my /29 home-office network.

I have some questions, though.

I am generating a series of "Live DVD" and I want them to be IPv6 ready from the moment they complete boot.

It's easy for me to assign them IPv6 addresses within a network.

I am not sure how to set up to automatically access the HE Tunnelbroker.

For example, one such Live DVD might boot and be attached by ethernet as a static-IPv4 address on a /29 IPv4 network. It seems straightforward to set this up in the same way as I set up the tunnel endpoint at my servers.

For another example, one such Live DVD might boot and get a wireless DHCP lease from a commercial cable/fiber ISP, with the usual NAT mechanism operating at the wifi/cable router.

Can this be set up in the exact same way?

By this, I mean, if for example the Live DVD boots and is assigned 192.168.1.101 from DHCP, does the router need to be IPv6 compliant in order to develop a tunnel from the booted machine to ::216.66.22.2 (tunnelbroker)?

[jimb]

The best ways to do this probably wouldn't be with a statically configured IPv6 tunnel service such as HE, or really, any service which requires an account to be set up, etc.

It'd probably be best to rely on SLAAC (StateLes Address Auto Configuration), which is built into IPv6, and/or DHCPv6 as the "preferred" way of obtaining IPv6 info.  That way if IPv6 is already running on the particular network infrastructure you come up on, it will use that, as is proper.

If it comes up on an IPv4 only network, then one could attempt to use Teredo or 6to4 to get IPv6 going.  Both of these do not require any previous setup to establish an IPv6 tunnel, both being automatic tunneling methods.  6to4 would be much more difficult to implement in an automatic fashion, and since it's based on 6in4, it doesn't play well behind IPv4 firewalls/NAT (for instance, forget about having more than one 6to4 client behind a single public IP NAT situation).

Teredo has more overhead than 6to4, and is byzantine in its operation compared to 6to4, but is basically completely automatic.  It's been implemented under Linux via the Miredo software.  Basically, once you turn it on, it determines its Teredo IPv6 by talking to various Teredo servers on the internet, and IPv6 traffic is encapsulated in UDP and relayed via various Teredo relays (which are different from Teredo servers) on the internet, or "directly" to other teredo clients using UDP hole punching.  Like 6to4, the Teredo IPv6 is determined by the public IPv4.  But since the IPv6 packets are encapsulated in UDP, it plays nice behind NAT devices/firewalls.  

So this would be by far the easiest way to establish an IPv6 island in an IPv4 sea.  The problem with Teredo I've found is that it can have slow startup, and a bit of overhead can lead to fairly slow RTTs.  But it generally works.  

BTW: HE runs many Teredo relays on the internet.  I believe nearly all their tunnel servers are also teredo relays (or have teredo relays present in the same PoP).  Tracing Teredo traffic from where I've been spending the holidays, I've noticed that large portion of my Teredo packets go straight to an HE relay. 

[tjhinternetsp]

-snips-

If it comes up on an IPv4 only network, then one could attempt to use Teredo or 6to4 to get IPv6 going.  Both of these do not require any previous setup to establish an IPv6 tunnel, both being automatic tunneling methods.  6to4 would be much more difficult to implement in an automatic fashion, and since it's based on 6in4, it doesn't play well behind IPv4 firewalls/NAT (for instance, forget about having more than one 6to4 client behind a single public IP NAT situation).

Teredo has more overhead than 6to4, and is byzantine in its operation compared to 6to4, but is basically completely automatic.  It's been implemented under Linux via the Miredo software.  Basically, once you turn it on, it determines its Teredo IPv6 by talking to various Teredo servers on the internet, and IPv6 traffic is encapsulated in UDP and relayed via various Teredo relays (which are different from Teredo servers) on the internet, or "directly" to other teredo clients using UDP hole punching.  Like 6to4, the Teredo IPv6 is determined by the public IPv4.  But since the IPv6 packets are encapsulated in UDP, it plays nice behind NAT devices/firewalls.  

So this would be by far the easiest way to establish an IPv6 island in an IPv4 sea.  The problem with Teredo I've found is that it can have slow startup, and a bit of overhead can lead to fairly slow RTTs.  But it generally works.  

BTW: HE runs many Teredo relays on the internet.  I believe nearly all their tunnel servers are also teredo relays (or have teredo relays present in the same PoP).  Tracing Teredo traffic from where I've been spending the holidays, I've noticed that large portion of my Teredo packets go straight to an HE relay. 

It occurs to me that I could also use IPv4 IPSec to get beyond the NAT and then tunnel through that to another IPSec machine which would also be connected to the IPv6 network. Teredo seems to be "do-able" but many of the sources I find seem to think that it's very much a stop-gap measure and should never be expected to be a standard approach. Then again, nobody expected widespread NAT and even multiple layers of NAT to become a standard approach.

The value of the IPSec is that it's not UDP, because a lot of places will exclude UDP by policy. Remember, UDP pretty much goes on forever, so lots of network admins won't let it onto their networks lest it clog up the works (so to speak). So something more stateful like TCP would likely be more guaranteed to get through firewalls, unless of course they're specifically filtering out IPSec packets, which some places actually do.

Then again, given an "ally" machine somewhere on the network, reachable from any NATted machine, SSL could provide the same sort of tunnel. But if the UDP/firewalling issue isn't too much of a problem, Teredo seems to be pretty widespread.

Thanks for the suggestions!

[jimb]

Yeah there's any number of tunneling solutions one could make use of to get IPv6 tunneled though.  But I thought the goal was to get IPv6 connectivity in a "turnkey" manner without having to set up any infrastructure.

Not sure what you mean by "UDP goes on forever".  I haven't run into many situations which don't allow UDP encapsulated IPSEC.  The majority of IPSEC clients employ this to traverse NAT.

ACK.  My plane is boarding.  BBL.