Hello,
I have been helping a friend getting access to native IPv6 connectivity
at home, using OpenBSD, and have been running into a few problems. It
would be nice to hear input from any developers on this.
The setup looks like this: We are supposed to get a default route on the
outside interface (em0), using autoconf, and then recieve an IPv6 prefix
on the inside (em1) using DHCP6-PD (prefix delegation).
The IP addresses have been masked to protect the innocent (though
you can trust that "XX.XXX" and "XXXX:XXX:XXXX:" are unique and correct
representations of a single set of real addresses)
Before starting, the interface configuration and routing table looks
like this:
===
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
priority: 0
groups: lo
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr d0:50:99:51:78:e8
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet XX.XXX.8.17 netmask 0xffffff80 broadcast XX.XXX.8.127
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr d0:50:99:51:78:e9
priority: 0
media: Ethernet autoselect (1000baseT
full-duplex,master,rxpause,txpause)
status: active
inet 192.168.212.254 netmask 0xffffff00 broadcast 192.168.212.255
enc0: flags=0<>
priority: 0
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
priority: 0
groups: pflog
===
===
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default XX.XXX.8.1 UGS 4 111678 - 8 em0
XX.XXX.8.0/25 link#1 UC 1 0 - 4 em0
XX.XXX.8.1 00:0c:db:f6:1c:00 UHLc 1 0 - 4 em0
XX.XXX.8.17 d0:50:99:51:78:e8 UHLl 0 0 - 1 lo0
XX.XXX.8.127 link#1 UHLb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 0 32768 1 lo0
192.168.212/24 link#2 UC 9 0 - 4 em1
192.168.212.1 0c:c4:7a:31:d7:38 UHLc 0 32699 - 4 em1
192.168.212.2 00:25:90:ae:ca:4a UHLc 0 383 - 4 em1
192.168.212.3 b8:27:eb:22:72:8b UHLc 0 674 - 4 em1
192.168.212.4 b8:27:eb:32:0b:66 UHLc 0 166 - 4 em1
192.168.212.109 50:55:27:f4:ff:82 UHLc 0 1079 - 4 em1
192.168.212.136 ec:a8:6b:f9:6e:35 UHLc 0 705 - 4 em1
192.168.212.249 58:6d:8f:a0:51:c8 UHLc 0 8 - 4 em1
192.168.212.252 d0:bf:9c:45:0c:a0 UHLc 0 2684 - 4 em1
192.168.212.253 d0:bf:9c:45:0c:a2 UHLc 0 1 - 4 em1
192.168.212.254 d0:50:99:51:78:e9 HLl 0 0 - 1 lo0
192.168.212.255 link#2 UHLb 0 0 - 1 em1
224/4 127.0.0.1 URS 0 0 32768 8 lo0
Internet6:
Destination Gateway Flags Refs
Use Mtu Prio Iface
::/104 ::1 UGRS 0
0 32768 8 lo0
::/96 ::1 UGRS 0
0 32768 8 lo0
::1 ::1 UHl 14
0 32768 1 lo0
::1 ::1 UH 0
0 32768 4 lo0
::127.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS 0
0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0
0 32768 8 lo0
2002::/24 ::1 UGRS 0
0 32768 8 lo0
2002:7f00::/24 ::1 UGRS 0
0 32768 8 lo0
2002:e000::/20 ::1 UGRS 0
0 32768 8 lo0
2002:ff00::/24 ::1 UGRS 0
0 32768 8 lo0
fe80::/10 ::1 UGRS 0
0 32768 8 lo0
fe80::%lo0/64 fe80::1%lo0 U 0
0 32768 4 lo0
fe80::1%lo0 fe80::1%lo0 UHl 0
0 32768 1 lo0
fec0::/10 ::1 UGRS 0
0 32768 8 lo0
ff01::/16 ::1 UGRS 0
0 32768 8 lo0
ff01::%lo0/32 ::1 UC 0
0 32768 4 lo0
ff02::/16 ::1 UGRS 0
0 32768 8 lo0
ff02::%lo0/32 ::1 UC 0
0 32768 4 lo0
===
Our pf.conf contains a single inet6 rule, which is "pass inet6" to
simplify the debugging for now.
The only IPv6 related sysctl settings that have been configured in
sysctl.conf are the following (the last one to aid debugging):
===
net.inet6.ip6.forwarding=1
net.inet6.icmp6.nd6_debug=1
===
We start out by enabling autoconf on em0 to get a default route via
fe80:
===
# ifconfig em0 inet6 autoconf
===
The interface configuration now looks like this:
===
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
priority: 0
groups: lo
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
em0: flags=208843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500
lladdr d0:50:99:51:78:e8
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet XX.XXX.8.17 netmask 0xffffff80 broadcast XX.XXX.8.127
inet6 fe80::d250:99ff:fe51:78e8%em0 prefixlen 64 scopeid 0x1
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr d0:50:99:51:78:e9
priority: 0
media: Ethernet autoselect (1000baseT
full-duplex,master,rxpause,txpause)
status: active
inet 192.168.212.254 netmask 0xffffff00 broadcast 192.168.212.255
enc0: flags=0<>
priority: 0
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
priority: 0
groups: pflog
===
This is where possibly unexpected things start happening. Our first
note is that no default route is appearing for IPv6:
===
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default XX.XXX.8.1 UGS 4 161453 - 8 em0
XX.XXX.8.0/25 link#1 UC 1 0 - 4 em0
XX.XXX.8.1 00:0c:db:f6:1c:00 UHLc 1 0 - 4 em0
XX.XXX.8.17 d0:50:99:51:78:e8 UHLl 0 0 - 1 lo0
XX.XXX.8.127 link#1 UHLb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 0 32768 1 lo0
192.168.212/24 link#2 UC 9 0 - 4 em1
192.168.212.1 0c:c4:7a:31:d7:38 UHLc 0 47705 - 4 em1
192.168.212.2 00:25:90:ae:ca:4a UHLc 0 478 - 4 em1
192.168.212.3 b8:27:eb:22:72:8b UHLc 0 979 - 4 em1
192.168.212.4 b8:27:eb:32:0b:66 UHLc 0 199 - 4 em1
192.168.212.109 50:55:27:f4:ff:82 UHLc 0 1338 - 4 em1
192.168.212.136 ec:a8:6b:f9:6e:35 UHLc 0 941 - 4 em1
192.168.212.249 58:6d:8f:a0:51:c8 UHLc 0 8 - 4 em1
192.168.212.252 d0:bf:9c:45:0c:a0 UHLc 0 2820 - 4 em1
192.168.212.253 d0:bf:9c:45:0c:a2 UHLc 0 1 - 4 em1
192.168.212.254 d0:50:99:51:78:e9 HLl 0 0 - 1 lo0
192.168.212.255 link#2 UHLb 0 0 - 1 em1
224/4 127.0.0.1 URS 0 0 32768 8 lo0
Internet6:
Destination Gateway Flags Refs
Use Mtu Prio Iface
::/104 ::1 UGRS 0
0 32768 8 lo0
::/96 ::1 UGRS 0
0 32768 8 lo0
::1 ::1 UHl 14
0 32768 1 lo0
::1 ::1 UH 0
0 32768 4 lo0
::127.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS 0
0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0
0 32768 8 lo0
2002::/24 ::1 UGRS 0
0 32768 8 lo0
2002:7f00::/24 ::1 UGRS 0
0 32768 8 lo0
2002:e000::/20 ::1 UGRS 0
0 32768 8 lo0
2002:ff00::/24 ::1 UGRS 0
0 32768 8 lo0
fe80::/10 ::1 UGRS 0
0 32768 8 lo0
fe80::%em0/64 link#1 UC 1
0 - 4 em0
fe80::20c:dbff:fef6:1c00%em0 00:0c:db:f6:1c:00 UHLc 0
0 - 4 em0
fe80::d250:99ff:fe51:78e8%em0 d0:50:99:51:78:e8 UHLl 0
0 - 1 lo0
fe80::%lo0/64 fe80::1%lo0 U 0
0 32768 4 lo0
fe80::1%lo0 fe80::1%lo0 UHl 0
0 32768 1 lo0
fec0::/10 ::1 UGRS 0
0 32768 8 lo0
ff01::/16 ::1 UGRS 0
0 32768 8 lo0
ff01::%em0/32 link#1 UC 0
0 - 4 em0
ff01::%lo0/32 ::1 UC 0
0 32768 4 lo0
ff02::/16 ::1 UGRS 0
0 32768 8 lo0
ff02::%em0/32 link#1 UC 0
0 - 4 em0
ff02::%lo0/32 ::1 UC 0
0 32768 4 lo0
===
When looking in dmesg, we can see the following messages related to
the net.inet6.icmp6.nd6_debug flag:
===
defrouter_select: called unexpectedly (forwarding=1)
nd6_ra_input: invalid prefixlen 48 for rfc2374 prefix XXXX:XXX:XXXX::, ignored
===
There are two kinds of messages, when looking at one of
the ISP router advertisements in wireshark, we see that it contains a /48
prefix:
===
XXXX:XXX:XXXX::/48
===
If this is "wrong" or not, we are not sure, but that explains the
"invalid prefixlen 48" message we see in dmesg. The kernel throws this
error if the prefixlen is anything other than 64.
The reason the packet contains the /48 is because this is the netmask of the
network assigned to the upstream router vlan interface. We are only supposed to
get a default route from this message, not configure an IP address however. (I
have noticed Linux will populate it's routing table with the /48 though).
The more troublesome message is "defrouter_select: called unexpectedly
(forwarding=1)". This appears to be the reason no default route is being added
to the routing table.
This probably ties in with the "be both a router (ip6 forward enabled)
and a client (using autoconf) at the same time" problem that was hinted
at in this message on tech@ (talking about SOHO routers):
http://marc.info/?l=openbsd-tech&m=140541936220074&w=2
Disabling ip6 forwarding makes the route appear:
===
# sysctl net.inet6.ip6.forwarding=0
net.inet6.ip6.forwarding: 1 -> 0
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default XX.XXX.8.1 UGS 4 217856 - 8 em0
XX.XXX.8.0/25 link#1 UC 1 0 - 4 em0
XX.XXX.8.1 00:0c:db:f6:1c:00 UHLc 1 0 - 4 em0
XX.XXX.8.17 d0:50:99:51:78:e8 UHLl 0 0 - 1 lo0
XX.XXX.8.127 link#1 UHLb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 0 32768 1 lo0
192.168.212/24 link#2 UC 9 0 - 4 em1
192.168.212.1 0c:c4:7a:31:d7:38 UHLc 0 64749 - 4 em1
192.168.212.2 00:25:90:ae:ca:4a UHLc 0 500 - 4 em1
192.168.212.3 b8:27:eb:22:72:8b UHLc 0 984 - 4 em1
192.168.212.4 b8:27:eb:32:0b:66 UHLc 0 204 - 4 em1
192.168.212.109 50:55:27:f4:ff:82 UHLc 0 1341 - 4 em1
192.168.212.136 ec:a8:6b:f9:6e:35 UHLc 0 1112 - 4 em1
192.168.212.249 58:6d:8f:a0:51:c8 UHLc 0 8 - 4 em1
192.168.212.252 d0:bf:9c:45:0c:a0 UHLc 0 2952 - 4 em1
192.168.212.253 d0:bf:9c:45:0c:a2 UHLc 0 1 - 4 em1
192.168.212.254 d0:50:99:51:78:e9 HLl 0 0 - 1 lo0
192.168.212.255 link#2 UHLb 0 0 - 1 em1
224/4 127.0.0.1 URS 0 0 32768 8 lo0
Internet6:
Destination Gateway Flags Refs
Use Mtu Prio Iface
::/104 ::1 UGRS 0
0 32768 8 lo0
::/96 ::1 UGRS 0
0 32768 8 lo0
default fe80::20c:dbff:fef6:1c00%em0 UG 0
0 - 56 em0
::1 ::1 UHl 14
0 32768 1 lo0
::1 ::1 UH 0
0 32768 4 lo0
::127.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS 0
0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0
0 32768 8 lo0
2002::/24 ::1 UGRS 0
0 32768 8 lo0
2002:7f00::/24 ::1 UGRS 0
0 32768 8 lo0
2002:e000::/20 ::1 UGRS 0
0 32768 8 lo0
2002:ff00::/24 ::1 UGRS 0
0 32768 8 lo0
fe80::/10 ::1 UGRS 0
0 32768 8 lo0
fe80::%em0/64 link#1 UC 1
0 - 4 em0
fe80::20c:dbff:fef6:1c00%em0 00:0c:db:f6:1c:00 UHLc 1
0 - 4 em0
fe80::d250:99ff:fe51:78e8%em0 d0:50:99:51:78:e8 UHLl 0
0 - 1 lo0
fe80::%lo0/64 fe80::1%lo0 U 0
0 32768 4 lo0
fe80::1%lo0 fe80::1%lo0 UHl 0
0 32768 1 lo0
fec0::/10 ::1 UGRS 0
0 32768 8 lo0
ff01::/16 ::1 UGRS 0
0 32768 8 lo0
ff01::%em0/32 link#1 UC 0
0 - 4 em0
ff01::%lo0/32 ::1 UC 0
0 32768 4 lo0
ff02::/16 ::1 UGRS 0
0 32768 8 lo0
ff02::%em0/32 link#1 UC 0
0 - 4 em0
ff02::%lo0/32 ::1 UC 0
0 32768 4 lo0
===
Leaving the forwarding disabled for now, the next step is to fetch the
IPv6 prefix from the ISP using DHCP6-PD. We use the dhcp6c client from
the wide-dhcp6 package for this. First of all the configuration:
===
# cat /etc/dhcp6c.conf
interface em0 {
send ia-pd 0;
};
id-assoc pd {
prefix-interface em1 {
sla-id 1;
sla-len 8;
};
};
===
This will request a prefix delegation and assign it on em1. When running
dhcp6c the following can be seen:
===
# dhcp6c -Df -c /etc/dhcp6c.conf em0
Jun/30/2015 18:14:33: get_duid: extracted an existing DUID from
/var/db/dhcp6c_duid: 00:01:00:01:1d:1f:02:b3:d0:50:99:51:78:e8
Jun/30/2015 18:14:33: dhcp6_ctl_authinit: failed to open /etc/dhcp6cctlkey: No
such file or directory
Jun/30/2015 18:14:33: client6_init: failed initialize control message
authentication
Jun/30/2015 18:14:33: client6_init: skip opening control port
Jun/30/2015 18:14:33: cfdebug_print: <3>[interface] (9)
Jun/30/2015 18:14:33: cfdebug_print: <5>[em0] (3)
Jun/30/2015 18:14:33: cfdebug_print: <3>begin of closure [{] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>[send] (4)
Jun/30/2015 18:14:33: cfdebug_print: <3>[ia-pd] (5)
Jun/30/2015 18:14:33: cfdebug_print: <3>[0] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of sentence [;] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of closure [}] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of sentence [;] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>[id-assoc] (8)
Jun/30/2015 18:14:33: cfdebug_print: <13>[pd] (2)
Jun/30/2015 18:14:33: cfdebug_print: <13>begin of closure [{] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>[prefix-interface] (16)
Jun/30/2015 18:14:33: cfdebug_print: <5>[em1] (3)
Jun/30/2015 18:14:33: cfdebug_print: <3>begin of closure [{] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>[sla-id] (6)
Jun/30/2015 18:14:33: cfdebug_print: <3>[1] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of sentence [;] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>[sla-len] (7)
Jun/30/2015 18:14:33: cfdebug_print: <3>[8] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of sentence [;] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of closure [}] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of sentence [;] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of closure [}] (1)
Jun/30/2015 18:14:33: cfdebug_print: <3>end of sentence [;] (1)
Jun/30/2015 18:14:33: configure_pool: called
Jun/30/2015 18:14:33: clear_poolconf: called
Jun/30/2015 18:14:33: dhcp6_reset_timer: reset a timer on em0, state=INIT,
timeo=0, retrans=960
Jun/30/2015 18:14:34: client6_send: a new XID (bf310c) is generated
Jun/30/2015 18:14:34: copy_option: set client ID (len 14)
Jun/30/2015 18:14:34: copy_option: set elapsed time (len 2)
Jun/30/2015 18:14:34: copyout_option: set IA_PD
Jun/30/2015 18:14:34: client6_send: send solicit to ff02::1:2%em0
Jun/30/2015 18:14:34: dhcp6_reset_timer: reset a timer on em0, state=SOLICIT,
timeo=0, retrans=1069
Jun/30/2015 18:14:34: client6_recv: receive advertise from
fe80::20c:dbff:fef6:1c00%em0 on em0
Jun/30/2015 18:14:34: dhcp6_get_options: get DHCP option IA_PD, len 41
Jun/30/2015 18:14:34: IA_PD: ID=0, T1=0, T2=0
Jun/30/2015 18:14:34: copyin_option: get DHCP option IA_PD prefix, len 25
Jun/30/2015 18:14:34: copyin_option: IA_PD prefix: XXXX:XXX:XXXX:a00::/56
pltime=9000 vltime=14400
Jun/30/2015 18:14:34: dhcp6_get_options: get DHCP option client ID, len 14
Jun/30/2015 18:14:34: DUID: 00:01:00:01:1d:1f:02:b3:d0:50:99:51:78:e8
Jun/30/2015 18:14:34: dhcp6_get_options: get DHCP option server ID, len 14
Jun/30/2015 18:14:34: DUID: 00:01:00:01:1a:bc:08:bf:00:50:56:9b:dd:3c
Jun/30/2015 18:14:34: client6_recvadvert: server ID:
00:01:00:01:1a:bc:08:bf:00:50:56:9b:dd:3c, pref=-1
Jun/30/2015 18:14:34: client6_recvadvert: reset timer for em0 to 0.975240
Jun/30/2015 18:14:36: select_server: picked a server (ID:
00:01:00:01:1a:bc:08:bf:00:50:56:9b:dd:3c)
Jun/30/2015 18:14:36: client6_send: a new XID (32e604) is generated
Jun/30/2015 18:14:36: copy_option: set client ID (len 14)
Jun/30/2015 18:14:36: copy_option: set server ID (len 14)
Jun/30/2015 18:14:36: copy_option: set elapsed time (len 2)
Jun/30/2015 18:14:36: copyout_option: set IA_PD prefix
Jun/30/2015 18:14:36: copyout_option: set IA_PD
Jun/30/2015 18:14:36: client6_send: send request to ff02::1:2%em0
Jun/30/2015 18:14:36: dhcp6_reset_timer: reset a timer on em0, state=REQUEST,
timeo=0, retrans=991
Jun/30/2015 18:14:36: client6_recv: receive reply from
fe80::20c:dbff:fef6:1c00%em0 on em0
Jun/30/2015 18:14:36: dhcp6_get_options: get DHCP option IA_PD, len 41
Jun/30/2015 18:14:36: IA_PD: ID=0, T1=0, T2=0
Jun/30/2015 18:14:36: copyin_option: get DHCP option IA_PD prefix, len 25
Jun/30/2015 18:14:36: copyin_option: IA_PD prefix: XXXX:XXX:XXXX:a00::/56
pltime=9000 vltime=14400
Jun/30/2015 18:14:36: dhcp6_get_options: get DHCP option client ID, len 14
Jun/30/2015 18:14:36: DUID: 00:01:00:01:1d:1f:02:b3:d0:50:99:51:78:e8
Jun/30/2015 18:14:36: dhcp6_get_options: get DHCP option server ID, len 14
Jun/30/2015 18:14:36: DUID: 00:01:00:01:1a:bc:08:bf:00:50:56:9b:dd:3c
Jun/30/2015 18:14:36: get_ia: make an IA: PD-0
Jun/30/2015 18:14:36: update_prefix: create a prefix XXXX:XXX:XXXX:a00::/56
pltime=15199889269544, vltime=14400
Jun/30/2015 18:14:36: ifaddrconf: add an address
XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9/64 on em1
Jun/30/2015 18:14:36: update_ia: T1(4500) and/or T2(7200) is locally determined
Jun/30/2015 18:14:36: dhcp6_remove_event: removing an event on em0,
state=REQUEST
Jun/30/2015 18:14:36: dhcp6_remove_event: removing server (ID:
00:01:00:01:1a:bc:08:bf:00:50:56:9b:dd:3c)
Jun/30/2015 18:14:36: client6_recvreply: got an expected reply, sleeping.
^C
===
We now have a prefix assigned to em1:
===
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
priority: 0
groups: lo
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
em0: flags=208843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500
lladdr d0:50:99:51:78:e8
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet XX.XXX.8.17 netmask 0xffffff80 broadcast XX.XXX.8.127
inet6 fe80::d250:99ff:fe51:78e8%em0 prefixlen 64 scopeid 0x1
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr d0:50:99:51:78:e9
priority: 0
media: Ethernet autoselect (1000baseT
full-duplex,master,rxpause,txpause)
status: active
inet 192.168.212.254 netmask 0xffffff00 broadcast 192.168.212.255
inet6 fe80::d250:99ff:fe51:78e9%em1 prefixlen 64 scopeid 0x2
inet6 XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 prefixlen 64
enc0: flags=0<>
priority: 0
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
priority: 0
groups: pflog
===
However, no directly connected route for the /64 has been created as a result:
===
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default XX.XXX.8.1 UGS 4 322151 - 8 em0
XX.XXX.8.0/25 link#1 UC 1 0 - 4 em0
XX.XXX.8.1 00:0c:db:f6:1c:00 UHLc 1 0 - 4 em0
XX.XXX.8.17 d0:50:99:51:78:e8 UHLl 0 0 - 1 lo0
XX.XXX.8.127 link#1 UHLb 0 0 - 1 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 0 32768 1 lo0
192.168.212/24 link#2 UC 9 0 - 4 em1
192.168.212.1 0c:c4:7a:31:d7:38 UHLc 0 92342 - 4 em1
192.168.212.2 00:25:90:ae:ca:4a UHLc 0 681 - 4 em1
192.168.212.3 b8:27:eb:22:72:8b UHLc 0 1278 - 4 em1
192.168.212.4 b8:27:eb:32:0b:66 UHLc 0 274 - 4 em1
192.168.212.109 50:55:27:f4:ff:82 UHLc 0 1344 - 4 em1
192.168.212.136 ec:a8:6b:f9:6e:35 UHLc 0 1422 - 4 em1
192.168.212.249 58:6d:8f:a0:51:c8 UHLc 0 8 - 4 em1
192.168.212.252 d0:bf:9c:45:0c:a0 UHLc 0 3228 - 4 em1
192.168.212.253 d0:bf:9c:45:0c:a2 UHLc 0 1 - 4 em1
192.168.212.254 d0:50:99:51:78:e9 HLl 0 0 - 1 lo0
192.168.212.255 link#2 UHLb 0 0 - 1 em1
224/4 127.0.0.1 URS 0 0 32768 8 lo0
Internet6:
Destination Gateway Flags Refs
Use Mtu Prio Iface
::/104 ::1 UGRS 0
0 32768 8 lo0
::/96 ::1 UGRS 0
0 32768 8 lo0
default fe80::20c:dbff:fef6:1c00%em0 UG 0
3 - 56 em0
::1 ::1 UHl 14
0 32768 1 lo0
::1 ::1 UH 0
0 32768 4 lo0
::127.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::224.0.0.0/100 ::1 UGRS 0
0 32768 8 lo0
::255.0.0.0/104 ::1 UGRS 0
0 32768 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0
0 32768 8 lo0
2002::/24 ::1 UGRS 0
0 32768 8 lo0
2002:7f00::/24 ::1 UGRS 0
0 32768 8 lo0
2002:e000::/20 ::1 UGRS 0
0 32768 8 lo0
2002:ff00::/24 ::1 UGRS 0
0 32768 8 lo0
XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 d0:50:99:51:78:e9 UHLl
0 0 - 1 lo0
fe80::/10 ::1 UGRS 0
0 32768 8 lo0
fe80::%em0/64 link#1 UC 1
0 - 4 em0
fe80::20c:dbff:fef6:1c00%em0 00:0c:db:f6:1c:00 UHLc 1
4 - 4 em0
fe80::d250:99ff:fe51:78e8%em0 d0:50:99:51:78:e8 UHLl 0
0 - 1 lo0
fe80::%em1/64 link#2 UC 0
0 - 4 em1
fe80::d250:99ff:fe51:78e9%em1 d0:50:99:51:78:e9 UHLl 0
0 - 1 lo0
fe80::%lo0/64 fe80::1%lo0 U 0
0 32768 4 lo0
fe80::1%lo0 fe80::1%lo0 UHl 0
0 32768 1 lo0
fec0::/10 ::1 UGRS 0
0 32768 8 lo0
ff01::/16 ::1 UGRS 0
0 32768 8 lo0
ff01::%em0/32 link#1 UC 0
0 - 4 em0
ff01::%em1/32 link#2 UC 0
0 - 4 em1
ff01::%lo0/32 ::1 UC 0
0 32768 4 lo0
ff02::/16 ::1 UGRS 0
0 32768 8 lo0
ff02::%em0/32 link#1 UC 1
0 - 4 em0
ff02::1:2%em0 link#1 UHLc 0
2 - 4 em0
ff02::%em1/32 link#2 UC 0
0 - 4 em1
ff02::%lo0/32 ::1 UC 0
0 32768 4 lo0
===
Leaving this lurking problem for now, we try to enable rtadvd on em1:
===
# rtadvd em1
===
... which fails with the following error:
===
Jun 30 18:17:01 gw01 rtadvd[3118]: non zero router lifetime is specified for
em1, which must not be allowed for hosts. you must change router lifetime or
enable IPv6 forwarding.
===
At this point it is clear we need to enable forwarding again:
===
# sysctl net.inet6.ip6.forwarding=1
net.inet6.ip6.forwarding: 0 -> 1
===
After starting rtadvd, a windows client on the local network configures an
address via SLAAC, and we attempt to ping it from the router which fails:
===
# ping6 XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1
PING6(56=40+8+8 bytes) XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 -->
XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1
^C
--- XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1 ping6 statistics ---
19 packets transmitted, 0 packets received, 100.0% packet loss
===
The lack of a route for the /64 address on em1 makes the ping
packets go out on em0 instead, which explains why we recieve no
response:
===
# tcpdump -n -e -ttt -i em0 ip6
[...]
Jun 30 19:03:08.625595 00:0c:db:f6:1c:00 d0:50:99:51:78:e8 86dd 70:
XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 > XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1:
icmp6: echo request
Jun 30 19:03:08.625610 d0:50:99:51:78:e8 00:0c:db:f6:1c:00 86dd 70:
XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 > XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1:
icmp6: echo request
Jun 30 19:03:08.625839 00:0c:db:f6:1c:00 d0:50:99:51:78:e8 86dd 70:
XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 > XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1:
icmp6: echo request
[...]
===
If we manually create the route, then the packets stop going out on em0, but
the ping fails with a different error:
===
# route add XXXX:XXX:XXXX:a01::/64 -iface XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9
add net XXXX:XXX:XXXX:a01::/64: gateway XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9
===
===
# ping6 XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1
PING6(56=40+8+8 bytes) XXXX:XXX:XXXX:a01:d250:99ff:fe51:78e9 -->
XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1
ping6: sendmsg: Invalid argument
ping6: wrote XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1 16 chars, ret=-1
ping6: sendmsg: Invalid argument
ping6: wrote XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1 16 chars, ret=-1
ping6: sendmsg: Invalid argument
===
At the same time we see strange errors in dmesg:
===
[...]
nd6_storelladdr: something odd happens
nd6_storelladdr: something odd happens
nd6_storelladdr: something odd happens
[...]
===
At some point messages like these are generated as well (probably when
the windows machine was trying to perform outbound connections), making
me believe all is not well with the routing table (that address is
inside the /64 network assigned to em1, so it should be considered a
neighbour).
===
nd6_ns_input: NS packet from non-neighbor
nd6_ns_input: src=XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1
nd6_ns_input: dst=ff02:2::1:ff51:78e9
nd6_ns_input: tgt=fe80::d250:99ff:fe51:78e9
nd6_ns_input: NS packet from non-neighbor
nd6_ns_input: src=XXXX:XXX:XXXX:a01:ecc3:2959:1362:32f1
nd6_ns_input: dst=ff02:2::1:ff51:78e9
nd6_ns_input: tgt=fe80::d250:99ff:fe51:78e9
===
In summary, the problems we face are these:
* Having ip6 forwarding enabled disables the possibility to learn routes
via SLAAC, this is necessary in a SOHO situation like this.
* When dhcp6c assigns the prefix on em1, no directly connected
route for that network is created.
* Even when assigning the route manually, it seems the 5.7 machine is not
happy. This is different from 5.6, where adding the route manually made the
ping packets start working.
Any input on this would be much appreciated! As a side note, related to
the "should i handle RAs when I am a router": another friend noted that the
Linux camp allows two levels of this setting:
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt:
===
accept_ra - INTEGER
Accept Router Advertisements; autoconfigure using them.
It also determines whether or not to transmit Router
Solicitations. If and only if the functional setting is to
accept Router Advertisements, Router Solicitations will be
transmitted.
Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.
Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled.
===
So basically, setting it to 0 disables the handling of router advertisements,
setting it to 1 accepts them given that forwarding is disabled (pretty close
to what we are seeing OpenBSD doing right now when handling of RAs are enabled)
and 2 makes it handle the RAs without any regard of forwarding status (what we
would probably need in this SOHO case).
--
Patrik Lundin
