Print

[sysadmininc]

Hi all.

I'm having some issues and I'm not sure where else to turn. Let me give the background of my setup then the configuration.

My internet provider is Verizon FiOS and I'm using their 9100EM router. This seems to allow me to configure protocols to let through and it looks like I was able to configure protocol 41. I have a dynamic IP but it stays pretty static until the router is rebooted.

I'm using my NAT Linux box as my IPv6 router.

cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=wibble.sysadmininc.com
GATEWAY="192.168.168.254"
IPV6FORWARDING=yes

192.168.168.254 is the IP of the router.

cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
IPADDR="192.168.168.1"
HWADDR="00:06:4F:63:86:F0"
DNS1="192.168.168.254"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Ethernet"
UUID="fb552591-42b1-4b3c-ac8a-a853e2786d3a"

192.168.168.1 is, obviously, the ip address of the Linux box.

Now to configure my tunnel I'm using the following snippet in /etc/rc.local

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.218.224.42
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f0e:a0::2/64
route -A inet6 add ::/0 dev sit1

then to setup the forwarding
ip a a 2001:470:1f0f:a0::1 dev eth0
ip r a 2001:470:1f0e:a0::/64 dev eth0

I can confirm ipv6 forwarding is enabled:
sysctl net.ipv6.conf.eth0.forwarding
net.ipv6.conf.eth0.forwarding = 1

So my network configuration looks like so:

ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:06:4F:63:86:F0
          inet addr:192.168.168.1  Bcast:192.168.168.255  Mask:255.255.255.0
          inet6 addr: 2001:470:1f0f:a0::1/128 Scope:Global
          inet6 addr: fe80::206:4fff:fe63:86f0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:147711 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62496 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:34226459 (32.6 MiB)  TX bytes:13909424 (13.2 MiB)

eth1      Link encap:Ethernet  HWaddr 00:1E:90:FE:5B:15
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:307 errors:1 dropped:0 overruns:0 frame:1
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:51292 (50.0 KiB)  TX bytes:958 (958.0 b)
          Interrupt:31 Base address:0x4000

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:220 errors:0 dropped:0 overruns:0 frame:0
          TX packets:220 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:73477 (71.7 KiB)  TX bytes:73477 (71.7 KiB)

sit0      Link encap:IPv6-in-IPv4
          inet6 addr: ::127.0.0.1/96 Scope:Unknown
          inet6 addr: ::192.168.168.1/96 Scope:Compat
          UP RUNNING NOARP  MTU:1480  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:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2001:470:1f0e:a0::2/64 Scope:Global
          inet6 addr: fe80::c0a8:a801/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:4517 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4126 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2204326 (2.1 MiB)  TX bytes:729533 (712.4 KiB)

and it actually works!
ping6 www.google.com
PING www.google.com(oa-in-x63.1e100.net) 56 data bytes
64 bytes from oa-in-x63.1e100.net: icmp_seq=1 ttl=56 time=78.7 ms
64 bytes from oa-in-x63.1e100.net: icmp_seq=2 ttl=56 time=79.1 ms
64 bytes from oa-in-x63.1e100.net: icmp_seq=3 ttl=56 time=80.5 ms

ping6 2001:470:0:78::1
PING 2001:470:0:78::1(2001:470:0:78::1) 56 data bytes
64 bytes from 2001:470:0:78::1: icmp_seq=1 ttl=63 time=52.9 ms
64 bytes from 2001:470:0:78::1: icmp_seq=2 ttl=63 time=51.9 ms

So, now the problem is that I have a Windows 7 Ultimate 32bit box that isn't working with ipv6.

Let's look at the radvd.conf file

interface eth0
{
        AdvSendAdvert on;
        prefix 2001:470:1f0f:a0::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
        };
        route ::/0
        { };
};

then I run in the foreground with logging/debugging

radvd -u radvd -m logfile -l /var/log/radvd.log -d 5

Now, over on the windows box. I've disabled the generation of temporary ipv6 addresses.

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : THROW
   IPv6 Address. . . . . . . . . . . : 2001:470:1f0f:a0:921:ee36:be1b:e2d1
   Link-local IPv6 Address . . . . . : fe80::921:ee36:be1b:e2d1%10
   IPv4 Address. . . . . . . . . . . : 192.168.168.2
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::206:4fff:fe63:86f0%10
                                       192.168.168.254

So you can see, the ipv6 gateway is being set to ..well, I have no idea where that's going to actually. In my radvd.log file I see the following when I  enable the ipv6 interface on Windows.

radvd: version 1.6 started
radvd: mtu for eth0 is 1500
radvd: hardware type for eth0 is 1
radvd: link layer token length for eth0 is 48
radvd: prefix length for eth0 is 64
radvd: interface definition for eth0 is ok
radvd: Initializing privsep
radvd: sending RA on eth0
[snipping timer calls etc]

then eventually I get

radvd: received RS or RA with invalid hoplimit 1 from fe80::921:ee36:be1b:e2d1

At this stage, I cannot use ipv6 on the Windows box. I'm at the limit of my knowledge on this and would appreciate any help.

Thanks,
Nigel

[kasperd]

then to setup the forwarding
ip a a 2001:470:1f0f:a0::1 dev eth0
ip r a 2001:470:1f0e:a0::/64 dev eth0

This part looks incorrect. You did not specify a prefix length when assigning the address to eth0, and from your ifconfig output, it appears it has defaulted to a /128. The manual assignment of the route on the interface should not be necessary, additionally you got it wrong. You routed the tunnel prefix to eth0 instead of the routed prefix.

If you replace those two lines with this one line ip addr add 2001:470:1f0f:a0::1/64 dev eth0, then it should work better.

[sysadmininc]

Thanks for the suggestion. I made the change you recommeded.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:06:4F:63:86:F0
          inet addr:192.168.168.1  Bcast:192.168.168.255  Mask:255.255.255.0
          inet6 addr: 2001:470:1f0f:a0::1/64 Scope:Global
          inet6 addr: fe80::206:4fff:fe63:86f0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9902682 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16425934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2424267611 (2.2 GiB)  TX bytes:21950295939 (20.4 GiB)

ip -6 route
::/96 via :: dev sit0  metric 256  mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:1f0e:a0::/64 via :: dev sit1  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:1f0f:a0::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 via :: dev sit1  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 4294967295
default dev sit1  metric 1  mtu 1480 advmss 1420 hoplimit 4294967295

radvd gives me the same error "received RS or RA with invalid hoplimit 1 from fe80::921:ee36:be1b:e2d1" when I disabled and re-enabled ipv6 on the windows side, however I can ping the Linux box ipv6 from windows now...sort of...

C:\Windows\system32>ping 2001:470:1f0f:a0::1

Pinging 2001:470:1f0f:a0::1 with 32 bytes of data:
General failure.
Reply from 2001:470:1f0f:a0::1: time=724ms
General failure.
Reply from 2001:470:1f0f:a0::1: time<1ms

Ping statistics for 2001:470:1f0f:a0::1:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 724ms, Average = 362ms

C:\Windows\system32>ping 2001:470:1f0f:a0::1

Pinging 2001:470:1f0f:a0::1 with 32 bytes of data:
Reply from 2001:470:1f0f:a0::1: time=733ms
Reply from 2001:470:1f0f:a0::1: time<1ms
Reply from 2001:470:1f0f:a0::1: time=1ms
General failure.

Ping statistics for 2001:470:1f0f:a0::1:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 733ms, Average = 244ms

And, of course, cannot ping any ipv6 on the internet.

I'll maybe set a static ipv6 and gateway next unless there's any other suggestions.

Thanks again,
Nigel

[kasperd]

radvd gives me the same error "received RS or RA with invalid hoplimit 1 from fe80::921:ee36:be1b:e2d1" when I disabled and re-enabled ipv6 on the windows side

Ah. I missed that part from your first post. So it appears you have had more than just one problem.

The error message suggests the problem has to do with what is used for hoplimit on packets, which are supposed to be link-only and never be routed.

On one hand it makes sense for the sender to use 1 for the hop limit, because then the sender is guaranteed that the packet will never be forwarded by any router. On the other hand if the sender used 255 for the hop limit, then the receiver will know for sure that it was not forwarded. That is because if it was forwarded the hop limit will have been decreased, and it could never have been more than 255 in the first place. This knowledge is only usable on the receiving host if the standard dictates that the sender uses 255, because then the sender can ignore any packet with hop limit different from 255. That will avoid certain spoofing attacks.

It appears Windows chose the first approach and use 1 for the hop limit and radvd is using the second approach and ignores every packet with a hop limit different from 255.

There are two questions, which you want answers to. First of all is Windows or radvd at fault? If the standard says this packet must be sent with a hop limit of 255, then Windows is at fault for using a hop limit of 1. If the standard does not say this packet must be sent with a hop limit of 255, then radvd is at fault for rejecting a valid packet.

Secondly, can you change any configuration settings to make it work. Maybe you can tell Windows to use 255 for the hop limit on router solicitations. And maybe you can tell radvd to disable this safety check and accept router solicitations with hop limit less than 255. If you do the later, you should ensure it only answers router solicitations from your LAN and not router solicitations routed through the internet.

If it turns out to be possible to adjust the configuration on either side, then it would make sense to adjust the configuration on whichever side is not standard compliant.

however I can ping the Linux box ipv6 from windows now...sort of...

C:\Windows\system32>ping 2001:470:1f0f:a0::1

Pinging 2001:470:1f0f:a0::1 with 32 bytes of data:
General failure.
Reply from 2001:470:1f0f:a0::1: time=724ms
General failure.
Reply from 2001:470:1f0f:a0::1: time<1ms

Ping statistics for 2001:470:1f0f:a0::1:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 724ms, Average = 362ms

Looks very much like neighbor discovery is broken, but one side picks up the MAC address to send to from other packets, when it doesn't get replies to solicitations. This would explain both the packet loss and periodically high latency. On a LAN you'd not expect to see latency above 1ms. Last time I experienced something similar on IPv4 (due to RFC1918 address collisions) I found a workaround. I simply left a ping running trying to ping an unused IP address on the LAN.

You should try the same and leave a ping command running on both the Windows and Linux machines each trying to ping an unused IPv6 address on the LAN. I would not call that a solution, but if it is a workable workaround, it will at least point us towards the cause of the problem.

It is not unlikely that the neighbor discovery problem is caused by the same hop limit issue, which is reported by radvd. If that's the case, then both radvd and kernel on the Linux machine ignores packets from the Windows machine due to wrong hop limit, and you probably need to fix the Windows machine.

A packet trace of the traffic on the LAN could be used to check if my guesses are correct. Do you have tcpdump or wireshark installed?

[sysadmininc]

I'm sort of lost here. I'm sure this worked long, long ago. I setup up a static IP on the Windows 7 box to avoid using radvd, but still no joy. I think I'll just forget about it until my ISP does native ipv6. (HAH).

Thanks for the help, but it shouldn't be this difficult, I'm sure.