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