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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg