Help with configuring LEDE for dual-stack IPv4/6 operation

Installing and Using OpenWrt
1

Can I impose on the wisdom of the LEDE community to help me understand how to configure LEDE to provide a dual-stack SoHo IPv4/6 environment? I apologise for this being something of an essay, but I'm a bit of an IPv6 novice, and I'm not sure how much of what I've done so far might be relevant to my questions at the end. So ...

I'm running LEDE 17.01 on a TP-Link WDR4300, with a PPPOE connection to a VDSL2 modem providing native IPv4 connectivity with a single static public IPv4 address. I then have a private lan behind the router with a couple of WiFi access points attached to it. A few devices on my LAN are using static IPv4 addresses, many devices are using pseudo-static IPv4 addresses via static DHCP leases, and transient devices get genuinely dynamic addresses. One of my devices with a static IPv4 address is a Linux system that acts as an internet-facing Web/Mail/VPN/etc server, using port redirection through the IPv4 NAT/Firewall in the router, with my (hosted) DNS A record pointing to the routers public IPv4 address.

The hostnames for the static & pseudo-static addresses are provided via the LEDE hosts file and the static DHCP leases respectively. I'm generally not worried about giving the truly dynamically assigned devices hostnames, but of course some of them provide a client name as part of the DHCP process, and that seems to be honoured in LEDE (by cleverness in dnsmasq I believe). So for IPv4, dnsmasq appears to act as the DNS server for the devices on my LAN, answering authoritatively for devices in my domain (ie, on my LAN) and proxying requests for names not on my LAN to public DNS servers. Devices inside my LAN can resolve hostnames within the LAN, devices outside are not even aware of them.

So far, I suspect this isn't particularly unusual. But now I'm trying to add IPv6 to the mix.

I've added an HE 6in4 tunnel to LEDE (as ISP's providing native IPv6 are rare in the UK) giving me IPv6 connectivity using a routed /48 prefix. My understanding is that LEDE will assign IPv6 addresses to my LAN from the first /64 prefix in the /48, and reserve the remaining prefixes in the /48 for delegation via DHCP-PD. I also have a ULA /64 prefix assigned, and IPv6 aware devices on my LAN are acquiring IPv6 addresses in both the prefixes as I would expect.

My first step has been to add a statically defined global scope IPv6 address to my Web/Mail/VPN server, within the first /64 of the routed /48, rather than letting it autoconfigure its own global IPv6 address in the prefix dynamically. I also disabled IPv6 privacy extensions on the server for clarity, and I can see it acquiring that single IPv6 address in the global prefix (and a dynamic link-local IPv6 address, obviously). I'll add a matching static IPv6 address in the ULA prefix next, just for completeness, and then punch holes in the firewall to the global prefix address for the relevant services, and add a DNS AAAA record to my DNS provider pointing to my servers static global IPv6 address.

So, to my questions:

  1. I would like to assign some of my IPv6 aware devices pseudo-static global scope IPv6 addresses in the same way that I do for IPv4 addresses. How do I achieve this? I believe I can only do this using stateful DHCPv6, but is it done in LEDE using dnsmasq, odhcp6, something else? Do I need to configure this through LUCI or uci commands or editing config files? It's probably my lack of familiarity with LEDE, but I've not been able to work it out from the LEDE documentation, so while hints are always appreciated, for this, a clear simple description would be preferred!

  2. I have a ULA prefix and a global prefix where devices can (will) acquire IPv6 addresses. Is there any way to control the Interface ID (ie, lowest 64bits) so a device has the same Interface ID in both the ULA prefix and the global prefix? Clearly I can do this if I assign static IPv6 addresses to every client, but can I also do this for pseudo-static addresses, using some variation of whatever the answer to my first question is?

  3. But what about dynamic addresses? My belief is that anything that autoconfigures itself using SLAAC is largely outside of my control, so to maintain control I will need to assign dynamic IPv6 addresses using stateful DHCPv6. So given some MAC address, how can I assign common Interface IDs within two (or more) prefixes, while not knowing in advance what the MAC address will be? And for bonus points, is there any way to base those IPv6 Interface IDs on the IPv4 address being assigned to the device too? (I'm guessing there is not!)

  4. From what I read, this use of DHCPv6 will expose a problem with Android devices, as they don't seem to implement DHCPv6 in any form, and ignore the M & O bits in the RAs. So I think they will always autoconfigure themselves, no matter what I try to do from the router. So the best I can hope for with Android devices is to try to put a meaningful hostname into LEDEs DNS service pointing at whatever address(es) the Android device has autoconfigured for itself. How do I do that? Is it even possible to do that?!

  5. Finally, am I right in assuming that devices that configure themselves using stateful DHCPv6 will not use the IPv6 privacy extensions? And if not, is it possible to configure the router to force them to not use the privacy extensions?

Thanks for reading this far, and for any help you can offer.

2

I am asking myself exactly the same questions. My network is SoHo too and I registered HE as my provider RED in France does not offer IPv6 behind fiber (incredible in 2017?).

My understanding is that we should use only DHCPv6 or State-full/stateless configuration using DNSmasq and RAs. IPv6 adresses can be guessed from MAC. So there is no real privacy.

My main router receives a full /48 and delegates a /60. Then my subrouters delegate a full /64. It allows me to have separate zones: a full DMZ, a home zone, a WIFI zone (I don't trust WIFI).

I did some testing connecting remotely from an IPv6 host : all ports a very well firewalled, So from a security point of view, this is great.

Android devices cannot receive an IPv6, same issue.

Some remarks:

  • I did not test IPv6 dhcp configuration. I guess that dhcp is the default in a pure IPv6.

  • There is also another issue that I would like to resolve. I would like to be able to assign non-routable addresses to hosts, for security reasons. If you have a small server and don't want any connection from outside, it may be interesting to use a non-routable address. Think about a local syslog server that should not be accessed from outsied. The only way for me to precess was remove the WAN/WAN6 interface and let the eth0 interface autoconfigure. This is that when dnsmasq is not running on the host, it cannot receive a routable address. But this is not very acceptable. I would prefer a switch somewhere "provide routable/non-routable address". From a security point, this is not acceptable to rely solely on a firewall to make sure that your device is not exposed. I am really banging my head against the wall to understand how to dot it. DHCPv6 could be a solution, because if you assign a non-routable address, this is done.

  • Also, I have a feeling that a modern local network should be only IPv6 and provide an IPv4 bridge. So your only piece of IPv4 is the gateway. At some point, you should be able to remove IPv4.

  • If I remove IPv4 in my settings, IPv6 addressing does not work. I really don't understand why.

In fact, except auto-configuration, everything about IPv6 is very confusing.

To summarize:

  • IMHO, the goal is to have only IPv6 local network, with a bridge to IPv4, even when using HE tunneling. In the future, the Internet will be IPv6 only. Of course, some devices will always remain IPv4. But we should not have IPv4/IPv6 when a device supports both.

  • Present document is for reference only. We should write a HOWTO, to gather our knowlede. It could be here: https://lede-project.org/docs/user-guide/ipv6_ipv4_transitioning

3

Well, if it is so important to clarify a lot of types of this processes here, you are welcome to start from it.