[spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)] Somewhat long, hopefully useful content follows... Barrett Lyon wrote: [..]

The other thought that occurred to me, does FF/Safari/IE have any ability to default back to v4 if v6 is not working or behaving badly? This could be a helpful transition feature but may be more trouble than it's worth.

The IETF recommendation is that IPv6 is tried before IPv4, BUT there is RFC3484 (http://www.ietf.org/rfc/rfc3484.txt) which gives an extra edge to this. In general it comes down that the resolver will, assuming there is both an IPv4 and IPv6 address (A + AAAA) on the dns label requested try, as a source address: - IPv6 native (anything not 2002::/16 + 2003::/32) - IPv4 native - IPv6 6to4 (2002::/16) - IPv6 Teredo (2003::/32 Of course when there is only a A or AAAA only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it connects correctly. The above table is re-programmable per host and there are discussions/drafts to automate that for a complete network. The correct way to use getaddrinfo() is described in: http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html by Eva Casto and of course the almost 10 year old document by Jun-ichiro itojun Itoh at: http://www.kame.net/newsletter/19980604/ 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. Thus if a user has IPv6 and the server has it also but the connectivity between them is b0rked then it will take quite some time to recover properly from this. Apps could of course do a multi-connect and try all in parallel but I am pretty sure that servers are not waiting for that and for instance the Firefox programmers don't even know what "threading" is, seeing that they can't even separate their UI from the network and rendering code, thus don't wait for them to do it for that. Also there is this nasty concept of deployed base and getting people to upgrade is of course far from easy, fortunately those types won't do IPv6 either hopefully ;) 6to4 and Teredo are a big problem here, especially from an operator viewpoint. This as an operator has absolutely no control over the flow of packets from/to his/her network. When the packets flow back it might just be that, due to BGP in the remote network, something attracts the 6to4 packets destined back for 6to4 and they mysteriously disappear or get routed around the world. The same for the way from the user on your network to the 6to4 relay at 192.88.99.1 (if you, like me, can't remember the address just type "host -t any 6to4.ipv6.microsoft.com" ;) This one can also be situated anywhere on this planet and BGP might pull it somewhere where you don't want it to go. 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. - 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. 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 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. As for the above spammed toys URL, I have to note that especially AXIS folks are really cool, you send them a mail asking "what products support IPv6" and the next day you get back very nice PDF's containing their overviews of everything that supports IPv6, they have lots of it, nearly all their products do. The best thing of course is that the sales reps actually KNOW what IPv6 is, wow, I like those AXIS folks! :) Greets, Jeroen

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: 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) -- Nathan Ward

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: http://tools.ietf.org/html/draft-palet-v6ops-proto41-nat-03 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. Regards, Jordi De: Nathan Ward <nanog@daork.net> Responder a: <owner-nanog@merit.edu> Fecha: Mon, 17 Sep 2007 01:17:24 +1200 Para: NANOG <nanog@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.

<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: 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) -- Nathan Ward ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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.

On Mon, 24 Sep 2007 23:35:12 +1200, Nathan Ward said:

Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though.

If you have 6,000 people behind a single NAT, proto-41 is probably the least of your concerns, and Randy Bush may or may not be thinking of awarding you an Innovative Engineering Award. :)

On 24-sep-2007, at 13:55, Nathan Ward wrote:

The other thing to note - 6to4 kicks in on Vista if it has a non- RFC1918 IPv4 address, so we're talking about people NATing large numbers of non-RFC1918 space. Regardless of how crazy they might seem, these networks exist

[...]

when those networks become few enough that we can turn on AAAA records for production stuff, they'll be forced to sort their stuff out).

How far can one bend over backwards before breaking said back?

Yes, that's clear, I was assuming we are talking about "end boxes" such as a CPE. Regards, Jordi

De: Nathan Ward <nanog@daork.net> Responder a: <owner-nanog@merit.edu> Fecha: Mon, 24 Sep 2007 23:35:12 +1200 Para: NANOG <nanog@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 24/09/2007, at 10:46 PM, JORDI PALET MARTINEZ wrote:

...

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.

Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though.

-- Nathan Ward

********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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.

- setup a 6to4 relay + route 192.88.99.1 + 2002::/16

How?

- setup a Teredo Server + Relay and make available the

How?

- 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.

Congratulations for explaining how to do it at the same time as you give the advice. --Michael Dillon

On 9/15/07, Jeroen Massar <jeroen@unfix.org> wrote:

[spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)]

Somewhat long, hopefully useful content follows...

Barrett Lyon wrote: [..]

[ clip ]

Of course when there is only a A or AAAA only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it

Since when is a timeout on the Internet ok? Haven't we moved beyond that? This is a controllable timeout. We don't have to do it, which is the point. What's the right way to do this? Thank you, and thank you Barret for starting the thread. :-) -M<

On 9/21/07, Mark Andrews <Mark_Andrews@isc.org> wrote:

In article <2d106eb50709202254q6f4ea4b7v6beda6deee5f7143@mail.gmail.com> you write:

...

On 9/15/07, Jeroen Massar <jeroen@unfix.org> wrote:

...

[spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)]

Somewhat long, hopefully useful content follows...

Barrett Lyon wrote: [..]

[ clip ]

...

Of course when there is only a A or AAAA only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it

Since when is a timeout on the Internet ok? Haven't we moved beyond that?

You mean to say you get 100% connectivity with IPv4?

I mean to say that I don't willingly set out to deliver < 100%.

On 21-sep-2007, at 7:54, Martin Hannigan wrote:

...

All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one

Since when is a timeout on the Internet ok? Haven't we moved beyond that? This is a controllable timeout. We don't have to do it, which is the point. What's the right way to do this?

I agree that it's not acceptable to engineer things such that timeouts occur by design. However, things tend to break, and in those situations it's important to recover as well as can be expected. So the correct way to operate here is for the network designer to make reasonably sure ("unreliable datagram" etc) that everything works, for the stack designer to make sure that there is a good algorithm for selecting the "best" combination of destination and source addresses and for the application to cycle through all addresses if the two former efforts weren't completely successful.

On 9/15/07, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

On 15-sep-2007, at 21:25, Barrett Lyon wrote:

...

The other thought that occurred to me, does FF/Safari/IE have any ability to default back to v4 if v6 is not working or behaving badly? This could be a helpful transition feature but may be more trouble than it's worth.

Browsers are pretty good at falling back on a different address in general / IPv4 in particular when the initial try doesn't work,

"Pretty good" as in there is a browser standard to poke for v6 then v4 or is this a stack behavior? -M<

[as this has nothing to do with Apple Airports in particular I changed the subject again] Martin Hannigan wrote:

Should be an operation defined by gethostbyname() no?

and in another:

"Pretty good" as in there is a browser standard to poke for v6 then v4 or is this a stack behavior?

No, it is done by getaddrinfo() and the resolver layers of the OS, please read the somewhat longer mail from with the subject of "Going dual-stack, how do apps behave and what to do as an operator", yes it is long, but it explains more or less how it works and answers these questions. Andy Davidson wrote:

On 16 Sep 2007, at 07:39, Martin Hannigan wrote:

...

On 9/15/07, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

...

Browsers are pretty good at falling back on a different address in general / IPv4 in particular when the initial try doesn't work, "Pretty good" as in there is a browser standard to poke for v6 then v4 or is this a stack behavior?

Since this conversation has already talked about behaviour when encountering AAAA vs A, I am worried that a browser running on a dual-stack laptop might cache the AAAA returned when it has some v6 connectivity, and then refuse to look again for the A when I pick it up and take it somewhere with only v4 connectivity.

getaddrinfo() asks first for AAAA, then for A, then sorts the records and then returns them to the application. Thus no such problem there unless some OS implements this in the wrong way, but afaik that is not the case. Now indeed when you are swapping locations and thus change IP addresses (eg loose the IPv6 connection, gain IPv4, or change from one IPv4 address to the other or one IPv6 address to another), indeed TCP sessions will die, but that is a problem with mobility.

We see the browser cache bite us regularly with regard to the way they dip into the cache for long-stale records today. The support burden will increase if there are stack transitionary woes as well.

Browsers should (and afaik don't) care about the IP protocol they got a resource from, they cache based on URI "http://www.example.com/bla.png" and do not note the IP protocol it was from. Note that there are a couple of browsers though which have their own internal "IPv6 off" switches, eg firefox has "network.dns.disableIPv6" which can be turned off by the user, Safari had/has IPv6 turned off per default and so was Opera. This as they perceived IPv6 to have problems and thus if there is IPv4 they always first use IPv4 and then IPv6, ignoring the ordering done by getaddrinfo(). Greets, Jeroen

On Sun, Sep 16, 2007, Iljitsch van Beijnum wrote:

...

We see the browser cache bite us regularly with regard to the way they dip into the cache for long-stale records today.

Does browser caching still work these days? I thought all web admins disabled it on their servers because they can't be bothered to think about which cache directives to send along with each page. I can rarely return to a previously viewed page without the browser hitting the network, in any event.

Not all Web Admins do. At least, people still see ~30% byte hit rates on Squid caches. ;) Besides, these are two different things - browser DNS caching and browser content caching. Adrian

Iljitsch van Beijnum wrote:

Does browser caching still work these days? I thought all web admins disabled it on their servers because they can't be bothered to think about which cache directives to send along with each page. I can rarely return to a previously viewed page without the browser hitting the network, in any event.

Actually, browser caching is a function of the Web design tags, not the server. So, the decision to allow caching is on the page creator. On my own sites, I leave caching to the default unless there is a good reason to disable caching. One site I used to run, a warranty form processor, I disabled all caching -- at all levels -- because it was a database-driven site allowing updates from multiple people at the same time, so caching was highly inappropriate. Caching use to bite me regularly when I was doing customer support. Which led to the mantra "Clear the cache!"

On 17-sep-2007, at 19:06, Martin Hannigan wrote:

Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated.

For debugging purposes, it's always good to have blah.ipvX.example.com, but the real question is: do you feel comfortable adding AAAA records to your production domain names? Although I've been running that way for years and I've had only one or two complaints during that time, I can see how someone could be worried about reduced performance over IPv6 (it's still slower than IPv4 a lot of the time because of tunnel detours etc) or even timeouts when advertised IPv6 connectivity doesn't work for someone, such as a Vista user with a public IPv4 address behind a firewall that blocks protocol 41. Then again, I'm guessing that few people type www.ipv6.google.com rather than www.google.com. And with stuff like mail, where you set up the server names once and forget about it, it's even worse. So... I'd say: gain some experience with a service that is important enough that people will complain when things are slow, but not important enough that bad things happen if you don't fix the issue for them. For instance, you could host the page with all the NOC contact info on a domain with an AAAA record. :-)

At 4:47 PM -0400 9/17/07, Martin Hannigan wrote:

On 9/17/07, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

...

On 17-sep-2007, at 19:06, Martin Hannigan wrote:

...

Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated.

For debugging purposes, it's always good to have blah.ipvX.example.com, but the real question is: do you feel comfortable adding AAAA records to your production domain names? Although I've been running that way for years and I've had only one or two complaints during that time, I can see how someone could be worried about reduced performance over IPv6 (it's still slower than IPv4 a lot of the time because of tunnel detours etc) or even timeouts when advertised IPv6 connectivity doesn't work for someone, such as a Vista user with a public IPv4 address behind a firewall that blocks protocol 41.

Then again, I'm guessing that few people type www.ipv6.google.com rather than www.google.com. And with stuff like mail, where you set up the server names once and forget about it, it's even worse.

I see. There isn't really an answer. :-) That's what I am getting at. Not to suggest that this is your responsibility, it's not - it's ours.

For now, I'm going to try the unique A/AAAA and segregate the answers by protocol and sub domain the v4 traffic since it's a migration "to" v6.

-M<

On Mon, 17 Sep 2007 17:15:38 EDT, John Curran said:

In addition, if the AAAA record is added for the node, instead of service as recommended, all the services of the node should be IPv6- enabled prior to adding the resource record. "

Not a problem for names which are single services (www.foo.com), but caution is required when the name has multiple services running.

My favorite shoot-self-in-foot on that topic - I stuck a quad-A in for a host that *was* IPv6-enabled on the production service, but it didn't have (at the time) an IPv6-ready ssh daemon. Hilarity ensued when using an IPv6-enabled ssh client - you'd get back an RST packet real fast and it was Game Over. So remember - there's probably more services you need to worry about. ;)

Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated.

Personally I find separation of the A/AAAA somewhat of a dysfunctional way to deal with this issue. Users that opt-in to dual-stack will be accepting of the downfalls in the v6 deployments out there. In that case, it should be fine to provide a seamless experience with overlapping DNS records. However, users are not getting a choice or even an education on what is happening on the tunnel and are getting impacted from overlapping AAAA/A records. This is the breakdown, I think that if we start segmenting DNS to fix a symptom and not the problem itself, we're just adding more ducktape. I would actually think Apple (and any other vendor that default enable v6 tunnels without notifying the user) should react to this and provide a fix that allows their current user base to opt-in to their pre-existing tunnels with education on what that means to the user. It's great to be progressive, but it's not good to do it when it can impact users. Regarding segmented v4/v6 DNS, this may already exist, but it may also be a good idea for the web masters out there to create a v6 logo or marking denoting that a user has reached a v6 page vs. a v4 page. This could also be more helpful and also allow users to choose which protocol is used to reach the site. It also creates a reason to have both an overlapping AAAA/A www. and a special www.v6./w6. and www.v4. alias. If that framework accompanied the overlapping DNS, then HREFs could shuffle users from one version of the site pending on the user preference. On a totally unrelated note: Not to make any accusation on the security of the end-point tunnel network what-so-ever, but an entirely other issue is the tiny bit of a security conundrum that default tunnels create -- tunneling traffic to another network without notifying the user seems dangerous. If I were a tinfoil-hat security person (or a CSO of a bank for example) this would really freak me out. -Barrett

Barrett Lyon wrote: [..]

I would actually think Apple (and any other vendor that default enable v6 tunnels without notifying the user) should react to this and provide a fix that allows their current user base to opt-in to their pre-existing tunnels with education on what that means to the user. It's great to be progressive, but it's not good to do it when it can impact users.

IMHO what Apple (bcc'd :) should provide is a 'connectivity test'. Thus when they enable 6to4 per default, they should test that they can at least reach the 6to4 anycast node which is going to relay their packets and they should test a remote node (eg connectivity-test.apple.com) if they can reach that. Which is sort of what Vista tries to do to and several other connection managers which show visually how/if there is "Internet connectivity". XP for instance also whines when you don't have good connectivity to the Internet based on some tests. If the connectivity looks broken, then either disable the tunnel or at least notify the user that experience might be diminished.

Regarding segmented v4/v6 DNS, this may already exist, but it may also be a good idea for the web masters out there to create a v6 logo or marking denoting that a user has reached a v6 page vs. a v4 page. This could also be more helpful and also allow users to choose which protocol is used to reach the site. It also creates a reason to have both an overlapping AAAA/A www. and a special www.v6./w6. and www.v4. alias.

Please please please, for the sake of a semi-'standard', please only use the following forms in those cases: www.<domain> www.ipv6.<domain> www.ipv4.<domain> Don't come up with any other variants. The above form is what is in general use around the internet and what some people will at least try to use in cases where a DNS label has both an AAAA and A and one of them doesn't work. You can of course add them, it is your DNS, but with the above people might actually try them.

If that framework accompanied the overlapping DNS, then HREFs could shuffle users from one version of the site pending on the user preference.

On a totally unrelated note: Not to make any accusation on the security of the end-point tunnel network what-so-ever, but an entirely other issue is the tiny bit of a security conundrum that default tunnels create -- tunneling traffic to another network without notifying the user seems dangerous. If I were a tinfoil-hat security person (or a CSO of a bank for example) this would really freak me out.

Just if an enduser controls the path over which his traffic goes now anyway? The answer to that is crypted VPN's and nothing else. And of course for instance MS allows you to turn off those features using Active Directory management. Maybe Mac's also have such a button somewhere? Next to of course the use of a firewall which explains you what connections are being made and which packets are being sent. Greets, Jeroen

On Sep 18, 2007, at 1:30 PM, David Conrad wrote:

HI,

On Sep 18, 2007, at 5:45 AM, Jeroen Massar wrote:

...

Please please please, for the sake of a semi-'standard', please only use the following forms in those cases:

www.<domain> www.ipv6.<domain> www.ipv4.<domain>

Don't come up with any other variants. The above form is what is in general use around the internet and what some people will at least try to use in cases where a DNS label has both an AAAA and A and one of them doesn't work. You can of course add them, it is your DNS, but with the above people might actually try them.

What RFC (or other standards publication) is this documented in?

Where did the www.ipv6 and www.ipv4 "standard" come from? As for end- users such as normal non-network people, having a standard that adds more characters than necessary (that eventually may become arbitrary) seems rather silly. Why wouldn't w4.<domain> or w6.<domain> suffice for this purpose rather than making it overly scientific? I can understand the want to use ipv4 etc to separate out other services such as DNS, SMPT, etc, but everyone does what they want with those services anyway. -Barrett

...

...

Don't come up with any other variants. The above form is what is in general use around the internet and what some people will at least try to use in cases where a DNS label has both an AAAA and A and one of them doesn't work.

Where did the www.ipv6 and www.ipv4 "standard" come from?

He already explained that as quoted above. It is a de-facto standard since that is what is in general use around the Internet. Standards are not always created by standards groups, sometimes they just grows, like Topsy. The key thing here is that adding AAAA records for a host that also has an A record, can cause strange things to happen. If this would be bad for the services offered by the host with the A record, then you can create two new pseudo-hosts ipv6.host and ipv4.host. Put the AAAA record only on the ipv6.host entry, and make the ipv4.host entry either a duplicate of, or a CNAME to the original host with the A record. That way, you can still get some IPv6 traffic from IPv6 knowledgeable people for testing purposes. Or you can solicit people to help with your testing by using the ipv6.host variant. --Michael Dillon

On 9/15/07, Barrett Lyon <blyon@blyon.com> wrote:

...

How did you do the naming? Matching AAAA or unique?

Matched AAAA, I was thinking about doing a w6 or something more unique for now, but that somewhat defeats the point.

I tried to do it in a round robin record based on the described behavior. My theory was that the inverse response should occur and satisfy. My results were failure. BIND 9.3.2 accepted the record, did not complain and properly reloaded the zone, but did not offer the v6 AAAA as the inverse. I'm probably missing something here... like "not supported". :-)

The other thought that occurred to me, does FF/Safari/IE have any ability to default back to v4 if v6 is not working or behaving badly? This could be a helpful transition feature but may be more trouble than it's worth.

Should be an operation defined by gethostbyname() no? -M<