Hacker News Reader

Hacker News

Comment by londons_explore | Hacker News Reader

Parent Full thread

londons_explore

> However, that only works with a /64 prefix

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

View on HN

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...

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

> 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.

Reply on news.ycombinator.com