Attached as text/plain. $ wc -w ILNP-response.txt 499 ILNP-response.txt
Ran PS: Significantly more readable ILNP I-Ds have been submitted, and should appear soon at official I-D archives. In the meantime, they can be obtained from <http://ilnp.cs.st-andrews.ac.uk>.
ILNP eliminates the perceived need for PI addressing, and encourage increased DFZ aggregation. Many enterprise users view DFZ scaling issues as too abstruse. So ILNP creates more user-visible incentives to upgrade deployed systems. ILNP mobility eliminates Duplicate Address Detection (DAD), reducing the layer-3 handoff time significantly, compared IETF standard Mobile IP.[ACM MobiArch] ICMP Location updates separately reduce the layer-3 handoff latency. Also, ILNP enables both host multi-homing and site multi-homing. Current BGP approaches cannot support host multi-homing. Host multi-homing is valuable in reducing the site's set of externally visible nodes. Improved mobility support is very important. This is shown by the research literature and also appears in discussions with vendors of mobile devices (smartphones, MP3-players). Several operating system vendors push "updates" with major networking software changes in maintenance releases today. Security concerns mean most hosts receive vendor updates more quickly these days. ILNP enables a site to hide exterior connectivity changes from interior nodes, using various approaches. One approach deploys ULA prefixes within the site and has the site border router(s) rewrite the Locator values. Usual NAT issues don't arise because the Locator value is not used above the network-layer. [MILCOM] [draft-iab-ipv6-nat-02.txt] makes clear that many users desire IPv6 NAT, with site interior obfuscation as a major driver. This makes global-scope PI addressing much less desirable for end sites than formerly. ILNP-capable nodes can talk existing IP with legacy IP-only nodes, with no loss of current IP capability. So ILNP-capable nodes will never be worse off. Secure Dynamic DNS Update is standard, and widely supported in deployed hosts and DNS servers. [Liu] says many sites have deployed this technology without realizing it (e.g. by enabling both the DHCP server and Active Directory of MS-Windows Server). If a node is as mobile as the critique says, then existing IETF Mobile IP standards also will fail. They also use location updates (e.g. MN->HA, MN->FA). ILNP also enables new approaches to security that eliminate dependence upon location-dependent ACLs without packet authentication. Instead, security appliances track flows using Identifier values, and validate the I/L relationship cryptographically [DNSsec] or non-cryptographically by reading the [ILNP-Nonce]. The DNS LP record has a more detailed explanation now. LP records enable a site to change its upstream connectivity by changing the L records of a single FQDN covering the whole site, providing scalability. DNS-based server load balancing works well with ILNP by using DNS SRV records. DNS SRV records are not new, are widely available in DNS clients & servers, and are widely used today in the IPv4 Internet for SLB. Recent ILNP I-Ds discuss referrals in more detail. A node with a binary-referral can find the FQDN using DNS PTR records, which can be authenticated [DNSsec]. Approaches such as [draft-carpenter-behave-referral-object-01.txt] improve user experience and user capability, so are likely to self-deploy. Selection from multiple Locators is identical to an IPv4 system selecting from multiple A records for its correspondent. Deployed IP nodes can track reachability via existing host mechanisms, or by using the SHIM6 method. [RFC 5534]
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg