said by Morac:
I've been trying to read up on how this is all supposed to work ( »manpages.ubuntu.com/manpages/har···f.5.html, »www.ietf.org/rfc/rfc3315.txt, »www.ietf.org/rfc/rfc3633.txt ) and from my understanding the delegating router (i.e. Comcast) is supposed to assign the requesting router (Tomato) a prefix. It's up to the requesting router to divvy that up into subnets and addresses and give it to local clients.
If Tomato is getting the prefix, which it sounds like it is, then Comcast should know to route any responses back to addresses that falls in that Prefix to Tomato, unless Tomato is mangling the outbound requests, but you already tested trying to do an inbound traceroute (which failed) so that seems unlikely. As such it sounds like the initial DHCPv6 setup is screwy since the delegating router doesn't know where the requesting router is.
Has anyone dumped out the actual DHCPv6 requests going back and forth?
Yes, I have done this. Let me explain the annoyance however:
The problem with using tcpdump on TomatoUSB is that it (and libpcap) is extremely old and does not have decent IPv6 support. I'm using the one available via ipkg, which come from »ipkg.nslu2-linux.org/feeds/optwa···/stable/
libpcap - 1.0.0-2 - PCAP Library
tcpdump - 4.0.0-1 - tcpdump dumps the traffic on a network
Old. Ancient. Horrible. The problem is that these can detect IPv6 packets (based on protocol header) but it cannot decode any of the IPv6 header data/etc.. This requires one to do the following:
kill `cat /var/run/dhcp6c.pid`
tcpdump -p -l -n -s 0 -i vlan2 -w /tmp/filename.pcap
Then in another window...
dhcp6c -T LL vlan2
Then wait a while, let things settle (it can sometimes take up to 120 seconds for DHCPv6 to fully do its thing; sometimes Comcast's servers don't respond to the request immediately). Then once you decide "I hope things are done", you have to do:
scp -p /tmp/filename.pcap user@someboxthatrunssshd:
And then look at the file using Wireshark.
It would be a lot easier if I had an inline tap which could look at packets flowing across the WAN port of my RT-N16, but I'd rather not go down to my garage and have to dig out my rack-mounted HP ProCurve switches just to get port mirroring. I do not have any hubs (god forbid anyone! ;-) ).
said by Morac:
The thing I find a bit odd is that Tomato does not appear to use the prefix to assign itself an iPv6 address on the WAN side. You'd think it would need one in order to talk for itself (as opposed to LAN clients) on the WAN side.
And that is exactly what the IA-NA problem/fix is about. By enabling IA-NA in dhcp6c.conf, you do get a single IPv6 address (/128) on vlan2. However, as arkmarkley and other people have stated, this shouldn't be needed.
What should be happening is that Comcast should be delegating a /64 prefix to the customer, which then gets assigned to the br0 interface on TomatoUSB. That part works.
TomatoUSB should then be forwarding any outbound packets (from any IPv6 member on the /64 LAN to the Internet) to the default IPv6 gateway on the router itself.
Likewise, Comcast's routers should know that packets destined to the /64 prefix should be sent to the address delegated with that /64. Let me explain what I mean by that:
Comcast DHCPv6 hands me 2601:9:4600:4f:e2cb:4eff:fec0:c4/64, which gets assigned to br0.
In English (using wildcard syntax), that means 2601:9:4600:4f:* is mine.
Likewise, since Comcast has delegated me 2601:9:4600:4f:e2cb:4eff:fec0:c4 -- which is a single IPv6 address -- their routers should know to send packets destined for 2601:9:4600:4f::/64 to 2601:9:4600:4f:e2cb:4eff:fec0:c4.
Thus, the whole IA-NA fix ("getting a /128 IPv6 WAN IP on vlan2") really shouldn't be required. The TomatoUSB router which gets 2601:9:4600:4f:e2cb:4eff:fec0:c4 should be able to talk to the world using that address, and clients (on the LAN) using that same /64 prefix should be able to talk to the world as well.
said by Morac:
Speaking of the later, it sounds like the router is supposed to assign addresses to the LAN using the prefix with stateless address autoconfiguration and then announce those using router advertisements. That could be why routing is failing.
But that wouldn't explain why in my case (see Linksysinfo.org forum posts) with statically-assigned IPv6 it isn't working.
To me, this almost looks like something on the Comcast side is not configured, route-wise, to forward packets destined to the /64 prefix to the IPv6 address they delegate.
The official Comcast forum thread with people testing IPv6 using a web browser
isn't helpful because nobody is showing what actually gets delegated / announced / etc.. The only post I can find that has even remotely useful information is this picture, which is from a customer's router, where he also decided to edit the picture and hide his MAC prefix section:
VERY IMPORTANT: Note that in that photo, he has a "WAN IPv6 Address" with a /128. The only way to get that is to enable the IA-NA fix I mentioned in this thread (first post), but doing that DOES NOT solve the issue of packets from the /64 prefix LAN going out the Internet and coming back.
I wish that guy would have provided his router's routing table!!--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.