Print

[kasperd]

While looking on some logfiles I found that my gateway had encountered an ICMPv6 error, it was unable to route. The destination IP of the ICMPv6 error (and the source IP of the IPv6 packet inside the error) was 2002:a19:eb00:1234:41bd:73b4:74a4:492d. Anybody know what sorts of systems produce such invalid 6to4 addresses?

Perhaps I should add code to detect invalid 6to4 addresses as they enter my network. Currently my gateway does treat it as a valid IPv6 address. The destination address of the original packet was a bittorrent client, which had been shut down 24 hours earlier, so that triggered a port unreachable error. On leaving my network the destination address triggered an error. But of course at that point any information about the origin of the packet was long gone.

Checking another logfile I found that I have received packets from a lot of that kind of addresses. The 1234 in most of the addresses might indicate that they are all produced by the same software.
2002:c0a8:f02:1234:10a7:c921:9e3f:de95
2002:a01:a3c:1234:986e:be78:5b5f:3309
2002:a01:a3c:1234:71b2:adc:338d:f7fe
2002:c0a8:103:e472:211f:9cf3:bc50:852e
2002:a01:a3c:1234:c5a3:2297:a192:96cb
2002:a01:a3c:1234:c5a3:2297:a192:96cb
2002:a01:a3c:1234:9910:703a:8a0c:7207
2002:a01:a3c:1234:9910:703a:8a0c:7207
2002:a19:d4c7:1234:2481:e7a6:169b:a009
2002:a19:fd1f:1234:b4b0:3829:21c5:84cd
2002:c0a8:141:0:c44d:5e48:82f1:b715
2002:ac1b:232f:1234:216d:762b:cad:41be
2002:a19:fd1f:1234:8820:8b79:76f5:6d10
2002:c0a8:175:e472:5cdb:55e2:2070:b853
2002:a19:fd1f:1234:d63:4cc6:7b31:3b74
2002:a01:a3c:1234:9910:703a:8a0c:7207
2002:a19:fd1f:1234:f05a:d112:36ca:7b99
2002:a19:dcec:1234:ac33:8b7d:3570:170b
2002:c0a8:116:1234:54fc:9ad5:1fd6:3d27
2002:a19:dcec:1234:50e1:55b5:ba65:8db8
2002:c0a8:102:1234:9880:dd2a:d9c7:a047
2002:c0a8:f02:1234:12a:7fcc:aeb6:c069
2002:a19:dfb0:1234:58d0:c919:9cdd:ba42
2002:c0a8:f02:1234:12a:7fcc:aeb6:c069
2002:c0a8:f02:1234:12a:7fcc:aeb6:c069
2002:a19:f526:1234:d129:161e:5d8c:3a79
2002:c0a8:b08:1234:c124:89db:7154:cfab
2002:c0a8:b08:1234:d4fc:166c:62d9:bad
2002:a19:cd8f:1234:b15d:62bc:f61b:edb5
2002:a19:cd8f:1234:286a:91ed:704:2732
2002:c0a8:b08:1234:bc81:d89e:57b8:4f8b
2002:a19:cd8f:1234:6010:732b:8580:a4b0
2002:c0a8:a:e472:dca:c1e:35de:fbfb
2002:a00:21:e472:d491:1977:7094:ecf2
2002:a19:ddd5:1234:ecb4:ed63:55f4:117f
2002:a19:ddd5:1234:a110:9c2:4841:612c
2002:a01:102:e472:3874:1ab:65b7:de6c
2002:a19:f1d8:1234:dd4e:7be4:b84e:daa9
2002:a19:f1d8:1234:e078:7120:8b3a:b01b
2002:a19:eb00:1234:e45c:e5d5:e54f:3bef
2002:a19:eb00:1234:41bd:73b4:74a4:492d

[cconn]

many would argue that 6to4 in itself is broken 

RFC 1918 addresses should not be routed, no idea what broken OS/software would use a RFC1918 6to4 derived address, but you might as well just filter them at your network boundary.  2001:db8::/32 as well 

[kasperd]

many would argue that 6to4 in itself is broken  

They do have a point, but some people take that position to such extremes that they produce an end result, which is even more broken. 6to4 is more reliable than Teredo, and if both endpoints are using 6to4 then it is faster and more reliable than a configured tunnel through a tunnel broker such as HE.

Why do some systems actually prefer to use Teredo rather than 6to4, and why do some systems prefer to use Teredo for both endpoints as soon as one of the endpoints is using Teredo?

Given a choice between communication where both endpoints are using 6to4 or communication where both endpoints are using Teredo, you should always go with 6to4. Because we are comparing what may be the most reliable kind of IPv6 tunnel (6to4 at both endpoints) to the least reliable kind of IPv6 tunnel (Teredo in a situation that requires NAT hole punching). And still there are people who consider 6to4 to be so broken, that they'd rather use Teredo.

6to4 is great as long as you are careful only to use it when you can avoid third party relays. In my stack I don't even offer a way to turn 6to4 off, and I use it in innovative ways, that gives better reliability than I could ever achieve without 6to4.

RFC 1918 addresses should not be routed, no idea what broken OS/software would use a RFC1918 6to4 derived address, but you might as well just filter them at your network boundary.

True. Then I would at least know which IPv4 address tunnelled it to me. Though I am guessing I would just find the HE tunnel server. I am guessing what happened was

• Some host generated a 6to4 address from an RFC 1918 address
• Packet was sent towards 192.88.99.1
• A NAT replaces the source address, and doesn't know about the type of payload, so cannot possibly realize it is broken.
• Packet arrives at a 6to4 relay, which doesn't check validity of the source address
• Packet traverses IPv6 network and arrives through my tunnel without passing any router looking at more than the first 16 bits of the IPv6 source address.

I could certainly implement code to remember which IPv4 address I received the 6to4 packet from and send replies that way. But I don't think it is worth the effort, because they would just make it to the tunnel server before encountering a no route to host error.

Due to the way my system works, the particular packet actually made it through my gateway three times and only on the fourth pass through the gateway was found to be invalid. It was about to send a no route to host error in reply to an ICMPv6 error and decided to log it instead.

2001:db8::/32 as well  

Throughout all my unit tests I use documentation addresses. So I cannot have code to drop documentation addresses, as it would break all my unit tests. And according to my interpretation of how documentation addresses are to be used, software shouldn't treat them as special. You just shouldn't use them in any live configuration files, and if you do they'll only be routed as far as there is a default route.

[colonelf74]

I'm no expert in all of this, but I can attest to the fact that when I was using Comcast's internal "automatic" tunnel
all of the machines on my home network were being assigned and using 2002: addresses.

I could dig up my old /etc/hosts file if that'd help.

I'm still scratching my head and wondering if that prefix is precisely why sites like Facebook just weren't working at all much.

[kasperd]

I'm no expert in all of this, but I can attest to the fact that when I was using Comcast's internal "automatic" tunnel
all of the machines on my home network were being assigned and using 2002: addresses.

I have heard bad things about Comcast, but I can't believe they are that incompetent.

It is possible for an ISP to take one public IPv4 address and use that to deploy CGN and use the same IPv4 address for 6to4 such that they can deploy dual stack behind a single public IPv4 address. There is nothing wrong with doing that, and if it was done, the 6to4 part would scale to a larger number of customers than the CGN part would.

But it is only acceptable for an ISP to provide such a setup if they provide native IPv6 at the same time. And at that point the 6to4 gateway they deployed on that public IPv4 address would actually only handle packets in one direction. Packets from the 6to4 addresses to native IPv6 addresses would be transmitted as native IPv6 all the way without going through 6to4 gateway or 6to4 relay.

If that is what Comcast did, then it might be that some routers have a problem with having two different prefixes. If your router only picked up the 6to4 prefix and not the native prefix, then that could explain what you saw. This is just guessing, I don't even think this is the most likely explanation of what Comcast did.

It could also be that all Comcast has done was to provision 6to4 relays within their network without deploying any 6to4 gateway. In that case any customer with a public IPv4 address (which I suppose is still all of them) could run their own 6to4 gateway.

Functionally that would look very similar, except it wouldn't necessarily involve any native IPv6 addresses for the customers. If you setup your own 6to4 gateway, and Comcast have 6to4 relays for you, then packets from you will go through both 6to4 gateway and relay, but will still leave the Comcast network as native IPv6. You wouldn't rely on third party relays for packets in that direction, but you'd still rely on a third party relay for the return traffic.

If the later describes what Comcast had done, and you decided to use 6to4 as your only connectivity to the IPv6 backbone, then you made a mistake. You shouldn't have decided between using 6to4 or HE, you should have used both. It is possible your router isn't capable of doing both simultaneously. If your router cannot do both, then that sucks, and you should go with just HE, as that is overall a better choice than 6to4.

If you have two public IPv4 addresses from Comcast, then you can setup two different routers with 6to4 on one and an HE tunnel on the other. However be warned, that computers on the LAN might not understand which packets to send to which router, so it could end up being worse than just a single router.

A single router with both 6to4 and a configured tunnel on the same router is the most reliable IPv6 connectivity you can get, if you cannot get native IPv6 from your ISP.

I could dig up my old /etc/hosts file if that'd help.

It would be interesting to see. What I am most interested in from that is the IPv4 address, which is embedded in the 6to4 addresses.

I'm still scratching my head and wondering if that prefix is precisely why sites like Facebook just weren't working at all much.

If you are using a 6to4 address to contact facebook, then you are relying on whatever relay they are using for the return traffic. In both of the two possible setups Comcast would be in a position where they could guarantee a reliable connection in one direction. But they can do nothing about the return traffic.

It may be that facebook consider reliability to be a high priority and thus have deployed their own 6to4 relays for the return path, in which case both directions could be going through reliable relays. But it is also possible that facebook have no 6to4 relays, and thus are relying on third party relays. Then that would definitely explain why you experienced problems.

The only two networks I know of to have deployed 6to4 relays on a large scale is HE and Akamai. There may be others, which I don't know about. It is not always possible to find out whose 6to4 relay is being used.

[colonelf74]

Here's what I'm guessing are the relevant parts of my old /etc/hosts file(sorry about the tabs):

10.0.0.1        kendace-wifi    kendace-wifi.parents.com    # Airport Extreme
10.0.0.2        wilson          wilson.home.com             # Airport Extreme
71.239.54.1     gateway         gateway.comcast.net
#
10.0.0.100      dhcp01          dhcp01.parents.com  # MacBook (most likely)
#
10.0.0.201      kendace-mac     kendace-mac.parents.com     # iMac
10.0.0.202      forbin          forbin.home.com             # iMac
#
2002:47ef:368b::21f:f3ff:fe40:8aa       kendace-wifi    kendace-wifi.parents.com
2002:47ef:368b::217:f2ff:fecf:69a       kendace-mac     kendace-mac.parents.com
2002:47ef:368b::21f:f3ff:fecf:9ee0      kendace-macbook kendace-macbook.parents.com
2002:c058:6301::                        gateway         gateway.comcast.net

Just a random question, if you have the time...in the realm of IPv6 are 2002: addresses
therefore sort of like 192.168 in IPv4?  I have a really technical book on TCP/IP but it
never really states an opinion on that...just tons of references to RFC's.

[broquea]

2002::/16 is address space specifically allocated for the 6to4 service. Your /48 allocation out of 2002::/16 is based on your IPv4 address (globally routed). If you want an RFC1918 analog, then look at using ULA.

[colonelf74]

Well, thanks for the food for thought.  I'll have to re-read that again to take it all in.

The only reason I asked is so far I've seen some bizarre behavior "out there" that made me wonder
exactly what was going on.  Hopefully native IPv6, once I get it up and running, will fare better.

[kasperd]

71.239.54.1     gateway         gateway.comcast.net
#
2002:47ef:368b::21f:f3ff:fe40:8aa       kendace-wifi    kendace-wifi.parents.com
2002:47ef:368b::217:f2ff:fecf:69a       kendace-mac     kendace-mac.parents.com
2002:47ef:368b::21f:f3ff:fecf:9ee0      kendace-macbook kendace-macbook.parents.com

The IPv4 address embedded in those 6to4 addresses is 71.239.54.139. Comparing that with the gateway address above makes me think that 71.239.54.139 was the IPv4 address assigned to your router, and your router was the 6to4 gateway for your LAN.

2002:c058:6301::                        gateway         gateway.comcast.net

The IPv4 address embedded in that 6to4 address is 192.88.99.1, which is the 6to4 relay anycast address.

There is nothing Comcast specific about your setup. It is just plain 6to4 that anybody with a public IPv4 address could set up. The only thing Comcast could do is deploy 6to4 relays to make it more reliable. And any packet will take the relay closest to the sender, which means communication with parties outside of the Comcast network will only use the Comcast relay in one direction and some other relay in the other direction.

You can try to run a traceroute to 192.88.99.1 to see if the relay you were using was actually inside the Comcast network.

Just a random question, if you have the time...in the realm of IPv6 are 2002: addresses
therefore sort of like 192.168 in IPv4?

No. Those have nothing in common.

The relevant RFCs are 1918 for IPv4 and 4193 for IPv6. In IPv4 as you probably know, there is 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 allocated for private addresses. With IPv6 it works a little bit different to avoid the conflicts you sometimes have run into with RFC1918 addresses.

With IPv6 you generate your own prefix in the following way. The first byte is FD, then you take five randomly generated bytes (On a Linux system you could use "head -c5 /dev/urandom |hexdump -Cv"). Concatenate this to produce your 48 bit prefix, which could end up looking like this: fdd3:35be:ec18::/48.

[Tuska]

colonelf74,

kasperd is correct, this is not using the comcast 6to4 relay.  If you did it would have a 2001:558:: address to it.  and Yes Comcast does have a 6to4 relay running for its customers.

[kasperd]

this is not using the comcast 6to4 relay.  If you did it would have a 2001:558:: address to it.

If you were using a 2001:558::/31 address, then it wouldn't be 6to4. 6to4 by definition uses 2002::/16. However you can use similar tunnel methods with native IPv6 addresses.

For example they might be using 6rd, which uses a DHCP option to tell the router which IPv6 prefix is used instead of 2002::/16. With 6rd only the provider itself is announcing that IPv6 prefix over BGP, so no third party relays are involved.

[colonelf74]

I'd ask exactly how to setup Comcast's 6to4 tunnel, but I hope in the next month or so to pickup a new router
in which case(hopefully) any kind of tunnel is a temporary measure at best.  I've gotta update the thread
on their support site later today, we'll see what happens next.  :-)

[kasperd]

I'd ask exactly how to setup Comcast's 6to4 tunnel

Setting up 6to4 is the same regardless of provider. The only difference is how far the packets you send have to travel before they reach a relay. It seems you didn't try to run a traceroute to 192.88.99.1 to find out how far that was in your case.

Some providers do have relays on other addresses than 192.88.99.1, and in some cases the closest relay is using a different address. If your provider has given you a different relay address to use instead of 192.88.99.1, you should ask them, why they didn't just use the anycast address.

I hope in the next month or so to pickup a new router
in which case(hopefully) any kind of tunnel is a temporary measure at best.

At the current time you get the most reliable connectivity by having both native IPv6 addresses and 6to4 addresses assigned on your network. Each host can choose between native IPv6 and 6to4 depending on the peer they are communicating with.

Additionally running your own Teredo relay provides better reliability when communicating with peers, who are using Teredo. But don't use any Teredo addresses on your own network. Teredo clients are really only suitable for devices that you move between different networks where you can't always get any other connectivity. For example a Teredo client on a laptop can provide a reliable connection to your home network from most networks the laptop connects to, as long as you have a Teredo relay on your home network.

Packets from your network to a Teredo destination should use the Teredo relay regardless of source IP. Packets from your network to 6to4 addresses should use your 6to4 tunnel regardless of source IP. Packets from your network to native IPv6 addresses should use your native connectivity or your 6to4 tunnel depending on the source IP address. Some routers may mess up the last part where treatment of the packet depends on not only destination address, but also source address.

[colonelf74]

Actually, I did run the traceroute, just out of curiousity but didn't post it.

Here it is:

<adace@phoebe:~> traceroute 192.88.99.1
traceroute to 192.88.99.1 (192.88.99.1), 64 hops max, 52 byte packets
 1  kendace-wifi (10.0.0.1)  0.429 ms  0.283 ms  0.245 ms
 2  c-71-239-54-1.hsd1.il.comcast.net (71.239.54.1)  32.639 ms  24.127 ms  30.016 ms
 3  te-1-2-ur04.algonquin.il.chicago.comcast.net (68.87.208.125)  9.688 ms  11.155 ms  9.199 ms
 4  te-0-3-0-0-ar01.area4.il.chicago.comcast.net (68.87.230.41)  17.483 ms  15.124 ms  15.597 ms
 5  te-9-1-ur09.area4.il.chicago.comcast.net (68.87.230.222)  12.768 ms  16.009 ms  14.333 ms
 6  te-8-3-ur08.area4.il.chicago.comcast.net (68.87.210.13)  15.107 ms  12.946 ms  11.995 ms
 7  te-9-2-ur05.area4.il.chicago.comcast.net (68.87.229.106)  14.669 ms  15.647 ms  13.893 ms
 8  * * *

This seems consistent to what I was experiencing when setting the Apple Airport Extreme to "Automatic Tunnel".

Thanks for the advice, though, on having multiple IPv6 routes.  That's a bizarre one.  From what I've seen online
a Cisco Linksys EA4500 should do the trick, even if I have to downgrade the firmware.

[kasperd]

There are multiple possible reasons for a traceroute to 192.88.99.1 not to complete. One possibility is that packets you send actually don't reach any relay, in which case 6to4 would not work for you. Another possibility is that somebody felt that debugging networking problems was too easy, and thus decided to create a filter to drop some (or all) ICMP packets in order to make it harder to debug. In that case 6to4 might still be working, but you cannot know from the traceroute output how many hops are actually missing from the output before the packets finally reach 192.88.99.1. There may be more possible reasons, which I don't know of.

It's OK to raise this problem with the ISP. They should provide you with a functional 6to4 relay or forward your concern to their upstream provider, if they aren't running the 6to4 relay themselves.

It may be possible to get a better idea about the whereabouts of a 6to4 relay by looking at both a traceroute to 192.88.99.1 and a traceroute to some native IPv6 address using a 6to4 address as sender. A more specialized tool with knowledge of protocol 41 could vary TTL in both inner and outer header to produce a more precise traceroute output indicating exactly how many hops are missing from the output before and after the 6to4 relay.