Re: [rrg] IPv4 & IPv6 routing scaling problems

[Robin Whittle <[e-mail]>]

Short version:     A taxonomy of different types of end-user network
                   including massive adoption of mobile devices in
                   the foreseeable future.

                   Large IPv4 networks doing whatever they can to
                   keep using IPv4.

                   Government-mandated adoption of IPv4 by many
                   larger networks would contribute to the IPv6
                   scaling problem - but may not actually advance
                   genuine IPv6 adoption.


Hi Eric,

Thanks for your appreciative message:

EF> The argument that we are rapidly running out of IPv4 addresses has
EF> always been a significant concern for me personally.  New
deployments
EF> (e.g., civil aviation's ATN IPS) and certain industries that have
vast
EF> numbers of networked devices (e.g., electrical power
EF> industry) are excellent candidates to adopt IPv6 for this very
reason.
EF> However, for the majority of end users, I expect us to prefer to
EF> indefinitely use IPv4 by leveraging map-and-encaps techniques
such as
EF> RANGER, despite the fact that RANGER is part of the effort to
support
EF> a clean migration to IPv6.
> 
>> I agree with all this, except I would use the term Core-Edge Separation 
>> architectures, and at present I think LISP and Ivip are a better solution 
>> than RANGER for either IPv4 or IPv6.

> I value your articulate insights, Robin. 
> 
> You apparently read the above paragraph of mine as trying to
> comment on the technology choice confronting the RRG.

No - I was focused on the main body of what you wrote, not the
mention of map-and-encaps (CES) and RANGER at the end.

My interpretation was that your main points were:

 1 - End-user networks which need massive numbers of IP devices
     and which are installing all new hardware and software to
     achieve this are likely to adopt IPv6.  (I think this is
     particularly the case with wireless linked utility meters
     which are not required to be publicly accessible, don't
     handle large numbers of packets and don't need to communicate
     with all hosts on the IPv4 Internet.)

 2 - Most end-users - who are using the IPv4 Internet day-to-day
     and who need to be able to communicate with any other host
     which is involved in global communications (and all such hosts
     today use IPv4) - will do whatever they can to keep using
     IPv4, rather than attempt to adopt IPv6 to the exclusion of
     IPv4.  This is because the IPv6 Internet doesn't have the
     most important property of the IPv4 Internet: that everyone
     who wants to use Internet communications is using this
     Internet.

 3 - That a successful Core-Edge Elimination architecture (these
     were previously known as map-and-encaps) would enable a more
     intensive use of IPv4 address space - and therefore enable
     more continued use of IPv4 than would otherwise be the case.

A agree with all this, and wanted to signal this while at the same
time noting that I didn't think RANGER was the best example of a
successful Core-Edge Elimination architecture.

What you wrote was primarily about what und-user networks would do -
and I think with an implication that a CES architecture should be
chosen (which I agree with) and with RANGER as an example of such an
architecture - which it is.


> Rather, I was explaining what the large end user has a very high
> probability of doing concerning the issues that the RRG is
> considering. This is a different topic, since I believe that the
> RRG is primarily oriented to ISPs and largely lacks the large end
> user viewpoint.

I think the RRG would benefit from having a lot more hands on deck -
especially from ISPs and end-users of all types, from universities
and corporations, to small businesses, mobile operators and companies
which might be interested in providing global mobility via the TTR
approach.

It is hard for me to say whether ISPs are overly represented in the RRG.

My biggest concern, in addition to general lack of people who are
prepared to read and constructively discuss a variety of proposals,
is that there are a number of people who think it is both practical
and desirable to rewrite all existing Internet applications to
support the Locator / Identifier Separation naming model which they
prefer.  This is what all CEE architectures do - though they do so in
differing ways.

Loc/ID separation is more flexible than the current naming model of
the Internet - and to these people more architecturally correct.
However I think it will slow down the establishment of Internet
communications, and exacerbate the problems of battery-powered hosts
on slow, high-latency, less than 100% reliable wireless links.

CEE takes the load off the routing system.  If CEE was universally
adopted then there would be no more need for PI space.  All hosts
would be using portable Identifiers and there would be no need for PI
space - since portability, multihoming and inbound TE would work fine
with CEE with each end-user network using one or more PA prefixes.

Once CEE was universally adopted, we can keep the current routers,
BGP and the DFZ just as they are.  Until it is universally adopted,
PI prefixes will remain the only way of providing portability and/or
multihoming.

CEE involves burdening all hosts with extra work so the routing
system doesn't need to be altered.

It also involves all applications being modified - many of them
substantially or radically - for CEE.  It also involves a universal
abandonment of IPv4 and the adoption not just of IPv6, but of the
CEE-enhanced IPv6.

Most CEE protocols assume the use of IPv6, because there is room to
put both the Identifier and Locator in the one IPv6 address.  This
does not work with IPv4.  A more fundamental problem is that
multihoming with CEE involves using double the global unicast address
space, or triple if three upstream ISPs are used.  This is never
going to be practical in IPv4.

So not only must all applications be rewritten, they must be moved to
this modified version of IPv6, and all user's Internet access
services will need to support IPv6 as well.

All this to take the load off the routing system and use a naming
model which some people regard as more elegant or architecturally
correct.   I think the routing system should serve the needs of hosts
- and that the current naming model is better than that of Locator /
Identifier Separation.


> Large end users with an adequate supply of IPv4 addresses have a
> strong business motivation to maintain their network infrastructure
> "as is".

Yes - and this is in addition to the absolute requirement, for pretty
much all end-users, that their Internet service enables them to
communicate with all other Internet users.

I think there are two broad types of end-user now and a third in the
near future:

  1 - Those who can do what they want when their hosts are behind
      IPv4 NAT.  This includes most of what home and SOHO users do
      today, and a great deal of what all other end-users, do since
      email, WWW, instant messenger, file upload to public sites and
      SSH to public sites all work fine from behind NAT.

      To the extent that these people want or need a web site, they
      usually find it best to get a cheap hosting arrangement whereby
      another end-user company runs a virtual server for them.

      It seems that everyone and their dog (an Aussie term, but
      literally true in some cases) has a Facebook or MySpace page,
      and this serves their needs for an easily updated WWW page,
      without any fuss or expense with domain names or running their
      own virtual server.

      These people are generally perfectly well served by existing
      single-homed DSL etc. services, with a single IPv4 address
      and their own NAT router (though 99% don't know or understand
      what NAT means).

      However, I think a significant number of these end-users
      rely on port-forwarding from the single IP address their
      home or office is given.  This means they wouldn't be able to
      run certain applications which are important to them if the
      port number is fixed for the application and if the address
      they get is behind a NAT box in the ISP.  That NAT box will
      have one global unicast address and won't be able to satisfy
      the port forwarding requirements of the multiple customers
      which access the Net through the box.

      So these people do fine with a single IPv4 global unicast
      address per home or office - and DHCP allocation of the address
      is fine.  They generally don't need a fixed address, though it
      might be convenient for many if they did, since they could
      use port forwarding to, run their own web server, game
      server etc.  They don't need portability - since it is not too
      difficult to change any DNS they have on the rare occasions
      when they choose another ISP.

  2 - Those who need stable, reliable, public IP addresses to run
      mail-servers, web-servers which they host on their own
      premises, VPN access from other sites and their staff to
      the local network etc.

      a - Some of these can do all this with a single IPv4 address.
          I can do all this with a GNU-Linux box doing NAT, WWW, DNS,
          SMTP, IMAP, SSH etc - all running from a single fixed IPv4
          address.  My DSL service is highly reliable (I don't recall
          an outage in nearly 4 years) and I don't really need
          portability or multihoming.

          I don't need portability or multihoming, since the
          multihoming arrangements could scarcely be more reliable
          than the service I already get, and it would be easy to
          change my DNS to move to a new IPv4 address if I chose
          another ISP.

      b - Other end-user networks which can do what they want
          with a single IPv4 address per physical site, but which
          want/need portability and mulithoming.

          If I was running a more substantial business, especially
          one where I ran my own TLS site for credit card
          transactions and other important customer contact
          purposes, I would want multihoming.

          Even if these end-users have a substantial network,
          this will mainly be of hosts behind NAT.  With a single
          IPv4 address many of them wouldn't really want or
          need portability - but others would.

          This would be particularly the case if they had
          multiple sites and relied on the IPv4 address of each
          site for VPN connections - and didn't want to rework
          all their connections whenever one of their hundreds
          of shops, branch offices etc. chose a new ISP.


      c - End-user networks with substantial networks who need
          larger amounts of global unicast IPv4 address space -
          beyond a handful of IPv4 addresses.

          These end-users want/need portability, multihoming and
          probably inbound TE.

          These organisations range from schools, companies with
          more than a handful of employees, through universities,
          corporations etc. right up to the largest multinational
          companies.

          The larger ones get it now, with their own PI space.  The
          remainder are not getting it - and this is the part of the
          routing scaling problem which is hardest to measure.

      Most of these end-user networks which don't yet have PI
      space could probably work perfectly well from a much
      smaller amount of space than 256 IP addresses.  Quite a
      few of them could probably function OK with a single IPv4
      address.  For instance, a company with a chain of hundreds
      or thousands of shops or small offices all over the world
      could probably run fine with each such office or shop having
      a single IPv4 address

      Even amongst those with PI space, the huge popularity of
      the smallest chunk available (256 IPv4 addresses in a
      /24 prefix) indicates that many or most of them would
      probably get by with significantly less than 256 addresses.


  3 - In addition, in the foreseeable future, there are going to be
      billions of end-users with IP-capable "cell-phones" - or
      whatever such things will be known as - including things which
      are general purpose computing devices, hand-held or laptop.  I
      think these end-users are like the first group, except that
      they are generally not going to be running their own
      WWW, mail or game-servers on their cell-phone.

      There's no way of giving most of these end-users their
      own IPv4 global unicast address space, but I figure they
      could all get IPv4 access via NAT.

      They could all be given their own IPv6 global unicast /64, or
      their own global unicast IPv6 IP address, but these would
      change every time they got a new connection to whatever
      access networks they were using.  When using wired Ethernet
      or using WiFi, at home, or in the office, these cellphones
      laptops and probably iPads etc. would probably get an IPv4
      address behind NAT.

      With a TTR Mobility system in which the MN could tunnel
      to TTRs with either IPv4 or IPv6, and with the TTR system
      using both the IPv4 and IPv6 CES systems, then all these
      end-users could have their own globally mobile, IPv6
      space (such as a /64 or a single IPv6 address).  A subset
      of them could have their own globally mobile IPv4 address
      - since there aren't enough IPv4 addresses for all
      5 billion 10 billion or whatever such mobile devices.


I think you were referring to the larger end-user networks which
roughly fit my 2c classification.

> The only thing that I can see changing this is if a "killer
> app" requires the use of IPv6, but thus far no such "killer app"
> has appeared except in niche contexts (e.g., smart grid, ATN IPS).

Can you suggest any pages with good overviews of the Aeronautical
Telecommunications Network (ATN)?  I understand it is OSI-based, but
that the IPS (Internet Protocol Suite) is an important alternative.

There's nothing in the IPv6 protocols which seems to be superior to
IPv4 from the point of view of most "applications", when thinking of
an "application" as a piece of software running on a PC or server.  I
think there is more Mobile IP support for IPv6.   Better mobility
support and no effective limits on public and private address space
are also important in some "applications" - in a more expansive use
of the term to cover entire global systems, such as the ATN.


> Should one appear, then IPv6 will be deployed as needed and the
> network infrastructure will be modified to accommodate it.

Is this happening with ATN/IPS?


> By contrast, should external business relationships or government
> decrees require IPv6, then the end users' externally facing network
> will support IPv6 but the internal infrastructure itself is
> unlikely to change.

OK.

I am wary of government mandates pushing larger organisations to
adopt IPv6 or whatever.   Some think that they can afford the
whatever this costs - but ordinary people collectively pay for all
these organisations' expenses through taxation or by directly or
indirectly paying for their services.


> Large end users lacking an adequate supply of IPv4 addresses for
> their continued growth are also likely to remain IPv4-only in a
> similar manner for parallel reasons.  There are many map-and-encaps
> technologies that enable end users to retain IPv4 indefinitely in
> combination with private addresses. I only mentioned RANGER because
> I believe that it is a clean alternative.

I don't see how a CES system such as RANGER, LISP or Ivip can
indefinitely meet the needs of end-user networks which require more
global unicast addresses.  NAT can already give client-style access
to IPv4 Internet - and that has nothing to do with a CES architecture.

A CES architecture will enable each physical site of a large
organisation to get one or any number of IPv4 addresses, in a stable,
portable and multihomable fashion, via any one or more ISPs being
used for connectivity.  This will be more flexible and will be less
expensive than the current practice of each site advertising a /24 -
which chews a whole 256 IPv4 addresses, even when only one or a few
are needed at each site.

So I expect a good CES solution will enable a much greater
utilization of IPv4 address space.  But this is not an indefinite
solution, because the 3.7 billion addresses may be too few, at some
stage in the future, for the wants/needs of all Internet users.

It is easy to imagine 3 billion, 6 billion or whatever IP-based
cellphones which ideally would have their own IPv4 address, globally
portable, via TTR Mobility.   That can't happen.

I guess that some people will get their own globally mobile IPv4
address and the rest will make do with NATed IPv4 access.  If they
want globally mobile address space for their cellphone - which would
allow direct application protocols between these devices and
non-mobile networks at home, also with IPv6 space - then there would
be no problem providing this via TTR Mobility.


> Of course, should senior management become convinced to bear the
> expense to internally support IPv6 for patriotic or other
> non-business reasons, then this analysis will not pertain to that
> particular company.

In which case the shareholders will have some interesting questions
for them . . .


> Mergers and acquisitions are a special case that should worry the
> RRG because of the possibility of companies externally advertising
> multiple discontinuous PI address spaces. Of course, such issues
> already exist for corporations using pre-CIDR addresses.

>From the point of view of maximising IPv4 address utilization, we
might expect a pair of merged companies to consolidate their usage
and while leaving some room for expansion (and other acquisitions)
probably be able to return some of the PI space the previously two
companies were using.

However, it would be a lot of work - and maybe it is best to think of
large companies as modular units, not bonded together by
interdependence on shared address space and overly entangled networks.

Untangling a sub-division from the corporate address space and
preparing it for sale to another company sounds like a disruptive and
expensive process.


> Should governments push IPv6, then the issues confronting the RRG
> will become more problematic due to the need to externally route a
> combination of IPv4 and IPv6 for corporations that solely use IPv4
> today and who will probably continue to only use IPv4 internally in
> the future.

Yes, since a properly written regulation would surely require all
corporations, universities or whatever above some size limit to get
their own PI space, advertise it in the DFZ and demonstrate that
their networks (PCs? laser printers?) were fully IPv6 capable.

Affirmative action for IPv6 . . .

 - Robin