Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt
ms at berkeley.edu
Sat Sep 25 21:28:46 CEST 2010
On 09/24/10 23:51, Fred Baker wrote:
> I would appreciate opinions from the operators forum; please post
> comments to v6ops at ietf.org.
> The IPv6 Operations Working Group has been asked to adopt this
> document as a working group draft. In essence, the outcome would
> become a suggestion to the RIR and *NOG communities regarding the way
> the IETF would suggest that IPv6 prefixes be allocated. Note the use
> of the word "suggest". In summary, what this says is that the IETF
> holds no strong opinions about specific prefix lengths or boundaries,
> but strongly feels that the allocation policies should be scalable -
> which means that PI allocations to edge networks should be done only
> when Really Truly Appropriate.
> My question is: is this something that the operational community
> would consider helpful, or is it something the operational community
> would prefer the IETF kept its nose out of? If the operational
> community would find it helpful, is the specific suggestion
> reasonable from an operational perspective?
I may be a bit of a curmudgeon here, but I think one sentiment you might
hear from the operations community is: "No thank-you. The IETF has
already done more than enough to place obstacles in front of IPv6
adoption, particularly by 'end sites'. We don't need to add to that."
On a slightly more constructive note:
It's very clear to me that the belief that we could limit the routing
table growth by massively aggregating prefixes and creating a strong
distinction between "end sites" and "service providers" has been
discredited--and IPv6 almost failed as a result. I don't think turning
the clock back is going to help at all and I think such an effort will
be largely ignored (as was the original effort to make IPv6 largely
Three major issues I have with this and similar efforts:
1. It presupposes a particular economic architecture within the
Internet, one where there is a relatively clear distinction between
service providers and end sites, specific relationships between service
providers and end sites, and a particular arrangement of these entities.
Even if I accept this as matching the reality of today's Internet--and
that point is certainly arguable, I can't know that this arrangement
will exist throughout the lifetime of IPv6--it certainly didn't for the
full life of IPv4.
Moreover, the policy recommendations are driven by this economic
characterization. The draft goes through a number of logical gyrations
in section 2.3 to show that the recommendations are based on technical
grounds in order to justify the IETF's jurisdiction. Strikingly, this
is the longest section of the document, and by far the longest section
of original content, as opposed to quotations from other RFCs.
Nevertheless, the recommendations rest entirely on a particular economic
reality (or characterization thereof) and therefore make little sense
coming from a standards body.
2. It is service-provider-centric. This is justified by topological
considerations in section 4 (the second-longest section of the
document), but this justification is misplaced, partly due to its
assumption that aggregation among *end sites* is the only way to reduce
routing table growth. The recommendations impose costs on end sites by
making them renumber when they want to change service providers or by
making them convince service providers to poke holes in their
announcements--requests which service providers could easily ignore. It
makes multi-homing of end sites more difficult. It imposes no costs on
service providers who happily have access to portable addresses, derive
additional benefit from a smaller routing table, and share zero cost for
either of these benefits. It doesn't require much thought to see why
the operations community might be opposed to this. Standards shouldn't
merely reflect the interests of those who only make up a portion of the
overall Internet community.
3. It makes an extrapolated projection of the IPv6 prefix growth rate,
while characterizing that growth based solely on current IPv6 address
growth, rather than including the richness of IPv4 experience. The
current IPv4 stats tell us that IPv4 table bloat is caused by
announcement of disaggregated prefixes that could be aggregated, and by
announcement of multiple non-aggregable prefixes by the same AS. A
rather draconian policy would be to assert that no AS can ever announce
more than one IPv6 prefix. If someone acquires additional prefixes from
mergers and acquisitions, they must renumber. It imposes costs on end
sites and service providers alike, which is why it would never be
adopted. It also forces the AS allocation policy to be the limiting
policy for address growth and might put pressure on that policy. But
unlike a PA-only policy, it takes into account more factors in routing
Anyway, my point is not to say that my suggestion is better; rather it
is intended as a straw man to show how stilted the proposed draft is
regarding service providers (#2 above) and our limited IPv6 experience
On a more general note, these arguments are best left to the RIRs and
their constituents and the NRO--and they are well versed in this topic.
Having the IETF get involved at this stage of the game would be
counter-productive. On the other hand, having the IETF work on new
protocols that scale better would probably be appreciated.
More information about the ipv6-ops