Hello all,
forgive me if this has been answered else where, I searched the forums and did not see anything specific to this question.
Here is my question along with some specific information to hopefully help someone answer it.
Where are the global unicast addresses coming from on my local network?
I have obtained an ipv6 tunnel address from he.net and configured my n300/E1200 linksys router for a 6rd tunnel.
This is the output from ifconfig on my local box:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 2001:470:1f10:632:8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x0<global>
inet6 fe80::8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x20<link>
inet6 fd54:79a6:c646:0:8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x0<global>
ether 88:9f:fa:77:d1:3c txqueuelen 1000 (Ethernet)
RX packets 351135 bytes 114409735 (109.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 378688 bytes 53483556 (51.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The bold line is the address that every external web site says my address is, it is global and the output of ipv6calc is this:
Address type: unicast, global-unicast
Address type has SLA: 0632
Registry for address: ARIN
Interface identifier: 8a9f:faff:fe77:d13c
EUI-48/MAC address: 88:9f:fa:77:d1:3c
MAC is a global unique one
MAC is an unicast one
OUI is: Hon Hai Precision Ind. Co.,Ltd.
I have 2 other linux boxes on the local network and each has it's own unicast global address.
The prefix is from the he.net address pool, but how are they being assigned is my question again?
radvd is not running on any local machine, the router has no dhcp6 capability that I am aware of.
Are the address coming from he.net? Automagically, from somewhere I am not aware of?
Thanks for taking the time to answer this question for me.
Quote from: eagle8762 on November 13, 2012, 08:33:59 PMI have obtained an ipv6 tunnel address from he.net and configured my n300/E1200 linksys router for a 6rd tunnel.
AFAIK he.net does not support 6rd, only 6in4. (6in4, 6rd, and 6to4 all use the same packet format, but the method for assigning addresses are different.)
Quote from: eagle8762 on November 13, 2012, 08:33:59 PM
This is the output from ifconfig on my local box:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 2001:470:1f10:632:8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x0<global>
That address looks incorrect. The LAN side of your router should be using the routed /64. But that address is from your tunnel /64. You probably mixed up the two prefixes when configuring your router.
Quote from: eagle8762 on November 13, 2012, 08:33:59 PMradvd is not running on any local machine, the router has no dhcp6 capability that I am aware of.
The router most likely is running radvd (or equivalent).
Your router is acting a bit strange. This is what I see, when I try to traceroute you:
traceroute to 2001:470:1f10:632:8a9f:faff:fe77:d13c (2001:470:1f10:632:8a9f:faff:fe77:d13c), 30 hops max, 80 byte packets
1 2a01:d0:839a:babe:735d:77a7:990d:702c 17.475 ms 11.987 ms 12.013 ms
2 2001:470:1f0a:1e45::1 72.034 ms 72.074 ms 72.071 ms
3 2001:470:0:69::1 72.100 ms 56.032 ms 56.066 ms
4 2001:470:0:21b::2 72.167 ms 72.249 ms 72.190 ms
5 2001:470:0:1b1::1 139.052 ms 140.539 ms 140.569 ms
6 2001:470:0:286::1 154.491 ms 166.857 ms 167.302 ms
7 2001:470:0:6e::2 162.898 ms 149.355 ms 152.750 ms
8 ::74.129.228.249 174.050 ms 178.960 ms 179.490 ms
9 * * *
10 * * *This is the second time I have seen an IPv4 address showing up in a traceroute to a tunnelbroker.net address. Perhaps the two of you are using the same router firmware.
Okay, I reconfigured my router using the routed prefix:
2001:470:1f11:632::
The image attached is from the router configuration page for the IPv6 portion.
This is the relevant portion of my ifconfig regarding the inet6 address:
inet6 2001:470:1f11:632:8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x0<global>
inet6 2001:470:1f10:632:8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x0<global>
inet6 fe80::8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x20<link>
inet6 fd54:79a6:c646:0:8a9f:faff:fe77:d13c prefixlen 64 scopeid 0x0<global>
And this is the IPv6 address on the internet right now:
2001:470:1f11:632:8a9f:faff:fe77:d13c
So, when I configure this router should I be using the prefix portion of the IPv6 tunnel address from tunnelbroker?
Which is:
2001:470:1f10:632
Thanks
Quote from: eagle8762 on November 14, 2012, 04:42:34 AMSo, when I configure this router should I be using the prefix portion of the IPv6 tunnel address from tunnelbroker?
You are supposed to be using both prefixes in the proper places in the configuration.
The screenshot you attached is from a page intended for configuration of 6rd. What tunnelbroker.net provides is 6in4. The two are similar, but not identical. And as you have found out, it is possible to set the 6rd parameters in a way, which for the most part works correctly against a 6in4 provider. If your router has 6in4 support, you'll be better off finding the correct page to configure 6in4 connectivity.
If your router can only handle 6rd, then your configuration is probably close to the best you can do. There are two problems to keep in mind.
The first question is, do you configure the tunnel /64 or the routed /64 for the LAN. Using the routed /64 is more appropriate, because on the tunnel /64 there are a few addresses that are reserved, and nothing on your LAN would know about that. If however you could somehow avoid using those few reserved addresses for anything on your LAN, you really could treat the tunnel /64 as just another routed /64.
There is a theoretical possibility that using your tunnel /64 as if it was a routed /64 could increase the memory usage on the tunnel server. Whether this happens in practice is something, which I don't know.
For both of the mentioned reasons, I'd recommend using the routed /64. That is what this prefix is intended for.
The other problem is whether HE thinks your tunnel is being used or not. HE has been deleting tunnels, which appeared to be unused. One of the methods used to identify tunnels which are unused is by pinging the IPv6 address of the user's router. In your case that would be 2001:470:1f10:632::2. Your router doesn't respond to pings on that IP address. It also didn't respond to those before you changed the prefix.
If your router doesn't have any 6in4 support, the best you can do is to keep using 6rd and hope HE is still able to see your tunnel is in use such that it doesn't get deleted.