On Aug 2, 2012, at 11:44 AM, jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu
(Noel Chiappa) wrote:
we should instead focus on the ways that the technical architecture of
the Internet creates control points that are vulnerable to capture and
consider ways in which those control points can be made capture-proof.
Agreed.
The challenge of course is that one of the simple/efficient mechanisms to
implement desirable features (e.g., security, scalability, manageability) is to
create hierarchies, but those very hierarchies provide control points that can
(at least in theory) be captured. The DNS root is one such, the proposed RPKI
root is another. Perhaps a variation of the Software Engineering Dilemma
("fast, good, cheap: pick two") applies to Internet architecture: secure,
scalable, manageable: pick two?
If the ITU-T wants to also be in the business of handing out IPv6
address names then give then a /21 or a /16 and tell them to go
party.
I don't think this is what the ITU is after. My impression is that the ITU is
arguing that member states should get the /<whatever> directly.
I basically agree. It could have negative impacts on the routing, by impacting
route aggregatability, but it can hardly be worse that those bletcherous PI
addresses, so if it makes them happy to be in charge of a large /N, why not?
I believe the routing scalability risk lies not in the allocation body, but
rather the policies imposed around the allocations. That is, imagine a world
of 200+ National Internet Registries instead of 5 Regional Internet registries.
If the government behind an NIR then decides that to use the Internet in their
country, you must use addresses allocated by the NIR of that country, you then
run the risk of having 200+ prefixes for each entity that operates globally.
This risk could be addressed if it didn't matter where you get your addresses,
however that isn't true with the existing model and there are political
pressures that would likely ensure that it would not be true in the NIR model.
There are also risks associated with upkeep of registration data, which is
already a challenge with the existing limited set of registries. I imagine
this would get worse with more registries.
Regards,
-drc