Re: IPv6 end user addressing

[Jeff Wheeler <jsw () inconcepts biz>]

On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen () delong com> wrote:
> > Well, you aren't actually doing this on your network today.  If you
> > practiced what you are preaching, you would not be carrying aggregate
> > routes to your tunnel broker gateways across your whole backbone.
>
> Yes we would.

No, if you actually had a hierarchical addressing scheme, you would
issue tunnel broker customer /64s from the same aggregate prefix that
is used for their /48s.  You'd then summarize at your ABRs so the
entire POP need only inject one route for customer addressing into the
backbone.  Of course, this is not what you do today, and not because
of limited RIR allocation policies -- but because you simply did not
design your network with such route aggregation in mind.

> Those are artifacts of a small allocation (/32) from a prior RIR policy.
> The fact that those things haven't worked out so well for us was one of
> the motivations behind developing policy 2011-3.

There was nothing stopping you from using one /48 out of the /37s you
use to issue customer /48 networks for issuing the default /64 blocks
your tunnel broker hands out.

> We give a minimum /48 per customer with the small exception that
> customers who only want one subnet get a /64.

You assign a /64 by default.  Yes, customers can click a button and
get themselves a /48 instantly, but let's tell the truth when talking
about your current defaults -- customers are assigned a /64, not a
/48.

> We do have a hierarchical addressing plan. I said nothing about routing,
> but, we certainly could implement hierarchical routing if we arrived at a
> point where it was advantageous because we have designed for it.

How have you designed for it?  You already missed easy opportunities
to inject fewer routes into your backbone, simply by using different
aggregate prefixes for customer /64s vs /48s.

> > > However, requesting more than a /32 is perfectly reasonable. In
> > > the ARIN region, policy 2011-3.
> >
> > My read of that policy, and please correct me if I misunderstand, is
> > that it recognizes only a two-level hierarchy.  This would mean that
> > an ISP could use some bits to represent a geographic region, a POP, or
> > an aggregation router / address pool, but it does not grant them
> > justification to reserve bits for all these purposes.
>
> While that's theoretically true, the combination of 25% minfree ,
> nibble boundaries, and equal sized allocations for all POPs based
> on your largest one allows for that in practical terms in most
> circumstances.

I don't think it does allow for that.  I think it requires you to have
at least one "POP prefix" 75% full before you can get any additional
space from the RIR, where 75% full means routed to customers, not
reserved for aggregation router pools.  This is not a hierarchy, it is
simply a scheme to permit ISPs to bank on having at least one level of
summarization in their addressing and routing scheme.

2011-3 does not provide for an additional level to summarize on the
aggregation routers themselves.  It should, but my read is that the
authors have a very different opinion about what "hierarchical"
addressing means than I do.  It should provide for route aggregation
on both the ABR and the aggregation router itself.

> > AT&T serves some entire states out of a single POP, as far as layer-3
> > termination is concerned.
>
> Are any of the states with populations larger than Philadelphia among
> them?

Yes, for example, Indiana.  Pretty much every state in the former
Ameritech service territory.

-- 
Jeff S Wheeler <jsw () inconcepts biz>
Sr Network Operator  /  Innovative Network Concepts