[ppml] Policy Proposal 2005-1: Provider-independent IPv6
Stephen Sprunk
stephen at sprunk.org
Thu Apr 27 04:49:11 EDT 2006
Thus spake "Jason Schiller (schiller at uu.net)" <jason.schiller at mci.com>
> On Thu, 27 Apr 2006, Christopher Morrow wrote:
>> I think I agree with Aaron here, they just won't ever come back...
>> there are legacy /24's assigned that no one can recover today. there
>> will be 'legacy' /48's (or 44's or whatever the decision on size is)
>> assigned tomorrow and never recovered.
>
> The routes in the Internet routing table will likely be more specific than
> a /48 assuming people want to slice and dice their aggregate to do
> traffic engineering... I haven't done a study to see how many slices
> people typically need.
It's interesting to note that, according to the Weekly Routing Table Report,
roughly half of all routes in the v4 DFZ are longer than the RIR maxima.
This implies that there is no real problem in the v4 world with
deaggregation even at the level of 180k routes -- otherwise ISPs would be
filtering.
If you disagree with deaggregation for the purpose of traffic engineering,
which IMHO is perfectly valid if you're not being paid for those routing
slots, then filter anything longer than RIR maxima and be done with it. In
PIv6 land, this would be a /48.
Now, if you're claiming there will be sufficient /48s to cause you problems,
that's another matter entirely.
> One way to look at it is to consider that since /56s are assigned to
> soho then maybe this makes the /56 the new /24, and providers will
> allow more specifics upto /56. In other words, small sites will have
> just enough PA space to take up one slot in the Internet routing table
> and make multihoming work.
While I understand your concern about this, the proposal under discussion
only refers to /48s for large end sites. Please don't conflate the two
discussions.
S
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
More information about the ARIN-PPML
mailing list