[rrg] Scalable solution hitting IPv4's limits

Robin Whittle <rw@firstpr.com.au> Sun, 19 April 2009 15:24 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC19428C214 for <rrg@core3.amsl.com>; Sun, 19 Apr 2009 08:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level:
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_50=0.001, FB_NO_MORE_ADS=1.174, GB_I_INVITATION=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9smLPaAoCwbd for <rrg@core3.amsl.com>; Sun, 19 Apr 2009 08:24:53 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 520C43A6810 for <rrg@irtf.org>; Sun, 19 Apr 2009 08:24:52 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id B27921759D4; Mon, 20 Apr 2009 01:26:06 +1000 (EST)
Message-ID: <49EB4294.2070601@firstpr.com.au>
Date: Mon, 20 Apr 2009 01:26:12 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <49E69AB5.6060409@firstpr.com.au> <FC05B8B8-1E66-4257-AD86-DF97BBB981D0@pch.net> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> <A0F5D6E2-6CEE-415A-BA5D-B865ACE7317F@pch.net>
In-Reply-To: <A0F5D6E2-6CEE-415A-BA5D-B865ACE7317F@pch.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] Scalable solution hitting IPv4's limits
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Apr 2009 15:24:56 -0000

Short version:  Long reply to Tom Vest, discussing his concerns
                about IPv4, even with a scalable routing solution,
                hitting the limits of its address range and so
                causing difficulties for aspiring new ISPs.

                The same issues are covered more concisely in the
                footnote to the draft list of constraints.

                Also, some discussion of the TTR Mobility approach
                in the hope that people will read it and so not be
                so alarmed at the mention of mobility with scalable
                routing.  I first described this in June 2007 and
                this full description, with diagrams, has been
                available for 8 months:

                  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf


Hi Tom,

The list of constraints due to the need for voluntary adoption is at:

   http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

I have added a second last paragraph which mentions some of your
concerns.  As I discuss here and in the Footnote at the above page, I
think your concerns are important but that there is no need to change
the list itself.  I intend it to be a factual list of constraints we
can all agree to - even if some of them seem to be at odds with a
truly satisfactory outcome in terms of endless address space and the
avoidance of barriers to new entrants.


Here is a reply to your message in the "Constraints on a solution
..." thread.  Thanks again for your thoughtful discussion and
constructive suggestions.  You wrote:

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

I have amended the text to:

   be both accessible to, and voluntarily adopted by

and I hope you will find that the new second-last paragraph at least
partially mentions your concerns.

   The benefits resulting from the best imaginable
   solution for IPv4 may be limited by shortage of IPv4
   space and resulting difficulties for new networks in
   gaining this space.  While no such restrictions exist
   with IPv6, constraints similar to 2, 3, 4 and 5 are
   likely to continue to be a barrier to widespread
   migration to IPv6.

I want the list of constraints to be a terse description of things we
all (ideally) agree are true.  The focus is on what is needed for
end-user networks and their ISPs to adopt the solution.

As a statement of fact, this text does not assume that there is a
solution which will meet all these constraints.  I think there will
be solutions which meet them all in IPv4 - but I agree that during '
adoption and in the decades to come, no matter how ubiquitously the
scalable routing solution is adopted and how well it works, the
address space shortage is likely to limit the IPv4 Internet's
capacity to provide multihoming etc. for all end-user networks which
want it.  This includes especially those end-user networks which are
to be established in the future and/or those whose Internet access
would benefit from newly established ISPs who, in practice, may find
it difficult to gain the address space they need.

I added another paragraph at the end:

   The above constraints generally apply for IPv4 when
   end-user networks already have IPv4 space and need to
   retain full connectivity to all, or almost all,
   existing hosts.  They may not apply in other
   circumstances, such as if IPv4 space is unobtainable
   and/or if the functionality of devices in a newly
   established end-user network does not depend so
   strongly on connectivity to IPv4 hosts and/or if the
   hosts in the new network are all purpose built for
   it.  Development of a large IPv6-based cellphone
   network may exemplify these circumstances.

which summarises the example I give in the Footnote about how I can
imagine a newly established IPv6-based cell-phone network not being
so affected by all these constraints.

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

Thanks, I have used this suggestion.


Regarding the Footnote, which I have completely rewritten, you
wrote:

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

Similar text is in the new Footnote.

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

I don't agree with this, for a number of reasons.

Firstly, I don't assume that the only alternative to IPv4 is IPv6.

Secondly I don't assume there is a solution to the IPv4 address
shortage which enables most users to transition to some new protocol
without disruption and costs they would in fact accept.  I think most
end-users would not accept having to abandon applications which work
fine on IPv4 or having to use a network which did not give them full
access to all hosts, most of which are on IPv4.

Can you propose a solution which achieves the goals you want to set
for any scalable routing solution?

I believe the routing scalability problem can be solved for IPv4 and
IPv6 separately, but I am yet to see how any system, involving
scalable routing or not, could provide for mass adoption of IPv6 or
some other protocol or disruption-free migration to that from IPv4.

I think you have argued that a scalable routing solution for IPv4
will not succeed fully if at some point in the future, there is no
more address space to accommodate new end-user networks.  My counter
argument is that in that case, those end-user networks wouldn't be
able to get address space they would use in an unscalable way - so
the real problem is address shortage and not a deficiency in routing
scalability.

I think the IPv4 address shortage - in absolute terms and/or in terms
of overly concentrated control of usable space in the hands of
established networks - will be the biggest limitation on the
successful development of the Internet even if the scalable routing
problem is fixed.

I think IPv4 address exhaustion and fears of (to new entrants) unfair
address distribution outcomes is a far better understood problem than
the routing scaling problem.

Ivip is well suited to making the very best use of IPv4 space - for
instance by giving networks 1, 2, 3, 4, 5 or whatever number of
contiguous IPv4 addresses they need.  I think the most numerous types
of end-user networks will be those which use one or a few IPv4
addresses.  So theoretically we could have a billion such
networks occupying a billion or two addresses with close to 100%
utilization efficiency.

I think LISP or APT could also be used in much the same way, although
their EIDs are restricted to prefixes of 1, 2, 4, 8 etc. IPv4
addresses.  The designers of neither proposal seem to be very
interested in networks with a handful of addresses.  I think the LISP
designers in particular are heavily focused on substantial end-user
networks which have 256 and more IPv4 addresses.

Yet the whole benefit of LISP-ALT is its ability to handle
essentially limitless numbers of EIDs and therefore end-user networks.

I think LISP-NERD, the fastest and simplest of the proposals, could
easily scale to 10 or 20 million EIDs.  Yet it is impossible for me
to imagine more than this number of fixed (non-mobile) end-user
networks ever needing multihoming.  With a population of 10B people,
10M end-user networks would be one for every 1000 people.  I just
cant imagine any more than this number of fixed networks having such
a desire for multihoming to get two physically separate links and
ISPs.  Nor can I imagine more than this number of fixed end-user
networks needing portability.

So if LISP-ALT is going to be better than LISP-NERD, it is only going
to be because LISP-NERD can't scale to the number of EIDs which
LISP-ALT can handle with ease.  (LISP-NERD, APT and Ivip, is far
superior to LISP-ALT or TRRP because these first three involve little
or no delay to any packets while the latter two involve often
significant delays to initial packets due to the delays and perhaps
packet losses inherent in their completely decentralised global query
server networks.

My point is that if LISP-ALT is to be better than LISP-NERD, then it
must be due to LISP-ALT supporting mobile end-user networks.

It can do this, with the TTR Mobility approach - as long as the
designers accept that this involves the ETR is separate from the
end-user network (they currently assume it within the end-user
network) and if they accept the ETR not even being in the access
network - it is in a network of the TTR company (or some network of
an ISP which is where the TTR company has its TTR).  The TTR is
typically physically close to the access network, such as 100km or less:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

So if LISP-ALT is to be superior to LISP-NERD for IPv4 - meaning it
is going to support 100M, 1B, 2B etc. EIDs (and nearly the same
number of end-user networks), then it is going to have to support
Mobility - and mobile devices probably only need a single IPv4 address.

The same is true of APT and Ivip - both can use the TTR Mobility
approach and both must support mobility if they are going to cope
with more end-user networks than LISP-NERD could comfortably handle.

Ivip is intended to scale well to billions of micronets (EIDs in LISP
terminology) and to have many advantages over LISP-ALT/NERD and the
other alternatives, including better modularity and better support
for the TTR Mobility model.


To summarise the above:  Ivip should be highly capable of using IPv4
space in a highly efficient manner.  While the designers of APT and
LISP don't seem to be thinking in these terms, I think their systems
could do much the same.

So I think the best scalable routing system for IPv4 will enable
a very high utilization of IPv4 space.  In principle, this may
provide considerable leeway for new-entrant end-user networks.

With Ivip the new SPI space (Scalable PI space) for each end-user
network will be rented from some company which "own" a much larger
"Mapped Address Block" (MAB), which is a BGP advertised prefix.  A
typical MAB may contain 64K to 1M or whatever IPv4 addresses - and
this can be used for micronets of all sizes, including in principle
64K or 1M or whatever single IPv4 address micronets.

The companies which "own" the MABs and rent out the space will not
necessarily be ISPs.  They will generally be commercial operations
like ISPs, but they don't need an access network.  The MAB company
needs to ensure there are OITRDs (Open ITRs in the DFZ - like LISP
Proxy Tunnel Routers) for its MABs, ideally multiple OITRDs
physically distributed all over the Net.  If it runs them itself, the
MAB company needs to be an AS.  However, it could easily pay some
other company to run those OITRDs.

In a fully developed Ivip system, the global unicast address space
would be divided into several types of usage.  The actual BGP
advertised prefixes for these could be all over the place.

 1 - Conventional prefixes for ISPs which use it for their own
     internal purposes, their servers and routers etc. and for
     providing PA space to many of their customers.  This PA
     space includes substantial end-user networks which need
     multiple addresses.  It also includes the hundreds of
     millions of DSL, cable modem etc. customers who currently
     use a single IPv4 address each.

 2 - Conventional prefixes for end-user networks which are ASes
     and are not using Ivip-mapped space.

 3 - MABs which are "owned" by MAB companies and rented out to
     end-user networks which are using this Ivip-mapped SPI space.

If we imagine an idealised situation in which all the end-user
networks adopt SPI space then this leaves only three categories of
address space:

 1a - ISPs use this for their internal purposes, and for ITR and
      ETR addresses.

 1b - That part of ISP's prefixes which are devoted to their
      numerous PA customers.

 3 -  MAB space which is used with potentially very high utilization
      rates approaching 100% for SPI-using end-user networks.

In the long-term future, here are some figures:

 1a -   100M   } ISPs
               }
 1b - 2,000M   }

 3 -  1,600M   } MAB companies, which are not necessarily ISPs.

Let's say there are 10M fixed end-user networks using SPI space and
that on average they need 80 IPv4 addresses.  Most need less, such as
4 or 8 and quite a few need only 1 or 2.  However a small number of
these are corporations, universities, hospitals, government
departments, hosting companies etc. which need thousands or hundreds
of thousands of IPv4 addresses.

This leaves 800M IPv4 SPI addresses available for mobile end-user
networks - physically mobile devices such as cellphones, media
players or PCs.  There won't be much difference in the near future -
an Iphone or Gphone is arguably all these already.

These will work fine with a single IPv4 address.  These devices can
use this address via Ivip and the TTR Mobility system no matter what
their connection to the Net, including behind NAT.

Many such mobile devices will have their CoA on one of the 1b
addresses - they will have a PA address to themselves.  Others will
be behind NAT, so multiple such devices might be on WiFi etc. behind
NAT and sharing a single 1b address.

These mobile devices need at least one CoA - and they need their own
unique SPI address - type 3, which they rent from the MAB company,
which is not necessarily an ISP.

I think that in your model of IPv4 adoption, the crucial question is
how new entrants:

  Aspiring ISPs

  End-user networks which want an AS and their own PI prefixes.

gain access to address space when it is all held by either existing
ISPs or existing PI-using end-user networks.


In the above model of Ivip usage (I think LISP or APT would be the
same in principle) the system does provide SPI space for potentially
far more end-user networks than could ever have the resources to get
their own PI space.  1, 2, 3, 64 to 128 or similar smallish number of
IPv4 addresses will surely be less expensive than the full costs of
gaining one or more /24 prefixes and having ISPs advertise it in BGP.

(Theoretically the current /24 limit on the prefixes routers accept
could be loosened to allow 128, 64, 32 etc. address prefixes - but I
can't imagine this happening as long as there is already
unsustainable growth in the number of DFZ routes.)


Mobile end-users are dependent on ISPs in one way or another to give
them Internet access and a CoA.  They are also dependent on a MAB
company from whom they rent probably a single IPv4 address, which
they can use via any ISP in the world.  They also need to pay a TTR
company, which needs its own 1a type of space to run its TTRs (which
are ETRs as far as the Ivip system is concerned).  However a single
TTR on a single IP address can simultaneously handle dozens to
hundreds of simultaneous mobile end-users via the one IP address.


A non-mobile end-user network does not need any PA space - since it
has no CoA.  They need one or two ISPs to provide Internet access.
No matter how many SPI addresses each end-user network has, these
only require a single ETR in each of its ISPs.  Each such ETR can
simultaneously serve the needs of many such end-user networks.

With Ivip, the ETRs for fixed end-user networks are in the ISPs they
use.  This is totally different than for LISP, in which each end-user
network has its own ETR for each ISP.  So for LISP, no matter how
many EID addressees the end-user network has, it consumes at least
one IPv4 address for the ETR it uses for each of its two or more
ISPs.   These ETR addresses come from the ISP's 1a type space.  So an
ISP with 10,000 LISP end-user networks needs at least 10,000 separate
type 1a IP addresses for all these ETR addresses.

With Ivip, the same ISP might handle 100 end-user networks with each
of its ETRs, so it only needs 100 type 1a IPv4 addresses.


In this model, it is vital that aspiring ISPs AND MAB companies can
get the address space they need.  To the extent that they can and to
the extent that the compete and provide good services, this enables
the actual SPI-using end-user networks to get the Internet access
they need AND the SPI address space they need.

So your concern about IPv4 address space shortage and control by
incumbents is just as valid as without Ivip.  The details are
different, because MAB companies are not necessarily ISPs, with all
their physical infrastructure in particular locations.


I can imagine Ivip working nicely and providing really high
utilization for the IPv4 address space - provided it is made
available by whoever currently "owns" it.  If, as I suspect, we will
be stuck in IPv4 for a very long time, I think there will be
increasing regulatory pressures to free up underutilised address
space to make it available to ISPs and MAB companies which will use
it efficiently.  Also, those companies which do use it efficiently
will be able to derive profits and so pay a price for the space which
makes it attractive for underutilising companies to sell it.

Still, depending on the world's population and how important it will
be for cellphones/PCs to have a globally mobile IPv4 address, there
may well be a point, even with the fairest distribution of the 3.7B
global unicast IPv4 addresses, where the demand can only be met by
putting some or many mobile devices on IPv6 and/or by forcing some or
many DSL etc. customers onto some second-rate kind of NATed service,
rather than the current practice of giving each customer their own
global unicast IPv4 address.

This is a long way of saying that in principle I agree with your
concerns, but that I can imagine technical and commercial
developments - such as Ivip with TTR mobility - which enable the IPv4
address space to be utilized close to 100%.

Since I foresee the barriers to mass IPv6 adoption (except perhaps
for cellphones) will remain very high, I think it will generally be
cheaper and easier at any one point in time to keep making the most
of IPv4 than to for anyone to try to migrate to IPv6 without using an
IPv4 address.

Arguably, this would be a painful, drawn-out torture.  Maybe it would
be best if the entire IPv4 Internet evaporated sometime soon and
forced everyone to move to IPv6 instead.

It is not a popular position, but I think there is a lot of scope for
squeezing more and more from IPv4 and that we will probably be
depending on it as THE global Internet for decades to come.

At the same time, I am keen to facilitate any development which could
provide a better alternative.


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

I understand from this that what I wrote about widespread IPv6
adoption scenarios is less likely to occur than I suggested.

I am keen to know of anything concerning IPv6 adoption or the lack
thereof in large mobile networks, in China and in other countries
where one might expect the IPv4 address shortage to strongly motivate
the adoption of IPv6-only or perhaps dual stack services.  I think it
is relevant to scalable routing, but perhaps it is too contentious to
be put on the RRG list.

I see you have some research materials at:

  http://tinyurl.com/IPliquidity

which leads to a page at your site http://www.eyeconomics.com .


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

Very interesting.  I hope this learning experience somehow pays the
bills today!  I see http://www.caida.org/home/staff/tvest/ has your
your extensive ~2006 CV and I understand you are part of the RIPE NCC
Science Group, though I found no web pages for this.


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

OK - but see the footnote at:

 http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

for why I think the total functionality of a large IPv6 cellphone
network wouldn't depend so much on IPv4 connectivity as would
conventional Internet services.


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

I wrote a longer footnote which mentions it extensively.

I think that for most RRG folks:

   Scalable_Routing + Mobility = Teeth-itch

I hope people will read:

   http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

and so hopefully realise that a core-edge separation scheme such as
LISP, APT or Ivip can directly support a new ETR-like Translating
Tunnel Router approach to global IP address mobility, for IPv4 and
IPv6.  This would be a good complement to existing MIP techniques.
It does NOT involve frequent mapping changes - such as every time the
MN gets a new CoA.


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

I am hoping that this message and the footnote is a good response to
the interesting matters you have raised so far.


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

OK.

>> ...
>>
>> I sense you are very concerned about the difficulty of establishing
>> Internet services beyond the finite constraints of IPv4.
> 
> That is fair to say!

With good reason, I believe.  While I can imagine Ivip and fair
distribution of IPv4 space creating a better IPv4 outcome than most
people think possible, even if these things eventuate as I hope,
there will be many years of difficulties beforehand.


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

I agree.


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

Yes - but this assumes that the RRG solution could have done more to
enable widespread adoption of IPv6.  That is outside the formal scope
of the RRG's goals, AFAIK.  If I can make Ivip in some way facilitate
migration from IPv4 to IPv6 or any better alternative, I will do so.

Without any specific suggestion for how a scalable routing solution
or anything else could help with easing the dependence on IPv4, I
don't think it is fair to insist that the RRG or anyone else should
do more to achieve such a goal.  I count it as a highly desirable
goal, but not a requirement.   If I thought there was a way of doing
it, then I would change my mind and regard it as a requirement -
because it is so important.

I am trying to keep the list of constraints and its associated test
as terse as possible.  The first of the new paragraphs at least
acknowledges that in practical terms, the constraints apply entirely
within IPv4 and also suggest that constraints similar to 2, 3, 4 and
5 are a major factor in the failure of IPv6 to be widely adopted.

Please suggest improvements, but I am really trying to keep it short.
 It is my experience that anything longer than about 4 paragraphs
tends to be largely ignored by some key RRG people.


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

I know little about these things, but it is easy for me to imagine
the big fish eating the small fish - especially with the economic
crisis.

I guess the most numerous and significant of these aspiring new
networks - in terms of competition policy and in terms of development
of Internet services in countries which are not well served at
present - would be new ISPs and cell-phone companies wanting to be
ISPs to give their customers direct Internet access.

There would also be a growing number of end-user networks - new and
existing - who have the resources and the impetus to get multihoming,
TE and portability with existing BGP techniques, if they could only
get their own PI space.

I think a good scalable routing solution will enable many such
end-user networks to use the new kind of address space, without the
investment in BGP routers and expertise.  Furthermore, many more
smaller networks who would never have the resources or justification
to get PI prefixes will be able to use the new kind of scalable
address space too, for low costs and by using as few IP addresses as
they really need.

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

I fully agree that the RRG should discuss and encourage the design of
scalable routing solutions which also help with:

 1 - Improving IPv4 address space utilization.

        I think any decent core-edge separation scheme will be
        capable of this.


 2 - Fairer allocation of IPv4 addresses to new ISPs.

        I can't see how the RRG can affect this, other than by
        helping to design a flexible, efficient, scalable
        routing system which enables finer slicing and dicing
        of the address space, which is the same thing as 1 above.


 3 - Adoption of and transition to IPv6.

        This nut has never come close to being cracked.  I think
        it may be impossible.  I don't assume it is so, but until
        you or anyone else has a scheme which will work, in part
        by meeting constraints similar to those I listed, I don't
        think it is fair to expect anyone else to solve this
        infernal problem.

I also believe that because the TTR mobility approach is so desirable
and is such an easy extension of a core-edge separation scheme, that
the RRG should take a greater interest in it.

Also, mobility is the only way I can imagine that any of the
proposals LISP-ALT, APT, Ivip or TRRP will be required to scale
beyond the 10M or so EIDs which could easily be handled by the
simpler, more direct and optimally fast LISP-NERD.


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

I really appreciate your messages.  This field has many technical,
human and commercial complexities.  I think progress often results
from detailed, thoughtful discussions.


  - Robin