IPv6 end user addressing

Sat Aug 6 16:48:55 UTC 2011

On Aug 6, 2011, at 3:40 AM, Mukom Akong Tamon wrote:

> On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton <dougb at dougbarton.us> wrote:
>> For example, if you reserve a /48 per customer but actually use the
>> first /56 out of it, you are safe if _you_ need the other /56 for some
>> reason, or if the customer needs to expand into the full /48.
> 
> +1. Be generous in planning and then assign what makes operational
> sense. Be sure to make sure that as you dole out smaller than blocks
> to customers that requested from your RIR, you preserve your ability
> to give a client a second block from the same aggregatable range.
> 

The way to address this better is to use allocation by bisection to your
customers rather than giving them /56s.

If you give a site a /48, it is very unlikely they will ever need an additional
prefix for that site. Of course if you're talking about a customer that is
using a single connection to you to feed multiple sites, that's a different
issue and will require additional planning.

For anyone that already understands allocation by bisection, you can
skip the rest of this message.

What I mean by allocation by bisection is simply issuing prefixes such
that each issued prefix has the largest possible contiguous aligned
space available for expansion. Let's assume 2001:db8::/32 as our
starting point and that we are assigning /48s to 50 end sites from it.
(I'm skipping the whole hierarchy to fit inside a /32 and keep the example
simple).

We'd assign 2001:db8::/48 for our own infrastructure and support machines.
The first customer would get 2001:db8:8000::/48.
The next customer would get 2001:db8:4000::/48, then 2001:db8:c000::/48.
In the next round, we'd assign 2001:db8:2000::/48, 2001:db8:6000::/48,
	2001:db8:a000::/48 and 2001:db8:e000::/48
This would be followed by …1000::/48, …3000::/48, …5000::/48, …7000::/48,
	…9000::/48, …b000::/48, …d000::/48, and …f000::/48.

At this point, we've assigned 15 customers, and each of them could be
expanded from /48 to /36 without invading any of our existing assignments.

Continuing, we would assign the next 16 customers as:

	2001:db8:0800::/48, 2001:db8:1800::/48, 2001:db8:2800::/48,
	2001:db8:3800::/48, 2001:db8:4800::/48, 2001:db8:5800::/48,
	2001:db8:6800::/48, 2001:db8:7800::/48, 2001:db8:8800::/48,
	2001:db8:9800::/48, 2001:db8:a800::/48, 2001:db8:b800::/48,
	2001:db8:c800::/48, 2001:db8:d800::/48, 2001:dbu:e800::/48,
	2001:db8:f800::/48

That brings us to 31 customers all of whom have room to expand
their /48 up to a /37 (though I wouldn't recommend doing /37s
as they are not nibble-aligned, so, outside of exceptional circumstances,
you would be unlikely to expand in place beyond /40 at this point.)

The next 32 customers would fill in the 2001:db8:?400::/48 ranges
and the 2001:db8:?c00::/48 ranges. This limits those customers
now to /38s.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110806/fefa030c/attachment.bin>