Short version:   Slightly amended text, followed by a brief
                 reply to Tom Vest's message and some ideas
                 on how large mobile networks could be the
                 first large-scale IPv6 deployments.

                 Changes indicated: *.


Constraints imposed by the need for voluntary adoption        *

    A successful solution to the routing and addressing
    scaling problem is tightly constrained by the need
    for it to be voluntarily adopted, over a period of        *
    years, by the great majority of end-user networks         *
    of all sizes who want or need multihoming, inbound
    traffic engineering and/or portability of their
    address space between ISPs.

    Broadly speaking, this means that at the time of
    introduction:

     1 - The solution must provide immediate and
         compelling benefits to the end-user networks
         who adopt it, irrespective of how many other
         networks have so far adopted it.

     2 - Therefore, it must provide multihoming, TE and
         portability for the adopting networks in a
         manner which fully supports communications with
         all hosts - including all hosts in non-upgraded
         networks.

     3 - Therefore, the solution must be compatible with
         all hosts (stacks and applications) and routers
         in non-upgraded networks.

     4 - The solution must be compatible with all
         existing applications in the adopting networks.

     5 - Although in principle, some or many host stacks
         could be upgraded in the adopting networks, the
         difficulties this presents means that a scalable
         routing solution will only be widely enough
         adopted on a voluntary basis if no such upgrades
         are required in order for the new system to
         provide compelling benefits.

         Firstly, there are difficulties in motivating
         operating system / stack programmers to add and
         test new facilities.  Secondly there may be
         costs and disruption for the adopting network in
         upgrading the stacks.  Thirdly, in many or most
         end-user networks, some or many hosts will not
         be amenable to stack upgrades due to them using
         operating systems which are no longer being
         maintained or developed.  This is especially
         the case for devices such as printers, routers
         etc. which do not use one of the major operating
         systems.

     6 - The solution must be compatible with all
         existing DFZ routers.  (Unless it can be shown
         that all DFZ routers can be upgraded - such as
         via a software update - by the time of
         introduction.)

     7 - The solution must be attractive for the large
         number of smaller networks who currently cannot
         get PI space to do multihoming etc.  Our goal is
         not just to reduce the number of DFZ routes but
         to enable a much larger number of end-user
         networks to gain multihoming, TE and portability
         than is currently possible.

     8 - Ideally the solution will also be attractive for
         most or all end-user networks who currently have
         their own PI prefixes.  This is firstly to
         improve scaling by attracting those larger
         end-user networks away from their current
         conventional PI address space usage and secondly
         to ensure that smaller networks which aspire to
         be bigger in the future will perceive the new
         kind of scalable end-user network address space
         as suitable for their long-term needs.

     9 - Ideally the new system should not compromise
         security or performance compared to that of
         current PI or PA techniques.  Any degradation
         in security, packet path lengths, end-to-end
         packet transit times, packet loss rates and
         general robustness etc. needs to be more than
         compensated for by reduced costs and/or benefits
         such as a more flexible and responsive
         multihoming restoration capability than is
         possible with current BGP techniques.

    10 - The solution will probably not be widely enough     *
         adopted if it requires upgrades to the internal
         routers of adopting networks - except perhaps in
         small networks such as SOHO where one or a few      *
         inexpensive routers need upgrading anyway to        *
         perform ITR and ETR etc. functions.

    In the longer term - in the years and decades to
    come - upgrades to DFZ routers, to ISP and end-user
    network internal routers and to host stacks can be
    made without significant cost or inconvenience and
    may allow enhanced performance for the new system.


[Optional footnote if most people like it.]

    As a footnote, it should be acknowledged that the         *
    constraints as described above seem to involve great      *
    difficulty in providing any Internet service at all       *
    - based on scalable routing or not - beyond IPv4.         *

    The above text attempts to summarise the real-world
    constraints on a scalable routing solution.  It
    appears that these constraints create a very high
    barrier to migration of significant numbers of
    existing end-user networks from IPv4 to an IPv6
    service, either with or without retaining their
    IPv4 address space.

    It follows that even if IPv6 had a scalable routing
    solution, that the barriers to mass IPv6 adoption
    would remain high.  A potential exception may be         *
    mobile devices, whose functionality may not be as        *
    dependent on full IPv4 connectivity as is the case       *
    for most hosts today.    [See note below.]               *

    Our goal is to solve the routing scaling problem
    in both the IPv4 and IPv6 Internets - and for the
    foreseeable future, the problem only manifests in
    the IPv4 Internet.

    A good IPv4 scalable routing solution may enable         *
    finer divisions in the address space than is             *
    practical with current BGP techniques and so may         *
    contribute to a significantly higher number of           *
    end-user networks being able to use the available        *
    space.  Nonetheless, the finite limits of IPv4           *
    address space remain a serious concern, especially       *
    for newly established ISPs and end-user networks.        *

    On this basis, it would be desirable if a                *
    scalable routing solution, in some way yet to be         *
    determined, facilitated adoption of an alternative       *
    to IPv4 - such as IPv6 - which is a more promising       *
    basis for accommodating billions of hosts, many of       *
    which are expected to be mobile devices.                 *



Note on IPv6 mobile devices.   I am envisaging a situation, such as
in China or other countries, where cellphones and mobile PCs etc.
need an IP address in order for various voice and messaging services
to be provided, and for direct communications between devices in the
same or similar mobile networks.  The huge number of such mobile
devices precludes giving each an IPv4 global unicast address, and for
many purposes (but not global IPv4 connectivity) an IPv6 address may
work fine.

With a sufficiently large number of cellphones etc. on IPv6 like
this, it would be profitable to deploy many commercial IPv6 servers
to provide "content" for these devices would also be.  This would
make non-mobile IPv6-only services more attractive.  This "mobile
first" scenario for widespread IPv6 adoption is the most likely one I
can imagine.  A less likely scenario is certain countries providing
IPv6 only DSL etc. services to customers who cannot access any IPv4
service.



Hi Tom,

I will respond more fully to your thoughtful message separately,
probably with a subject like "Breaking IPv4's constraints".

The main body of text above is intended to be a statement of fact
about the major constraints which arise from our reliance on
widespread voluntary adoption.  This is to complement statements of
the functional goals of the solution - such as to provide a new form
of address space for end-user networks which scalably provides
multihoming, inbound TE and portability.  (Also, I think, support for
global mobility.)

Perhaps if enough people like this text - or some improved version of
it - we could add it to:

  http://tools.ietf.org/html/draft-irtf-rrg-recommendation


I am trying to keep it brief, but would like some kind of footnote to
at least acknowledge the inherently IPv4-centric nature of these
constraints - since IPv4 is not mentioned specifically in the main text.

While this text embodies what I always meant by "incremental
deployability" I am not trying to define this term.  You wrote
several times about my text as if it was to become "RRG "incremental
deployability" recommendations".

I want it to be a concise but reasonably complete statement of some
constraints which most of us agree are are real-world limitations we
must work within.

Only by implication is it a "recommendation" - for how to evaluate
potential solutions: proposals, architectures, candidate designs or
whatever.

I sense you are very concerned about the difficulty of establishing
Internet services beyond the finite constraints of IPv4.  I think
there's nothing which could be written now which would contribute to
a solution to this problem.  I think a footnote is the best way of
acknowledging this.


  - Robin