The Choice: IPv4 Exhaustion or Transition to IPv6

Thu Jun 28 17:15:28 UTC 2007

> Date: Thu, 28 Jun 2007 17:42:47 +0100
> From: Stephen Wilcox <steve.wilcox at packetrade.com>
> Sender: owner-nanog at merit.edu
> 
> 
> Hi John,
>  I wasnt specifically thinking of reclamation of space, I was noting a
>  couple of things:
> 
> - that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be:
>  :- used and routes
>  :- reclaimed and reassigned
>  :- sold on

Some of it, but a large part of the "missing" space belongs to the US
Government, mostly the military. It is very much in use and is routed
carefully such that it does not show up in the public Internet. It might
be replaced with RFC1918 space, but I'm not sure that there is enough
1918 space to do the job as the address space needed is quite large.

Also, some is used where 1918 space certainly could be used, but I have
spoken with those responsible to ask them to move to 1918 space and the
answer is an unequivocal "NO", not now or ever. I don't understand this,
but I know it exists. One research lab has multiple /16s and several are
used by classified nets that lack any external connectivity.

While these are wasted, getting them back is essentially impossible.

> - that much of the space in use within organisations could be optimised
>  :- mop up unused gaps in subnet
>  :- return IPs to the org's pool by forcing departments onto NATs
> 
> Pushing to NAT is on the face of it similar to pushing for early
> adoption of v6 whereby v6-v4 gateways provide a translation. However
> the technology for NATs is well established, widely deployed, cheap
> and very understandable to any IT guy.
> 
> You also refer to routing table size. The current routing table is
> growing quickly but people have been predicting the tables will
> outgrow the technology for many years but in each case new hardware
> gets released and on modern routers we can take significant growth
> (400%?).

Not really. See the presentations by the major router vendors on FIB
size from NANOG39 in Toronto at <http://www.nanog.org/mtg-0702/jaeggli.html>.

Most large network operators are truly frightened at the prospect of
what we are facing. There are some very real issues beyond adding more
TCAM. Issues that IPv6 will probably make worse. Right now the
available TCAM is mostly allocated to IPv4 unicast and very little to
IPv6. If the IPv6 table gets very large (and each IPv6 entry takes up
four times the space in TCAM as an IPv4 entry), the choice is rather
painful. 

> I dont believe routing table size comes into play in this, the simple
> reason is that whatever we say there will always be companies willing
> to take routes for money and it doesnt matter who or where they are
> because the rest of the world just has to route it.
> 
> I dont think that hierarchical routing will ever be a reality in
> todays diverse internet backbone, to not be a top tier carrier with
> your own ASN, and a full set of routes means you are closing your
> doors on selling transit. There are many thousand organisations making
> money from that, I cant see 99% of them bowing out gracefully to leave
> a few 'tier1s' behind.. that would be like turning back the clock 15
> years.

In the current routing schemes there is a large issue here.
Hierarchical routing simply won't do the job in a global fashion, but
there is work going on on new techniques that could deal with this.
Vince Fuller, Dave Meyer, Dave Oran, and Dino Farinacci presented an
approach at the last NANOG:
<http://www.nanog.org/mtg-0706/Presentations/lightning-farinacci.pdf>
They are not the only ones working on resolving this issue.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070628/4ebe3d6c/attachment.sig>