Re: Apple Airport Extreme IPv6 problems?
Some months ago I already circulated in this list instructions that I've provided in other IPv6 related exploder for doing so ... Introduction to 6to4 https://lists.afrinic.net/pipermail/afripv6-discuss/2007/61.html Configuring 6to4 Relay in Cisco https://lists.afrinic.net/pipermail/afripv6-discuss/2007/66.html Configuring 6to4 Relay in Linux https://lists.afrinic.net/pipermail/afripv6-discuss/2007/67.html Configuring 6to4 Relay in BSD https://lists.afrinic.net/pipermail/afripv6-discuss/2007/68.html Configuring 6to4 Relay in Windows https://lists.afrinic.net/pipermail/afripv6-discuss/2007/74.html Configuring Teredo Server/Relay in Linux/BSD https://lists.afrinic.net/pipermail/afripv6-discuss/2007/80.html Regards, Jordi De: [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 16 Sep 2007 15:38:21 +0100 Para: nanog@merit.edu Conversación: Apple Airport Extreme IPv6 problems? Asunto: RE: Apple Airport Extreme IPv6 problems? I think we will never move to IPv6 if vendors don't do things like the one in the Airport. However, in order to make this transition phase where there may be a possible degradation of the RTT, we need to cooperation of the operators, for example deploying 6to4 relays in their networks. And just what should operators do to cooperate? Are you aware of any documents that describe how to set up 6to4 relays in an ISP network? --Michael Dillon ** 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.
Re: Apple Airport Extreme IPv6 problems?
For a production service, I will never use dual naming for IPv4 and IPv6, is ridiculous ask the users to understand if they want to use one or the other to use a different name. For a testing, not an issue. Regards, Jordi De: Martin Hannigan [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 17 Sep 2007 13:06:25 -0400 Para: Iljitsch van Beijnum [EMAIL PROTECTED] CC: Barrett Lyon [EMAIL PROTECTED], nanog@merit.edu Asunto: Re: Apple Airport Extreme IPv6 problems? On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] 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, but it does take too long if the packet is silently dropped somewhere. If there is an ICMP unreachable there is no real delay. Worst case is a path MTU discovery black hole, then browsers generally don't fall back. 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. I have also read Jordi? saying that no dual naming should occur, but I think this is unrealistic. (Sorry if I misquoted you, Jordi) It would be good if more ISPs deployed 6to4 gateways so the 6to4 experience would be better. We are. There are an unending supply of small details that are in the way at the moment. :-) Best, Marty ** 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.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Unfortunately, Juniper doesn't support 6to4, only in Netscreen boxes. This is ridiculous and I already asked Juniper several times about this ..., but never got a positive feedback about when it will be supported. Regards, Jordi De: [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Sep 2007 14:54:11 +0100 Para: nanog@merit.edu Conversación: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) Asunto: RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 How? This is reasonably well documented for a Cisco but here's a minimal sample config: Thanks. I used your info, and other sources, to put up a page at http://www.getipv6.info/index.php/First_Steps_for_ISPs which describes how to set up 6to4 relay on Cisco, where to get Teredo relay software that you can run, and where to get tunnel broker software. There are a couple of gaps. I can find no info on how to set up 6to4 relay services on Juniper routers. Does JUNOS support this at all? If you know, go to the above page, click on Juniper, and tell us what needs to be done. In addition, CSELT in Italy distributed an IPv6 tunnel broker package at one time. I cannot find this anywhere. If you know where this software can be acquired or if you know of better IPv6 tunnel broker software, add it to the above page. I now know why people are so quick to give advice on what to do without explaining how to do it. It just is not easy to find out how to setup 6to4 relay services, Teredo relay services and IPv6 tunnel broker services. No doubt you can hire a consultant to do this for you, but if we want to get significant deployment we cannot rely on consultants who keep their toolkits secret. --Michael Dillon ** 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.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
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 [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] 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 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
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
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 20/09/2007, at 4:08 AM, Seth Mattinen wrote: Adrian Chadd wrote: On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run save-config script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/ routers out of, and quite inexpensive. Adrian, Seth, anyone else interested. I've almost got a Soekris FreeBSD image going, working just as Adrian describes RE upgrades, running Miredo and 6to4 relays. I'll release for testing within a couple weeks, drop me an email if you'd like to play. I'm doing both NET4801 and NET4501, as that's what I've got here right now. The only stuff left to do is put some basic configs on there, and test Miredo some. 6to4 etc. all functions fine, it just needs some hand holding. -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
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. :) pgpmLKqZ6571Z.pgp Description: PGP signature
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 11:48 PM, [EMAIL PROTECTED] wrote: 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. :) Don't worry, /I/ don't do this. Some large enterprise/campus networks do, though. Let's revise my number to 2. Just as much as a problem if they're both trying to do proto-41 :-) 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, and they're preventing people from rolling out IPv6 () to production stuff. It's annoying, because they're often the same people who say I'm not going to pay attention to IPv6, I've got enough addresses., and we all lose because of it. (That, or when those networks become few enough that we can turn on records for production stuff, they'll be forced to sort their stuff out). -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Yes, that's clear, I was assuming we are talking about end boxes such as a CPE. Regards, Jordi De: Nathan Ward [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] 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.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
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 records for production stuff, they'll be forced to sort their stuff out). How far can one bend over backwards before breaking said back?
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Mon, Sep 24, 2007, JORDI PALET MARTINEZ wrote: Yes, that's clear, I was assuming we are talking about end boxes such as a CPE. You'd be surprised how many Cisco 827's there are out there in strange places without a sane NAT config (with all the 12.4T NAT twiddles set appropriately.) Max NAT session before running out of RAM? ~8k or so? What kills it? Trackerless P2P. Lovely. And lets not discuss the default cisco IOS firewall and its tracking state + throttling stuff.. Adrian
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Date: Mon, 24 Sep 2007 12:41:12 +0200 From: JORDI PALET MARTINEZ [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Unfortunately, Juniper doesn't support 6to4, only in Netscreen boxes. This is ridiculous and I already asked Juniper several times about this ..., but never got a positive feedback about when it will be supported. Unfortunately, IPv6 support in almost any network hardware is pretty lame. Yes, both C and J support IPv6, but that is often pretty slim support, especially in terms of management and accounting. And they have the nerve to charge extra for IPv6 capability that is missing most features needed to provide true, production quality support. It's even worse in areas like security products and various network application, monitoring, and analysis devices. About the only things that is pretty likely fully IPv6 capable is the end system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpQJwSHy3ESq.pgp Description: PGP signature
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
In article [EMAIL PROTECTED] you write: On 9/15/07, Jeroen Massar [EMAIL PROTECTED] 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 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? 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 I've been running dual stacked for 5 years with a trans pacific tunnel to HE (10 hops). While there have been the occasional glitch I don't see much difference between IPv4 and IPv6. Work has also been running dual stacked. I very rarely fall back to IPv4, and given my usage patterns I do notice when IPv6 connectivity fails. Looping through the addresses as returned by getaddrinfo is a reasonable strategy. Mark
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 9/21/07, Mark Andrews [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you write: On 9/15/07, Jeroen Massar [EMAIL PROTECTED] 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 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%.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
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.
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/routers out of, and quite inexpensive. Before you choose which hardware platform to use, you should take a look at the software platform and see what other people are using. There are dozens of Linux router distros like OpenWRT out there. http://leaf.sourceforge.net/ Linux Embedded gateway/router/firewall http://www.linuxdevices.com/articles/AT6003080606.html Building a low cost router appliance Linux Devices is a good site to find information about embedded hardware platforms that support Linux. There are a lot of possibilities ranging from fanless x86 systems built around a Via EPIA motherboard to traditional embedded platforms based around ARM or MIPS processors. And just about anything that runs Linux will also run BSD if that is what you want. --Michael Dillon
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 9/15/07, Jeroen Massar [EMAIL PROTECTED] 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 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
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
When I wrote my book, I mostly looked at Cisco for this, and apart from Cisco to FreeBSD and Linux. The logic is that on a Cisco, you can build a good tunnel box (6to4 or manual tunnels) on a C7200 or some other box that has a decent CPU that can do the tunneling in software. Quite possibly a Juniper can do the same with hardware support (although I don't know that and it's also very possible that they can't do it in hardware or with decent speed in software) but there are no cheap(er) Juniper boxes that are suitable for deployment as a 5 - 200 Mbps tunnel box, in my opinion. Are you saying that 6to4 relay servers should be dedicated to that task? I.e. you should either dedicate a pair of routers per PoP or set up a couple of BSD/Linux boxes per PoP? --Michael Dillon
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Just stumbled upon this article http://www.networkworld.com/news/tech/2007/090507-tech-uodate.html Suggested here is that Dual Stack is more attractive than tunneling. Is the advise here based on real life experience or is it a matter of what is good for the goose may not be good for the gander? The article is written for enterprise network administrators, not for ISPs. If you are an ISP, the two main options are to dual-stack or to use MPLS with 6PE. Even if your network does not have an MPLS core today, you should still consider whether it makes sense to use MPLS with 6PE as your migration path to IPv6. Every network is different so there is really no panacea here. As for tunnels, I expect that everybody uses them somewhere in the network. There are lots of different kinds of tunnels, more than mentioned in the article. For ISP purposes, you could build an IPv6 overlay network instead of either dual-stacking or MPLS with 6PE. For small to midsize ISPs this may make a lot of sense. For larger ISPs, they will likely do some of this to accommodate their 2nd and 3rd tier PoP locations. The important thing about tunnels is to make sure that they are well-designed and well-maintained. The most important aspect of maintaining a tunnel, is making sure that you get rid of it when it is no longer the best solution. MPLS is based on tunneling. Lots of broadband access is based on tunnels. Pseudo-Wire Emulation is based on tunnels. --Michael Dillon
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 18-sep-2007, at 23:51, [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2007 23:29:38 +0200, Iljitsch van Beijnum said: they can't do it in hardware or with decent speed in software) but there are no cheap(er) Juniper boxes that are suitable for deployment as a 5 - 200 Mbps tunnel box, in my opinion. I presume your thinking is that by the time you get to 200Mbps of tunneled stuff, it's time to get native mode turned up? No need to wait that long... Native is always the best way to go if possible. Honestly, I haven't considered the possiblity of someone needing more than a couple hundred megabits worth of tunnel traffic.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 19-sep-2007, at 11:58, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Are you saying that 6to4 relay servers should be dedicated to that task? No, of course not. However, even though today IPv6 traffic is fairly minimal for pretty much everyone, it has the potential to grow quickly now that more stuff comes with IPv6 support out of the box. If someone then adds an record to a service that generates a lot of traffic, a noticeable amount of traffic can move from IPv4 to IPv6 over night. So I wouldn't be comfortable doing any form of IPv6 that is limited to, say, 200 Mbps on a router that can handle many gigabits worth of IPv4 traffic. That way, if more than a few percent of the traffic moves from IPv4 to IPv6, you're in trouble. Note that this equally applies to tunnel en/decapsulation and regular IPv6 forwarding if those are not hardware accelerated. However, if you have a box that has the same IPv6 as IPv4 capabilities, you won't have any trouble. And if you have a somewhat limited box handle IPv6 and then IPv6 grows beyond the capabilities of that box, at least your IPv4 traffic isn't affected. I.e. you should either dedicate a pair of routers per PoP or set up a couple of BSD/Linux boxes per PoP? No need to do tunneling at leaf nodes (i.e., ones where all the traffic goes into one direction) and if you have at least two in your network one location can be backup for another, so then one per location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. But doing it on non-dedicated routers is fine as well as long as you're sure an excess of IPv6 traffic isn't going to cause problems.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run save-config script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. Adrian
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Adrian Chadd wrote: On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run save-config script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/routers out of, and quite inexpensive. ~Seth
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Wed, Sep 19, 2007, Seth Mattinen wrote: If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/routers out of, and quite inexpensive. Good for some things. You can get bigger things for ~ $1k in a 1ru formfactor that take single-core or dual-core CPUs depending on what you need. (I think the latest whitebox wholesaler was Supermicro who were pushing AUD $700 1ru barebones 300mm deep servers with an intel motherboard. Add RAM+CPU+flash, shake and stir.) How much traffic can a modern intel board with a core 2 duo handle with $EL_GENERIC_UNIX_OS ? Adrian
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Wed, Sep 19, 2007, Alex Thurlow wrote: How much traffic can a modern intel board with a core 2 duo handle with $EL_GENERIC_UNIX_OS ? The PCI-Express bus tops out at 2.5 Gbps I believe, and they (Vyatta router salespeople to be specific) say you should be able to reach that. At 850 Mbps, my Intel Core 2 Duo running Quagga/IPtables (with a decent number of firewall rules) on Gentoo only hits about 30% CPU usage. With that, it sound like you could hit the 2.5Gbps if you had the connection. What pps are you seeing on that? Adrian
Re: Apple Airport Extreme IPv6 problems?
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 /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 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 signature.asc Description: OpenPGP digital signature
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
- setup a 6to4 relay + route 192.88.99.1 + 2002::/16 How? This is reasonably well documented for a Cisco but here's a minimal sample config: Thanks. I used your info, and other sources, to put up a page at http://www.getipv6.info/index.php/First_Steps_for_ISPs which describes how to set up 6to4 relay on Cisco, where to get Teredo relay software that you can run, and where to get tunnel broker software. There are a couple of gaps. I can find no info on how to set up 6to4 relay services on Juniper routers. Does JUNOS support this at all? If you know, go to the above page, click on Juniper, and tell us what needs to be done. In addition, CSELT in Italy distributed an IPv6 tunnel broker package at one time. I cannot find this anywhere. If you know where this software can be acquired or if you know of better IPv6 tunnel broker software, add it to the above page. I now know why people are so quick to give advice on what to do without explaining how to do it. It just is not easy to find out how to setup 6to4 relay services, Teredo relay services and IPv6 tunnel broker services. No doubt you can hire a consultant to do this for you, but if we want to get significant deployment we cannot rely on consultants who keep their toolkits secret. --Michael Dillon
Re: Apple Airport Extreme IPv6 problems?
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 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? Thanks, -drc
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 18-sep-2007, at 15:54, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: There are a couple of gaps. I can find no info on how to set up 6to4 relay services on Juniper routers. Does JUNOS support this at all? If you know, go to the above page, click on Juniper, and tell us what needs to be done. When I wrote my book, I mostly looked at Cisco for this, and apart from Cisco to FreeBSD and Linux. The logic is that on a Cisco, you can build a good tunnel box (6to4 or manual tunnels) on a C7200 or some other box that has a decent CPU that can do the tunneling in software. Quite possibly a Juniper can do the same with hardware support (although I don't know that and it's also very possible that they can't do it in hardware or with decent speed in software) but there are no cheap(er) Juniper boxes that are suitable for deployment as a 5 - 200 Mbps tunnel box, in my opinion.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Tue, 18 Sep 2007 23:29:38 +0200, Iljitsch van Beijnum said: they can't do it in hardware or with decent speed in software) but there are no cheap(er) Juniper boxes that are suitable for deployment as a 5 - 200 Mbps tunnel box, in my opinion. I presume your thinking is that by the time you get to 200Mbps of tunneled stuff, it's time to get native mode turned up? What's the prevailing common wisdom on that? pgpWZHCajE8Oz.pgp Description: PGP signature
Re: Apple Airport Extreme IPv6 problems?
On 17/09/2007, at 2:38 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think we will never move to IPv6 if vendors don't do things like the one in the Airport. However, in order to make this transition phase where there may be a possible degradation of the RTT, we need to cooperation of the operators, for example deploying 6to4 relays in their networks. And just what should operators do to cooperate? Are you aware of any documents that describe how to set up 6to4 relays in an ISP network? I believe there are books that document it. Personally, I've got a bunch of slides - if you think that they'll be of use I can clean them up. I intend to add some step-by-step textual stuff to http:// ipv6.cluepon.net/ but haven't had a chance yet, I've only really covered end user Teredo stuff - please add stuff if you can. -- Nathan Ward
Re: Apple Airport Extreme IPv6 problems?
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 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 record. :-)
Re: Apple Airport Extreme IPv6 problems?
On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] 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, but it does take too long if the packet is silently dropped somewhere. If there is an ICMP unreachable there is no real delay. Worst case is a path MTU discovery black hole, then browsers generally don't fall back. 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. I have also read Jordi? saying that no dual naming should occur, but I think this is unrealistic. (Sorry if I misquoted you, Jordi) It would be good if more ISPs deployed 6to4 gateways so the 6to4 experience would be better. We are. There are an unending supply of small details that are in the way at the moment. :-) Best, Marty
Re: Apple Airport Extreme IPv6 problems?
On 9/17/07, Iljitsch van Beijnum [EMAIL PROTECTED] 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 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/ and segregate the answers by protocol and sub domain the v4 traffic since it's a migration to v6. -M
Re: Apple Airport Extreme IPv6 problems?
At 4:47 PM -0400 9/17/07, Martin Hannigan wrote: On 9/17/07, Iljitsch van Beijnum [EMAIL PROTECTED] 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 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/ and segregate the answers by protocol and sub domain the v4 traffic since it's a migration to v6. -M
Re: Apple Airport Extreme IPv6 problems?
On Mon, 17 Sep 2007 17:15:38 EDT, John Curran said: In addition, if the 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. ;) pgpiRzVNBC2F6.pgp Description: PGP signature
Re: Apple Airport Extreme IPv6 problems?
At 1:06 PM -0400 9/17/07, 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. RFC 4472 has an excellent discussion of the topic, and while pointing out that your mileage may vary, it recommends the on the same name only when: 1. The address is assigned to the interface on the node. 2. The address is configured on the interface. 3. The interface is on a link that is connected to the IPv6 infrastructure. In addition, if the 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. /John
Re: Apple Airport Extreme IPv6 problems?
[EMAIL PROTECTED] wrote: On Mon, 17 Sep 2007 17:15:38 EDT, John Curran said: In addition, if the 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. ;) Indeed, which is why a good policy to have for 'servers' is to have: - a hostname, generally I bind these to the EUI-64 address - a servicename, eg 'www' or 'imap', which are bound to ::80 and ::993 Then when the box dies or you want to move the service to another box, you just move the alias, or actually just kill the quagga on the box and let another instance handle it ;) Still the maintainance of the box can be done by directly accessing it. Of course one should simply have that all integrated into the service deployment system and not care about the boxes themselves, you just want n of them to provide service X and m of them to handle service Z, or to use as many of them so that service Y is running topnotch with capacity to spare. All depends on your size of course ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Apple Airport Extreme IPv6 problems?
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/ 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 /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 /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
Re: Apple Airport Extreme IPv6 problems?
On 9/17/07, Barrett Lyon [EMAIL PROTECTED] wrote: 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. I wonder how setting Internet policy by putting defaults on become part of the regular operational internet? We're seeing a lot of this with v6 and I can't figure out how this is being driven. Best, Marty
Re: Apple Airport Extreme IPv6 problems?
On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] 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
Re: Apple Airport Extreme IPv6 problems?
On 9/15/07, Barrett Lyon [EMAIL PROTECTED] wrote: How did you do the naming? Matching or unique? Matched , 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 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
Re: Apple Airport Extreme IPv6 problems?
On 16 Sep 2007, at 07:39, Martin Hannigan wrote: On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] 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 vs A, I am worried that a browser running on a dual- stack laptop might cache the 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. 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. Andy
How do applications handle IPv6 and IPv4 dual-stacked (Was: Apple Airport Extreme IPv6 problems?)
[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 [EMAIL PROTECTED] 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 vs A, I am worried that a browser running on a dual-stack laptop might cache the 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 , 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 signature.asc Description: OpenPGP digital signature
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 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,
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 16-sep-2007, at 15:17, Nathan Ward wrote: 6to4 uses protocol 41 over IP. This doesn't go through NAT Those statements are both true, but they're unrelated. If your NAT box knows there is more to IP than TCP and UDP, it's possible that you can do IPv6-in-IP tunneling in general (protocol 41) through the NAT box, but that doesn't help 6to4 because your 6to4 address range is constructed from your IPv4 address which can't be done successfully using RFC 1918 addresses. stateful firewalls (generally). Depends on the firewall and how it's configured. This is a problem, because if you use public addresses but protocol 41 is blocked, IPv6 stuff needs to time out. 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. Right. 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 records alongside our A records from doing so. Well, I don't care: you break it, you buy it. But I can see how people who make money from their content would...
Re: Apple Airport Extreme IPv6 problems?
On 16-sep-2007, at 10:46, Andy Davidson wrote: Since this conversation has already talked about behaviour when encountering vs A, I am worried that a browser running on a dual-stack laptop might cache the 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. Hm, yes, that would suck. I've never seen problems with this with MacOS, though. I haven't used anything else both long and mobile enough to make a difinitive statement, but I think you'll be allright: when an application tries to do IPv6 when there is no IPv6 connectivity, MacOS/BSD/Windows detect this and return an error rather than let the attempt time out. Not 100% sure about Linux and I think Solaris had some trouble in this area in the past. 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.
Re: Apple Airport Extreme IPv6 problems?
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
Re: Apple Airport Extreme IPv6 problems?
On 16 Sep 2007, at 15:13, 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. I mean the dns cache sorry. Firefox definitely has one, it keeps annoying me.
Re: Apple Airport Extreme IPv6 problems?
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!
RE: Apple Airport Extreme IPv6 problems?
I think we will never move to IPv6 if vendors don't do things like the one in the Airport. However, in order to make this transition phase where there may be a possible degradation of the RTT, we need to cooperation of the operators, for example deploying 6to4 relays in their networks. And just what should operators do to cooperate? Are you aware of any documents that describe how to set up 6to4 relays in an ISP network? --Michael Dillon
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 16-sep-2007, at 16:46, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 How? Listing 11-7. A Cisco 6to4-to-IPv6 Gateway Configuration ! interface Loopback2002 ip address 192.88.99.1 255.255.255.255 ! interface Tunnel2002 ipv6 enable ipv6 mtu 1280 tunnel source 192.88.99.1 tunnel mode ipv6ip 6to4 ! Listing 11-8. A Private 6to4 Gateway in the IPv6-to-6to4 Direction ! interface Tunnel2002 ipv6 address 2002:DFE0:E1E2::/16 ipv6 mtu 1280 tunnel source 223.224.225.226 tunnel mode ipv6ip 6to4 ! Assuming you have already configured your normal IPv6 connectivity (you havent!? http://www.bgpexpert.com/presentations/ ipv6_tutorial.pdf ). Don't forget to sprinkle some redistribute connected over your favorite routing protocols and you're in the 6to4 gatewaying business. If you want to run a public gateway, announce 192.88.99.0/24 and 2002::/16 over BGP. Iljitsch -- I've written another book! http://www.runningipv6.net/
Apple Airport Extreme IPv6 problems?
Apple is nice enough to provide an automatic v6 tunnel from their new Airport Extreme units. They even get all the machines on the network to participate -- by default! At first this did not seem to be much of an issue, it was even pretty cool. However, I noticed as I roll out more v6 services to support native v6 users, I am impacting the network performance of almost all of the Apple airport population that has an inefficient tunnel configuration. The user obviously will take the v6 published IP over the v4 A record. Don't get me wrong v6 tunnels are great, when you opt-in and know what you are getting into. For example, my grandparents tunnel in California goes to Virginia. This impacts the user experience rather significantly with the first hop being nearly 100ms where their services to California are ~20ms. It's painful for a lot of users, especially when they don't even know what's going on. Has anyone else ran into this? It's not pretty for a CDN or anyone trying to provide a quality service over v6, shunting users over inefficiently tunneled routes does not sit well with me. I think Apple has made a mistake by enabling this by default. -Barrett
Re: Apple Airport Extreme IPv6 problems?
I think we will never move to IPv6 if vendors don't do things like the one in the Airport. However, in order to make this transition phase where there may be a possible degradation of the RTT, we need to cooperation of the operators, for example deploying 6to4 relays in their networks. As many 6to4 relays exists (even if they are closed only to the customers of that network), less this will be problem. I understand that sometimes is not easy to provide native IPv6 services, but deploying a 6to4 relay (same as a Teredo Relay) is a very simple and inexpensive step, but it helps a lot. In regions such as Africa and LAC, where upstream b/w is expensive, I'm helping the ISPs to setup those, in order to avoid traffic going thru the upstream links and staying local. Remember that even if we don't have products such the Airport, our customers have OS which come with IPv6 enabled by default and they try 6to4 or Teredo when they don't have native connectivity, so is not a problem that we can hide from. We really need to move one step forward and avoid support calls, for example. Regards, Jordi De: Barrett Lyon [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sat, 15 Sep 2007 09:05:43 -0700 Para: nanog@merit.edu Asunto: Apple Airport Extreme IPv6 problems? Apple is nice enough to provide an automatic v6 tunnel from their new Airport Extreme units. They even get all the machines on the network to participate -- by default! At first this did not seem to be much of an issue, it was even pretty cool. However, I noticed as I roll out more v6 services to support native v6 users, I am impacting the network performance of almost all of the Apple airport population that has an inefficient tunnel configuration. The user obviously will take the v6 published IP over the v4 A record. Don't get me wrong v6 tunnels are great, when you opt-in and know what you are getting into. For example, my grandparents tunnel in California goes to Virginia. This impacts the user experience rather significantly with the first hop being nearly 100ms where their services to California are ~20ms. It's painful for a lot of users, especially when they don't even know what's going on. Has anyone else ran into this? It's not pretty for a CDN or anyone trying to provide a quality service over v6, shunting users over inefficiently tunneled routes does not sit well with me. I think Apple has made a mistake by enabling this by default. -Barrett
Re: Apple Airport Extreme IPv6 problems?
On Sep 15, 2007, at 11:01 AM, Rich Groves wrote: Are there any reliable stats on the number of 6in4 tunnel connects after the Extreme was released ? I'm just wondering if this is something that we as a community can easily track. Some DNS analysis at the provider I worked for in the past showed the bulk of requests (to my surprise) were for Nintendo Wii specific content (the weather app and news app) . When the Nintendo folk decide to do something more interesting and latency sensitive this could be a real problem I suppose. We removed on our production hosts shortly after we deployed it, our global v6 deployment goes production next week, at which time I may re-add the to limited production. If we do this, I publish a report of the stats once I have more accurate figures.
Re: Apple Airport Extreme IPv6 problems?
On 9/15/07, Barrett Lyon [EMAIL PROTECTED] wrote: [ snip ] We removed on our production hosts shortly after we deployed it, our global v6 deployment goes production next week, at which time I may re-add the to limited production. If we do this, I publish a report of the stats once I have more accurate figures. How did you do the naming? Matching or unique? I have no idea what to expect over time with behavior on matching and A since I have no idea what to expect with v6 since we don't really have any standard deployment plans or even de-facto standards in place to move forward. Is there any de-facto or otherwise standard around host schemes for dual stack? -M
Re: Apple Airport Extreme IPv6 problems?
How did you do the naming? Matching or unique? Matched , I was thinking about doing a w6 or something more unique for now, but that somewhat defeats the point. 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. -Barrett
Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
[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 + ) 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 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 '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 signature.asc Description: OpenPGP digital signature
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 15-sep-2007, at 22:03, Jeroen Massar wrote: [spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)] Spam: read a good book about IPv6. :-) 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 + ) 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 No, that's not true: If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: PrefixPrecedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 :::0:0/96 10 4 So first IPv6 loopback, then IPv6 any, then some ancient automatic tunneling that nobody uses and finally IPv4. :::0:0/96 is for IPv4-mapped IPv6 addresses (or was it the other way around??) so that prefix contains all IPv4 addresses in a way that they can be used with IPv6 APIs. However, Windows XP wil _in_ _practice_ do what Jeroen says because of the label matching. The idea is that source and dest must have the same label value and then the highest precedence wins, this avoids using an IPv6 source address with an IPv4 destination address and the like. If you have native IPv6 on the remote end and 6to4 (2002::/16) on your end, then the labels don't match but for IPv4 on both ends they do so XP will choose that over the native/6to4 combo. Not sure what Vista or FreeBSD do, not aware of any other OSes that implement RFC 3484. 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. Easily solved by running your own private (or public) 6to4 relay: then the packet goes directly to the other end without detours over IPv4. You can't control how the packets get from the remote 6to4 user to you, though.
Re: Apple Airport Extreme IPv6 problems?
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, but it does take too long if the packet is silently dropped somewhere. If there is an ICMP unreachable there is no real delay. Worst case is a path MTU discovery black hole, then browsers generally don't fall back. For some reason, I can't reach the IETF or ARIN over IPv6 from home, which means every time I want to read an RFC I have to wait for my browser to time out and retry. Apple's Mail is worse: it has a bug that prevents it from delivering mail with SMTP over IPv6, but it won't fall back to IPv4 so you need to intervene manually. It would be good if more ISPs deployed 6to4 gateways so the 6to4 experience would be better. Windows Vista will also try to use 6to4 out of the box (but only if it has a public IPv4 address, can't do 6to4 from behind NAT).
