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