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
