Hacker News Reader

Comment by j16sdiz | Hacker News Reader

No.

In IPv6, you can get an address using RA. DHCPv6 only if you want to smuggle some unrelated metadata as options (which, of course, not widely used outside enterprise). DHCPv6-PD are used only when you need a whole prefix.

If everybody implement all the specs out there, we will have two different DNS record type, 4 or 5 address allocation schemes, a handful of IPv6-over-IPv4 protocol, whole a lots of incomplete and incompatible IPv4-ovr-IPv6 protocol.... Etc... while telling everybody ipv6 is simple and ask why we haven't got there yet

View on HN

SLAAC is fine, until you somehow get a subnet smaller than /64 on your router, in which case SLAAC completely breaks. I understand why SLAAC has such a limitation, but this is what we get.

It's not optimal, but the upstream network provider does not budge, and now everything except Android devices get IPv6 address via DHCPv6.

Unicast IPv6 addresses are required to have a 64 bit interface identifier and a 64 bit network identifier (e.g. /64), handing out subnets lower than /64 is not spec compliant.

Network operators can do crazy things, but if you color outside the lines things may break.

AFAIK, it's not strictly true that unicast addresses are required to use a /64 network identifier.

It's common, almost necessary even, for environments with dynamic clients to use /64 subnets (precisely so that SLAAC works), but in a static environment it's perfectly fine to use prefixes larger than /64 (e.g. delegate a /80 to each individual host in a datacenter, for virtualization applications etc).

Hence, I'm wondering what the spec is you mention that is broken?

RFC 4291 section 2.5.1

and to your point, yeah you can step outside the spec and things can work in controlled environments, but "there be dragons" when your dealing with interoperability on a large scale (in this case Android expecting /64s per the RFC)

Who's out there being so crazily stingy? Allocating a subnet that small is making things more complicated for no benefit.

Someone should double check me, but I think PD less than a /64 also just breaks (and probably is against the spec).

A lot of the complaints I have seen in the last decade is from ISPs doing silly things and cutting their teeth on fresh IPv6 deployments. My ISP seems to have their collective ducks in a row now, and it has been rock solid for years.

I actually had a case recently where a misbehaving IPv4 IoT device consumed my entire DHCP pool. IPv6 devices kept chugging along without any problem.

It probably is. I remember that putting a /72 into OpenWRT's `ip6prefix` field actually breaks the whole network stack (including IPv4, the interface no longer has any address assigned to it).

I wonder if that's an artifact of configuration-generation scripts detonating before they ever get around to writing out any configuration, leaving the network interfaces entirely unconfigured.

There was a proposal for variable length SLAAC, but it went nowhere

https://datatracker.ietf.org/doc/html/draft-mishra-6man-vari...

I meant.... I love DHCPv6.

If only RA wasn't mandatory part of IPv6, I am all for DHCPv6.

It's the fault of early IPv6 designers with NIH syndrome created this mess.

Out of interest as I have found IPv6 RA to work flawlessly for my home network (alongside legacy IPv4 DHCP), what advantage (if any) is there in deploying DHCPv6 within the home LAN? Or were you meaning to say DHCPv6 is great for certain (enterprise?) use cases?

When I was experimenting with IPv6 on my lan, router advertisements indeed worked great!

But the big loss was that I had no control to reserve a particular IPv6 address for a particular MAC address inside the DHCP server, or assign DNS names automatically, etc. since it's basically 1 way - device receives a RA then configures itself with a random address.

You could give the device a static address and let duplicate address detection do it’s thing

And also really optimistic that client-client connections are allowed to perform the auto-configuration.

Probably true in a home network, probably not at the office. I hope not at the office.

Reply on news.ycombinator.com