Is DHCPv6 client completely broken or am I missing something?


#1

This spawns from http://forum.vyos.net/showthread.php?tid=18564, but apparently I can’t move a topic.

Is VyOS’s IPv6/DHCPv6-client system even working at all? I hate to file a bug without being 100% sure I’m not doing anything wrong, but something just isn’t right and I’m not getting any traction in the HowTos forum. I’ve been trying to get this to work for over a week, but it doesn’t appear as if my config changes are having any effect on the underlying network config.

With this config on eth0:

ethernet eth0 { address dhcp address dhcpv6 description "Red Interface" duplex auto hw-id 00:50:56:3f:ff:01 smp_affinity auto speed auto }

I get this dhclient conf file auto-generated:

[code]$ more /var/lib/dhcp3/dhclient_eth0.conf

autogenerated by vyatta-interfaces.pl on Sat Feb 21 10:04:07 CST 2015

interface “eth0” {
send host-name “fw”;
request subnet-mask, broadcast-address, routers, domain-name-servers, interface-mtu;
}[/code]

And this dhclient6 conf file auto-generated:

[code]$ more /var/lib/dhcp3/dhclient_v6_eth0.conf

This file was auto-generated by the Vyatta

configuration sub-system. Do not edit it.

Generated on Mon Mar 2 13:11:04 2015 by root

interface “eth0” {
}[/code]

It’s as if my configuration changes have had zero effect on the underlying generated network configuration.

Is there some log file somewhere that may give me a hint as to what’s going on?


#2

Okay, so the changes are having some effect, because I’m seeing solicitation packets from my VyOS eth0 interface (link-local address fe80::250:56ff:fe3f:ff01/64).

$ sudo tcpdump ip6 17:19:31.205831 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 17:19:34.215813 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 ... 17:21:15.435268 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 17:21:18.436328 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 17:21:19.073396 IP6 fe80::250:56ff:fe3f:ff01.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 17:21:19.120153 IP6 fe80::201:5cff:fe65:ae46 > ff02::1:ff3f:ff01: ICMP6, neighbor solicitation, who has fe80::250:56ff:fe3f:ff01, length 32 17:21:20.115334 IP6 fe80::201:5cff:fe65:ae46 > ff02::1:ff3f:ff01: ICMP6, neighbor solicitation, who has fe80::250:56ff:fe3f:ff01, length 32 17:21:21.115663 IP6 fe80::201:5cff:fe65:ae46 > ff02::1:ff3f:ff01: ICMP6, neighbor solicitation, who has fe80::250:56ff:fe3f:ff01, length 32 17:21:21.445313 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 17:21:24.455443 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 ... 17:23:06.514969 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80 17:23:09.515203 IP6 fe80::201:5cff:fe65:ae46 > ip6-allnodes: ICMP6, router advertisement, length 80

This repeats over and over again. But it’s certainly not a complete handshake. It doesn’t look anything like the same tcpdump I get when I connect my MacBook Pro directly to my cable modem—In that case, the “dhcp6 solicit” message is followed by dozens of back-and-forth packets. But no matter how I change the VyOS DHCPv6/IPv6 settings, the tcpdump is always the same (unless I remove all IPv6 settings, in which case I don’t see anything).

It looks like VyOS/eth0 sends a “dhcp6 solicit” packet and Comcast’s router (link-local fe80::201:5cff:fe65:ae46) immediately responds with a “neighbor solicitation” packet for eth0’s link-local address. Shouldn’t VyOS be responding to this?


#3

Well, I feel rather stupid. I made big progress, but I’m still having problems I can’t figure out.

First, my original problem was the firewall. I didn’t think about the fact that my firewall’s default rule is to deny everything and I hadn’t yet created any IPv6 rules to allow IPv6 traffic. It was so restrictive, not even router advertisements, DHCP replies, and neighbor solicitations were making it through. Once I opened up the firewall, I successfully got an IPv6 address assigned to me. But I still can’t ping ipv6.google.com.

First, my (working?) eth0 config:

ethernet eth0 { address dhcp address dhcpv6 description "Red Interface" duplex auto hw-id 00:50:56:3f:ff:01 smp_affinity auto speed auto }

I now have an assigned IP address:

[code]$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description


br0 172.16.123.1/24 u/u Green Bridge from eth1 to vtun0
eth0 68...131/23 u/u Red Interface
2001:558:6016:19:
:::*/64
eth1 - u/u Green Interface
eth2 192.168.123.254/24 u/u DMZ 1 Interface
lo 127.0.0.1/8 u/u
::1/128
vtun0 - u/u Green VPN[/code]

I can ping eth0’s IPv6 address, Comcast’s router’s public IPv6 address, and Comcast’s router’s link-local IPv6 address, but not ipv6.google.com, respectively:

$ ping6 2001:558:6016:19:****:****:****:**** PING 2001:558:6016:19:****:****:****:****(2001:558:6016:19:****:****:****:****) 56 data bytes 64 bytes from 2001:558:6016:19:****:****:****:****: icmp_seq=1 ttl=64 time=0.086 ms $ ping6 2001:558:6016:19::1 PING 2001:558:6016:19::1(2001:558:6016:19::1) 56 data bytes 64 bytes from 2001:558:6016:19::1: icmp_seq=1 ttl=64 time=8.69 ms $ ping6 -I eth0 fe80::201:5cff:fe65:ae46 PING fe80::201:5cff:fe65:ae46(fe80::201:5cff:fe65:ae46) from fe80::250:56ff:fe3f:ff01 eth0: 56 data bytes 64 bytes from fe80::201:5cff:fe65:ae46: icmp_seq=1 ttl=64 time=7.85 ms $ ping6 2607:f8b0:4002:c07::8a connect: Network is unreachable $ ping6 -I eth0 2607:f8b0:4002:c07::8a connect: Network is unreachable

Clearly my routes are messed up, and indeed I am right, there’s no route for IPv6:

[code]$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [210/0] via 68.47.160.1, eth0
C>* 68...0/23 is directly connected, eth0
C>
127.0.0.0/8 is directly connected, lo
C>* 172.16.123.0/24 is directly connected, br0
C>* 192.168.123.0/24 is directly connected, eth2

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0[/code]

Granted, unless I’m still doing something wrong, a route should be added automatically (the IPv4 route is added automatically, so the IPv6 route should, too). But, for workaround purposes, I tried adding static routes two different ways:

[code] static {
route6 ::0/128 {
next-hop 2001:558:6016:19::1 {
}
}
}

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

S>* ::/128 [1/0] via 2001:558:6016:19::1, eth0
C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0[/code]

[code] static {
route6 ::0/128 {
next-hop fe80::201:5cff:fe65:ae46 {
interface eth0
}
}
}

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

S>* ::/128 [1/0] via fe80::201:5cff:fe65:ae46, eth0
C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0[/code]

[code] static {
interface-route6 ::/128 {
next-hop-interface eth0 {
}
}
}

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

S>* ::/128 [1/0] is directly connected, eth0
C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0[/code]

The last one makes the most sense, because the interface never changes but the router IP might. Regardless, none of the three worked. I can still ping eth0’s IPv6 address, Comcast’s router’s public IPv6 address, and Comcast’s router’s link-local IPv6 address, but I still can’t ping ipv6.google.com.

I’m going to mess with the firewall a bit more, but since I can ping Comcast’s router, I don’t see how it could be a firewall problem. Any ideas?


#4

[Almost There!]

:oops: sigh

Well, it would help if I used the right default gateway address (::/0 instead of ::/128). Once again, I find myself embarrassed. I guess I’m just too tired. The following different static routes both work and I am now, finally able to ping ipv6.google.com:

[code] static {
route6 ::/0 {
next-hop 2001:558:6016:19::1 {
}
}
}

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

S>* ::/0 [1/0] via 2001:558:6016:19::1, eth0
C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0

$ ping 2607:f8b0:4002:802::1002
PING 2607:f8b0:4002:802::1002(2607:f8b0:4002:802::1002) 56 data bytes
64 bytes from 2607:f8b0:4002:802::1002: icmp_seq=1 ttl=55 time=16.5 ms[/code]

[code] static {
route6 ::/0 {
next-hop fe80::201:5cff:fe65:ae46 {
interface eth0
}
}
}

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

S>* ::/0 [1/0] via fe80::201:5cff:fe65:ae46, eth0
C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0

$ ping 2607:f8b0:4002:802::1002
PING 2607:f8b0:4002:802::1002(2607:f8b0:4002:802::1002) 56 data bytes
64 bytes from 2607:f8b0:4002:802::1002: icmp_seq=1 ttl=55 time=17.1 ms[/code]

However, the following does not work, which means I’m going to have to manually update my static routes if Comcast’s router’s IP address ever changes:

[code] static {
interface-route6 ::/0 {
next-hop-interface eth0 {
}
}
}

$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

S>* ::/0 [1/0] is directly connected, eth0
C>* ::1/128 is directly connected, lo
C>* 2001:558:6016:19::/64 is directly connected, eth0
C * fe80::/64 is directly connected, vtun0
C * fe80::/64 is directly connected, eth2
C * fe80::/64 is directly connected, eth1
C * fe80::/64 is directly connected, eth0
C>* fe80::/64 is directly connected, br0

$ ping 2607:f8b0:4002:802::1002
PING 2607:f8b0:4002:802::1002(2607:f8b0:4002:802::1002) 56 data bytes
From 2001:558:6016:19:::: icmp_seq=1 Destination unreachable: Address unreachable[/code]

That leaves me with three remaining questions, and the answers to the last two will determine whether or not there is any sort of bug here:

  1. Is it better for the static route to use the router’s public IP address or the router’s link-local IP address + interface, or does it matter?
  2. The default IPv4 route is created automatically when the IPv4 address is assigned through DHCP. Is there a way to make the default IPv6 route be created automatically when the IPv6 address is assigned through DHCPv6?
  3. An IPv6 /64 address range is considered a single subnet, and, for compatibility reasons, it’s really only good for addressing that single subnet. All major ISPs are actually handing out larger address ranges (/63 to allow 2 subnets, /60 to allow 16 subnets, /48 to allow 65535 subnets, etc.). VyOS is, by default, requesting a /64 address range from DHCPv6, which is only good for providing addresses to a single subnet. According to Comcast, they’ll hand out whatever size allocation the DHCPv6 client requests (within reason). So how do you configure VyOS to request a /63 or /60 instead of a /64?

#5

[quote=“beamerblvd, post:3, topic:402”]
First, my original problem was the firewall. I didn’t think about the fact that my firewall’s default rule is to deny everything and I hadn’t yet created any IPv6 rules to allow IPv6 traffic. It was so restrictive, not even router advertisements, DHCP replies, and neighbor solicitations were making it through. Once I opened up the firewall, I successfully got an IPv6 address assigned to me. But I still can’t ping ipv6.google.com.[/quote]

I working on the same problem. Which rules did you add to allow it to get the ipv6 address? I’ve added some, but apparently not the right ones.

Would you be willing to post some snippets from your config?


#6

[quote=“dan, post:5, topic:402”]

Got past that. It was a rule and zone problem. Now I have an ipv6 address from Comcast.
Next up: try to get a default route working and then request a /60 block instead of the default /64.