IPv6 - secondary router to ULA

Installing and Using OpenWrt
1

Hi All,

My question is about IPv6 router advertisements and proxying. It's probably related to the odhcpd package.

I want to add a secondary OpenWRT IPv6 router to my network specifically to route to a ULA subnet.

I have a default router supplied by an ISP. I want to add a secondary router to my local network, specifically to route to an isolated subnet with a set of unique-local-addresses. I want hosts to auto configure so that they can see either the global internet, or devices on the ULA.

Here's a diagram:

IPv6 router advertisements
IPv6 router advertisements1668×590 31.1 KB

My reasons for having the ULA cloud use a /48 subnet (e.g. larger than the lan) are complicated, and probably not worth going into. It's not really a delegated prefix, at least in the traditional sense.

Here's my question: what is the best way to configure the OpenWRT router so the hosts auto-configure their IPv6 routes appropriately? I know I can manually add a /48 route to each host. I'd prefer they auto-detect the routes based on messages from the OpenWRT routers. The hosts are correctly creating multiple their IPv6 addresses, but the routing is incorrect.

Seems to me that there might be two approaches, but I haven't been able to get either to work:

  • Neighbor Discovery Proxy. I could try to configure the OpenWRT router to proxy for everything on the ULA. I can't figure out how to configure this to work in my scenario. Honestly, it doesn't seem well documented. I'm willing to help document it if I can figure it out.

  • Adding a Route Information Option (RIO) to the RA messages from the OpenWRT router. I hope this will cause the hosts to add the ULA /48 to their routing tables (although I've heard that doesn't always work). I can't figure out how to force odhcpd to add RIO to RA messages.

Any help or guidance would be appreciated. Thanks,

-Joe

2

If I am not mistaken, in absence of a GUA prefix and a default route, odhcpd will advertise the whole ULA prefix in its RAs.

1 Like
3

Thank you for your quick reply.

That's not what I see when I capture packets with Wireshark. Instead, what I see is that the RA coming from the OpenWRT router includes the ULA for address configuration on-link (fdaa:bbb:cccc:dddd::/64), but no routing information to the larger /48 ULA subnet.

Ideally, I would like the RA message from OpenWRT to communicate to each of the hosts: "You are on a /64 subnet, so you can configure your address accordingly. I will also be the router to carry your traffic off-link to the larger /48 ULA network."

In other words, I want the hosts to create a default route to the global internet based on the RA from the ISP gateway, and a route to the /48 ULA subnet based on the RA from the OpenWRT router.

Per RFC 4191, I believe that including Route Information Option (RIO) in Router Advertisements will accomplish that. I'm sure I've seen RIOs in Router Advertisements from OpenWRT before (it was a long time ago), but I'm not sure how to create a dhcp config file that forces it to happen.

Thank you again.

4 
# tcpdump -vni any icmp6
...
	  prefix info option (3), length 32 (4): fdc9:6a0:218d::/64, Flags [onlink, auto], valid time infinity, pref. time infinity
	  route info option (24), length 24 (3):  fdc9:6a0:218d::/48, pref=medium, lifetime=1800s
...

# ubus call system board
{
	"kernel": "4.14.221",
	"hostname": "openwrt1",
	"system": "Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz",
	"model": "QEMU Standard PC (i440FX + PIIX, 1996)",
	"board_name": "qemu-standard-pc-i440fx-piix-1996",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.7",
		"revision": "r11306-c4a6851c72",
		"target": "x86/64",
		"description": "OpenWrt 19.07.7 r11306-c4a6851c72"
	}
}
1 Like
5

@vgaetera Thank you. That is not what I'm getting on my OpenWRT router.

Would you mind sharing your /etc/config/network, and /etc/config/dhcp?

Here's the router advertisement I am seeing:

root@echo:~# tcpdump -vvni br-lan icmp6
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
21:48:11.223580 IP6 (flowlabel 0xe3537, hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::8adc:96ff:fe8e:650c > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 96
	hop limit 64, Flags [other stateful], pref low, router lifetime 90s, reachable time 0ms, retrans timer 0ms
	  source link-address option (1), length 8 (1): 88:dc:96:8e:65:0c
	    0x0000:  88dc 968e 650c
	  mtu option (5), length 8 (1):  1500
	    0x0000:  0000 0000 05dc
	  prefix info option (3), length 32 (4): fdfe:cb5c:b2ae:6968::/64, Flags [onlink, auto], valid time infinity, pref. time infinity
	    0x0000:  40c0 ffff ffff ffff ffff 0000 0000 fdfe
	    0x0010:  cb5c b2ae 6968 0000 0000 0000 0000
	  rdnss option (25), length 24 (3):  lifetime 90s, addr: fdfe:cb5c:b2ae:6968::1
	    0x0000:  0000 0000 005a fdfe cb5c b2ae 6968 0000
	    0x0010:  0000 0000 0001
	  advertisement interval option (7), length 8 (1):  30000ms
	    0x0000:  0000 0000 7530

The important lines (I think) from /etc/config/network on my router are:

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0 eth1'
	option proto 'static'
	option dns '8.8.8.8'
	option netmask '255.255.255.0'
	option ipaddr '192.168.88.7'
	option gateway '192.168.88.3'
	option ip6ifaceid '::1' 
	option ip6hint '6968'  
	option ip6assign '64'  

config interface 'wan'  
	option ifname 'bat0'
	option proto 'static'
	option macaddr '8a:dc:96:8e:65:0c'
	option ip6addr 'fdfe:cb5c:b2ae:ffff::6968/48'
	option ip6prefix 'fdfe:cb5c:b2ae::/48'

You know, I am kind of on the bleeding edge, running a candidate for release 21. It's possible that's the problem, but it has been pretty stable in other respects.

root@echo:~# ubus call system board
{
	"kernel": "5.4.108",
	"hostname": "echo",
	"system": "ARMv7 Processor rev 5 (v7l)",
	"model": "EnGenius ENS620EXT",
	"board_name": "engenius,ens620ext",
	"release": {
		"distribution": "custom",
		"version": "21.02-SNAPSHOT",
		"revision": "r15993-53d3d9e6fe",
		"target": "ipq40xx/generic",
		"description": "21.02-SNAPSHOT r15993-53d3d9e6fe"
	}
}
6

My config is basically the default.
So, your issue is likely due to odhcpd changes.
Check out the relevant documentation and code:
https://openwrt.org/docs/techref/odhcpd#documentation

7

this is more than a few weeks old? snapshots are intended to be transient... your first point of call if running an old snapshot and facing a bug is to update...

your second point of call is to report the bug in the right place or run a stable release...

2 Likes