On Mon, Aug 30, 2004 at 08:59:57AM +0300, Pekka Savola wrote: > On Sun, 29 Aug 2004, Michael H. Warfield wrote: > > On Sat, Aug 28, 2004 at 09:21:09AM +0300, Pekka Savola wrote: > > > IPV6TO4_IPV4ADDR has two purposes: it can be used when there are > > > multiple IPv4 addresses and you want to pick which one to use to build > > > the prefix. It was also imagined to be used to pass through the NAT > > > when the NAT has been configured to pass the protocol-41 packets to > > > specific internal host. > > > > > Note that this only supports one 6to4 router behind a NAT. Multiple > > > ones won't work. And you need to configure the NAT to forward all > > > proto-41 packets to that node. > > > > Actually, this is incorrect on both counts. > No, this is wrong, please think again. Well, it seems to work. At least for clients behind the NAT device. Or if you are building a "road warrior" type tunnel. Remember, too, you don't always have control over that NAT device, even assuming that it even supports protocol 41 passthrough. I'm thinking of the roadwarrior case where I sit down at a hotel (or conference center, or friend's house, or on vacation - happens a lot, couple times a month at least) and fire up my laptop and I have to cross a NAT box (or more if it's wireless and we're double NAT'ed through it and a cable modem or such) just to get to my network. Up until now, I've been firing up an entire IPSec NAT-T VPN just to tunnel IPv6 back to my tunnel anchor at a colo facility. Now I find that, far far more often than not, I can just fire up 6to4 with the proper addresses, and it just works. I can't go to that hotel and tell them "can you please enable protocol 41 passthrough in your NAT device for me?" They'll look at me like I grew three heads (after they regain focus from trying to figure out what I just said). I've still got to test it out in a lot more locations on the road yet, but it looks pretty good for everything I've tested so far. Roadwarrior mode, for me at least, seems to be the big use for this particular mode of operation. Cases where it fails, I can still fall back to the more complicated tunnels using IPSec NAT-T or ppp over ssh or something. I will admit that it doesn't support the case of trying to advertise a server behind a NAT device on 6to4. But, in my case, that's not all that interesting. In my mind, if you are already going to the effort of setting up a server you want to advertise, then the effort to set up a better gateway is not, incrementally, that much greater. Qualitatively, you've already stepped up above the simple case and it's a much more limited. Then too, supporting protocol 41 NAT doesn't preclude supporting 6to4 over 41 passthrough, either. Both methods can co-exist. And if someone has a device that doesn't support protocol 41 passthrough (or they have to work across a device they don't control and can't access) and they don't care about advertising a server, they can still get access through the protocol 41 NAT. If they want to advertised a server, they're probably going to have to upgrade the gateway NAT device either way. > > Again, according > > to draft-palet-v6ops-proto41-nat-03.txt they found that 80% - 85% of NAT > > devices on the market at that time support a true NAT of protocol 41. > Yes, but 6to4 support requires more than just proto41 forwarding. Full 6to4 support, servers and everything, sure. I'll grant you that. But to just support clients, it's fine. It's a case which does work but is not supported by the current scripts. But it can be. It's not that big of a deal and it could be very useful. One thing I'm not certain about (and I'm surprised the issue wasn't raised) is whether the anycast helper gateways will work over the NAT translation. Outbound should be fine but do they use the anycast address as the source IPv4 address for the return packets or do they use their unicast address? That's another potential breakage that I'm just getting around to exploring. I don't generally run into that very much with what I do, anyways. > > That means it does not require protocol 41 pass through. It > > translates the address on the way out and detranslates it on the way > > back based on the remote IPv4 address. It actually works. I've now > > done it. > Sure, this works just fine for configured tunneling, but if you read > my message carefully, I mentioned a scenario where this does not work, > and *cannot* work if you think it through. > All of this can work if the NAT support proto-41 state for packets > which originate behind a NAT, and replies come back during the > lifetime of that state. But that's not all to it. Doesn't need to be all of it. It's a specific case that can work and does work and works with far more of the NAT devices than trying to set up protocol 41 passthrough. Has anyone actually tried to survey how many NAT devices allow you to configure a passthrough on anything other that TCP or UDP? The devices I have on hand, or have access to through friends and family and our testing labs at work, just give to options to enter a port number and TCP or UDP for the passthrough and no way, which I've uncovered, to configure other protocols. A couple of years ago, we called the support departments for several vendors (IIRC, we called D-Link and, maybe, Linksys, and others) and asked them about a passthrough on protocol 41 and they had technical people get back to us saying it wasn't available and there were no plans to support anything other than TCP or UDP for passthrough. But the protocol 41 NAT seems to be supported (even if by accident). I guess, if you were trying to support a server using this scheme, you would have to get a better gateway in any case, but then you could get something decent that could support IPv6 anyways. > But it does *NOT* work when you publicize e.g., the 6to4 address of > your webserver, and someone, using 6to4 addresses, tries to contact > the server. The encapsulated packet comes to the NAT, but the NAT has > no state for that particular IPv4 address (because the internal hosts > have not communicated with it). Further, if there are multiple 6to4 > routers inside the NAT, the NAT cannot even know which one this is > destined. I don't find the server case nearly as interesting, simply because if you are setting up servers and want to advertise servers, then you can put a little more effort into your gateway (like installing a Linux server as the gateway) and handling 6to4 on the gateway itself. Seems to me that the very effort of even finding a NAT device that's going to support protocol-41 passthrough is going to make alternatives, such as a Linux gateway, more attractive. For the server case, I'm not even sure I would want to support a server on 6to4 behind a NAT, given that it's easy enough, now, to get a configured tunnel from a tunnel broker for free. A server behind a NAT device on 6to4 just seems a little counter productive, even if you have a gateway that's capable of supporting it. > Hence, proto-41 does not work correctly and completely with 6to4 > without manual configuration of proto-41 at the NAT box. Do you have a list of devices that actually allow you to do this? I haven't found any. I'm sure there are some, but the vendors don't seem to interesting in it from my conversations with them. Still doesn't help with the case where you don't control or can't access that NAT device. There are lots of them out there. Protocol 41 NAT doesn't work completely, but it does work for a large set of valid cases and it doesn't interfere with the passthrough case. I'm not sure what you mean by "does not work correctly", though. For the cases were it works, it seems to work correctly. For the cases where it doesn't work, it simply doesn't work and is not "complete". So I agree with the "doesn't work completely" part. > (Configured tunneling can work correctly and completely without manual > configuration, even for multiple routers.) This is true. And the client case works as well (at least it sure seems to). It also supports multiprotocol applications (probably better than true NAT on IPv4) since the IPv6 is still uniformly addressed, even with reverse callbacks (such as port mode ftp). The "advertise a server case" doesn't work, but I would argue that you should have a better gateway for that case anyways. > > That also means it does not require a special configuration > > on that NAT device for the 6to4 gateway. As long as it does a blind > > IPv4 -> IPv4 NAT and reverses the NAT on the way back, it works. > For sessions initiated in one direction, yes. For the other, no. But that's a valid case and it's a valuable case and it's a case that's not currently supported. The server case can be managed through other mechanisms without discarding this case. > > It also means that multiple systems behind the gateway CAN > > use 6to4 (but, due to another design mistake, the 6to4 address is > > not unique because the EUI address is ::1 for the same prefix). If > > each node behind the NAT gateway had a unique EUI address, they would > > not collide on the local net and, as long as they were NOT going to the > > same site on the global net, they could share the same NAT gateway. With > > the addition of table caching in the NAT gateway that included the EUI > > address (which none that I know of do now) even the limitation that two > > nodes could not access the same external site could be handled by keying > > off of internal EUI (similar to indexing on port number). > This was considered a non-goal. If the NAT box would have to support > looking at the IPv6 packets, it could as soon be upgraded to act as > 6to4 router on its own. True... Once you have the NAT box examining protcol 41 and the IPv6 traffic, then you might as well get support on there for IPv6 as well. I agree with you there. The Linux based LinkSys devices are almost there (just a little more memory, if you please). Well... The NAT device has to support protocol 41 passthrough as well and that seems to be much less common than simple protocol 41 NAT. Yes, I know I probably don't possess a statistically valid sampling of devices to make that statement. Can anyone point me at a chart or survey comparing the two features? That IETF draft alluded to a survey of device manufacturers but didn't indicate where the survey results could be found. They said 80% to 85% of NAT devices on the market support this (protocol 41 NAT). What percentage support configuring a passthrough on protocol 41. None of the devices I've been able to lay my hands on from several manufactures seem to support anything other than TCP and UDP. You even need to use IPSec NAT-T (IPSec over UDP) with most of them because they aren't going to pass 50/51 through either. I'm happy that this works for the client case, once the scripts are patched, and it can be made to work over devices which do not even support protocol 41 passthrough. Servers and connections initiated from the outside in won't work, I'll grant you that. But the client direction can work and does work, even with devices which can not even be configured for protocol 41 passthrough. > [snip to the end] > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Mike -- Michael H. Warfield | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
pgp4Jv9gn2y8z.pgp
Description: PGP signature
