Hacker News Reader

To be clear, what you have is a router that's asking your ISP for a DHCPv6-PD prefix, assigning slices of that to one or more interfaces on that router, and what you want is for your dhcpd on that router to assign prefix-oblivious addresses to specific hosts on your LAN?

In other words, you want things to work like this?

  ISP-provided-PD-prefix 2001::/64 + Host address ::22 = Assigned address 2001::22
  ISP-provided-PD-prefix 2001:1:/64 + Host address ::22 = Assigned address 2001:1::22

If so, I'll poke around the docs to see if this is possible. I'm running both dhcpcd and ISC dhcpd on my LAN and have a hobbyist's experience with them.

But -honestly- what I've done is just relied on SLAAC to handle the globally-routable addresses, and advertised a ULA prefix for stable addresses. These go into my local DNS, but you could just as easily use that for DHCPd.

Not sure if this is what you were describing, but my dhcpd server is a separate machine to the router.

I’m just using an off the shelf ASUS router because it’s actually surprisingly good at the basics. But I wanted PXE booting so set up ISC dhcpd on a home server.

To be fair, it might actually be possible to do this on my ASUS router. I’ve not actually checked. I’ve had the same setup up for years. Easily more than a decade. Only updating hardware when necessary. So I might be missing a trick with these latest ASUS routers.

> Not sure if this is what you were describing, but my dhcpd server is a separate machine to the router.

That was not what I was describing. I was figuring that your DHCPv6 client (that talks to your ISP) and your DHCPd would be on the same machine, but maybe that's okay. How does your dhcpd server get its address? A DHCPv6 request to the router? If so, the following report might (might!) be useful to you:

So, while I DID find out about dhcp-eval(5), it doesn't look to me like ISC DHCPd will do what you want. I didn't see any parameters documented in the dhcpd.conf manual that looked like they were prefix-independent.

Probably your best bet is to template your dhcpd.conf and known_hosts files, then use your network manager's [0] "on address change" hooks to fill in the currently-assigned prefix, write out new files, and bounce dhcpcd.

[0] NB: NOT (neccessarily) NetworkManager (that nasty, wretched thing), but maybe like dhcpcd's run hooks.

> How does your dhcpd server get its address?

It’s hardcoded. For IPv4 it doesn’t need to be dynamic because NAT allows you to hardcode private address ranges. But that whole concept of networking doesn’t translate (no pun intended) to IPv6

This is the problem I’m running into with deploying IPv6. I don’t know what address ranges to allocate because the dhcp server doesn’t perform any handshakes with the ISP. And I’m a bit reluctant to rearchitect the network topology for IPv6 because everything already works really well without IPv6.

So ideally I’d want a way of sliding in IPv6 without having to break what’s already working.

Every solution I’ve explored thus far hasn’t achieved that. But there’s lots of good information shared here today so I’ll have another read and maybe they’ll offer up an insight I’d previously missed.

Oof.

Yeah, because you're gonna have to have a DHCPv6 client running on your router (and because your ISP is almost certainly using DHCPv6-PD the router is where you're pretty much going to have to first learn about your LAN-side DHCPv6 prefixes), it's probably going to be a bit tricky (but probably not impossible) to do what you want.

Best of luck. If you figure out how to do it within the HN comment freeze period (I think it's 14 days?), please do leave a follow-up comment. I'd be very interested in hearing what you come up with.

I have had success running a hybrid IPv4/6 network by reading this guide for inspiration:

https://blog.infected.systems/posts/2024-12-07-building-an-i...

This allows me to have a mixture of both protocols and even some boxes that have both IPv4 and IPv6 addresses. I still have some issues writing routing rules that does not fail for link-local addresses, but the network has now been fully operational for well over a month.

> If it’s for security then most of the actual security provided by NAT routing is actually just the routers firewall itself. So a good ipv6 firewall provides the same level of security.

Nitpicky, but I think this is not true. NAT's security is based on the router not knowing where to route the traffic and dropping it, where the firewall intentionally drops the traffic.

Agreed that it's functionally equivalent, though.

I think it is true... at least on Linux. I am pretty sure that if my firewall didn't have this line in the filter table

   -A INPUT -i wan-interface -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

along with this line in the nat table (or the equivalent with the SNAT target if you have a static WAN IP)

  -A POSTROUTING -o wan-interface -j MASQUERADE

then IPv4 NAT simply wouldn't work... well, not the NAT that nearly all regular folks have on their home networks.

It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0] But it's the decisions made in the firewall that both make the NAT work, and ensure that WAN traffic that hasn't been requested stays out.

[0] Unless the router were "excitingly" misconfigured!

> [0] Unless the router were "excitingly" misconfigured!

This is probably the pivotal difference lol. Most of the ISP-provided routers I've used either have a default-allow policy or auto-create firewall rules when you add a NAT forwarding rule. I don't honestly recall which because it's been like a decade, but I do remember that I didn't have to explicitly add a firewall rule.

The exciting misconfiguration I was thinking of was one where Internet hosts could send packets to the router with LAN IPs as the destination IP and the router would happily forward those along and output them on the LAN interface(s).

On a Linux router, perhaps setting ip_forward to 1 and leaving rp_filter at 0 would do the trick? It has been ages since I've had to play with rp_filter, so I can't remember exactly what its behavior is.

The second line is the only one you need for NAT to work. The first is irrelevant to forwarded traffic. If you have no other rules then a) NAT will be applied to your outbound connections, and b) you'll have no firewall for the network behind the router.

NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.

> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]

Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.

> NAT's security is based on the router not knowing where to route the traffic and dropping it

Nope, the router does know where to route the traffic for obvious reasons. At least for Linux if it's able to do NAT then it's ipso facto able to forward packets from one interface to another, and will do so unless explicitly told not to.

I get that I can do equivalent things with IPv6, but what are the _advantages_ of using IPv6 if I don't want/care about direct routing?