Segmenting IPv6 networks using dnsmasq

dnsmasqipv6local-area-network

I have a bit of a complicated network setup(*) where a WAN router connects to the upstream provider and provides an "external LAN" (where actually I have some services) and another local router has its external leg on the "external LAN" and provides an "internal LAN" (where most nodes are connected and there's also a DMZ host). IPv4 Clients on the "internal LAN" are double NATed and it works well enough for my needs (also the DMZ setup works well with the internal router set as the "DMZ host" for the WAN router).

No the WAN router has been upgraded with an IPv6 connected and the "external LAN" is provided with a 56 bit network – lets call it 2001:db8:2:300::. Hosts on the "external LAN" can DHCPv6 and get a 64 bit network address assigned to them and it works.

I want to have the internal router – which is running dnsmasq for network management – to offer IPv6 to the internal clients. I have selected a valid 64 bit network inside the "external LAN" 56 bit network – lets call it 2001:db8:2:333:: and have set up the internal router's "internal LAN" leg with the ::1 of that network. I had then set up dnsmasq to offer DHCPv6 on the "internal LAN" using:

enable-ra
dhcp-range=::2, ::FFFF:FFFF, constructor:vlan4, ra-names, 64, 12h

(on the internal router, vlan2 is the "external LAN" and vlan4 is the the "internal LAN")

I can trace now connect an "internal LAN" client and get an IPv6 address and ping the internal router. When I ping anything outside of that – such as the WAN router's internal IPv6 gateway port – I don't get a reply. Pings and connections from the internal router itself work well. I can trace an ICMP packet on the internal router and see it going out of the correct interface, but no reply is received.

As far as I understand, the WAN router doesn't understand where to send replies to hosts in 2001:db8:2:333:: as it thinks they should be directly connected on its LAN, but they aren't actually there.

I think I should have the internal router send Router Advertisement for 2001:db8:2:333:: to the WAN router? I tried to get dnsmasq to do it by adding:

interface=vlan2
dhcp-range=2001:db8:2:300:1234:5678:abcd:100,2001:db8:2:300:1234:5678:abcd:400,ra-only,infinite

But that doesn't work because clearly I have no idea what I'm doing. 😅🤷

A network expert that I manage to get 30 seconds of attention from said that I need to have internal router be a DHCPv6 relay towards the WAN router, so that the WAN router can allocate addresses to the internal clients and know to route to them through the internal router – but I can't figure out how to get dnsmasq to do that, while keeping IPv4 DHCP running as it is, as dnsmasq man page says that you can't have dhcp-relay and dhcp-range on the same interface.

I would love to try any suggestion and/or be taught about IPv6 because while I'm pretty good at IPv4 networks, IPv6 is clearly a bit over my head.

*) This weird setup is mostly due to issues of trust and control of the WAN router, which are out of scope of this issue, so if your only suggestion is to change that setup – please don't.

Best Answer

The key here is letting the upstream DHCP server know that you will be handing those addresses to devices not directly attached to the WAN router.

Configure your LAN router:

  1. to enable the PD flag on top of what its dhcpv6 client already does, and
  2. in dnsmasq, enable router announcements, constructor: automation, and proxy dns&ntp.

If you do not care about which specific prefix is used, neither does dnsmasq:

enable-ra
dhcp-range=::,constructor:wanside,1h
dhcp-option=option6:dns-server,::
dhcp-option=option6:ntp-server,::

Really, that was it? Well..

It worked for me, years ago, with a (literally) black box WAN, but the mechanism - while meant for such use case and mostly well defined - was and still is riddled with bugs in all involved software.

I know nothing about DHCP relaying, this answer is about automatic prefix delegation.

Internet
|
|     /----- directly attached machines
WAN router 
| v announces itself as router *AND* leases a /64 *AND* larger PD prefix
|       
| ^ requests its own /64 *AND* larger PD prefix *AND* a router address
my Router (and a firewall, but for once it did not interfere)
| v announces itself as router *AND* hands out /64s
|
| ^ request a /64 each *AND* a router address
internal boxes

Delegation is the option where

  1. the WAN Router does not need to know individual addresses used by the internal LAN, and
  2. your internal LAN uses both link-local & globally routable addresses, and
  3. once setup, it reconfigures new addresses as needed, even with wiped / replaced WAN router.

Details

  • You want the LAN Router to have both the address it gets that one via the more common DHCPv6 options already and additionally you want it to request a prefix the WAN box knows to be delegated to not-directly-attached boxed
  • No obvious way to tell dnsmasq "forward dns and ntp addresses as-is", but you probably were going to proxy it anyway, that is what dnsmasq does, right?
  • dnsmasq is picky about which address space to select when using constructor:, that is why no further configuration is necessary
  • dnsmasq is only announcing still-valid addresses in RA, thus the address dnsmasq announces as router to its downstream clients does not matter as long as the interfaces are separate on layer 2
  • I ran a separate dhclient that already supported the option back then (WIDE I believe), but but by now most clients, even systemd-networkd (albeit not via netplan) can be configured to do it and still request another directly leased prefix.
  • The IA_PD request can ask for a specific prefix size or even a specific prefix. Start without doing that, and only enable it after the simple case works for more consistent network addresses.
  • The WAN router completely forgot about the delegated prefix and associated routes as soon as the delegation expired. For extra fun, the dhcp client did not put the expiration from dhcp in the IP address expiration where it would have been obvious. You need to confirm that your dhcp client actually renews the lease including the delegated prefix - they do not necessarily expire at the same time.
Related Topic