[RRG] We can't bet the Internet on the imminent adoption of IPv6

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

Short version:

  We should agree that the RRG solution needs to work for both
  IPv4 and IPv6.


In Re: "Doing It Right" (was Re: [RRG] Consensus? IPv4 scaling
problem ...). Brian E Carpenter wrote:

> On 2008-05-28 09:36, David Conrad wrote:
> ...
>> Further, as evidenced by the lack of any significant deployment
>> after a dozen years, it can be argued that IPv6 has been a clear
>> market failure.
>
> I'd argue that the market test hasn't started yet, and won't until
> the RIRs actually run out of IPv4 prefixes. Obviously, that date
> was deferred by 10 or 15 years as a result of NAT, compared to
> what many expected in the IPng days.
>
> But is this really an RRG issue?

IPv6 adoption is an issue for the RRG for two reasons at least:

1 - Because it affects the urgency with which a scalable routing
    solution must be deployed for IPv6.

2 - Because some folks believe that we don't need to solve the
    routing scaling problem for IPv4 - just for IPv6.  To the
    extent that these folks make it impossible to reach a rough
    consensus that we must develop a solution for IPv4, then
    the question of how and when IPv6 will be adopted widely
    is central to the RRG's work.

    This is because only when IPv6 is very widely adopted could
    enough end-user networks not use IPv4 - which is the only way
    of solving the IPv4 problem without solving it directly.

    Randall and others argue that IPv6-only networks can
    interoperate with IPv4 for most major protocols.  Other than
    email and perhaps HTTP, I strongly disagree.  There is no
    evidence that the required proxies or ALGs exist or that they
    are technically possible.  See Randy Bush's October 2007 piece:
    http://www.nanog.org/mtg-0710/presentations/Bush-v6-op-reality.pdf

        How does a user at a v6-only site get to the Internet, i.e.
        a v4-only site?

        They don’t!

        What can be done to help as much as possible?

        Core Routing – conversion to dual stack is slow

           New line cards are often required!
           $50 DSL Modems do not support v6
           $50 Firewalls do not support v6
           Teredo does not really scale

        shim6 is does not solve enterprise or large site, and is
        not deployable due to security and routing model issues

        Enterprise
          Databases, PeopleSoft, Siebold, Business Applications ...
          Firewalls, VPNs, Access, ...
          Millions of lines of in-house code
          NFS Appliances, unknown
          If one link in the business application production chain
          is not there, it does not transition

        Where is the web page with a matrix of application by
        platform showing which are v6 capable and clickable link on
        how to turn it on?

        Many applications which support v6 have sufficiently poor
        performance that early adopters are being told to turn v6
        off XP will not work in a v6-only environment, because it
        does not support DNS queries over IPv6

        All IPv6 sites need to have the ability to SMTP to arbitrary
        IPv4 sites

        Therefore everyone needs private dual stack relay until the
        world is all dual stack SMTP

        (On NAT-PT which was moved to historic status with
        RFC 4966) The IETF needs to standardize 4/6 NAT for ICMP,
        UDP, TCP, RTP, maybe how ALGs plug in, especially DNS ALG.

    This is from someone who strongly believes in IPv6!

An IT system with very low adoption after 12 years is a clear market
failure.  It is arguably a technical failure too - but the technical
challenge, to be backwards compatible with IPv4, was perhaps an
impossible task.


I think it would be a grave mistake to bet the continued health of
the Internet on the rapid adoption of IPv6 to the point where, in
some foreseeable time-frame soon enough for the coming (2010 and
beyond) explosion in IPv4 DFZ routes, IPv6 adoption will be
ubiquitous enough that significant numbers of end-user networks
won't need IPv4 addresses.

I think it would be a very good thing to achieve consensus that we
must solve the IPv4 routing scalability problem directly.  Besides,
if we don't then most folks outside the IETF - who generally don't
have any great belief in Salvation through IPv6 - will look on the
RRG's work as being derailed by people with a completely unrealistic
confidence in the ubiquitous adoption of IPv6.

The IPv6 faithful have some valid reasons for thinking of IPv6 as
the only possible long-term solution - but at present, and in the
foreseeable future, the only substantial benefit IPv6 offers is
freedom from IPv4's address crunch.

This crunch is being played up, as was Y2k, as the sky falling in at
a discrete point in time (2010 or so) and that there won't be any
more IPv4 space - so all newcomers will be forced to adopt IPv6
addresses.

This is completely unrealistic for reasons including the following:

1 - There is plenty of address space left in IPv4
-------------------------------------------------

Iljitsch wrote (http://psg.com/lists/rrg/2008/msg01344.html):

   This is exactly the reason IPv6 has seen so little uptake so far.
   Then again, we still have a billion unused IPv4 addresses. It's
   no use complaining that nobody buys umbrellas when the sun is
   shining.

So there's plenty of IPv4 space available, and the only major reason
for adopting IPv6 address is because IPv4 space is, or soon will be,
 "unavailable".

There are probably something like 220M IPv4 addresses actually in use:

   http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf
   http://www.firstpr.com.au/ip/host-density-per-prefix/

even if you double that figure, it is still small compared to the
1700M advertised addresses.  There are about 2700M IPv4 addresses
which could be advertised.

The poor utilisation is primarily due to two factors:

  a - In many cases, it has been easier to get more space than to
      use it efficiently.  This includes allowing for expansion
      of existing networks.  With a map-encap scheme, it would
      be easy and desirable to expand with smaller patches of
      independent map-encap PI space, rather than the current
      pattern of having large numbers of small organisations all
      start with short public BGP managed PI prefixes in case they
      get bigger 10 years later.

  b - BGP, as currently administered (/24 limit and high costs)
      means that the address space can only be sliced and diced
      very crudely.

Whether or not the RRG decides to solve the IPv4 scaling problem
directly or not, it seems likely that as fresh IPv4 space runs out
one or more map-encap systems will be developed to slice and dice
IPv4 space down to single IP addresses, for mobility and for
multihomed portable IPv4 space for paying customers of all sizes etc.

If that doesn't happen, IPv4 space will still be much better
utilized, but through the undesirable, non-scalable process of finer
and more numerous slices with existing BGP methods.  This would lead
to a sharp increase in the growth rate of the DFZ routing table and
so to a more rapid worsening of the IPv4 routing scaling problem.

Both the map-encap system(s) and the finer slicing of IPv4 space
will give end-users what they want and need - IPv4 space.  IPv6-only
space simply does not suit the needs of end-users, with the possible
exception of cell-phone users whose applications are built-in and
potentially OK for IPv6-only.

So there are multiple ways the IPv4 Internet will continue to supply
the address needs of end-users for the next one, two (three?)
decades.  The longer times (perhaps indefinitely) will also be due
to the ability to serve large numbers of end-users from a few IPv4
addresses, as discussed below.



2 - Many end-user networks can use operate from a few IPv4 addresses
--------------------------------------------------------------------

Tony Li wrote recently:

   ... many organizations are very happy sitting behind a NAT box.

A company with a hundred desktop machines could probably run their
network from a single IPv4 address, with mail server, a web server,
NAT box, VPN access etc. - provided they were not making many
machines public facing.

  Side-note on portability:

    I agree that this is quite a likely scenario - so maybe these
    kinds of end-user networks don't absolutely need portable
    address space, because those few  public facing machines and a
    few DNS zone file lines should be easy to change without fuss.

    However, map-encap provides multihoming and TE in a scalable
    fashion by way of portable address space - all in a perfectly
    scalable manner which doesn't further burden the BGP system.
    So why not relax about portability?  The objections to it only
    arise from the restrictions of the current routing system.

Ivip or some other map-encap scheme would make that single IP
address entirely portable to any ISP, and likewise robustly
multihomable with two or more ISPs.  The map-encap schemes are a
good match for this approach, including expanding it as the company
grows.

With Ivip, 2, 3 or whatever contiguous IPv4 addresses could be used.
 (1, 2, 4, 8 for the other map-encap schemes.)  Or separate,
unrelated, single IPv4 addresses or small ranges of them could be
added later.  Each IPv4 address (or small range) can have a separate
mapping, so multiple ISPs can be used to load-share the traffic by
mapping one IPv4 address to one ISP's ETR, another to another ISP's
ETR etc.  Then, in failure mode, they can all be mapped to the
operational ISP's ETR.



3 - For DSL customers etc. double-NAT is easier and better than IPv6
--------------------------------------------------------------------

As Bill Herrin recently wrote, if ISPs are finding it hard to get a
separate IPv4 address for every DSL, cable modem or cell-phone
customer, they will probably put each customer's service on a NATed
private address.  Most DSL and cable modem customers will have a NAT
box in their modem, so the system will have two levels of NAT.

  http://psg.com/lists/rrg/2008/msg01350.html

   > IPv6 may be the future of the Internet, but that future has yet
   > to arrive. The possibility of an IPv44 double-NAT world with
   > lots of little bitty islands of public IPv4 addresses for
   > servers is still in the cards.
   >
   > The nasty thing

{RW: nasty for those who believe the only salvation is imminent IPv6
adoption}

  > is this: Double-nat is  *very* incrementally deployable, so it
  > could deploy ahead of IPv6 in order to relieve the pressure and
  > serve as a stopgap after the end of the IPv4 free pool. But IPv4
  > exhaustion is the only thing driving IPv6 deployment. Relieve
  > that pressure and the expense of IPv6 deployment might well stop
  > it dead.

There would be some practical limits to this, since the ISP's NAT
box has a lot of work to do, and probably needs a UDP and TCP port
for each communication session, but it still enables dozens or maybe
up to a hundred ISP customers to be served via a single IPv4 address.

This is messy, and has costs, but the customers will have full
access to the IPv4 Internet, which is what they need.  I understand
that most and perhaps almost all currently widely used application
protocols are able to work through double NAT.

This will be a lot easier than performing heroics with proxies, ALGs
etc. with the customers having IPv6 addresses.  As far as I know,
ALGs between IPv6-only hosts and the IPv4 internet don't really
exist - and probably can't exist - for many widely used protocols.

For the foreseeable future (to 2020 or so) with the possible
exception of cell-phones, the idea of putting end-users on IPv6-only
addresses is and will remain a complete non-starter for these
reasons at least:

1 - Ordinary end-users will quickly find they can't run their
    full range of (IPv4 only, or IPv6 not-quite-right) applications.

2 - It will never be a fully fledged Internet service, as competing
    ISPs with IPv4 services will gladly point out.

3 - The support costs would be entirely prohibitive:

      Q: My neighbour runs XYZ and it works fine.  When I try this
         application I get %2&*~!/$#&!!!

      A: Oh, that is because XYZ is not compatible with IPv6 - The
         New Kind of Internet.

      Q: Waddya mean "IPv6 . . .".  XYZ works for my neighbour.

      A: Well, your neighbour must have an IPv4 service.  That was
         the previous version of the Internet.

      Q: But his/her service does what I want and my service
         doesn't!

      A:

   It would be impossible to profitably retain customers as long as
   a competing ISP is offering an IPv4 service, including one which
   is behind an ISP's NAT.


   - 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