[arin-announce] IPv4 Address Space (fwd)

Mailman List Mirror (Read Only)
1

I love this.

ARIN publicly states, "Whatchoo talkin about, Willis?" (see announcement
below)

So, by extrapolation, if we've collectively used 20 /8s over the past 5
years, and we have 90 left, that's over 20 years of IPv4 growth we have
left.

Some would ask, "What about increasing address usage?"

I would ask, "What evidence do you have that usage is increasing?"

Technologies like NAT and efforts to reclaim poorly assigned address space
have a large negative pressure on the increase of IP utilization. As more
and more "appliances" need IP addresses, people will realize more and more
that the last thing they want is those "applicances" on public IP space.

Does anybody have statistics for assigned-but-not-announced space? I'd be
willing to bet there will be more and more dead space over the years, and
in fact quite a bit of "increasing usage" is just churn.

What does any of this matter? I think there is a huge financial incentive
for NSPs to ignore IPv6 until the situation arrives where they are at a
competitive disadvantage to NOT deploy it. I also don't think that time
will ever come, as I expect new technology to trump IPv6 by the time it's
actually needed (some would argue that NAT has already accomplished this).
How about a protocol that eliminated the need for BGP, while
simultaneously making every address portable? That, to me, would be The
Answer. Not that it seems possible given what we currently know, but 20
years is a long time :slight_smile: Try to think backwards 20 years, and you see how
impossible it is to conceive of the next 20 years. (Yes, I realize that
statement neuters the basis of my argument. But I'm not really stating the
future demand for IPs as fact, just assumptions to be debated.)

Does anybody honestly think companies will commit the capex needed to
implement IPv6?

I know this thread keeps on coming up...but I don't see any positive
momentum for IPv6, and if the people of this Esteemed Forum can't agree
that IPv6 is something that must happen ASAP, how will the PHBs (those who
control the money) and the customers (those who control demand) ever be
convinced?

Hell, I can't even convince myself that IPv6 is neccessary. Is anybody out
there totally sold on IPv6, enough to evangelize it to anybody willing to
listen? I mean, IPv6 is no CIDR...

Andy

2

Does anybody have statistics for assigned-but-not-announced space? I'd be
willing to bet there will be more and more dead space over the years, and
in fact quite a bit of "increasing usage" is just churn.

I have these statistics at
http://www.completewhois.com/statistics/ip_statistics.htm

At above page look specifically at the blue part of the graph for assigned-
but-not-allocated space. I actually looked at opposite (assigned & routed
- this I named "routing utilization ratio") as way to determine efficiency
of RIR policies. This ratio is very high for the new ARIN ip blocks (97%),
but as you pointed above the churn is high for older blocks and only 42%
of allocated space in 192/8 is actively routed. The ratios are in between
around 60%-80% for other old blocks and these numbers both has to do with
allocation policies that were not developed at the time and with churn due
to dead companies. I have done analysis for different time periods, see:
http://www.completewhois.com/statistics/rir_ratios.htm

If you need data on exact amounts, you will need to do your own substraction
use allocation statistics data from
http://www.completewhois.com/bogons/data/allocation-statistics.txt
and substract current use data from
http://www.completewhois.com/bogons/data/data-bgp-announced/ipv4-activeblocks-statistics.txt

Does anybody honestly think companies will commit the capex needed to
implement IPv6?

Not without additional benefits. We need either applications that are
working a lot better at ipv6 or we may yet have to see ipv4 space ran out
before it becomes clear to everybody that ipv6 is a must.

3

Andy Dills wrote:

Technologies like NAT and efforts to reclaim poorly assigned address space
have a large negative pressure on the increase of IP utilization. As more
and more "appliances" need IP addresses, people will realize more and more
that the last thing they want is those "applicances" on public IP space.

It seems that the Internet will take the "switchboard lady" detour due to misguided
thinking like the one above, mostly due to the fact that a major OS explodes
when it touches the Internet. Fortunately hardly any of these "applicances" have
this OS.

How about a protocol that eliminated the need for BGP, while
simultaneously making every address portable? That, to me, would be The
Answer. Not that it seems possible given what we currently know, but 20

This protocol is called HIP, right? (Host Identity Payload)

Does anybody honestly think companies will commit the capex needed to
implement IPv6?

Yes. Investment in information technology hardly ever makes sense. If it would,
market share numbers of various ICT products would look wildly different.

I know this thread keeps on coming up...but I don't see any positive
momentum for IPv6, and if the people of this Esteemed Forum can't agree
that IPv6 is something that must happen ASAP, how will the PHBs (those who
control the money) and the customers (those who control demand) ever be
convinced?

Because they heard somebody from Gartner, IDC, etc. so say so.

Hell, I can't even convince myself that IPv6 is neccessary. Is anybody out
there totally sold on IPv6, enough to evangelize it to anybody willing to
listen? I mean, IPv6 is no CIDR...

You are smarter than many of them. Like most of the readers here.

Pete

4

http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html
                                                                                                                                              
This is actually a pretty good write-up about the IPv4 address lifetime
by Geoff Huston. It has some graphs that compares BGP to actually
assigned space comparisons. Makes very good reading about all this.

5

imagine a network without NAT. I stopped counting applications
that are struggling/breaking with NAT...

But many people still believe rfc1918 and NAT are a cool thing
because they just got used to it...

   tschuess
             Stefan

6

They're a cool thing for other reasons.
If "more IP addresses" is the only motivation for using IPv6, it's
really not enough. For environments where direct access to the internet
isn't required, NAT serves perfectly well.
There's also no *need* to use public IP's on a private internal-only
network either, so it makes little sense to do so.

The way I see it, there are a lot of reasons not to use IPv6..

7

Avleen Vig wrote:

If "more IP addresses" is the only motivation for using IPv6, it's
really not enough. For environments where direct access to the
internet isn't required, NAT serves perfectly well.

IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT,
doesn't it?

8

No.

Anything that relies on knowing which host it is talking to by looking at
the source address of packets breaks.

Plenty of UDP based apps work over NAT.

Simon

9

Indeed, and IPSec tunnels are frequently done between routers on
networks, rather than individual hosts on networks (at least in most
multi-site enterprises i've seen).

10

this is true, but incomplete. there are numerous deployment strategies
for IPSec, some of which work around NAT, some of which can be
coerced to work through NAT, and most of which don't work around
or through NAT.

businesses deploying IPSec often lack the flexibility to pick and
choose, especially in extranet deployments where two independent
business are deploying a tunnel with mismatched equipment and limited
choices. it's particularly bad when one end is a 800 lb gorilla with
all the high cards, forcing a particular set of parameters on the small
business on the other end. i've consulted for small businesses on the
wrong end of that stick, and it's no fun at all. you ought to try it some
time before you casually toss off a statement like the one quoted
above.

richard

11

Simon Lockhart wrote:

Anything that relies on knowing which host it is talking to by
looking at the source address of packets breaks.

Indeed. Novell networking for example - or MS Exchange New Mail
notification. of course, you shouldn't be doing either on the internet,
but a common "small branch office" solution involves ADSL, NAT and a
single VPN client....

Plenty of UDP based apps work over NAT.

depends a lot on the nat - if the UDP app isn't port-specific, then often
a "smart" nat can create a virtual map for it (and IPSec NAT traversal
often relies on a single internal initiator creating such a map on the nat
device, and the destination not minding too much)
If the "outside" sender expects the recipient to be on a fixed port
though, often the best you can hope for is that *one* internal host can
receive data.

12

Avleen Vig wrote:

Indeed, and IPSec tunnels are frequently done between routers on
networks, rather than individual hosts on networks (at least in most
multi-site enterprises i've seen).

Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at home. our accounts department looks a
certain amount of askance at IT when they get a large phone bill in
expenses for someone using a 33.6 modem right next to a nice shiny half
meg ADSL connection that IPSec won't traverse....

13

> imagine a network without NAT. I stopped counting applications
> that are struggling/breaking with NAT...
> But many people still believe rfc1918 and NAT are a cool thing
> because they just got used to it...

They're a cool thing for other reasons.
If "more IP addresses" is the only motivation for using IPv6, it's
really not enough. For environments where direct access to the internet
isn't required, NAT serves perfectly well.

At that point, so does application layer proxying. *shudder*

There's also no *need* to use public IP's on a private internal-only
network either, so it makes little sense to do so.

Ever tried to setup connectivity between the internal networks of two
different companies who both use the same RFC-1918 range internally?
VPN or PtP link, it's not fun either way, and usually involves heavy
packet mangling or renumbering the smaller (or less important
politically) side of the connection.

The way I see it, there are a lot of reasons not to use IPv6..

Other than the new hardware investment, what? It's not really worse than IPv4,
and lets us get rid of this damned RFC-1918 stuff, even if you end up changing
(pointlessly) the source IPv6 address of your packets, at least your network is
internally uniquely numbered. I'm tired of having to work around NAT limitations
for SIP, IPSEC, and all the other innovative stuff people haven't even bothered
to publicly release because it's horribly broken by NAT and they don't want to
support it. I'm tired of meticulously configuring my peer to peer clients to work
with my NAT, because the other guys don't configure theirs to and I can't download
anything.
I want my end to end back.
-Paul

14

The most common use of VPN links is the roadwarrior.
IPSEC in this context is broken badly by NAT. Even when the extensive
hackery required to workaround NAT is enabled, it still can not work in
the case where two roadwarriors are behind a single address connecting to
the same VPN gateway.

15

Dave Howe wrote:

Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at home. our accounts department looks a
certain amount of askance at IT when they get a large phone bill in
expenses for someone using a 33.6 modem right next to a nice shiny half
meg ADSL connection that IPSec won't traverse....

IPSec can traverse NAT. Often times, it's the implementation of IPSec that doesn't traverse NAT. Software vendors apparently didn't think it necessary to allow for address translation. Tis sad, really.

I have customers that can VPN through NAT and customers that require public addressing. The one's that really make me laugh seem to require a static IP address.

Of course, the customer is always right.

-Jack

16

No. IPSEC and SIP break because their payloads include information that
is dependent on the IP address header. In the case of IPSEC, this is
to support end-to-end authentication and avoid certain kinds of man-in-
the-middle attacks. In the case of SIP, it's because SIP is a call setup
protocol which facilitates the creation of an RTP session. It's much the
same problem as FTP. The reason FTP doesn't BORK is because most NAT
gateways understand about the need to proxy FTP and because PASSIVE mode
FTP doesn't have the same call-setup problems.

In the case of IPSEC, there is an IPSEC standard for NAT traversal. It
allows for a slight compromise in the end-to-end security while still
preserving most of the capabilities of IPSEC.

UDP works just fine through NAT, as evidenced by DNS and other protocols
that aren't inherently broken with NAT. (Of course, DNS could suffer from
the same effects as SIP on some levels since the contents of the DNS
A record answers may be dependent on an un-natted world).

Owen

17

Right... Forgot about the SNMP breakage. SIP doesn't depend on knowing
which host it's talking to from the source address, but, it does depend
on being able to assign RTP session parameters based on IP addresses
contained within the SIP payload. Thus, when the SIP payload goes through
a NAT box and the payload is not modified accordingly, the RTP session
rarely works out right.

Owen

18

However, what is authenticated in the IPSEC datagrams is the addresses
of the IKE gateways (the routers). The fact that an entire netblock
exists within the tunnel is not especially relevant to the part
that suffers from NAT breakage.

Owen

19

Owen DeLong wrote:

It's much the
same problem as FTP. The reason FTP doesn't BORK is because most NAT
gateways understand about the need to proxy FTP and because PASSIVE mode
FTP doesn't have the same call-setup problems.

Passive mode has the same problems that PORT FTP does. It just pushes the
problems to the server end. If you put a FTP server behind a NATed address,
you'll need to proxy PASV (and also inverse to the client behind NAT, PORT
needs none at the server end).