Issues setting up use of routed /64 and /48

[mcgurrin]

I'm running several several machines which I am trying to setup with the ipv6 tunnel service, the one I am having the most trouble with is running centos 64 bit and I can get it to ping out but I can't get it to respond on its routed /64 IP addresses from another IPv6 capable machine.  I have run through the steps given on the tunnel details page but I don't see any configuration when I look on the machine to tell it to use the routed /64 addresses, only the ppp tunnel address and some other that seem to be automatic from before I set up the tunnel that seem to be loopback and other similar addresses.  Can anyone help me?  If there are specific command outputs that would help let me know and I would be happy to post them, I have tried so many commands though I just don't want to post them all without knowing which are helpful.  Thanks.

[cholzhauer]

A copy of your routing tables and ifconfig would be helpful.

[mcgurrin]

A copy of your routing tables and ifconfig would be helpful.

I have included them below, its odd though because I see no IPv6 routing data even though I can use "ping6 ipv6.google.com" with success and get responses, is there some different command for ipv6 routing data?  Thanks.

[root@1 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3E:01:03:16 
          inet addr:173.234.9.77  Bcast:173.234.9.127  Mask:255.255.255.128
          inet6 addr: 2001:470:1f07:bdd:216:3eff:fe01:316/64 Scope:Global
          inet6 addr: fe80::216:3eff:fe01:316/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:100280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5740 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6862589 (6.5 MiB)  TX bytes:2510599 (2.3 MiB)

he-ipv6   Link encap:IPv6-in-IPv4 
          inet6 addr: 2001:470:7:920::2/64 Scope:Global
          inet6 addr: fe80::adea:94d/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1352 (1.3 KiB)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2004 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2004 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:354554 (346.2 KiB)  TX bytes:354554 (346.2 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.100.200.1  P-t-P:10.100.200.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00 
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:7665 (7.4 KiB)

[root@1 ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.200.2    *               255.255.255.255 UH    0      0        0 tun0
173.234.9.0     *               255.255.255.128 U     0      0        0 eth0
10.100.200.0    10.100.200.2    255.255.255.0   UG    0      0        0 tun0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         173.234.9.1.rdn 0.0.0.0         UG    0      0        0 eth0
[root@1 ~]#

[cholzhauer]

netstat -nr also works

[snarked]

inet6 addr: 2001:470:7:920::2/64 Scope:Global

- especially when:

inet6 addr: 2001:470:1f07:bdd:216:3eff:fe01:316/64 Scope:Global

seems to be your routed /64.

Are you certain you're using your tunnel's /64 correctly?

The encapsulated interface should have the tunnel ...::2 address on it, NOT one from the routed /48.

[cholzhauer]

If you could post a copy of your tunnel details, it might clear up a bunch of confusion.

[mcgurrin]

If you could post a copy of your tunnel details, it might clear up a bunch of confusion.

The tunnel details page is attached.  I used the linux-route2 commands so the name is actually he-ipv6 for the interface.  You are correct on the tunnel /64.  I don't think my endpoint is supposed to respond from the internet from my reading, try pinging 2001:470:8:920:1:1:1:1 which is within my routed /64 and I think it is responding to pings at my server but it seems to work sometimes and others not as I mentioned, I think that is due to some misconfiguration on one of the machines I tried pinging from's network though based on my tests.

If your "routed" block were 2001:0470:1f07:0bdd::/64 then this would route to your tunnel endpoint and not as below to "crash430"

  I don't think that that is my routed /64 based on the pages on this site.  I think that that block is from my host and it might just be the one address listed as I did nothing that would have set that address up and I see no reference to the entire /64 block on either of my tunnel details pages, one for this server one for another.  I think I figured out the labor intensive way to get it responding but what I need now is efficiency instead of assigning each address one by one and cluttering up my output, especially when I am not sure it will persist beyond a reboot and so I either have to write a script or do it all over again.

Thanks for all of the help so far, it has been really helpful in figuring this out both directly and indirectly.

[cholzhauer]

OK, so your routed /64 is 2001:470:8:920::/64  and the /48 is 2001:470:e2c4::/48  Your tunnel /64 is 2001:470:7:920::/64

We don't want to do anything with 2001:470:7:920::/64 other than use it for the tunnel end points

Since you have the /48, you might as well use it, so we'll ignore 2001:470:8:920::/64 as well (but you could use it)

I cannot ping the address you provided

Code:

[carl@mars ~]$ ping6 2001:470:8:920:1:1:1:1
PING6(56=40+8+8 bytes) 2001:470:c27d:e000:20c:29ff:fe8a:1618 --> 2001:470:8:920:1:1:1:1
^C
--- 2001:470:8:920:1:1:1:1 ping6 statistics ---
20 packets transmitted, 0 packets received, 100.0% packet loss

As for automatically assigning addresses, your choices are Router Advertisements (RA) or DHCPv6.  As long as you're running DNS internally, RA is easier to set up and more universally supported.

[snarked]

Still not proper, but maybe working?

The TUNNEL /64 is supposed to be the ONLY thing on the tunnel encapsulation interface.  "he-ipv6" should have ONLY "2001:470:7:920::2" as global on it (it may be a "/64", but only "/126" addresses will be used).  The other addresses, "2001:470:8:920::/64" and "2001:470:e2c4::/48" should be on OTHER interfaces (like eth0 or virbr0).

Eth0's "2001:470:1f07:bdd:216:3eff:fe01:316/64" is wrong - and seems as if it's a leftover from a prior tunnel you may have had via a different tunnel server location.

[mcgurrin]

Still not proper, but maybe working?

The TUNNEL /64 is supposed to be the ONLY thing on the tunnel encapsulation interface.  "he-ipv6" should have ONLY "2001:470:7:920::2" as global on it (it may be a "/64", but only "/126" addresses will be used).  The other addresses, "2001:470:8:920::/64" and "2001:470:e2c4::/48" should be on OTHER interfaces (like eth0 or virbr0).

Eth0's "2001:470:1f07:bdd:216:3eff:fe01:316/64" is wrong - and seems as if it's a leftover from a prior tunnel you may have had via a different tunnel server location.

Oh, I didn't realize that for the other addresses, maybe that is why it is not working.  Actually this is the first tunnel I have done and that address works so I think it is actually an address from my host so unless it starts causing issues I will leave it though I didn't notice it until recently.  I have removed the addresses from the tunnel interface and I added the first back except on eth0 and that helped and made it work, can you try pinging 2001:470:8:920:1:1:1:1 to see if it works, that is the address I put back with that one change.  To think it might have been such a simple issue for the last half of this discussion.  Now the only remaining question as long as that continues to work is how would I add a group of addresses without specifying each one individually, say an /112?  Thanks, that is a huge help.