IPv6 end user addressing

Owen DeLong owen at delong.com
Sat Aug 6 18:26:48 CDT 2011


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

> On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong <owen at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110806/7362b7e2/attachment.bin>


More information about the NANOG mailing list