[rrg] ILNP: existing applications & other critiques

[Robin Whittle <[e-mail]>]

Hi Ran,

In your "Updating hosts" message you wrote, in part:

> Indeed, ILNP does update hosts, but does so with a 
> clearly documented "backwards compatibility" mechanism
> and also a clearly documented "incremental deployment"
> scheme.
> 
> At least one ILNP prototype already has shown an *un-modified* 
> (i.e. no source code changes, no recompilation) FreeBSD ping6 
> binary using ILNPv6 between a pair of ILNPv6-enabled hosts.
> (NB:  I'm aware of 2 independent implementations of ILNP 
> that are underway, one for Linux and one for FreeBSD.)
> 
> This is a good initial step towards showing that ILNP
> will enable existing "host applications" to be used with
> ILNP -- without requiring application changes.


In I tried to figure out how ILNP could work with existing applications,
as it was claimed to do.  The thread is:

  ILNP: stack behavior to work with IPv6 apps? 2010-07-13
  http://www.ietf.org/mail-archive/web/rrg/current/thrd2.html#07108

Neither I nor anyone else was able to show how it could be done.
Sections 10.4 to 10.6 of RFC6741 seem to be relevant:

  http://tools.ietf.org/html/rfc6741#section-10.5

    Those applications that directly use IP Address values in
    application state or configuration will need to be modified
    for operation over ILNP.

My guess is that this would involve most applications.


This thread:

  Fwd: I-D Action:draft-irtf-rrg-recommendation-09.txt - ILNP problems
  http://www.ietf.org/mail-archive/web/rrg/current/thrd2.html#07185
  2010-08-01

contains further critiques of ILNP including the need for an extra
lookup (compared to the existing host protocols, DNS, IP addressing
etc.) when the responding host needs to ensure its return packet will
either go to the purported sending host (as represented by the initial
packet, which might be from another host) or be dropped by the routing
system if no such host exists.

There was no rebuttal of these critiques, but one RRG participant agreed
they were important.  Also, I can't see how ILNP can adapt securely or
rapidly enough to a host getting a new IP address to support
3G/4G/WiFi-style mobility of IP address, especially for voice applications.

As far as I know, ILNP is only practical for IPv6.  Despite a decade and
a half of faith on the part of many IETF people and repeated "real soon
now" statements about IPv6's imminent widespread adoption, I see no sign
of it.  If a 2012-11-07 statement by Nick Hilliard is to be believed:


https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-November/007374.html


then excluding "the top 10% of the v6 talkers", IPv6 traffic volumes are
an order of 1/100,000 of IPv4 traffic volumes.


I think ILNP represents a logical approach to Locator Identifier
Separation.  (LISP, my Ivip and Fred Templin's IRON are not Locator
Identifier Separation architectures - they are Core Edge Separation
architectures.)  If you accept the impossibility of rapid response to
host mobility, the need for an extra lookup in the common circumstances
I mentioned above, and reliance on the IPv6 Internet, I think it is a
good approach.  The existing BGP system could be retained and there
would be no need to add prefixes to the DFZ for the purposes of
multihoming or mobility.

However I don't believe it can provide the host mobility we need - and
it can't help at all with the IPv4 Internet which everyone uses now and
for the foreseeable future.

I think the IP-address-based host communications and DNS arrangements we
have now are a good thing, in part because it means the recipient host
doesn't have to muck around with costly and time-consuming lookups every
time it replies to a packet in the many cases where that reply must go
only to the host which is identified by the source IP address of the
original packet.

I believe that host mobility (for both IPv4 and IPv6) can be provided
robustly with my TTR Mobility proposal, which is apparently used, in
principle, by IRON for all communications and which could work well with
LISP.  http://www.firstpr.com.au/ip/ivip/#mobile

  - Robin