Waste will kill ipv6 too

Lyndon Nerenberg lyndon at orthanc.ca
Thu Dec 28 22:50:54 UTC 2017


> On Dec 28, 2017, at 2:31 PM, Thomas Bellman <bellman at nsc.liu.se> wrote:
> 
> My problem with the IPv6 addressing scheme is not the waste of 64 bits
> for the interface identifier, but the lack of bits for the subnet id.
> 16 bits (as you normally get a /48) is not much for a semi-large organi-
> zation, and will force many to have a dense address plan, handing out
> just one or a few subnets at a time, resulting in a patch-work of
> allocations.  24 bits for subnet id would be more usable.

If you need (and can justify) more than a site /48, you can easily get that.  

> 
> Consider e.g. a university or company campus.  There are probably at
> least 16 departments, so I would like to use 8 bits as department id.
> Several departments are likely to have offices on more than one floor,
> or in more than one building, so I would like to let them have 4 bits
> to specify location, and then 8 bits to specify office/workplace within
> each location.  And allow them to hand out 16 subnets per workplace.
> That adds up to 24 bits.  So a /40 would be nice, not a /48.

IPv6 prefixes are not databases.  Coding this sort of thing into your address space is silly.  You can (and should) track this info externally.  It's pretty simple to do this using easily parsable text files.

If you encode policy into your address space like this, sooner or later you will find yourself painted into a corner you can't get out of.  Instead, carve up the 16bits of subnet space by allocating network bits from left-to-right.  This gives you the ability to slice your subnet space into variable-length allocations.  When you allocate in the subnet space, do so by bisecting the current network prefix.  That gives you room to grow your /64s into something larger, while keeping the routing simple.  

This is the same thing we've been doing to carve up IPv4 space for years: number hosts right to left, number networks left to right.  For IPv6, just s;hosts;/64s;.

--lyndon


More information about the NANOG mailing list