On 16/09/2007, at 8:03 AM, Jeroen Massar wrote:
- IPv6 native (anything not 2002::/16 + 2003::/32)
- IPv4 native
- IPv6 6to4 (2002::/16)
- IPv6 Teredo (2003::/32
Incase anyone is using this for reference purposes, Jaroen really means 2001::/32, not 2003::/32.
Teredo was also previously on 3ffe:831f::/32, for those of you on older Windows XP machines. This prefix no longer works - upgrade.
Now the really BIG problem there is though is that when network
connectivity is broken. TCP connect will be sent, but no response comes
back or MTU is broken, then the session first has to time out.
<snip>
6to4 and Teredo are a big problem here, especially from an operator
viewpoint.
Yes. Infact, especially if you have users on Vista. It does this IPv6 tunnelling thing that on the surface appears really cool. When you try and talk IPv6 to something other than link-local: (in order)
- If you have a non-RFC1918 (ie. 'public') address, it fires up 6to4.
- If you have an RFC1918 address, it fires up Teredo.
Seems cool in theory, and you'd think that it would really help global IPv6 deployment - I'm sure that's how it was intended, and I applaud MS for taking a first step. But in practice, however, this has essentially halted any IPv6 /content/ deployment that people want to do, as user experience is destroyed.
You can help, though - here's the problem:
6to4 uses protocol 41 over IP. This doesn't go through NAT, or stateful firewalls (generally). Much like GRE.
Because of this, if you're a enterprise-esque network operator who runs non-RFC1918 addresses internally and do NAT, or you do stateful firewalling, PLEASE, run a 6to4 relay on 192.88.99.1 internally, but return ICMPv6 unreachable/admin denied/whatever to anything that tries to send data out through it. Better yet, tell your firewall vendor to allow you to inspect the contents of 6to4 packets, and optionally run your own 6to4 relay, so outgoing traffic is fast.
Even if you don't want to deploy IPv6 for some time, do this at the very least RIGHT NOW, or you're preventing those of us who want to deploy AAAA records alongside our A records from doing so. If you need configs for <vendor/OS B/C/J/L>, let me know and I'll write some templates.
I see this sort of IPv4 network quite commonly at universities, where students take their personal laptops and throw them on the campus 802.11 network. While disabling the various IPv6 things in Vista at an enterprise policy level might work for some networks, it doesn't for for a university with many external machines visiting. So, if you're a university with a network like this (ie. most universities here in NZ, for example), please spend a day or two to fix this problem in your network - or better yet, do a full IPv6 deployment.
I'd like to get some work done to get some 'qualification' testing of the availability of 6to4 from a 'client' POV standardised, so this problem can go away. Moving city+job has hindered such things as of late.
As such, if you, as an ACCESS operator want to have full control over
where your users IPv6 traffic goes to you might want to do a couple of
things to get it at least a bit in your control:
- setup a 6to4 relay + route 192.88.99.1 + 2002::/16
- setup a Teredo Server + Relay and make available the
server information to your users and inform them of it.
For those not on v6ops, I've got a draft right now that explains why you should (as an access provider) run a Teredo server, and proposes a standard to allow you to direct your users to your local Teredo server. I should be pushing out an update to it shortly. See above RE. moving life around.
Also, Relays are only useful if you have native IPv6 somewhere, OR if you run a 6to4 relay (which probably means you have native IPv6..). Note the distinct usage of 'servers' and 'relays', for the uninitiated.
I'm building some embedded system images that run Teredo and 6to4 relays, with pretty much zero configuration. It runs on Soekris hardware right now (ie. sub $USD300), but if people are interested I can port it to regular x86 hardware. All you need is an IPv6 tunnel from a broker somewhere - you don't even need native transit, and you can improve the performance of IPv6 over the various tunnelling protocols for your end users. If you're interested in this, drop me an email.
- and/or the better option IMHO, to keep it in control: setup a
tunnel broker and provide your users access to that. For instance
Hexago sells appliances for this purpose but you can also ask SixXS
to manage one for your customers.
Fine if you've got small numbers of high value+clue customers. Not so good if you're a nation-wide residential provider.
For CONTENT operators, get yourself a nice chunk of RIR space from your
RIR. Then what you might want to do is setup the following little test:
your important content sites. This will allow you to discover if your
clients are using IPv6 and if they are able to reach it. Then if you are
confident that you are up to it and that your clients are fine, you
might want to consider adding AAAA's to your site and go fully dual stack.
If anyone does run the ipv6wwwtest code (or something similar), please talk to me, as I'd like some numbers from some larger web properties so I can rant about it soon at an operator meeting near you, and perhaps aggregate numbers and provide an "IPv6 Internet health report" regularly.
You don't actually need any RIR space. You'll note that the braintrust.co.nz website does the checks using 6to4, as the place that server lives can't get native IPv6 transit. This takes less than a day to set up and does not require you to turn on an IPv6 network, and you can regularly evaluate whether enabling your content (and network!) for IPv6 is a good idea or not.
Also, if you do deploy an IPv6 network for your content, set up a Teredo relay, and point 2001::/32 at it. Your viewers/users will automatically use this relay when accessing your content, and their traffic to you will be over IPv4, all they way from their PC to your network - so, equivalent performance as IPv4. Note that I say relay here, not server.
If you have somewhat tech savvy users you can of course also ask them to
test it for you. "Check out our Cool new toy: we got IPv6!" or something
and ask them how it works.
(Apologies for a dis-jointed email. It's 1am, I'm tired and in a ranty mood)