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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf