Re: [RRG] Fwd: [Q] draft-farinacci-lisp: IPv4 address depletion

[Robin Whittle <rw@firstpr.com.au>]

Satoshi Ogawa wrote, in part:

>> I think, the draft-farinacci-lisp is NOT a method to resolve IPv4
>> address depletion problem.
>>
>> Is my understanding is correct?
>>
>> If my understanding is correct, LISP is one of useful solution to
>> resolve only routing table scalability.

I don't think any of these proposals:

  LISP-NERD, LISP-CONS, eFIT-APT, Ivip, TRRP

is capable of "resolving" the IPv4 address depletion problem.  They
are all intended to resolve the problem of "routing table
scalability" by enabling the BGP routing system to work with a lower
number of prefixes and changes to those prefixes than would
otherwise be the case, particularly due to the increase in the
number of end-user networks which are multihomed.

Of these proposals, only my one - Ivip - has an explicit goal of
enabling significantly better utilisation of IPv4 address space.  I
have no clear idea of how much it would help, and I don't think
anything can fully "resolve" the problem of growing usage in a
finite address space.

My idea is that there are many end-user networks which need less
than 256 IP addresses and whose owners need or strongly desire their
networks to be multihomed and/or to be free to move to another ISP
without renumbering.  Either of these requirements means that their
network needs to keep its IP addresses, which under current
arrangements would mean at least one more prefix/route/advertisement
in the global BGP system.

With Ivip, the idea is that there will be multiple (thousands, tens
of thousands perhaps) address blocks each of which is advertised in
BGP and which is split up by the Ivip system to serve the needs of
more than one end-user network which needs to retain its IP
addresses when using a different ISP.  In principle, as long as Ivip
generally serves more such end-user networks than the number of
separately advertised address blocks it is managing, then it
facilitates a reduction in the number of advertised BGP routes,
thereby contributing to the resolution of the problem of "routing
table scalability".

The best outcome would be just a few - say 4 - large blocks of
addresses, such as some /8s, being split up by Ivip to serve the
needs of hundreds of thousands or millions of separate end-user
networks.

I believe that the same or similar benefits - reducing the impact of
IPv4 address shortage by enabling more end-user networks, each with
a given number of actively used addresses, to use the IPv4 address
space - should be achievable by all the other proposals.  It is not
a goal of the other proposals, and few if any people other than me
seem optimistic about this goal.

The principles are:

1 - The current IPv4 BGP granularity of address space division is,
    in practice 256 IP addresses.  This is due to widely implemented
    filtering of advertisements to reject any which are longer than
    /24.  There is no formal arrangement for this, but unless
    virtually all ISPs changed their policies to allow /25s etc., at
    least in some parts of the address space, this restriction will
    remain indefinitely.

2 - The blocks of address space which are managed by LISP, eFIT-APT,
    Ivip or TRRP are all similarly chosen with the same granularity
    - 256 addresses.

3 - All these proposals enable an end-user network to be given
    address space in smaller increments, including a single IP
    address.  Ivip arbitrarily maps the address space by individual
    IP addresses, so there is no restriction whatsoever.  I think
    the other protocols specify the space for each end-user network
    as prefixes, so they can do 1, 2, 4, 8 etc. address divisions.


In principle, if more and more end-user networks rely on NAT and so
only need one or a few IP addresses, then any one of these systems
could be used to greatly extend the use of IPv4.

It is possible - I think likely - that for many years to come, it
will be unattractive (probably completely unworkable for general
Internet communications) to have only an IPv6 address.  Therefore, I
think it is likely there will be continued pressure for everyone to
need an IPv4 address (with the possible exception of some cell-phone
and other specialised systems), if only via NAT for non-server
machines.  In that case, it is possible to imagine more and more
end-users, such as home and desktop office machines, being behind NAT.

This would enable large numbers of computers (but not servers ) to
be accommodated in an end-user network which has only one or a few
public IP addresses.

At present, any such end-user network which requires portability
and/or multihoming has to get at least a /24 and add one more
advertisement to the BGP system.

With any of these proposals, many such end-user networks could be
accommodated from an address block of 256, 512 etc. IP addresses,
with either no advertisements in BGP, or just one, for the entire
address block, with Ivip and perhaps LISP-NERD.

Ivip also intends to provide fast mobility, with optimal or nearly
optimal path lengths, for IPv4 and IPv6, with the correspondent host
not required to have any new software.  In this way, a physically
mobile device or entire NAT-based network (such as that of a
passenger aircraft) could occupy a single IP address.

Note: I haven't read the 02 version of LISP-NERD, or fully read Bill
Herrin's TRRP proposal.  Please see RRG messages 264 and 288 for why
I think LISP-NERD may involve "anycast ITRs" similar to those
proposed in Ivip.

  http://psg.com/lists/rrg/2007/maillist.html

  http://tools.ietf.org/html/draft-farinacci-lisp-03
  http://tools.ietf.org/html/draft-meyer-lisp-cons-02
  http://tools.ietf.org/html/draft-lear-lisp-nerd-02

  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/

  http://bill.herrin.us/network/trrp.html

 - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg