North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
- From: Joe Abley
- Date: Sun Sep 11 03:57:32 2005
On 10-Sep-2005, at 21:42, Patrick W. Gilmore wrote:
It'll only continue to fail (for this reason) as long as the various
RIR memberships don't vote for change.
On Sep 10, 2005, at 10:17 AM, Joe Abley wrote:
Yes, according to the current RIR policies. [So the determination
of "unworthy" above has been made, in effect, by RIR members.]
And this is why v6 has failed and will continue to fail.
It doesn't need to a foregone conclusion; it just needs to have
significantly non-zero probability, since if it turns out to be true
then we're all screwed.
2. Because there is vastly more v6 space than v4 space, if
entitlement to PI space in v6 was opened up the chances are many
more people would have v6 PI space than currently have v4 PI space.
This assumption has more holes in it than swiss cheese.
Right now there are lots of multi-homed organisations who use NAT,
and whose "PI" address space deployed internally comes from RFC1918.
If you imagine all those enterprises using a globally-unique, PI v6
block instead, then perhaps the thinking behind the speculation in
(2) above becomes clearer.
[ObCheese: most of the 450 or so kinds of cheese made in Switzerland
don't have holes.]
Ignoring the problems with #2, what is made of the idea that each
AS might only have a single block, since blocks are so much
larger? (And lots of other questions I'm sure you guys have
already covered which are probably not on-topic for NANOG.)
This is an RIR policy issue, not an IETF protocol issue. If the
members of RIRs all pushed for the idea that "I have a globally-
unique ASN" is also appropriate justification for a /32 allocation,
then I would imagine that the policy might change.
It's possible that the number of PI assignments might not be that
high, and the scaling properties in practice might not be so bad.
However, you only get to find this out after you've opened the
floodgates, and if it turns out that it doesn't scale, it's hard
to push the water back into the reservoir.
The goal in shim6 is to find a mechanism which provides all the
functional benefits of multi-homing without holding all the state
in DFZ routers.
Perhaps the goal ... was chosen poorly?
Perhaps. This will surely become clear with the benefit of hindsight :-)