Re: Creating demand for IPv6

["William Herrin" <herrin-nanog () dirtside com>]

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