Home page logo

nanog logo nanog mailing list archives

Re: IPv6 end user addressing
From: Owen DeLong <owen () delong com>
Date: Sat, 6 Aug 2011 09:48:55 -0700

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

On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton <dougb () 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

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,

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.


Attachment: smime.p7s

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]