Attached as text/plain.

$ wc -w ILNP-response.txt
     499 ILNP-response.txt


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 <>.

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

Reply via email to