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. 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. 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. 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. 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). > The reason for that is that while the tunneling to 6to4 relay would > work as long as the mapping is kept in the NAT (because that's > bidirectional), it wouldn't work for traffic between 6to4 nodes > (especially when the other 6to4 sends the initial packet to you) > because that would require NAT mappings being established beforehand. > I.e., 6to4 has limited support behind a NAT and always requires > configuring. Not true. I've already demonstrated this. No special configuration on the NAT device. No protocol 41 pass through. The 6to4 prefix is build using the external IP address of the NAT device plus the EUI of the local system, but the tunnel is build with the local interface address. It then works. The NAT device is NOT passing protocol 41 through. It's actually performing a NAT and deNATing the return packets. It does work. I just don't know how wide spread that support is. > For more generic use, I'd suggest looking at Teredo > (draft-huitema-v6ops-teredo-02.txt), which is pretty close to being > standardized. There are also a couple of implementations, at least > one of which works for Linux. That might be something to include in > Fedora soon. Teredo is an abomination. I sat in some of the working groups at the IETF and even they detest Teredo. But... Teredo is proof positive that the IETF truely has a sense of humor. The previous draft for Teredo is "Shipworm". Ok... Pop quiz. How many spot the connection? Teredo is a species of shipworm. That's not a worm, it's a molusk. It bores holes in the hulls of wooden boats and pier's and docks and rots them from the inside out (anyone getting a hint here?). That's what Teredo does to security systems and firewalls. Even the characters at the IETF recognized exactly what they were creating with Teredo. My "evil twin" at Microsoft was involved in one particular point with Teredo on XP. He refers to Teredo as "The Evil Firewall Destroying Deamon from Hell". If you enable IPv6 on XP, Teredo is enabled. IPv6 over UDP is a security hole just waiting for someone to plague. Recognizing the risk there, they disable Teredo when an XP box is joined to a domain, since no-one should be running Teredo from a corporate network. While IPv6 over UDP is interesting, the infrastructure and prefixes (Teredo currently uses a prefix assigned to Microsoft - where do you want to go today) and really a nightmare. I've looked at the "Meledo" project and it's got promise, but scary at the same time. The draft I'm referring to is draft-palet-v6ops-proto41-nat-03.txt. Turns out 04 is expired but 03 is still up. Looking at the expiration dates, 04 JUST expired earlier this month. > There are also other "tunnel broker" like solutions which go through a > NAT like a charm, and one will likely be standardized pretty soon.. Well... Seems to be that the scheme in Palet's drafts seems pretty workable without all this other cruft (the passthrough). The only gotcha is figuring out the external address of the NAT device. I'm interesting in finding out just how many NAT devices actually support this scheme. They claimed over 80% to 85% back then. Even if you DON'T take into account the local EUI, you can still support NAT with multiple 6to4 gateways, just based on IPv4 ordered pairs when no two local nodes access the same external site. But a single gateway advertising a route seems to work like a champ and makes the most sense and doesn't run into any of those problems. But you have to specify the external address in the 6to4 prefix and the true local address in the tunnel command for the tunnel endpoint. Then it seems to work. In fact, I have it working... I just need to test it in more environments. Looks like it's going to work like a charm over Linksys products. I'm looking to test over some other vendors now. > -- > 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:
pgpPkfuOKa8XT.pgp
Description: PGP signature
