peter hessler @openbsd is a user on You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
peter hessler @openbsd @phessler

I just committed this to -current:

Back in the history of time, IPv4 had classes of addresses. This was widely acknowledged as a failure. At the same time IPv4 classes were declared a
failure, decided to add
them back because using a mac address for IP address configuration was easy.

Now that we have RFC7217 support we can remove this artificial limitation: allow non-/64 prefixes to be configured by SLAAC.

· Web · 10 · 10

1) Yes, if you have a very small subnet, then you won't have many addresses available for privacy, or collision-avoidance. Duh. You break it, you can keep both pieces.

2) If you have disabled opaque ids (aka, using the old mac-address method), *and* have a smaller than /64 subnet, then you'll only get a privacy address.

Many junkies will claim this is a violation of the specs.

1) Don't care.

2) Don't believe you.

3) the RFC you'll pull out to "prove" me wrong, merely suggests that you shouldn't. See #1.

@phessler which reminds me, someone should implement proper DAD avoidance in slaacd(8) for RFC 7217 and RFC 4941 addresses.

Currently slaacd(8) goes pfrrt, yeah, fine, whatever when a configured address never leaves tentative state. In fact slaacd(8) doesn't even check...

@florian yea, I was thinking about that.

I need to stop ignoring the 2 day tutorial I'm giving on Monday/Tuesday, but I can look at that hopefully soon.

@phessler maybe I'll beat you to it :)
I imagine this also requires some kernel dickery. I'd like to have a route message when DAD fails.

@florian that would be very helpful, and would probably be 90% of the effort

@phessler @horia and in all likelihood it will not in the future.

@florian @phessler I like the sound of "netcfgd". Is there any more info about it?

@horia @florian lots of discussions, but no real code yet.

basically, a daemon that will take the resolv.conf settings from dhclient and slaacd, combine them and install them to the actual file; instead of those two programs fighting over who "owns" the file.

@phessler @florian awesome idea. I was thinking last night about "resolv.conf.slaacd"

Maybe netcfg could update IP, hostname, domainname, and other network settings in every .conf too ;)

@phessler Is FreeBSD's resolvconf framework reusable here?

@feld haven't looked at it, do you have a url for it?

@phessler @florian @horia dhcpcd(8) may hook into resolv.conf as well.

In only networks, (stateless) DHCPv6 is the only way to configure DNS on right now.

@kn @horia @phessler yes yes, and so probably does the wide dhcpv6 client and the isc one.
They are not in base though. One thing at a time.

@phessler IIRC they were like "you must not give customers less than /56, and a subnet should be /64, but you're not allowed to hardwire it into your routers, as this is just policy, and we might change it"
Did they now change their mind and decide that it's ok to hardwire into routeres?

Anyway, I think we're in the middlebetween two dangers:
vendors hardcoding the /64 and /56 prefix lenghts - we end up in a class-ful nightmare
-ISPs providing less than /56, or even less than /64, per customer

@Wolf480pl @phessler I know RIPE has recommendations about end-user prefix size

@samis @phessler IIRC the RFCs also contain some recommendations about this. But ISPs can be incredibly cheap. UPC gives /57 to their DS-Lite customers, with a working prefix delegation, and I consider that generous. I've heard of some residential ISPs providing only one /64.

Also, VPS providers will give you /64 if you're lucky, otherwise /128. ( is a notable exception, giving each customer a /48).

@samis @Wolf480pl this has nothing to do with end-user prefix sizes, this is about what is actually assigned on the interface.

end-user prefixes aren't installed onto the interface, they're routed to the device.

@phessler @samis yes, but the cable modem needs to allocate a subnet from that prefix on each of its interfaces. If it has 2 interfaces (normal LAN/WiFi, and guest WiFi) it means it needs 2x/64, so the ISP can't get away with giving each customer a single /64. They need to give at least /63, but maybe they'll give /62 or /60. If they could assign a /120 to each of those interfaces, I don't think they would allocate to you anything bigger than /112.