IPv6 end user addressing

Sun Aug 7 22:58:51 UTC 2011

In message <CAPWAtbJtPMDx-NzU8UphoSy+97ygo4Fknz5_eSghsjp-aN9x_A at mail.gmail.com>
, Jeff Wheeler writes:
> On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen at delong.com> wrote:
> >> Well, you aren't actually doing this on your network today. =A0If 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.

So you want HE to force all their clients to renumber.

> > 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.

The client can request a /48 or /64 as the initial allocation.

> > 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. =A0This 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.
> 
> --=20
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator=A0 /=A0 Innovative Network Concepts
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org