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).
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
