Objections to burdening hosts with more Routing and Addressing responsibilities

As part of the IRTF Routing Research Group discussions, here is an updated version of my arguments against expecting hosts to do more work than they currently do regarding routing and addressing.  I posted this to the RRG list on 2009-12-06: msg05471.html .

At present, they do not have any Routing and Addressing responsibilities - unless the host is running special Mobile IP protocols.

That's just fine, I think.  However, many people are keen to solve the routing scaling problem by extending the generally successful pattern of "dumb network, smart hosts" so that hosts will be responsible for additional Routing and Addressing functions. 

Generally speaking, these proposals involve the host having one or more "logical" addresses, used by applications, and one or more "physical" addresses.  The host can change one or more physical addresses and still retain session continuity from an application point of view, since the "logical" addresses never change.  Its a nice idea, but the only way of doing it securely involves a great deal of extra complexity in the host, and extra management traffic. 

Even if these were acceptable - and I think they are not - these arrangements have an unavoidable problem in that they delay the delivery of initial traffic packets from the current direct 0.5 RTT (Round Trip Time) to at least 1.5 RTTs.  HIP is an example of such a protocol.  (This is my general understanding of these protocols - please correct me if I am wrong.)

This is because host A can only send a traffic packet to host B, after it has securely established that B is at some physical IP address and has established a secure method of authenticating B if and when it moves to some other physical IP address.

This means significant performance degradation if the two hosts are on opposite sides of the world and/or if one or both are on high latency, unreliable, wireless links.

Robin Whittle  2009-12-18, a copy of the original mailing list message.
Last update: 2010-01-07:

Please see RRG discussions on ILNP in early January 2010.  msg05604 and  msg05610 .
Also, an earlier message along similar lines:
Fundamental objections to a host-based scalable routing solution

I plan to write this all up as an ID as soon as I can.  At present I am revising the Ivip IDs.
The rest of this page is from the original mailing list message.

<< To the main Ivip page.
<< To other pages concerning the RRG in 2009

Objections to burdening hosts with more RA responsibilities

Short version: Even if it were easy to change host stack and
application software (and I think it is very
difficult to change every host, except over decades)
here is an argument directly against what I think
some RRG people prefer.

There is an ideal of "dumb network - smart hosts"
which has served the Internet well, at least in
comparison to the telephone network.

However, extending this principle to *require* that
sophisticated scalable, routing and addressing
functions be performed in hosts is a bad idea.

Its fine to make such functions optionally
implemented in hosts, but burdening *all* end-user
hosts with Routing and Addressing responsibilities,
beyond the current DNS lookup and IP address stuff,
is undesirable since it causes major problems for
hosts which either must be simple and minimal
and/or which connect via slow, unreliable and/or
expensive links.

Even where the hosts are well-connected and
have plenty of CPU resources, these new schemes
typically involve complex interchanges of packets
so two hosts can identify and authenticate each
other's application level identity or address or

At present, a packet can be sent directly and incur
only the delay inherent in the physical network path.
With the proposed protocols in which the end-user
host must perform new routing and addressing
functions, there typically needs to be multiple
packets, including to and from each host, before
user-level communications can occur. So the inherent
physical delays are multiplied by 2 or more.

Such proposals, while conceptually elegant, would
slow down the establishment of user communications
in general, and be unworkably expensive, slow and
less reliable if one or both hosts relies on a slow,
unreliable and/or expensive WiFi, 3G or GEO/LEO
satellite link.

Further to Christian Vogt's message:

Host changes vs. network changes

it is possible to imagine a global network in which every physical
address for end-user networks and their publicly accessible hosts is
PA space. Then only ISPs get PI space and the BGP system keeps
working, with a scaling problem limited to the number of PI prefixes
the ISPs advertise.

In order to do this, either the host networks or the hosts themselves
need to do extra work to create logical addresses to which
applications are bound, where these addresses are not at all tied to
the particular one or more PA addresses the host uses for physical
connection to the Net.

The core-edge separation schemes (LISP, APT, Ivip and TRRP) provide
scalable routing without changing host responsibilities at all.

LISP-CONS/ALT and TRRP frequently involve significant delays to
initial packets, sometimes equivalent to dropping the packets for a
some time like a second or two, while the ITR waits for a map reply
from their global query server networks. APT and Ivip use
full-database local query servers so mapping replies come quickly and
reliably - in a few tens of milliseconds which is typically an
insignificant delay to the commencement of a new communication session.

Other than these delays, the core-edge separation schemes involve no
new delays - and no new responsibilities or management packets - for

The idea of moving all new RA functionality to hosts is to do away
with the need for ITRs, ETRs etc. - though there still may need to be
a mapping database with either local query servers or a global system
to handle map requests.

No-one seems to be advocating such a "change hosts so they do all the
new work" approach for IPv4, but there are various proposals to adapt
IPv6 to this approach, or to develop new addressing regimes. I think
most of these involve new stack <-> application interfaces - and
therefore completely rewritten application software.

Conceptually, this is simple and elegant. I can't imagine how such
as system could be widely adopted on a voluntary basis, but this
message is about the in-principle objections to the outcome, not
about how difficult it would be to have such a scheme widely adopted.

As long as the extra work must be done by the hosts themselves, then
there are some fundamental problems:

1 - This significantly raises the minimum complexity of any
host, in terms of CPU capacity, software requirements and
storage. This is bad for mobile devices and embedded
devices such as electricity meters and the famed IPv6 light

2 - AFAIK, in every potentially practical scheme, a lot of the
burden is in complex cryptographic exchanges which are needed
in order for hosts to be able to reliably identify and
authenticate each other.

3 - There is extra management traffic between the hosts and
probably between each host and some network-centric
support system, such as PKI or a mapping system.

4 - Since no user communications can take place before these
extra tasks are performed, and since these tasks involve
exchange of packets, these proposals mean that it will
generally take longer to begin a communication session
than it does now.

5 - All delays in these packets required for session
establishment - and worse-still, loss of these packets -
will further delay the establishment of user-level

I propose that in any scalable routing system or clean-slate network
redesign, that it better not to require host functionality beyond the
what is currently expected of all hosts:

1 - Except where configuration, software or a previous packet
provides an IP address, use a DNS lookup to get an IP
address of the other host.

2 - Send and receive packets using that IP address and one of the
potentially multiple IP addresses of the current host.

The core-edge separation schemes (LISP, APT, Ivip and TRRP - except
draft-meyer-lisp-mn-00) preserve existing host responsibilities.

Some, such as Ivip, make it possible for sending hosts to perform
their own ITR function, but this is not required of any host. This
is a low-cost and generally efficient approach, except for when the
host is on a slow, expensive or unreliable last-mile link. It would
work ten in principle, but it would tend to slow the establishment of
new sessions due to the delays and packet losses in the local link.

LISP mobile draft-meyer-lisp-mn-00 involves the MN being its own ETR.
The MN does not need to be an ITR, and the ETR function is purely
for decapsulating packets - AFAIK it is not an authoritative query
server for mapping querys sent over the ALT network. Although
draft-meyer-lisp-mn-00 involves this extra ETR responsibility, AFAIK,
this doesn't involve much extra management traffic or delay - so in
terms of this critique, it is fine. The problem is that the MN's CoA
(care of - physical - address) can't be behind NAT. Maybe that's not
such a limitation in IPv6 if IPv6 turns out to be NAT-free. A
critique is at:


The TTR approach to mobility:


retains conventional DNS and IP address host responsibilities, but
has an extra piece of software to provide tunnels to one or more
Translating Tunnel Routers which perform ITR and ETR functions. The
TTRs and potentially some other servers also communicate with this
extra piece of software to find out where the MN is and to coordinate
how it establishes two-way encrypted tunnels to (typically) nearby TTRs.

These are extra host responsibilities, but they do not alter the main
stack or the application software at all. Furthermore, while there
is some overhead of management traffic, such as that required to
ensure full delivery of packets in both directions between the TTR
and the MN, these extra packets do not delay the establishment of new
communication sessions. (Note: this proposal could be adapted to
allow non-retry of some classes of packets, such as streaming media
and VoIP packets.)

What I am arguing against is proposals of the "dumb network, smart
host" variety which require *all* hosts to do some additional complex
things in order to make the whole network more elegant, immune to
scaling problems or whatever.

With hosts today, or with the hosts using a core-edge separation
scheme, each host can send or receive a packet with no extra delay or
traffic on its link (other than the initial packet delays of

We could design a conceptually elegant Internet, with perfectly good
scaling properties, simple routers and PA space for all end-user
hosts, by making every host behave like a MN with its own portable
application layer address (or multiple such addresses) which it
maintains no matter what one or more physical address or addresses it
is physically using. The physical address and logical (application
layer) address could be separate namespaces, or separate sections of
the one addressing range in a single namespace.

HIP is an adaptation of IPv6 which does this. However, it requires
packets flow back and forth between two hosts, and I think packets to
and from other network-based systems, before the two hosts can
establish a communication session upon which actual application-level
packets can travel.

Even if if every host had plenty of CPU power etc. and had fast,
reliable, low-cost links, it would still be unacceptable since it
slows the establishment of every communication, including the
equivalent of a send-and-forget UDP packet, due to the need for
complex cryptographic exchanges. Whatever the delay time due to the
physical separation of the hosts, the speed of light in fibre, or of
radio waves in air, the delay in establishing communications will be
some multiple of the physical delay time, whereas today, there is no
such multiplication of delays beyond the DNS lookup and the TCP

Even if we weren't forced to rely on voluntary adoption to solve the
routing scaling problem, I would still probably favour, for the
"Ideal Internet" design, a system like that of the core-edge
separation schemes, with distinct ITR and ETR functions.

The system would not require any host to perform the ITR function.
However, the ITR function should be optionally possible to implement
in the sending host, since this will often be possible and desirable,
and can be done for no hardware cost whatsoever. (Ivip has this,
though not if the sending host is behind NAT. It would be possible
to extend this to sending hosts behind one or more layers of NAT.)

Maybe a host could be its own ETR, but I the system should never
require this (LISP-MN does require this).

To require every host on the Net to perform all its functions on the
shifting sands of one or more essentially transient PA addresses,
like the CoA addresses of mobile hosts, with no special
transformation of packets in the network itself, is at odds with the
need for mobile devices to be inexpensive, simple and robust when
packets are lost or the link is slow or expensive.

Let the network support the hosts by centrally (such as within each
ISP or end-user network) transforming packets, including tunneling
them between ITRs and ETRs, so all end-user hosts can just get on
with being hosts - so they do not need to be involved in the complex
business of portability, multihoming and inbound traffic engineering.

- Robin