In IPv6 the smallest 'subnet' is /64 if I recall correctly.

It's weird having a subnet size equal to a complete IPv4 Internet worth of IPv6 Internets but I believe the rationale was that you would never in practise run of out IPs in your subnet. A lot of Enterprise IPv4 headaches are managing subnets that are not correctly sized (organic growth, etc.). IPv6 is always routable for the same reason (companies reusing RFC1918 making connecting networks a pain).

There are different headaches with IPv6 - such as re-IPing devices if they move subnet - i.e. move physical location, or during a failover etc.

I'm not sure what the best practise there is as many enterprises don't use IPv6 internally. In my experience anyway.

▲

quietsegfault 17 hours ago | parent [-]

The big issue I see is every enterprise has a solid numbering plan for RFC1918 networks. Unfortunately, many of them have the SAME plan, and when peering networking between SaaS vendors and customers was more popular (now, of course, privatelink seems to be the move) we constantly ran into conflicts. There's still the risk of conflict with IPv6, but I think if numbering decisions are made thoughtfully, they can be avoided.

	▲	Dagger2 15 hours ago \| parent [-]
		There's no risk at all if you're using your own allocated prefix, because those are managed by IANA/RIRs/LIRs to not overlap. Incidentally, if you find yourself experiencing an RFC1918 clash, one simple way of fixing it is to use NAT64 to map the remote side's RFC1918 into a /96 from your v6 allocation. You can write the last 32 bits of a v6 address in v4 format, so this leads to addresses like 2001:db8:abc:6401::192.168.0.10 and 2001:db8:abc:6402::192.168.0.10, which don't overlap from your perspective. (If you wanted something simpler to type you could put them at e.g. fd01::192.168.0.10... but then you do start running the risk of collisions with other people who also thought they could just use a simple ULA prefix.)