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