Home page logo
/

nanog logo nanog mailing list archives

Re: IPv6 end user addressing
From: Owen DeLong <owen () delong com>
Date: Sat, 6 Aug 2011 16:26:48 -0700


On Aug 6, 2011, at 1:14 PM, Jeff Wheeler wrote:

On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong <owen () delong com> wrote:
On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
Note that in this thread, you advocate three things that are a little
tough to make work together:
* hierarchical addressing plan / routing
* nibble-aligned addressing plan
* minimum /48 per customer

Hasn't been hard so far.

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.

Perhaps you also wouldn't use one allocation on the tunnel broker
gateway for /64s and another, a /37 in the case of Ashburn for
example, for users who self-provision a /48 from it.  Also, of course,
your default assignment plan is /64, not /48, even though there are
typically around, what, 10k tunnels active network-wide?


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.

To be clear, you don't do any of the three things you advocate above
where Hurricane Electric's tunnel broker service is concerned.


Yes we do.

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

We will be implementing a nibble-aligned addressing plan as soon as
we can get enough space from the RIR. That's pending implementation
of 2011-3.

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.

I think we were talking about access customers. I don't see giving /48s
to individual dedicated servers as I don't see them having hierarchy
behind them. I would think that a /48 per TOR switch would be
reasonable in that case.

I wish there was more discussion about IPv6 addressing plans in
hosting environments on this list.  I think that, rarely, customers
will decide to tunnel from their home or office to their "dedicated
server," co-lo rack, etc.  My addressing policies provide for this
type of customer to receive a /56 upon request without breaking my
hierarchical addressing scheme.  If they need more than that, the
layer-3 aggregator has to inject an additional route into the POP
area.  If a whole bunch of customers on one aggregator ask for /56,
then the aggregator needs an extra /48 (which might really mean
growing its existing /48 to a shorter route.)


Sounds like a mess. We'll stick with /48s for people that need more
than a /64.

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.

density, even in 20 years. I realize that customer density in
urban areas does tend to increase, but, assuming a maximum
50% market penetration, serving a city the size of Philadelphia
out of a single POP still seems unlikely to me.

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?

Owen

Attachment: smime.p7s
Description:


  By Date           By Thread  

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