Reply to post: Re: "What's wrong with a /64 prefix?"

We are absolutely, definitively, completely and utterly out of IPv4 addresses, warns RIPE


Re: "What's wrong with a /64 prefix?"

Yes, the default behaviour using SLAAC is to use the MAC address (plus 16 other bits) to form the Host address, but there are privacy concerns with that, a device can be tracked across networks that way. However SLAAC isn't the only way to issue IPv6 addresses, and not all of them are tied to a 64 bit host address. So the argument against giving a /64 to a standard ISP connection of "but you can't do a none standard network partition without also using a none standard IP address assignment scheme" strikes me as poor. Most users are not going to subnet their network, and frankly those that are probably don't want to advertise their unique device identifiers to the internet. If for some reason you absolutely cannot have a shorter than 64 bit host address, and you need to subnet your network, you can subnet on link local addresses, and do some form of NAT (Oh I know, NAT is evil, but it is a possibility).

Also a /64 for a single connection is still, even if I accept that subnetting becomes impossible on that network, significantly better than what most of us find ourselves with on IPv4, a single IP address, and NAT, and in some cases that single IP address is non-routable as the connection is behind CGNAT.

PS: Yes I do know that IPv6 specifies giving multiple IP addresses to individual network interfaces, such that a laptop could have many IPv6 addresses, some for WiFi, some for cabled ethernet, some for Bluetooth, etc, even if you do take your /64 and sub split into 4 billion /96 subnets, using for example DHCPv6, each of those has 4 billion addresses going spare.

So I ask again, what are you planning to do that a /64 is insufficient for your needs?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon


Biting the hand that feeds IT © 1998–2020