About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space)

  • To: Address Policy WG address-policy-wg@localhost
  • From: Robin Whittle rw@localhost
  • Date: Mon, 30 Jul 2007 23:30:37 +1000
  • Organization: First Principles

I believe that a substantial amount of the remaining IPv4 space
should be put aside to be used with whichever new architecture is
developed to deal with the routing and addressing problems
discussed last year in the IAB RAWS workshop.

That new architecture will be able to apply address space much
more efficiently in terms of number of end-users, the proportion
of IP addresses actually used, and the usefulness of the address
space in terms of multihoming and portability without burdening
the BGP routing system.

This reservation - and perhaps operation of the new system - might
best be done by the RIRs.  I want to suggest this as part of a
debate about how to make best use of the remaining fresh IPv4 space.


The RAWS workshop report is:

  http://tools.ietf.org/html/draft-iab-raws-report
  http://www.iab.org/about/workshops/routingandaddressing/

Discussions are on the RAM list:

  http://www1.ietf.org/mail-archive/web/ram/current/
  http://www1.ietf.org/mailman/listinfo/ram

the IRTF Routing Research Group List:

  http://psg.com/lists/rrg/2007/
  http://www.irtf.org/charter?gtype=rg&group=rrg

and a small closed RADIR list with public archives:

  http://www1.ietf.org/mail-archive/web/radir/current/
  http://www3.tools.ietf.org/group/radir/

The central Problem is most frequently summarised as something
like: "There needs to be a way many more end-users can do
multihoming, traffic engineering and have portable address space
without requiring conventional PI space and without adding more
advertisements and churn to the global BGP routing table."  The
urgency now is about IPv4, but IPv6 will have the same troubles
whenever it is widely adopted.

The solution is most likely to be in two forms, which are quite
independent of each other.  Firstly some moderate improvements to
BGP's scalability and stability are likely to be made.  Secondly
there is likely to be some IP-level system involving a global
network of Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers
(ETRs).  These will enable multihoming and portability without
involving BGP.

The IP-level tunneling proposals to date are LISP-NERD, LISP-CONS,
eFIT-APT and my own: Ivip.

  http://tools.ietf.org/html/draft-farinacci-lisp-01
  http://tools.ietf.org/html/draft-lear-lisp-nerd-01
  http://tools.ietf.org/html/draft-meyer-lisp-cons-01
  http://tools.ietf.org/html/draft-jen-apt-00
  http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf
  http://www.firstpr.com.au/ip/ivip/

These proposals are all intended to apply both to IPv4 and IPv6,
not require changes in hosts, and retain reachability from
non-upgraded networks.

While most of the people in this field are focused on the
"multihoming etc. without BGP" problem, I make a direct causal
linkage from the limitations of the BGP routing system to the
clunky restrictions it places on address allocation (256 address
granularity and "Maximise route aggregation!!!"), the consequent
low proportion of advertised IPv4 addresses which are actually
used and therefore leading to the rapid, premature "exhaustion" of
IPv4 space.

Each one of these four proposals listed above, if it could be made
to work as intended, would enable much finer allocation of address
space to end-users, down to single IP addresses (/64s for IPv6
probably).  So once one of these systems is operational, IPv4
space will be able to be allocated to end-users in any size, from
/32, /31 etc. through /24 etc. with portability, multihoming and
no concern whatsoever for "route aggregation".  BGP can only do it
in /24 granularity - chunks of 256 addresses.

Since something like this needs to be built in the next few years,
I propose that a substantial amount of the remaining unallocated
space be kept for the new system, which can then put it to work,
in terms of numbers of end-users and in terms of actual
utilisation of IP addresses, *far* more efficiently than BGP can
use it.

I think many people have become accustomed to the very low rates
of utilisation of currently advertised portions of the 3.7 billion
address IPv4 space, which is the direct cause of us running out of
fresh space well before there are two or three billion IP
addresses in use.  I don't know how many are used now, but I think
it is probably around 200 or maybe 300 million.  I found about 108
million respond to ping, which I know has its limitations:

  http://www.firstpr.com.au/ip/host-density-per-prefix/

Here is my message which proposes some changes to the draft
"Problem Statement" from RADIR:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html

along these lines.  It considers the IPv4 address shortage as part
of the Problem - just as amenable to solution as the "multihoming
without BGP" problem.

I also think that a new ITR and fast mapping database architecture
could provide a tremendous boost to mobile IP, for IPv4 and IPv6,
with near optimal path lengths and without requiring changes in
correspondent hosts.  Of the current proposals, only Ivip could do
this.

Lack of mobility is not currently a "problem", but I think that
since a global ITR network (as all the four IP-level proposals
involve) could be used to drastically enhance mobility, that any
new architecture should either do this from the start, or at least
not preclude extensions in the future which do this.

  - Robin    http://www.firstpr.com.au/ip/ivip/




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community