I think this is indeed all about economics. Role acting ISP for a minute: From
a consumer ISP perspective asked to weigh in here, there are two options beyond
the ones mentioned below:
(1) They can support the new /10, which doesn't cost them anything and reduces
the chance that existing NAT boxes cause problems to near-zero.
(2) They can try to find some dusty corner of the existing RFC 1918 space, but
won't really be able to predict what happens until the phone lines light up.
When they do, they have to tell grandma to log into their NAT box and type in a
new address range.
From an ISP perspective, why would they ever choose (2)?
I don't see how we can eliminate the risk of (2) to essentially zero or even
estimate it accurately. (The typical DNS root "leakage" experiments, such as
the WIDE report, may miss exactly those devices that are in that dusty corner;
it seems to measure "broken" devices, rather than compliant devices.)
We don't necessarily have to care about the support costs for ISPs, but the
question is whether the total societal value of having this /10 be used for
"regular" users exceeds the support cost (and the associated consumer
aggregation), which is pure deadweight loss. I don't know if there's a good way
to estimate this.
Henning
On Dec 3, 2011, at 9:41 PM, David Conrad wrote:
On Dec 3, 2011, at 5:18 PM, Doug Barton wrote:
"We cannot use 1918 for CGN because some customers use it internally,
and they have CPEs that break if the same block is used on both sides.
Therefore, we need a new, !1918 block for our side of the CGN."
The problem with that argument is that there is nothing to stop
customers from using the new block internally (and everyone involved so
far has recognized that they inevitably will do this).
Hmm. So you're saying a customer behind a CGN is going to reconfigure their
CPE to use this new !1918 block in contravention to explicit statements in
the specification and then complain to their ISP when said reconfiguration
conflicts with the use of the CGN the customer is now behind? This seems
like a bit of a stretch to me. My guess is that the number of folks who would
even be aware of the new !1918 space would be quite small and of those, the
ones who would need to reconfigure to use that space would be infinitesimal
so this argument against the new !1918 space seems a bit specious.
Another possible reason 1918 space can't be used: the large scale ISPs
interested in deploying CGN have already used up all of the 1918 space, thus
to deploy CGN with minimal disruption to their deployed infrastructure, they
need another block. Anything else would require non-trivial renumbering at
undoubtedly high cost.
In any event, I'm still trying to figure out the problems that would be
created if the new !1918 block were not allocated. It seems to me that ISPs
deploying CGN who are unable to use existing 1918 space would be faced with
the following options:
a) use normal space
b) use somebody else's space
c) redeploy stuff
Option (a) simply means accelerating IPv4 free pool exhaustion. To me, this
implies moving the date when ISPs have to pay significantly increased costs
(going rate is now about US$12/address so a /10 would mean US$50M) to obtain
IPv4 addresses forward a year or two. Interestingly, getting normal space
now would probably pay off in the longer term as that space will likely be
quite in demand after free pool exhaustion.
Option (b) used to be SOP with a number of larger ISPs, although I gather at
least some of them have learned the risks of doing this the hard way. From a
pure business perspective, while unappealing, if the choice is between paying
$50M or not, I suspect finding a sparsely used /10 wouldn't be that hard (I
imagine everyone here has their favorite blocks they wouldn't mind seeing
sacrificed), but it does obviously come with risks.
Option (c) is simply inevitable one way or another, but pushing it forward is
probably viewed as extremely difficult/expensive in the near term, hence the
preference for either new !1918 space or going with options (a) or (b).
My impression is that the folks proposing draft-weil are trying to be good
net citizens and not use space inefficiently. Failure to pass draft-weil will
simply mean they'll go with option (a) or (b) -- I'd guess the moment
draft-weil is shot down, the RIRs will start getting very large and perfectly
justified address requests and the day of complete IPv4 free pool exhaustion
will jump forward.
What am I missing?
Thanks,
-drc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf