Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Mon Sep 24 10:46:05 UTC 2007
There is something not correct here ... Proto-41 is supported by many boxes,
even NAT boxes, I guess by mistake from de vendor/implementation ...
Basically many boxes just understand TCP and UDP and they decide to
"pass-thru" other unknown protocols, instead of discarding them.
I've document that long time ago:
There is a PDF document also linked into the ID which may be interesting to
read for an specific example.
I use many times proto-41 (even with 6to4) even when I get private (behind
NAT) addresses for my laptop via my 3G phone.
De: Nathan Ward <nanog at daork.net>
Responder a: <owner-nanog at merit.edu>
Fecha: Mon, 17 Sep 2007 01:17:24 +1200
Para: NANOG <nanog at merit.edu>
Asunto: Re: Going dual-stack, how do apps behave and what to do as an
operator (Was: Apple Airport Extreme IPv6 problems?)
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.
> 6to4 and Teredo are a big problem here, especially from an operator
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
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 126.96.36.199 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 188.8.131.52 + 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:
> http://www.braintrust.co.nz/ipv6wwwtest/ and/or mods of it, put it on
> 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.
Mozilla.org are doing this for example. Cue Matthew Zeier.
(Apologies for a dis-jointed email. It's 1am, I'm tired and in a ranty mood)
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
More information about the NANOG