Here is my understanding of the scalable routing problem, and how
this is part of the broader question of how to devise a "once in
several decades" architectural enhancement for the IPv4 and IPv6
Internets.
- Robin http://www.firstpr.com.au/ip/ivip/
The scalable routing problem
============================
For brevity:
EUN = End User Network.
PMHTE = Portability, Multihoming and/or Inbound Traffic
Engineering. These the the benefits many EUNs seek and
which they can currently only gain by advertising PI
prefixes in the DFZ - which is the cause of the
scaling problems. See definitions in point 4 below.
CES = Core-Edge (address) Separation architecture - such as
LISP, APT, Ivip, TRRP, TIDR or IRON-RANGER. See
(msg05865). CES architectures require no host changes
and maintain the current two-level IPv4/v6 naming
model. (msg05864)
CEE = Core-Edge (address) Elimination architecture, such as
GSE, ILNP, GLI-Split and Name-Based Sockets. These
only work for IPv6 and require host changes - with
rewritten applications for ILNP and Name-Based Sockets.
All CEE architectures alter the naming model to one
of "Locator/Identifier Separation" (LISP does not do
this - it is a CES architecture).
IPv4 scaling problem and solution constraints
---------------------------------------------
There are several broad aspects to the IPv4 routing scaling problem.
No-one appears to know for sure how many DFZ routers there are, but
all Internet users pay for them indirectly, since all substantial
ISPs have DFZ routers - and any smaller ISP without DFZ routers is
relying on an upstream larger ISP which does.
Also, larger EUNs have DFZ routers, and Internet users in general pay
for the operating costs of many of these larger EUNs. Furthermore
the reliability of Internet communications depends on the DFZ routers
quickly adjusting themselves ("converge") to be able to deliver
packets by suitably short paths, with as little packet loss as
possible due to congestion or paths leading to black holes.
Here are the aspects I perceive to the IPv4 routing scaling problem -
most of which also apply to IPv6.
1 - The growth in the number of prefixes advertised in the DFZ:
http://bgp.potaroo.net
Currently about 300k with a doubling time of about 5 years.
This figure drives several problems:
a - Increasing expense for each DFZ router due to the
correspondingly high number of prefixes in the FIBs.
b - Potentially greater difficulties updating the FIB, such
as computational cost and/or time the FIB can't be used
for classifying packets while updates are applied.
c - extra load on the RIBs due to the number of prefixes - with
DFZ routers with more neighbours being more heavily
affected in terms of the CPU and RAM requirements for
maintaining a two-way conversation with each neighbour
about each prefix.
d - Exacerbating problems with overall stability of the DFZ
control plane. For instance, a single outage will affect
more prefixes, causing more BGP processing, RIB and FIB
updating, more BGP changed announcements etc. Since
routers take time to do this, and due to other problems
with the BGP control plane (such as unwanted updates
occurring due to combinations of topology and MRAI timer
settings) the ability of the entire system to adapt to
changes and "converge" is lessened. "Converge" means
firstly all routers finding best paths which acceptably
forward traffic packets and secondly finding best paths
which are stable without requiring any further changes.
2 - Growth in rate of updates to how these prefixes are announced.
The number of prefixes represents one dimension of the load on
the BGP control plane. Each change adds further load, so the
number of changes in general adds to the routing scaling
problem. Some changes only require adjustments to best paths
of a few DFZ routers. Other changes could, in principle,
require changes to best path, or at least changes to the
AS details each DFZ router announces for the best path (even
if the best path remains the same) affecting many, most or
all DFZ routers.
3 - It is widely agreed that the DFZ can and must scale to handle
the prefixes advertised by ISPs - and that the scalability
problem is due to unsustainable growth in the number of EUNs
which advertise their own prefixes - and in the rates of
change in the way these prefixes are added. These prefixes
are "PI" prefixes. (I use this term to include an alternative
arrangement with the same impact - an EUN with a PA prefix from
one ISP causing it to be advertising in the DFZ by another
ISP.)
4 - Consequently, there are high barriers to EUNs obtaining PI
space and advertising it in the DFZ. These are not high
enough to acceptably constrain the growth in the number of
advertised PI prefixes, but they are already unacceptably
high compared to the need for millions (up to 10 million)
EUNs to gain benefits which are currently only available via
advertising PI space.
Advertising PI space in the DFZ is the only current method by
which an EUN can currently obtain the PMHTE benefits:
Portability - keeping its space when choosing another ISP.
Multihoming - two or more ISPs with session survivability
when switching between them to cope with
ISP or link failure.
Inbound TE - When two or more ISPs are used, the ability
to steer incoming traffic - potentially of
different sorts - between these ISP links for
the purposes of load balancing, optimising
costs, latency reliability or other
considerations.
These high barriers reduce the number of EUNs which can gain
these PMHTE benefits. These barriers also increase the costs
of those which are able to use PI space.
5 - This leads to a more difficult to measure aspect of the
problem: a large number of EUNs which want or need PMHTE
benefits and are currently unable to obtain it, due to the cost
and administrative barriers to obtaining and advertising PI
space.
6 - A further aspect of point 5 is that due to the convention of
not propagating prefixes longer then /24 in the IPv4 DFZ -
an EUN needs at least a /24 prefix before it can obtain PMHTE
benefits. EUNs probably need multiple /24s to be able to do
inbound TE.
While the total amount of space used in advertised /24s is
only a fraction of a percent of advertised space, if it were
somehow possible for millions of EUNs to have their own PI
prefixes, the /24 limit would cause many of them to use more
space than they actually need. The much higher numbers of
the smallest prefix - /24s - than any other length indicates
that the majority of EUNs need 256 IPv4 addresses or less.
(msg06092).
There appears to be broad agreement that the solution to these
problems cannot involve any of:
1 - Souping up all DFZ routers with faster route processors,
bigger FIB capacity etc. (This will continue, but the
current rates of growth in the DFZ and the growing number
of EUNs which can't get PMHTE benefits, together with the
increased costs for all DFZ router operators of paying for
these more capable routers constitutes the ongoing nature
of the routing scaling problem.)
2 - Replacing the DFZ with anything fundamentally different.
Firstly, it is not clear what would work better than BGP.
Secondly, if something different would work better - there
seem to be insurmountable barriers to adopting it.
3 - Erecting financial or administrative barriers to EUNs obtaining
PI space and advertising it in the DFZ. This would be
administratively difficult, would introduce competition
policy problems and would merely contain one aspect of the
scaling problem (the growth in the number of DFZ prefixes)
by worsening the other aspects: the number of EUNs which can't
get PMHTE benefits and the higher costs incurred by those who
are able to advertise PI space.
4 - Solutions to the "portability" problem along the lines of
EUNs not having truly portable space (or in a CEE architecture,
not having portable host identifiers) and having some
supposedly "acceptable" means of automatically renumbering
the hosts and routers in their networks, when changing ISPs.
For many networks, no such mechanism can come close to the
benefits of true portability, because the IP addresses of their
network and hosts may be stored in many other places beyond
their control, such as ACLs.
For example, a university may subscribe to many journals and
the journal sites give free access to hosts in the university's
address prefix - using a simple router-based ACL. Changing
the address range of the entire university network, to use a
new ISP, would involve complex, expensive and error prone
administrative costs for the universities and all the journals
it subscribes to.
Therefore, a solution to the IPv4 routing scaling problem would
involve, some combination of the following:
1 - Large numbers of EUNs being able to gain PMHTE - Portability,
Multi-Homing and inbound TE - for their networks in a manner
which placed little extra burden on the DFZ control plane
in general, and on the RIBs and FIBs of DFZ routers.
There is no consensus on numbers of such EUNs with fixed
networks which will want or need PMHTE benefits - but Brian
Carpenter and I have independently suggested 10 million as a
long-term upper bound. (BC msg05801). The RADIR Problem
Statement refers to "millions": "there are millions of
potential end sites which would benefit from being able to
multihome".
2 - Current EUNs with PI space being able to adopt - and actually
adopting - some scalable alternative to their current PI
arrangements. Likewise, EUNs which in the future would
in the absence of a solution, would advertise PI space in
the DFZ.
However, the solution must not involve any of:
1 - Less efficient use of IPv4 address space. (This rules
out CEE, since a CEE-using EUN with N hosts requires at
least N addresses from each ISP.)
2 - Changes to host stacks or applications - since this would
rule out the possibility of the changes being widely enough
adopted to solve the scaling problem. See:
List of constraints on a successful scalable routing solution
which result from the need for widespread voluntary adoption
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
3 - Assuming that IPv4 usage will decline (as most end-users
migrate to IPv6 and no longer need IPv4 space) fast enough
to make the IPv4 scaling problem not worth solving.
Future trends for the IPv4 routing scaling problem are the subject of
debate. Some argue that since IPv4 space is running out rapidly that
migration to IPv6 must begin soon and that therefore the routing
scaling problem in IPv4 will become either less significant and/or
will not grow as fast as in the past.
I believe the growth will accelerate as there is more slicing and
dicing of the available space to use it with more total hosts -
driving up the number of prefixes in the DFZ, of both EUNs and ISPs.
See the (msg05946) thread mentioned below for more on this.
In several recent RRG messages (sorry, I don't have their numbers
handy) people have expressed the view that IPv4 will be important for
a very long time, or indefinitely.
I believe that attempting to solve the IPv4 routing scaling problem
by solving the IPv6 routing scaling problem and moving the great
majority of end-users to IPv6 would be analogous to solving the
Earth's global warming problem by solving any such problems on Mars -
and assuming that most of humanity will move to Mars since Earth is
so obviously over-crowded.
Since we can only develop and suggest the adoption of technologies to
solve the routing scaling problem, and since it seems we need wide
adoption (such as 90% percent or more) to substantially solve the
problem - considering the two or more orders of magnitude difference
between the current 300k prefixes and a likely 10 million figure - we
face some "constraints due to the need for widespread voluntary
adoption". Please see my page where I attempt to describe these -
which has been improved after some RRG discussions:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
IPv6 scaling problem and solution constraints
---------------------------------------------
The IPv6 Internet currently has no scaling problem. For a fuller
discussion, please see the thread:
IPv4 & IPv6 routing scaling problems
http://www.ietf.org/mail-archive/web/rrg/current/msg05946.html
The IPv6 Internet has no scaling problem:
http://bgp.potaroo.net/v6/as2.0/
http://bgp.potaroo.net/v6/as6447/
These indicate about 2.6k prefixes with a doubling time
of about 20 months. At these rates it would take 11.4
years (2021) for this measure of the IPv6 scaling problem
to reach the level of today's IPv4 scaling problem. By
then, at the current growth rates, the IPv4 figure would
be about 1.46 million.
The IPv6 scalable routing problem - if and when it arises - is in
principle the same as IPv4's. However, there are some differing
constraints on the IPv6 solution - and potentially some different
techniques which are applicable to IPv6 which won't work on IPv6.
The constraints on IPv4 solutions due to shortage of global unicast
address space don't apply to IPv6. So CEE architectures could solve
the IPv6 problem. CEE architectures are wasteful of global unicast
address space, since each multihomed EUN with a /X prefix of IP
address space for the Locators of its hosts needs to obtain a /X PA
prefix from each of its upstream ISPs. Also, some CEE architectures
implement Locator / Identifier Separation by encoding both the host's
Identifier and its Locator into the one IPv6 address.
The Modified Header Forwarding techniques of Ivip - alternatives to
encapsulation for tunneling packets from ITRs to ETRs - are different
for IPv4 and IPv6:
http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw
http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/
Also, with IPv6's much lower base of hosts and routers - and with the
lesser urgency of widely deploying a solution - there is probably a
lot more scope than in IPv4 for upgrading routers (including DFZ
routers), host stacks and perhaps applications. Still, I believe
that requiring applications to be altered in any way presents the
greatest of all barriers to adoption. This is particularly the case
for the updates which would be required for an IPv4 or IPv6
application to use the CEE naming model - Locator / Identity
Separation. This may be easy for some applications, but would
require fundamental changes to protocols for others.
It is not absolutely necessary that the IPv4 and IPv6 routing scaling
problems be solved in the same way. However, the task of making
applications run on these systems at the same time - or at least that
the one code-base and set of basic application protocols could work
on all these systems:
IPv4
IPv4 with scalability solution
IPv6
IPv6 with scalability solution
is a further argument against CEE. Only CES architectures require no
changes to applications or stacks. It would be wildly unrealistic to
expect all IPv4 applications to be altered in any way - for any
reason at all, including scalable routing. Of the CEE RRG proposals,
only GLI-Split requires no changes to IPv6 applications - but I am
not yet convinced it will work. (I am yet to get a response from
Michael Menth and colleagues to my msg06056.)
Other problems and goals
========================
I think it would be irresponsible and impractical to develop and
attempt to deploy architectural enhancements - each a once in several
decades opportunity for improving the IPv4 and IPv6 Internets - for
the purpose of solving only a subset of these problems:
IPv4: Routing scalability
Address exhaustion
Mobility
IPv6: Routing scalability
Mobility
IPv4 address exhaustion and Mobility are discussed in sections below.
The forthcoming enhancements must be an effective solution for all
three IPv4 problems and both IPv6 problems.
First I want to mention some other potential problems which an
architectural enhancement might allow (or be constrained by), since
the IPv4 and IPv6 Internets face pressing problems beyond those
listed above.
Computer Security
-----------------
There are general problems of computer security, the ability of
attackers to directly gain control of hosts, or trick their users
into giving them control - but these do not seem to be amenable to
solution in the network itself.
DoS and other attacks
---------------------
There is a general, very serious, problem with the ability of
attackers to mount DoS and other attacks which disrupt Internet
communications.
This is largely a function of the ability of attackers to assemble
(or hire the services of) immense botnets of hundreds or thousands or
millions of compromised hosts, each capable of firing out packets to
the target. This is largely a function of the number of
Net-connected computers, the insecurity of their operating systems
and applications, and the lack or care and expertise of their owners.
The widespread adoption of faster DSL services - and especially
fibre services with much faster upstream links than are possible with
DSL, HFC cable or wireless links - will make this problem even worse.
If it looks like there might be some method of reducing this problem
as part of an architectural enhancement, I think this should be
explored. The ability of a CES architecture such as Ivip or LISP to
in some way help with this problem has not really been explored as
far as I know. I am not sure there is a way of doing so - but it
should be investigated as CES architectures are further developed.
Path MTU Discovery and packet length limits
-------------------------------------------
This is a whole can of worms for IPv4 and IPv6. Please refer to the
thread:
Fred's IPv4 PMTUD research: RFC1191 support frequently broken
http://www.ietf.org/mail-archive/web/rrg/current/msg05910.html
for more information.
PMTUD problem apparently cause minor data loss today on IPv4. The
problems generally involves some tunnels and networks either not
producing PTBs (Packet To Big messages) or dropping them with
filters. There may also be a problem with some hosts (stacks and/or
applications?) not responding properly to PTBs.
These problems lead to workarounds in which packet lengths are
artificially limited - which means that it will be impossible to use
~9k byte jumboframe paths across the DFZ as these become available.
In short, the current situation seems to indefinitely lock us into
slightly sub-1500 byte packets.
There are several worrying things about this. Firstly, the problems
result usually as a combination of circumstances - and can be
difficult to recognise, debug and isolate to the level of identifying
which ISP or other network did the wrong thing with their tunnel
arrangements and/or over-zealous ICMP filtering.
Secondly, each person who encounters these problems tends to adopt
quick-fixes which mask the fundamental problems - thereby enabling
the problems to continue and proliferate, while locking us more and
more into sub-1500 byte packet lengths indefinitely.
Thirdly, neither CES nor CEE routing scaling problems offer any
solution to these problems.
Finally, and most troubling, CES architectures need to use
encapsulation between ITRs and ETRs - unless one of Ivip's Modified
Header Forwarding techniques can be deployed, by upgrading all DFZ
routers, before the Ivip CES architecture itself is deployed. (In
the long-term Ivip should be able to transition from encapsulation to
MHF.) So PMTUD problems may make it significantly more difficult to
introduce a CES architecture.
I am unsure how serious these problems will be - but ITRs will need
to be able to send PTBs to sending hosts and have the sending hosts
respond with suitably shortened packets. If the ITR is outside some
network where the sending host doesn't get these PTBs due to
over-zealous filtering of incoming ICMPs by that network, then this
will cause real difficulties with the CES architecture. The CES
tunneling will frequently reduce packet sizes below what most
networks are used to getting at present.
There is only one proper answer to this situation - removing the
overzealous filtering. Placing the ITR in the network would fix this
problem - but make it harder (not impossible, at least with Ivip's
IPTM arrangement) to do PMTUD for the tunnel to the ETR, because then
the overzealous filtering would drop PTBs coming from routers in any
part of the ITR to ETR tunnel.
Tunnels in the DFZ or other networks which are part of the ITR-->ETR
tunnel and which either don't produce valid PTBs, or only produce
them on the second or subsequent occasion they drop a packet, make it
more difficult for ITRs to successfully judge the Path MTU to the
ETR. This is not insurmountable - but it delays the ability of the
ITR to correctly inform the sending host of the MTU it must use.
My view is that these PMTUD problems arise from people doing things
which are at odds with the Internet standards, and for which there is
no reasonable means of coping defensively. So I believe it would be
easier and better to identify these bad practices and have these
problems fixed, rather than crafting new protocols, such as RFC 4821,
to "route around" the problems. Fred Templin has a different view.
I think the PMTUD difficulties are probably worthy of a concerted
research response along the lines of the current phase of scalable
routing research, which was kicked off by the 2006 RAWS conference in
Amsterdam.
IPv4 address exhaustion and efficient utilization
-------------------------------------------------
This is a far more pressing and well accepted problem than scalable
routing. It is pretty much common knowledge amongst all IT people,
while scalable routing is not so widely known. Also, I think, even
some within the field regard it as a non-problem - well within the
capability of normal (Moore's law etc.) router technological
improvements.
I believe that a successful IPv4 scalable routing solution will, to
the maximum extent possible, "solve" the address exhaustion problem
by allowing very high rates of utilization - the percentage of
actively used IPv4 addresses out of each advertised prefix. Each
IPv4 address may be used for a single host, a NAT box at the end of
DSL, fibre, HFC or wireless service, or a single mobile host.
I believe the only class of solutions which can work for IPv4 are CES
solutions and of the CES RRG proposals, only Ivip or LISP could be
successful. (APT could also work, I think, but it is no longer being
developed.)
Both Ivip and LISP enable the slicing of "edge" space (SPI for Ivip,
EID for LISP) down to separately mapped chunks as small as a single
IPv4 address ("/32"). Ivip's micronets can be any integer number of
IPv4 addresses, while LISP only works in power-of-two prefixes. But
both could, in principle and in practice, scalably allow "edge" space
to be used very flexibly and with a close to 100% utilization level.
This won't forever solve the IPv4 address shortage problem. But
considering the improvements which can be made to utilization in this
manner, and the fact that only about 2.2 billion IPv4 addresses are
so far advertised, out of a total advertisable global unicast range
of 3.7 billion:
"Advertised Address Space" in:
http://bgp.potaroo.net/bgprpts/rva-index.html
I think the successful adoption of a CES architecture such as Ivip or
LISP will give us another 10 or more years of IPv4 usage without
really "running out" of addresses *except* for the desire to give 5
billion or more mobile devices their own global unicast scalable (SPI
or EID) "edge" address. Most of those billions of mobile IP devices
are going to have to work either behind NAT for IPv4 and/or on IPv6.
Since I believe only Ivip or LISP or the like could solve the IPv4
routing scaling problem, and since I believe each would offer the
best possible means of maximising IPv4 address utilization, I don't
think anything further needs to be done regarding this problem.
Indeed, I think that the IPv4 address shortage will probably drive
the adoption of Ivip or LISP for non-mobile networks wanting PMHTE
benefits who don't need large amounts of space and/or which don't
want to get PI space, advertise it in the DFZ etc.
Mobility
--------
While no-one has data about the future, I consider these trends:
Ubiquitous adoption of digital mobile telephony in developed
and developing nations.
Miniaturization of computers into hand-held devices for many
purposes, including playing sound and video, for telephony,
instant messaging (SMS texts and Internet IM protocols),
web-browsing and other Internet applications, micro-payment
systems, GPS capabilities, Bluetooth connections to other
devices etc. etc.
Ubiquitous adoption of Internet communications in developed
and developing nations.
to be analogous to several freight trains approaching the one
junction at full-throttle.
One doesn't need a crystal ball ("data about the future") to be sure
that billions of end-users will soon want Internet access on their
hand-held devices (phones, pads, netbooks, laptops or whatever) AND
that they will want the effective identity of their computer, and its
ongoing communication sessions, to persist despite the device
automatically and frequently connecting to the Internet by a wide
variety of physical link technologies and through various access
networks. Many of these connections will be completely ad-hoc - such
as a 3G network via roaming arrangements in a foreign country, or
using a WiFi service automatically, or with very little user
interaction, simply by being in range of a free service in a public
place.
I consider the upper limit for the number of these devices to be
approximately 10 billion - one or (sometimes two or more) for pretty
much every person on Earth, plus devices for selected pets, cars,
point of sale terminals, vending machines, trucks in vehicle tracking
systems etc.
Many of these devices will connect to IPv4 behind NAT, which
precludes the use of conventional mobile IP techniques. NAT will
hopefully not be used for IPv6.
LISP proposes a form of mobility by which the MN (Mobile Node) acts
as its own ETR. But there are many problems with this, not least its
inability to work behind NAT and the need for each MN to have an IPv4
address of EID space and its own IPv4 address of RLOC space. See the
end of:
http://www.firstpr.com.au/ip/ivip/lisp-links/#critiques
As far as I know, the only way of adequately solving the Mobility
problem - at least as I understand it, for IPv4 and IPv6, with hosts
accessing many networks on an ad-hoc basis, including behind one or
more layers of NAT - is the TTR Mobility architecture:
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
This is an extension to Ivip or perhaps to LISP. Mapping changes are
not required for each new host address. Mapping changes would be
infrequent for most MNs, since they are only needed (and even then,
not absolutely required) when the MN moves more than 1000km or so.
TTR Mobility doesn't require any new elaboration of the basic Ivip
architecture - though it would require many more micronets - up to 10
billion or so, rather than the 10 million or so required without
mobility.
Because of this, I don't see Mobility as being an extra burden on the
enhancement - as long as the enhancement is a CES architecture such
as Ivip or perhaps LISP.
CEE architectures theoretically support mobility, but not for IPv4,
not with the MN behind NAT - and at the cost of the MN having to do
much more routing and addressing work than the relatively simple
extra responsibilities it has in the TTR Mobility architecture.
Solutions
=========
I plan to write a separate message about this, but the short version is:
Many RRG "proposals" are not complete proposals for scalable
routing and can ignored.
Three proposals are are potential solutions, and are not CEE or CES
architectures: "Aggregation with Increasing Scopes" (AIS -
Evolution), hIPv4 and Name Overlay (NOL). I believe these are not
practical solutions.
There are four CEE proposals:
GLI-Split
ILNP
Name-Based Sockets
RANGI
These are only applicable to IPv6, and they all require host stack
changes. All but GLI-Split require upgraded applications. All of
them only provide substantial benefits to adoptors and substantial
routing scaling benefits after essentially all hosts (and therefore
all applications) adopt the new system. These are extraordinarily
high adoption barriers which preclude them from being seriously
considered, since there are CES architectures which could solve
the scaling problems and provide mobility. Even if there were no
such barriers, I would oppose them because I believe their
Locator / Identifier Separation naming model would decrease the
speed of session establishment and unreasonably burden all hosts
with extra traffic and responsibilities. That said, I am not
yet convinced any of these proposals would work as well as their
proponents intend. See (msg05865).
This leaves four CES architectures:
LISP (currently LISP-ALT, but perhaps in the future
with another mapping system)
Ivip (I will soon describe a Distributed Real Time Mapping
System which will be suitable for Ivip and LISP.)
TIDR
IRON-RANGER
TIDR doesn't solve the scaling problem, because the traffic
handling and mapping distribution is done by DFZ routers.
I think IRON-RANGER needs a lot of work before the scaling
and security problems inherent in its continual process of
EID prefix registration with VP routers can be understood
and shown to be resolved. I think it also lacks technical
and business arrangements for supporting packets sent from
non-upgraded networks.
That leaves LISP and Ivip. For reasons I won't repeat here,
I believe Ivip would be a good solution to the problems
discussed here and that LISP in anything like its current form
would be a poor solution. FWIW, if APT were still under
development, I would consider it better than LISP, since
like Ivip, it uses local full-database query servers to
avoid delaying or dropping initial packets.
Other work
==========
Please see the RADIR Problem Statement:
http://tools.ietf.org/html/draft-narten-radir-problem-statement-05
and my comments on it, which I will post after this message. This
message also contains pointers to the RRG Goals ID.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.