Hacker News Reader

Comment by pilif | Hacker News Reader

One of the features of IPv6 is address autoconfiguration, obviating the need for a central authority like DHCP on v4.

However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.

But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.

If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)

View on HN

I don't understand why getting rid of DHCP is desirable. DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!). Checking "Does my interface have an IP address?" is also a really really useful and quick analogue for "is the gear related to the LAN pretty much working or is something broken/misconfigured?".

As it is, all my interfaces just have these random IPv6 addresses configured which don't work most of the time. I don't get it.

FWIW; SLAAC works by setting the local part to the mac address.

So, if you have knowledge of your mac address (which is what you say you are using for DHCP) then you will know the fe80::<> IPv6 IP too, which, while not globally routable is probably what you want based on this comment.

Wait SLAACs aren't globally routable? I thought the whole idea behind IPv6 was to not use NAT?

There's an education here that unfortunately I don't have the time to give you.

SLAAC is the replacement for DHCP, it provides a local prefix address (fe80::) and optionally (and, crucially: additionally) provides a publicly routable IP if there's a public prefix available.

You can think of the subject being split into two components:

As a base: You will get a local IP

On top: you get DNS/Public routing.

Here's a bit more about how it works: https://www.networkacademy.io/ccna/ipv6/stateless-address-au...

> Wait SLAACs aren't globally routable?

It is not the host-component of IPv6 that determines routability, it is the prefix.

If you have a link-local prefix (fe80::/10) then it is not global, if it is a private prefix (fc00::/7) then it also may not be global; if it is part of IANA's unicast allocation (2000::/3) it is global (firewall permitting).

> I don't understand why getting rid of DHCP is desirable.

It's less infrastructure to run, especially with embedded networks.

> DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!).

You are limiting your thinking to macro-scale 'user-managed' devices, as opposed to things like embedded things:

* https://en.wikipedia.org/wiki/Matter_(standard)

I still haven't figured out how to get these auto-configured addresses into my home network's DNS (or any DNS, for that matter).

It is pretty easy on OPNsense but it's virtually impossible on many other types of routers. Meraki and Asus as two examples of that.

I'm actually running dnsmasq from a FreeBSD host. How would dnsmasq know about the self-configured addresses? I guess I could run DHCPv6, but it's next to impossible to get any kind of prefix delegation going with my ISP anyway. At the moment their router hands out the v6 addresses and I use v4 for dnsmasq.

> However, that only works with a /64 prefix

Well it should be redesigned so it works all the way down to individual addresses.

You can use DHCPv6 instead of SLAAC if you need autoconfiguration on sub-/64 prefixes.

Some systems like android don't support anything but SLAAC

IMHO it means that they are not fully IPv6 compliant. Corporate networks often have DHCPv6 rather than just SLAAC.

They are fully compliant, SLAAC is part of the standard whereas DHCPv6 is an optional extra.

DHCPv6 also does not work without RA. DHCPv6 just assigns an address, a routable prefix, dns servers etc, it does not assign a subnet or any routes, you need route advertisements for that.

Seen like this, you can also argue that DHCP is an optional extra for IPv4, but it almost essential in most networks. Sure, IPv4 has no SLAAC that can be a valid alternative, but still, given that SLAAC doesn't solve every use case...

> Well it should be redesigned so it works all the way down to individual addresses.

Why? What's wrong with how it works at the moment?

I actually have the issue where my ISP gives me a single /64 and it makes it difficult to split between multiple LANs.

Published guidance says they're meant to give out at least a /56. I don't know that making autoallocation work on smaller subnets would help with this problem - ISPs that currently give out the smallest possible subnet would probably just switch to whatever the new smallest possible subnet was.

There probably is a way to ask my ISP for a larger block, but I think it would be nice to be able to subnet a /64 regardless.

CIDR and the resulting address space fragmentation was the problem that IPv6 was originally meant to solve; allowing splitting into random-sized subnets makes routing more complex and worse. And if you made the routable part of an IPv6 address longer than 64 bits then that makes the routing much more compute-intensive. 64 bits in the local part of the address is sort of overkill, but a 128 bit address isn't really any harder to use than a 96 bit address, and it means things like, well, being able to automatically assign the local part based on the MAC address, which only works if the local part of the address is more than 48 bits.

You can still use a shorter hash of the Mac address.

Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

> Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

You can do that, sure. But it's more complex and slower.

It would rather be an ICMPv6 neighbor discovery packet or something like that, IPv6 doesn't use ARP.

Collisions are just as likely with the 48 bits as they are with the last 24 bits, as some OUI vendors reuse mac addresses.

Using a mac address in the IP is terrible anyway from a privacy point of view, use a random IP in the subnet, send out a check to see if it's already used, if it is choose a new one. That check is already a feature of ipv6.

On Comcast Business the SLAAC would hand out a /64, and DHCPv6 would give you a /64 unless you requested "Prefix Delegation" in which case they'd give you a /56, /58 or /60 depending on how large your static IPv4 allocation was.

Some do give you one but in the most incorrect way possible. When I had fibre through Orange France, they properly allocated a /56 to my connection, but the ISP provided router only routed the first /64 from the block. The UI even proudly displayed the full /56 in all of its glory followed by a "xx/64 usable".

Oh and I ended up disabling IPv6 altogether as their router would crap itself with a modest amount of IPv6 traffic. Pulling ~10Mbps of IPv6 would completely DoS the router, as it would not even go as far as answering to ARP. Some quality hardware for sure.

What do you mean by that? What you do inside your assigned range is completely up to you - you can split that up as you want.

Not if you want SLAAC to work in each LAN. Basically in IPv6 each LAN is supposed to have a /64, that's the real minimum allocation by design. Per the official recommendations, ISPs are supposed to give every individual customer at a minimum a /56.

Ah, right. That leaves a custom dhcpv6 pools config for you...

This is the same as if you get a /24 from your ISP, but the ISP has the .1 address on their router. In this case, you can't (easily) subnet the v4 range either, since the ISP router expects to be able to arp for all the 254 ips, meaning you have to resort to trickery in order to make subnetting almost work.

Same goes for ipv6. If you get one single net (and a 'small' one at that), you once again have to resort to trickery to subnet at your end.

Preferably in both cases, you would get a small (/31 for v4, /127 for v6) transport net that goes to the ISP router or your first fw device, then the ISP routes the real net /24 (or whatever size you can get from it on v6) behind your IP on the /31,/127 so that your first device can split this in any way you prefer.

Shitty ISPs will always give you as little as they can get away with. If the software enforces /64, they'll you /64. Raise the limit to /128 and they'll give you /128.

At least with the current state of affairs, you have the option to use ND Proxy instead of NAT66.

Doesn't AWS currently hand out /128?

If you create a v6 VPC you can choose /44-/60. Subnets can be between /44-/64.

There was a proposal for that: https://www.ietf.org/archive/id/draft-mishra-6man-variable-s...

But they aren't all /48s. Upthread there's a post about /16s already being allocated.

Reply on news.ycombinator.com