Home page logo
/

nanog logo nanog mailing list archives

Re: IPv6 end user addressing
From: Mark Andrews <marka () isc org>
Date: Mon, 08 Aug 2011 08:58:51 +1000


In message <CAPWAtbJtPMDx-NzU8UphoSy+97ygo4Fknz5_eSghsjp-aN9x_A () mail gmail com>
, Jeff Wheeler writes:
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. =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 () 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 () isc org


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault