On 12/3/2011 6: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? No, I explained the likely path to enterprises using this space in a different message. A combination of already having exhausted all/most 1918 space internally, and not being behind a CGN when the changes are made. And no, I don't expect it to happen in the short term, my point is that it's incredibly likely to happen down the road as the CGN nonsense drags on. > 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. The larger enterprises which are likely to have exhausted the 1918 space internally are likely to have more clued-in network folks who would be aware of the new alternative. Did you see the message where I pointed out that this is, in all likelihood, a 90/10 problem? > 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. I think to some extent you're right about this, but that reduces the current request in essence to "We need another 1918 block," which the IETF has already rejected, has it not? > 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 d) Use 1918 space other than 192.168.[01]/24 for 90% of customers, deal with one-offs for the rest. > 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) ... which is another reason I'm opposed. Like you, I recognize the monetary value of the block, and am opposed to giving a US$50M gift to the grasshoppers who've fiddled the summer away. [snip] > 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. I understand this line of argument, I just don't agree with it. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf