On 10/2/07, Randy Bush <randy@psg.com> wrote:
During early phase of free pool exhaustion, when you can't deliver more IPv4 addresses to your customers you lose the customer to a hosting provider who still has addresses left. So sorry. Those will be some nasty years. Unless you're Cogent, Level3 or one of the others sitting pretty on a /8. They'll be in phat city.
this is a very real and significant problem. a very small fraction of the arin membership holds the vast majority of the address space. it would be interesting to ask arin to give us the cdf of this.
Randy, It would be nice if it was that simple. Those /8's arise from legacy assignments that fall more or less directly under IANA without any form of agreement in place that could allow policy change. Barring government action, they're effectively the unrecoverable property of those organizations. They can even act as mini-registries and auction addresses off to the highest bidder if they're so inclined.
given that, the scenario you present is likely to be very real.
but what do we do about it?
Unless something brilliant arrives out of left field, the only thing we can do is deploy and get customers to deploy IPv6 -before- IPv4 free pool exhaustion starts to hit. That's really not on track right now. Some things which might help get it back on track are: 1. End the insanity of having software prefer IPv6 if available (AAAA records over A records). That's a commonly cited reason that folks who tried IPv6 stopped using it. I might make some of my stuff available via 6to4 but 6to4 is pretty meager so there's no way I'd consider it when stacks will prefer trying to communicate with IPv6. 2. Figure out a PI solution for IPv6 capable of scaling to the equivalent of hundreds of millions of routes in the core at a per-route cost two orders of magnitude less than it is today. RRG is working on this but there aren't enough people involved, they're not focused on a solution that delivers that degree of scalability, they're not in a hurry and AFAIK they're not well funded. This seems self-defeating given how much money rides on a useful answer coming out of the IETF. 3. Produce IPv6 NAT. Folks are used to NAT. They're comfortable with the security they believe NAT provides. They might eventually switch away from NAT if some desirable new application requires it but they won't refactor their network security policies as a prerequisite to deploying IPv6. On 10/2/07, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
Have you used a NAT free Internet?
Mark, I maintain a /23 in the swamp and have since '94. For the record, I didn't even like NAT back when it was still called "circuit level proxying." I'd love to have an Internet where all firewalls were packet filters. But that's not my call. That's the call of hundreds of thousands of network security officers who have NAT written in stone at the core of their security process. Tying NAT's abandonment to IPv6's deployment won't change their minds but it will doom IPv6.
So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed? http://www.cs.utk.edu/~moore/what-nats-break.html
Many of those never were meaningful problems and most of the rest have been obsoleted by the changing reality of network security on the Internet. Things like controlling the source port meant something once upon a time, but they have no place in a modern security infrastructure. That would be true with or without NAT. The -real- problems with NAT can be summed up in two statements: 1. NAT makes it more difficult to engage in certain popular activities that strictly speaking are against the TOS. 2. NAT makes logging and accountability more difficult. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004