Hacker News Reader

Hacker News

Comment by mfontani | Hacker News Reader

Full thread

mfontani

Unfortunately only a /64 per server :/

View on HN

Is that not enough? I was curious how many IPs that'd give you, and it is 2^64

Genuinely curious what you might need more for (for a single server).

It's about having multiple continuous ranges of addresses.

Think of it in IPv4 terms, it's like having the range 192.168.0.0 to 192.168.0.255 (192.168.0.0/24) assigned to your host. 256 addresses should be plenty of addresses, but you can't cleanly segment them into multiple ranges, like you could with 192.168.0.0/16: because you can have 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24.

By having multiple, complete blocks of /24, you can easily assign them to different classes of IP interfaces on your host.

Why not? Couldn't you just assign e.g. 192.168.0.0/26, 192.168.0.64/26, 192.168.0.128/26, 192.168.0.192/26?

Yes, you can, but there's a bit more mental math involved for a human looking at it, and more truthfully it's just less aesthetically pleasing.

Nothing in IPv6 says you have to stop dividing at the /64 level.

There has been some hardware that takes a bit of a performance hit when doing route lookups that are longer than /64 in the past, but if you're doing this all in software on an end host, that's not an issue.

Go ahead and divide up that /64 to smaller blocks for your classification purposes, you'll still have plenty.

> Nothing in IPv6 says you have to stop dividing at the /64 level.

but as you mentioned, there are a few roadblocks that say: you shouldn't

IPv6 SLAAC will not work on subnet smaller than a /64

I don't thing that is true.

The client obtains the network prefix from the RA, and then the client tries to generate unique host address.

"" The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. ""

https://datatracker.ietf.org/doc/html/rfc4862

Yes, all implementation that I'm aware of use EUI-64, which requires a /64

https://datatracker.ietf.org/doc/html/rfc7421 is helpful in understanding this.

Basically it explains that SLAAC RFC itself does not define the /64 limitation, but other RFCs that are relevant to network operation do.

""" The addressing architecture [RFC4291] [RFC7136] sets the IID length at 64 bits for all unicast addresses and therefore for all media supporting SLAAC. An immediate effect of fixing the IID length at 64 bits is, of course, that it fixes the subnet prefix length also at 64 bits, regardless of the aggregate prefix assigned to the site concerned, which in accordance with [RFC6177] should be /56 or shorter. """

You get one /64 per server. How often do you need to divide a range within a server and run SLAAC for one of these subdivisions?

You can actually request a /56 per-server for a one-time fee of, IIRC, 60 EUR or so. Just talk to support since it's not listed anywhere in their docs for some reason.

What would you do with all those addresses? Could you please elaborate about each one?

First thing I can think of is spam and abuse

Good luck sending emails with IPv6.

It works fine with Gmail. And since G Suite is so widely used, tons of domains can send/receive mail over IPv6 just fine.

Why should that be an issue?

Some mail-admins will downgrade IPv6-only MX servers reputation-wise, due to the limiting/cost-increasing factor of IPv4 Addresses.

I do it already. Well, both IPv4 and IPv6. There's a decent number of IPv6 capable MX's out there, the most prominent being GMail.

If you were meaning IPv6-only then yes that would be pretty bad.

If an IPv6 spam filter is working on a per-address basis, it's never going to work. The smallest allocation you can get from a RIR is a /48. Even residential ISPs give at least a /64. You could use a different address for every email and never run out.

A /56 + prefix delegation would enable IPv6 VMs without any dirty hacks.

... giving each VM one IP out of the /64 is not a "dirty hack". I guess if you want to do complex networks between the VMs it'd help a bit? Still, /64 is IMHO a good default for single machines.

Traffic for any of the addresses in the /64 arrives at your server’s "external" network interface. Is there any non-hacky way to forward this traffic to an internal virtual network?

You just create a route for it, same as you would with any size network. Linux allows you to create routes for IPv6 prefixes longer than /64 without any issue. On AWS I have a VM with a /80 routed to it, which I have divided into multiple /96's internally. It works fine.

Typically, a /64 in IPv6 is one subnet. You're not really supposed to subdivide networks beyond that point. The first 64 bits identify the network, the last 64 bits identify the host. Under this design, if you only assign a /64 per server, that would mean you couldn't have multiple networks on that VM (which you'd want for something like Docker.)

However, this principle isn't really enforced on a technical level. Only some standards such as SLAAC actually require the network to be a /64, and since SLAAC isn't really relevant for servers, most cloud providers have been relatively stingy with their IPv6 allocations - at least compared to what RFCs actually recommend. (Which would probably be a /48 per customer, per region.)

I appreciate the push to expand address allocations a bit, so that providers aren't charging a monthly fee for every /128 and the like. But /64 seems like ridiculous overkill. Even for a premises network connected to an ISP, the optimal thing to do is to continue NATting to hide information about your network. Privacy wise I'd rather have 2^16 separate /128's scattered throughout a provider's address space, than a single /64, which will inevitably be treated as a single address by the surveillance industry. Ultimately discrete public addresses are really only needed for services, and the services I want to share are few and enumerable. At this point I do more work making sure individual nodes aren't fully connected (eg Internet of Shit) than making services reachable.

> /64 seems like ridiculous overkill

The idea behind the /64 minimum was to make auto-configuration easier - you could just stick the layer 2 ID (i.e. the MAC address) in the second half and not have to worry about collisions or stateful assignment system like DHCP. Remember that IPv6 was designed in the mid-90's, so both of these decisions seem silly now - using the MAC would be a serious privacy issue (modern operating systems use a random ID which changes frequently) and DHCP is very mature.

Yeah I was going to touch upon that. I understand where they were coming from design wise (apenwarr's post is fantastic for that - https://apenwarr.ca/log/20170810). Privacy extensions mainly seems like doubling down on an unworkable idea. I can see the hypothetical benefit on a shared network, where say a coffee shop has a /64 and you can have every single app looking like a separate device on that network to an outside observer. I just foresee the inevitable future where IP surveillance databases contain information like "this /48 hands out /64 to each end user, so treat it as one entity", rendering those extra bits as a mere liability to be mitigated.

Sure, but as the ancestor comment mentions, SLAAC has no relevance for the use-cases people in this thread want more then 64-bits for (e.g. Docker sub-networks). Since your Docker containers don't have "MAC addresses", there's no reason that you need to use 64 bits specifically to configure them. Your container runtime is perfectly positioned to assign IP addresses and subnets however it chooses to. Assigning a /72 to each container is perfectly fine.

> "You're not really supposed to subdivide networks beyond that point."

Why not? Does it result in technical problems? I know very little about IPv6 (but I know that a /64 is an absurdly large network).

I know you are being funny. However, it does make me think hmmm... Is there any advantage/disadvantage to not handing out something like a /120? Or is there something else at play like in the way auto discovery is working? I am not familiar enough with it to say.

Yes, various pieces kind of assume that smaller networks than /64 are not a thing, e.g. SLAAC, one of the mechanisms to distribute IPs.

I have a /64 from my ISP and I want to run a few VLANs on my home network but I can't subdivide the /64 any further using my business class (TP-Link omada) router's controller. Maybe there are similar limitations in place here?

That's normal/standard for a whole LAN, and is more than enough for all of your VMs/containers on the box.

No, it's not enough because you end up needing Proxy NDP for your traffic to reach other subnets smaller than a /64 (e.g. a /80) if you have the /64 on your wan interface and carve it out. Normally, you'd have a /64 on your wan, then another /64 for your containers or multiple /64s for different container deployments or virtual machines. Then traffic would route properly between your networks with ipv6 forwarding enabled.

> is more than enough for all of your VMs/containers on the box

> you end up needing Proxy NDP for your traffic to reach other subnets smaller than a /64 (e.g. a /80) if you have the /64 on your wan interface and carve it out

It sounds like we are in full agreement.

If you're using proxy NDP then you don't have "more than enough" IP space for what you're doing. You have none and you're hacking up a workaround -- one that's inevitably going to have people coming away thinking "v6 is hard" rather than putting the blame where it deserves to be.

Reply on news.ycombinator.com