IPv6 Addressing Help

Sat Aug 15 00:15:16 UTC 2009

On 15/08/2009, at 1:03 AM, Chris Gotstein wrote:

> We are a small ISP that is in the process of setting up IPv6 on our  
> network.  We already have the ARIN allocation and i have a couple  
> routers and servers running dual stack.  Wondering if someone out  
> there would be willing to give me a few pointers on setting up my  
> addressing scheme?  I've been mulling over how to do it, and i think  
> i'm making it more complicated than it needs to be.  You can hit me  
> offlist if you wish to help.  Thanks.

I have some things to say on this. I've padded some of the following  
with zeros to make it easier to read/understand.

Let's say your allocation is 2001:db8::/32 (doc prefix)

2001:db8::/32
2001:db8::/48 - ISP use
  2001:db8::/64 - ISP internal routers
   2001:db8::/112 - 65K loopbacks for your routers
   2001:db8::0001:0/112
    .. through ..
   2001:db8::ffff:ffff:ffff:0/112 - 281 trillion link nets between  
your routers
   2001:db8:0000:0001::/64
    .. through ..
   2001:db8:0000:ffff::/64 - 65K-1 /64s for ISP servers, offices, etc.  
etc.
2001:db8:0001::/48
  .. through ..
2001:db8:000f::/48 - 9M Customer link nets
2001:db8:0010::/48
  .. through ..
2001:db8:ffff::/48 - Assigned to customers

Some notes:
1) The "Customer link nets" block should be long enough for you to get  
one link net per customer tail. You should do /64s for link nets to  
customers, unless you are *certain* that *all* customer devices will  
support whatever else you choose to use. The 15 I have suggested here  
gives you ~9M.
2) The "Assigned to customers" block can be chopped up in to /48s or / 
56s or /60s or whatever your want. I recommend chopping customer  
prefixes on 4-bit boundaries (4 bits per hex digit). Less IP math in  
your head = easier life. Especially for helpdesk staff, and customers  
themselves.
3) Filter the "ISP internal routers" prefix at your border. This is  
equivalent to your /30s, /31s and /32s in IPv4 land.
4) The reason we have the loopbacks in the very first /112, is you  
will have to type them a lot, and fudging them can make your network  
melt down.
5) The reason we have the ISP internal /64s in the first /64s, is for  
the same reason as (4).
6) The reason we have ISP servers etc. in the following /64s, is these  
are also short to type, which means customers and first line support  
can type your DNS server addresses easily, read them over the phone,  
etc.
7) Allow the first /48 through all your filters that normally impact  
customers - and rate shaping, etc. etc. This first /48 is for ISP  
stuff, no customers should ever be on it. This is the only place where  
ISP stuff should ever live.

You will have a temptation to chop your customer address space up in  
to "City", "POP", etc. I recommend resisting that - you are  
reinventing classful addressing, and when one POP or city grows too  
large, you have to make exceptions to your rules.
Instead, when you need new addresses in an area (ie. you need more  
than zero IPv6 addresses at a POP) assign it a /48. Then when you need  
more, assign it another /48.
You can do this intelligently, using the binary chop/sparse allocation  
method that Geoff Huston has written about. This lets you grow your / 
48s in to /47s, or /46s as need arises.
By doing your assignment this way, you don't get tied in to silly  
rules, nor do you get IGP bloat.
I have an extensible IP management tool that I've been hacking on  
heaps in the last week that does this stuff for you. It should be  
ready for people to tinker with in the next few weeks.

--
Nathan Ward

--
Nathan Ward