Re: ipv6 book recommendations?

[Owen DeLong <owen () delong com>]

On Jun 5, 2012, at 2:23 PM, William Herrin wrote:

> On 6/5/12, David Hubbard <dhubbard () dino hostasaurus com> wrote:
> > Does anyone have suggestions on good books to really get
> > a thorough understanding of v6, subnetting, security practices,
> > etc.  Or a few books.  Just turned up dual stack with our
> > peers and a test network but I'd like to be a lot more
> > comfortable with it before looking at our customer network.
>
> Hi David,
>
> Instead of going the book route, I'd suggest getting some tunneled
> addresses from he.net and then working through
> http://ipv6.he.net/certification/ .
>
> They have the basics pretty well covered, it's interactive and it's free.
>
>
> Some additional thoughts:
>
> 1. Anybody who tells you that there are security best practices for
> IPv6 is full of it. It simply hasn't seen enough use in the
> environment to which we're now deploying it and rudimentary
> technologies widely used in IPv4 (e.g. NAT/PAT to private address
> space) haven't yet made their transition.

Not quite.

I will say that the security BCPs are not mature and are evolving,
but that does not mean that they do not yet exist.

> 2. Subnetting in v6 in a nutshell:
>
> a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC)
> only works for /64.
>
> b. Delegations on 4-bit boundaries for reverse-DNS convenience.
>
> c. If it's a point to point, a reasonable practice seems to be a /64
> per network area and around /124 per link. Works OK for ethernet point
> to points too.

/64 is perfectly reasonable per point to point as well.

> d. Default customer assignments should be /56 or /48 depending on who
> you ask. /48 was the IETF's original plan. Few of your customers
> appear to use tens of LANS, let alone thousands. Maybe that will
> change but the motivations driving such a thing seem a bit pie in the
> sky. /56 let's the customer implement more than one LAN (e.g. wired
> and wireless) but burns through your address space much more slowly.
> /60 would do that too but nobody seems to be using it. /64 allows only
> one LAN, so avoid it.

Planning your IPv6 deployment based on today's network needs is
folly. Deploying /48s will help future-proof your network and pave the way
for some very interesting innovations in the home networking space.

> e. "sparse allocation" if you feel like it. The jury is still out on
> whether this is a good idea. Basically, instead of assigning address
> blocks linearly, you divide your largest free space in half and stick
> the new assignment right in the middle. Good news: if the assignment
> later needs to grow your can probably just change the subnet mask,
> keeping the number of entries in the routing table the same. Bad news:
> fragments the heck out of your address space so when you actually need
> a large address block for something, you don't have it.

Since you should be doing this mostly at the 4-12 bits to the right of your
base allocation and the policy is structured such that you should, in most
cases, be able to assign same-sized chunks everywhere at this level,
that really shouldn't be an issue.

Lower in the hierarchy, it's a judgement call on which optimization fits
better on a case-by-case basis.

Generally, the higher up the hierarchy, the more likely that allocation by
bisection (there are other forms of sparse allocation as well) is ideal.

In some cases, sparse allocation by reservation, for example, can reduce
fragmentation while still providing substantial room for likely growth.

> Trying to keep non-dynamic assignments in local or regional aggregable
> blocks works about as well as it did in IPv4, which is to say poorly.

If you apply for a large enough IPv6 block, this should be less of an issue.
That was hard to do under previous policy regimes, but the current ISP
allocation policy should make it pretty easy to optimize for this.

Certainly, if you have suggestions for how policy can better support
this, I am open to improvements at any time.

Owen