[RRG] Re: Why not take address depletion issue into account

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

Short version:

   When comparing map-encap proposals, we should consider their
   ability to help with the IPv4 address depletion problem.  All
   of them should be capable of making a major contribution to
   improving address utilization.

   This is the problem everyone knows about - so if we can
   say this routing scalability solution is also inherently
   a means of alleviating the IPv4 address "shortage", then
   it will be a lot easier to get people excited about it.

   Also, why we need to avoid changing hosts, even if that
   would be cheaper than changing and adding routers etc.


Hi Xiaohu,

You wrote, in part:

> If I understood correctly, LISP, ivip and other similar proposals
> are mainly based on one assumption: host should not be changed
> because the cost of host change is believed to be much larger
> than that of router change. 

I think this is true, but there are some other important aspects.
We need the new kind of address space to be adopted by many,
probably most and ideally all "end-users".  "end-user" means
anyone who wants or needs multihoming, traffic engineering,
portability etc. and either can't get it now with BGP-based address
slicing and dicing, or could get it, and so could add one or more
routes to the DFZ routing table.

No-one is in a position to force large numbers of such "end-users"
to adopt the new address space, so we need to ensure at a minimum
that the new space doesn't suck and secondly that it is is
affordable - hopefully cheaper and better than the alternatives.

Pretty much every such "end-user" uses their address space for
servers and desktop machines etc. which need to communicate with a
broad swath of other servers and desktop machines all over the
world.  Initially, all those other machines will not be using the
new address space, and they will be completely unaltered.

So the new address space has to support communications with the
"rest of the world" in a way which works as well as, or is superior
to, the alternatives - today's BGP managed PI or PA space.

The new kind of space is not suitable for use by ISPs - but it will
be highly suitable to end-users who are not selling connectivity to
others.

If the map-encap's address space involves degraded performance, even
a little, except for when hosts at one or both ends have been
upgraded (OS at least, applications far worse - it will never
happen), then most end-users won't want it and the whole idea will sink.

So for such a scheme A, even if the cost of upgrading all hosts was
somehow less than the cost of upgrading routers, implementing some
alternative map-encap scheme B etc. then scheme A will never succeed
because potential early adoptors generally won't adopt it.

> At least, the recent discussion about
> the tradeoff between initial packet delay/loss and the
> scalability of the mapping system is based on that assumption.
> That is to say, the EID->RLOC mapping query is initialized by the
> ITR, but not host. Provided that host could be changed and could
> do the EID-RLOC mapping query on behalf of ITR and carry the
> obtained RLOC information in the packets, most of the pain
> discussed recently in RRG mail-list will not exist.

With Ivip it would be possible to have a caching ITR function built
into the sending host.  However the system doesn't rely on this.  It
would make sense most where there are cost benefits for the person
who runs the hosts.  For instance, a server farm would have a choice
between purchasing a bunch of high-powered ITRs to do all the work
or installing some free software update to the OS of its servers.

Assuming the task per server is not to heavy on CPU or RAM (as it
would be, except perhaps for the busiest servers which send packets
to a very wide range of destinations), putting the ITR function in
the host would be the best approach.

There's nothing about Ivip which makes in-host caching ITRs (ITFH -
ITR Function in Host - not behind NAT) have higher performance,
because the use of external ITRs provides the highest level of
performance anyway.  It is purely a cost-saving alternative which is
attractive where the host OS can be changed without too much trouble.

If you have some map-encap scheme X which has sub-optimal
performance, except when the sending host is upgraded, then this
scheme will be rejected by most end-users.  These end-users need
their networks to work just as well as with ordinary address space
with the great mass of hosts out there, which initially will not
have any scheme-X-friendly upgrades.

> If the above assumption (host should not be change and still use
> IPv4) is true, how will LISP, ivip and other similar proposals
> deal with the address depletion problem? 

LISP, APT and Ivip can all slice and dice address space down to much
smaller chunks than the 256 IPv4 address chunks which the BGP system
is currently capable of. (This is an administrative matter, but
clearly it is not going to get any finer, since we are trying to
reduce the growth in the DFZ routing table.)

LISP and APT does it in chunks of 1, 2, 4, 8, 16 etc.  Ivip's
micronets can be of any size, 1, 2, 3, 4, 5 etc.  So Ivip is
marginally more suited to the flexible, fine, slicing and dicing of
IPv4 space we will need, assuming we are stuck with IPv4 for a long
time, which I think we are.


> Should we still use NAT to solve the address depletion issues?  

I think this is inevitable - unless someone can figure out a
backwards compatible way of migrating end-users off IPv4 and onto
IPv6 or some other kind of address system.

> If so, we would have to tolerate the side-effect of NAT on the 
> new application design and deployment, especially
> peer-to-peer applications which has already accounted for 80%
> in total internet traffic volume nowadays.

As long as we are using IPv4, I believe we are stuck with NAT - any
widely used application needs to be able to fight its way out of
whatever NAT or nested NATs, it finds itself in.  There is a lot of
potential for standardising how NAT is applied and how it can be
auto-discovered.  http://tools.ietf.org/wg/behave/ RFC 4787 but
there will be plenty of NATs around for a long time which do not
conform to any such standards.	


> Or should we adopt IPv6 (IPv6 can be adopted as EID in
> the above proposals) to solve the address depletion problem? If
> so, the change of host is unavoidable and this is conflicted with
> the basic assumption of the above proposals. Or should we operate
> on the Internet multiple times to solve the many existing
> problems one by one? If the deadline of the routing scalability
> issue is close to that of the address depletion issue, why not 
> solve them in one solution?

I think a successful map-encap scheme will buy us a lot of time with
IPv4 by making it much easier to increase address utilisation and
accommodate many more multihomed end-user networks.  The persistence
of IPv4 will be for for better or worse depending on how you view
the inherent merits of the world adopting IPv6.

My guess is that about 200 to 300 million IPv4 addresses are
currently in use.  See:

  http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf

and my analysis at the start of:

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

If we assume this to be 15% utilization of the 1.7 billion currently
advertised IP addresses, and apply some factors:

  1 - About twice this number of IP addresses could be
      advertised (theoretically 3.7 billion, I think), if push comes
      to shove, which it surely will in the next five to ten years.

  2 - The new map-encap scheme could foster much better address
      usage, by a factor of two to five.  I can imagine 75% of
      IP addresses being used, as their value becomes higher due
      to continuing demand and the physical limit of 3.7 billion.

So I guess that by advertising all the space, and by using a
map-encap scheme, we could get four to ten times the number of
actively used IP addresses.

To what degree NAT could be further applied to support more hosts
(desktop machines, cellphones, Net-connected LCD "picture frames"
etc.), more individual people using the Net etc. I am not sure.  If
NAT could be standardised so applications could fight their way out
of two or more depths of NAT, then each DSL or ADSL modem, or each
cellphone, could have a NATed address.  Then in principle you could
run an entire ISP from a single IP address and countless billions of
hosts could have this form of IPv4 access.

At the end of all this, someone will probably look back and observe
it would have been easier to rip out every computer and router in
2015 and replace them with IPv6-compatible devices.  Likewise
escaping the ruts of MS Windows and qwerty keyboards!

Since large numbers of desktop machines can be handled behind NAT on
a single IPv4 address, in principle this population of machines can
be handled almost indefinitely on a finite subset of the space,
simply by applying NAT to a greater degree.  Current practice is to
give every cable modem or DSL customer a single public IPv4 address
and let the modem NAT as many machines as they like.  Giving them
NATed addresses instead would mean two layers of NAT and (I guess) a
variety of problems for existing applications, so I doubt this would
happen unless all the alternatives were worse.


> I doubt why the draft-irtf-rrg-design-goals-01 doesn't take the
> IPv4 address depletion into account for a new routing and
> addressing architecture.

The IPv4 address shortage is the big problem virtually everyone
knows about.  Few people have heard of the routing scalability
problem - and not everyone who has heard of it believes it really is
a problem requiring the heroics we are contemplating with a
map-encap scheme.

I believe both the RRG Design Goals and RADIR Problem Statements:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01
  http://tools.ietf.org/html/draft-narten-radir-problem-statement-01

should recognise that a map-encap solution to the routing scaling
problem can and should lead to new methods of address management
which will be crucial in alleviating the IPv4 "address shortage".

I wrote about this in July 2007 regarding the RADIR statement:

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

and should have mentioned it regarding the RRG goals:

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


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


--
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