Hadriel, On Dec 4, 2011, at 10:33 AM, Hadriel Kaplan wrote: >> It isn't a question of whether CGN can be deployed, it is a question of how. As far as I can tell, lack of the a new /10 will simply mean ISPs get to make an operational decision, the result of which will either be more rapid exhaustion of the remaining IPv4 free pools or the use of already allocated space with the potential collisions it entails. > > It may mean "more rapid exhaustion of the free pool" for a short time, but at some not-too-far-away time it will stop meaning that since the free pool will be exhausted. So that's not a long-term result of not allocating a /10, and thus the phrase "either ... or" used in your email does not apply. The either/or (and it isn't necessarily xor) applies to the decision ISPs will make should draft-weil not move forward. > ISTM, ISPs would really be left with 4 choices: > 1) Use whatever address space they have already now as this new CGN space, Right, this is one possible version of the 'redeploy' option I mentioned in an earlier message (the one with the $50M estimate). I would imagine the cost of doing this would be sufficiently high as to make it a non-starter, but it is indeed an option. > That's not a result I think we should want to happen, both because it disrupts the current working IPv4 and because it limits potential new ISPs. (it gives an advantage to legacy ISPs with lots of existing v4 addresses) I suspect IPv4 exhaustion will be a bit more limiting to potential new ISPs than existing ISPs renumbering their existing space so they can make use of CGNs. > 2) "Squat" on someone else's space or un-allocated space. I don't think that's a result we should want to happen, for obvious reasons. (I also don't think it's likely many ISPs would do this either - just noting it's possible) Say you are the CIO of a large ISP. If you get to decide between spending $50M or having your customers be potentially unable to communicate with (say) a relatively tiny number of ham operators (44/8) or US SIPRnet (which I suspect is against the law for your customers to communicate with) or <pick your favorite block>, what would be your choice? > 3) Use RFC-1918 address space. That would work for pure "consumer" applications, but would break things like remote employees using VPNs. I thought the primary issue was the need to number the WAN interfaces of non-field-upgradable CPE that don't allow 1918 on that interface and/or in a way that doesn't collide with 1918 space used on the inside interface. Since we've seen multiple iterations of what is now draft-weil over the years, I have to assume using 1918 space isn't really an option. > 4) The CGN vendors and ISPs create a "CGN Forum" industry association, pool money together and buy the space to use from others. Right, this is a variation of the "use somebody else's space" option. They wouldn't need to buy the address space (at least if they do it soon): all the RIRs except APNIC can allocate a /10 now if it is justified. Since as far as I know numbering interfaces is seen as sufficient justification, one ISP could obtain the space and simply say 'hey, this space will never be announced'. Other ISPs could then use it or not as they see fit. > 4b) If one were to think evil-ly, one thing a big CGN vendor could do is use some of their own address space for *their* CGNs, and thereby have a sales advantage over other CGN vendors who weren't given big blocks in years past. I don't think that's a result we should want, either. Not sure why this would be considered 'evil'. It indeed might make business sense for a CGN vendor to do this and it is (arguably) a less inefficient approach than each CGN-deploying ISP going out and getting their own block for this purpose. My assumption is that this issue only applies to really large ISPs and that the CGN vendors for those ISPs already have sufficient existing legacy address space to do this. > p.s. <rant> and we should really stop talking about this as a "us" vs. "them" problem, Agreed. It is, after all, one address space. Well, sort of. Regards, -drc _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf