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
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
