ietf
[Top] [All Lists]

Re: NATs *ARE* evil!

2000-12-18 09:30:02

Perry E. Metzger wrote:

They can't avoid it. They need to get their work done. They have no
way of getting registered addresses. They're told to use NAT by
organizations like ARIN, and so they do the only thing they can.

I have a hard time believing ARIN is telling people to use NAT, when
the customer intends these hosts to have "external visibility".  I
can believe ARIN would send you to an ISP for small address blocks.
I can also believe companies don't want to pay the fees, and instead use
NAT to reduce the cost.

If ARIN is indeed refusing requests, on what basis are requests being
granted or refused?  By the use of the addresses (e.g. .org versus .com)?
Are these requests for "IPv4 ISP Registration" or "Individual IPv4 Address
Space Assignment to End Users"?  Perry, can you provide some more
details on what happened, or is this just what you were told by an ISP?

Anyone notice how odd the growth charts look for the v4 allocation
space? It is because we've already run out of addresses, folks -- or
at least we're acting as though we have.

I think that is exactly it; we are acting as though we've run out of
addresses.  I've yet to hear of a significant effort to "reclaim"
unused addresses.  Recovering a single class A picks up 16 million
addresses.  Until such an effort occurs, I refuse to believe the
address space is truely exhausted.  And if the address space isn't
gone, I don't see any justification for refusing reasonable requests.

Now whether we can route all of these addresses is another (much
different) question.  And if people aren't bothering to request
addresses because of routing issues, fine.  Let's say that instead
of saying we are out of addresses.

Granted, when addresses really start getting tight, and if the next
generation technology isn't ready, I can see the justification for
refusing some requests.  But then I'd expect a well defined criteria
describing how these decisions are being made.

Tony



<Prev in Thread] Current Thread [Next in Thread>