My native ipv6 – part1
So, I’ve spent about two years arguing with my network provider Fibra to enable my high speed internet for ipv6 native. A struggle that in January 2018 payed off. I was kindly offered to be included in their PoC for ipv6 and I was thrilled.
Thank you Fibra for finally coming around on this.
I’m no guru on ipv6, but I feel comfortable navigating the fundamentals and have been running ipv6 tunnels for many years now. This is my hopefully short blogg series on getting my native ipv6 working at home.
My ambition at this point, is to have a public ipv6 address assigned from my network provider along with a 48 bit routed network prefix which will be split into a 64 bit prefix delegation for my home network.
This seems like a very basic setup at the time of writing and suits my ambitions for now. Later, I will be running separate ipv6 prefixes on my other virtual environments, while keeping the home network separate.
My current WAN access setup is a openWRT Chaos Calmer TPLINK with the WAN interface obtaining public IP:s from Bahnhof in Sweden. Fibra is the network provider, that for the purpose of the PoC, has turned on the switchport for ipv6 traffic for me.
For this to make sense to a reader, this is an extract of a starting /etc/config/network that serves as a starting point for a native ipv6 setup.
config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' option ipv6 '1' config interface 'wan6' option _orig_ifname 'eth0.2' option _orig_bridge 'false' option ifname 'eth0.2' option proto 'dhcpv6' option reqaddress 'try' option reqprefix 'auto'
Bringing up and down the interface should have you ending up with a ipv6 address on the eth0.2 interface. I did that maneuver, but no ipv6 address was handed out to me.
Basic debugging needed, you would likely do the same if you get this result.
I started by turning off the firewall (to be sure no traffic is dropped before it hits the tcpstack):
$ /etc/init.d/firewall stop
Then I tcpdump for ipv6 icmp traffic. I expect to see some ipv6 icmp traffic which I did. (in an ipv6 network, icmp traffic is chatty which is a bit different than you might be used to from ipv4 networks)
$ tcpdump -i eth0.2 icmp6
I could see Router Advertisement messages from an interface not on my devices, so something was working at Fibras side. I needed to verify that my router actually sent out dhcpv6 messages and the replies that should follow.
So, I force the ipv6 dhcp client (odhcp6c) to send router solicitation messages out on the interface I wish to handle the ipv6 native stack.
$ odhcp6c -s /lib/netifd/dhcpv6.script -Nforce -P48 -t120 eth0.2
Nope, no reply from my network provider.
What should happen here is that the dhcp6 server at my network provider Fibra side should respond with a configuration package (Advertise), but as you can see – its just spamming RA packages, seemingly ignoring my client Router Solicitations. This is not the way its supposed to be and I sent Fibra the information above.
To be continued.
Update 1:
Client -> Solicit Server -> Advertise Client -> Request Server -> Reply
Update 2:
Also a note from my ipv6 friend guru Jimmy is that, if you need to see more details on the ipv6 dhcp messages coming from the odhcp6c, you can expand the tcpdump filter as:
$ tcpdump -i eth0.2 icmp6 or port 546 or 547
You should see packages coming out from your interface as:
IP6 fe80::56e6:fcff:fe9a:246a.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
Erik Lönroth 