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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf