> veering slightly from the topic (typical setup for a server host would > not be to use DHCPv6 but just statically route another block - usually a > /56 or /48), but...
I don't doubt this is typical for serious network operators. But I would counter that for every user who is in a position to request a statically-routed /48 there are dozens if not hundreds of us who have one /64 at home and another /64 on each of our VPSes. > (to request a prefix be routed to you, you need a DHCPv6-PD client, > not a server) Oops, correct. I was thinking "DHCPv6 daemon" when I typed it. The point is that configuring all those subnets and static routes is an awful lot of extra work when all I want to do is set up a VPN proxy. > why when people are looking for dhcpv6 software do they always find that > unmaintained-for-years run-the-whole-lot-as-root wide-dhcp6 thing? > > use dhcpcd if you want a client that can do DHCPv6. the most recent release > was a couple of months ago, it's sensibly written, uses pledge where possible, > and has decent privilege separation for the parts which can't pledge). Noted. I'm betting the reason people keep finding wide-dhcpv6 is that it is the only result for "pkg_info -Q dhcpv6". I used to search package descriptions at https://openports.se but that site is now defunct. It would be great if pkg_info could search descriptions as well as names, but so far none of the ideas that I think would be great hold much appeal to anyone else. > picking one other bit.. > >> I would also suggest comparing the "hackiness" of NDP proxying to the >> hackiness of NAT, which is how we solve this same problem in IPv4. > > it might be how some people solve it for v4. others solve it in a non-hacky > way which is exactly the same as the non-hacky way for v6; put the vpn clients > on a different subnet that's routed to the vpn gateway. I would note here that "some people" includes the OpenBSD FAQ. See: https://www.openbsd.org/faq/faq17.html#clientikev2 In any event, most of us can't readily get extra publically-routable IPv4 subnets. According to Google a /24 costs about $9000 right now. I could make do with a /28 since I only really want to connect three servers at a time, but how do I get the /28 routed to my server? Either I track down an ISP that provides these directly or else I have to set up BGP. All this to connect my laptop to a VPN proxy server! Most people use NAT for IPv4 because that's all most people can afford. Maybe I'm missing something here. Why is NDP proxying considered so distasteful? Can it cause technical problems down the road? I can see how cycling the client through temporary addresses gets complicated and has a lot of moving parts, but NDP proxying involves making a change to the routing table (which iked already has to do whenever VPN clients connect and disconnect) and its only effect (as I understand it) is announcing to nodes on the local link that the VPN tunnel host is a suitable destination for the address in question. Consider the laptop-connecting-to-home-VPN-from-coffee-shop use case. Suppose my home network is a /56 and I allocate a /64 for address assignments to VPN clients like that laptop. Now: how do I make sure that traffic on my local network which is destined for the laptop actually gets sent to the laptop? Am I supposed to configure static routes on all of the nodes on my home network that the laptop might want to communicate with? That doesn't sound right. I'm guessing the right way to advertise an entire subnet is with router advertisement messages, so I would want to configure rad to support this. But that's still a whole other thing to configure. So instead of using neighbor advertisements to direct two or three addresses at a time to the VPN proxy host, I'm using router advertisements to direct a whole subnet to it---which seems reasonable if I could justify the hassle of getting that whole subnet configured and advertised properly, but again, that's a *lot* of trouble. I recognize that there are other ways to get my individual use case to work without requesting changes to iked. If I don't expect to have more than 16 simultaneous connections, I could constrain iked to allocate addresses from a /124 subnet and add those 16 addresses to the NDP proxy list at server startup to get the equivalent of static routing while still not having to reconfigure the ISP's (or hypervisor's) router. But I would consider *that* to be hackier, because now I really am using NDP to advertise a subnet instead of just advertising the addresses that are actually in use. The other option I have on the table is a shell script that runs as a daemon with root privileges, monitors /var/log/daemon for IKEv2 connection and disconnection events, and runs ndp -s and ndp -d appropriately. But if you thought wide-dhcpv6 was bad for not being privilege separated, you'd hate my shell script. And I would too! That's the point. This is something iked could do automatically. I'm still trying to understand why everyone's take on this is that I need more subnets. It would be one thing if NDP proxying wasn't already supported in OpenBSD. But this functionality is already there. It solves the problem perfectly. And it makes it possible to set up an IPv6 proxy VPN after configuring and enabling only one additional daemon (iked) on both the client and the server---no dhcpv6, no rad, and no static routes provided by the ISP. You can just drop it on any random OpenBSD host and you're good to go---it's as easy to set up as SSH! The only thing making it difficult is the manual configuration of NDP proxying. Suppose a lot of people start asking questions about how to best to extend the "road warrior" proxy concept to IPv6. Now the question is "frequently asked" and the time comes to update the FAQ I linked to earlier. What should OpenBSD's official advice be to people who want to set up an IPv6 VPN proxy? Is the official advice going to be, "For IPv6, you should either use NAT like with IPv4 or you should get a statically-routed /56 subnet and start installing static routes all through your network"? Or should it instead be: "For small networks, you can set up a VPN using iked.conf alone"? It really seems like the latter approach makes more sense. What am I missing? Why is going out and getting a larger subnet from my ISP a better way to connect a laptop to my VPN than just proxying the neighbor solicitations? Thanks, Anthony Coulter
