On Apr 16, 2009, at 11:29 PM, Robin Whittle wrote:

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

Thanks once again Robin.

My concerns would be fully covered if the above language were changed  
slightly...

    A successful solution to the routing and addressing
    scaling problem is tightly constrained by the need
    for it to be both accessible to, and voluntarily adopted by
    the great majority of established and aspiring end-user
    networks who want or need multihoming, inbound
    traffic engineering and/or portability of their address
    space between ISPs. Because this voluntary adoption may
    occur over a period of years, the benefits of the solution
    itself should be broadly accessible to all end-user networks,
    regardless of their size or legacy (pre-solution) protocol
    endowments.

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


     1 - The solution must provide immediate and
         compelling benefits to any new or existing
	end-user network that adopts 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.

I would prefer something along the lines of:

    Our goal is to solve the routing scaling problem in
    in a manner that will accommodate growth of both IPv4
    and IPv6 Internets. Because of the looming exhaustion of
    unallocated IPv4 addresses, this dual protocol orientation
    represents the narrowest possible scope that any candidate
    solution must address in order to have any chance of being
    successful.


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

It's not an unimaginable scenario, but if China was truly hampered by  
a shortage of public IP addresses, that problem would have manifested  
itself years ago, in the course of extending non-mobile, IPv4-based  
Internet access. For a variety of reasons, China instead chose to  
develop alternative approaches for solving this problem -- mechanisms  
that are now coming to be known more widely as "carrier grade NATs."  
Scarcity of IPv4 was almost certainly not the primary factor driving  
this choice, but I would say that among the less obvious  
considerations, the commercial/competitive advantages of operator- 
imposed addressing were at least if not more important than more  
widely remarked-upon concerns about domestic order and state security.  
Thus, I would suggest that the China case tends to point to a quite  
different future than the one you suggest -- one that rather usefully  
illuminates the kind of concerns that I've tried to articulate in this  
exchange.

(for the record: I had the unique privilege of playing a leading role  
in the design, deployment, activation, and shortly thereafter the  
dismantling of the only international joint venture Internet access  
service in China -- the ill-fated "Legend-AOL"... an absolute  
commercial disaster, but an amazing/unique learning experience for me  
personally).

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

I agree with you that it's the most likely of all the plausible  
scenarios that one might imagine today.
Unfortunately, I think that it too is highly unlikely.

Not sure if it was your intent to incorporate the mobile scenario in  
the footnote, but I would recommend leaving it out.


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

I'll look forward to that...

> 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 appreciate the clarification -- was not really clear about the  
"normative" content of the deployability text, apart from the obvious  
(i.e., no coercive authority, etc. -- already covered). In any case,  
any apparent mischaracterizations were the product of uncertainty, and  
not of any positive assumptions on my part that are inconsistent with  
your response... i.e., please consider them to be idiosyncrasies of  
phrasing with no particular relevance.

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

That is fair to say!

> I think there's nothing which could be written now which would  
> contribute to a solution to this problem.

I would hesitate to reach that conclusion, in part for the following  
reason(s):

1. Any future RRG "final product" is almost certain to come after IPv4  
exhaustion and privatization (de facto and/or de jure).

2. If, after that point, RRG solutions are primarily or exclusively  
oriented toward IPv4 scaling/perpetuation, that will effectively put  
RRG in the novel role of maintainer of private/proprietary resources  
-- "proprietary" in a sense not unlike that in which specific branded  
commercial hardware or software is proprietary. The owners of the new  
proprietary resources may be numerous and widely distributed, but it  
will forevermore be a closed group, with something like "membership by  
invitation only."

3. Over the past decade or so, the population of routing system  
participants has been very dynamic, with appx. 5-10% growth in the  
form of new entrants each year (based on RIR "initial allocation"  
transactions involving IPv4) and a somewhat lower (and much harder to  
estimate) rate of departures due to M&A and/or termination of  
service.* After IPv4 runout or privatization (whichever comes first),  
the new add rate is likely to slow down to a trickle, leaving an ever- 
growing population of frustrated would-have-been routing system  
participants. At the same time, the drop rate is likely to increase as  
some large, well-heeled operators accelerate their pursuit of low- 
hanging IPv4 acquisition targets. Overall, this change is going to  
represent a radical, unprecedented break with the Internet growth  
processes of the last two decades. I don't think that it will take  
long for the general public to notice, and react.

If and when all of this comes to pass, "open addressing" will quickly  
achieve, at least, the same level salience/urgency as "scalable  
routing" in the overall RRG problem space. In anticipation of (at the  
very least) this possibility, I would suggest that it would be prudent  
for RRG to capitalize on every possible opportunity to reaffirm its  
commitment to delivering a solution to both problems, starting now.


Thanks again for being receptive to my troublesome and somewhat  
belated expressions of concern...

Tom


*(In the US at least, these routing system population dynamics almost  
exactly parallel those of the commercial banking sector).