An operational issue in the deployed IP Internet is that the IPsec
protocols, AH and ESP, have Security Associations (IPsec SAs) that
include the IP Addresses of the secure IPsec session endpoints. This
was understood to be a problem when AH and ESP were originally
defined in [RFC1825], [RFC1826], and [RFC1827] (which were obsoleted
by [RFC4301], [RFC4302], and [RFC4303]). However, the limited set of
namespaces in the Internet Architecture did not provide any better
choices at that time. ILNP provides more namespaces, thus now
enabling better IPsec architecture and engineering.
7.1. Adapting IP Security for ILNP
In essence, ILNP provides a very simple architectural change to
IPsec: in place of IP Addresses as used today for IPsec SAs, ILNP
uses Node Identifier values instead. Recall that Identifier values
are immutable once in use, so they can be used to maintain end-to-end
state for any protocol that requires it. Note from the discussion
above that the Identifier values for a host remain unchanged when
multihoming and mobility are in use, so IPsec using ILNP can work in
harmony with multihoming and mobility [ABH08b] [ABH09a].
To resolve the issue of IPsec interoperability through a Network
Address Translator (NAT) deployment [RFC1631] [RFC3022], UDP
encapsulation of IPsec [RFC3948] is commonly used as of the date this
document was published. This special-case handling for IPsec traffic
traversing a NAT is not needed with ILNP IPsec.
Further, it would obviate the need for specialised IPsec NAT
traversal mechanisms, thus simplifying IPsec implementations while
enhancing deployability and interoperability [RFC3948].
This architectural change does not reduce the security provided by
the IPsec protocols. In fact, had the Node Identifier namespace
existed back in the early 1990s, IPsec would always have bound to
that location-independent Node Identifier and would not have bound to
7.2. Operational Use of IP Security with ILNP
Operationally, this change in SA bindings to use Identifiers rather
than IP Addresses causes problems for the use of the IPsec protocols
through IP Network Address Translation (NAT) devices, with mobile
nodes (because the mobile node's IP Address changes at each network-
layer handoff), and with multihomed nodes (because the network-layer
IPsec session is bound to a particular interface of the multihomed
node, rather than being bound to the node itself) [RFC3027]
8. Backwards Compatibility and Incremental Deployment
ILNPv6 is fully backwards compatible with existing IPv6. No router
software or silicon changes are necessary to support the proposed
enhancements. An IPv6 router would be unaware whether the packet
being forwarded were classic IPv6 or the proposed enhancement in
ILNPv6. IPv6 Neighbour Discovery will work unchanged for ILNPv6.
ILNPv6 multicasting is the same as IETF standards-track IPv6
ILNPv4 is backwards compatible with existing IPv4. As the IPv4
address fields are used as 32-bit Locators, using only the address
prefix bits of the 32-bit space, IPv4 routers also would not require
changes. An IPv4 router would be unaware whether the packet being
forwarded were classic IPv4 or the proposed enhancement in ILNPv4
[RFC6746]. ARP [RFC826] requires enhancements to support ILNPv4
[RFC6747] [RFC6741]. ILNPv4 multicasting is the same as IETF
standards-track IPv4 multicasting.
If a node supports ILNP and intends to receive incoming network-layer
or transport-layer sessions, the node's Fully Qualified Domain Name
(FQDN) normally will have one or more NID records and one or more
Locator (i.e., L32, L64, and/or LP) records associated with the node
within the DNS [RFC6741] [RFC6742].
When an IP host ("initiator") initiates a new network-layer session
with a correspondent ("responder"), it normally will perform a DNS
lookup to determine the address(es) of the responder. An ILNP host
normally will look for Node Identifier ("NID") and Locator (i.e.,
L32, L64, and LP) records in any received DNS replies. DNS servers
that support NID and Locator (i.e., L32, L64, and LP) records SHOULD
include them (when they exist) as additional data in all DNS replies
to queries for DNS AAAA records [RFC6742].
If the initiator supports ILNP, and from DNS information learns that
the responder also supports ILNP, then the initiator will generate an
unpredictable ILNP Nonce value, cache that value locally as part of
the network-layer ILNP session, and will include the ILNP Nonce value
in its initial packet(s) to the responder [RFC6741] [RFC6744]
If the initiator node does not find any ILNP-specific DNS resource
records for the responder node, then the initiator uses classic IP
for the new network-layer session with the responder, rather than
trying to use ILNP for that network-layer session. Of course,
multiple transport-layer sessions can concurrently share a single
network-layer (e.g., IP or ILNP) session.
If the responder node for a new network-layer session does not
support ILNP and the responder node receives initial packet(s)
containing the ILNP Nonce, then the responder will drop the packet
and send an ICMP error message back to the initiator. If the
responder node for a new network-layer session supports ILNP and
receives initial packet(s) containing the ILNP Nonce, the responder
learns that ILNP is in use for that network-layer session (i.e., by
the presence of that ILNP Nonce).
If the initiator node using ILNP does not receive a response from the
responder in a timely manner (e.g., within TCP timeout for a TCP
session) and also does not receive an ICMP Unreachable error message
for that packet, OR if the initiator receives an ICMP Parameter
Problem error message for that packet, then the initiator concludes
that the responder does not support ILNP. In this case, the
initiator node SHOULD try again to create the new network-layer
session, but this time using IP (and therefore omitting the ILNP
Finally, since an ILNP node also is a fully capable IP node, the
upgraded node can use any standardised IP mechanisms for
communicating with a legacy IP-only node. So, ILNP will not be worse
than existing IP, but when ILNP is used, the enhanced capabilities
described in these ILNP documents will be available.
9. Security Considerations
This proposal outlines a proposed evolution for the Internet
Architecture to provide improved capabilities. This section
discusses security considerations for this proposal.
Note that ILNP provides security equivalent to IP for similar threats
when similar mitigations (e.g., IPsec or not) are in use. In some
cases, but not all, ILNP exceeds that objective and has lower
security risk than IP. Additional engineering details for several of
these topics can be found in [RFC6741].
9.1. Authentication of Locator Updates
All Locator Update messages are authenticated. ILNP requires use of
an ILNP session nonce [RFC6744] [RFC6746] to prevent off-path
attacks, and also allows use of IPsec cryptography to provide
stronger protection where required.
Ordinary network-layer sessions based on IP are vulnerable to on-path
attacks unless IPsec is used. So the Nonce Destination Option only
seeks to provide protection against off-path attacks on an ILNP-based
network-layer session -- equivalent to ordinary IP-based network-
layer sessions that are not using IPsec.
It is common to have non-symmetric paths between two nodes on the
Internet. To reduce the number of on-path nodes that know the Nonce
value for a given session when ILNP is in use, a nonce value is
unidirectional, not bidirectional. For example, for a network-layer
ILNP-based session between nodes A and B, one nonce value is used
from A to B and a different nonce value is used from B to A.
ILNP sessions operating in higher risk environments SHOULD also use
the cryptographic authentication provided by IPsec *in addition* to
concurrent use of the ILNP Nonce.
It is important to note that, at present, a network-layer IP-based
session is entirely vulnerable to on-path attacks unless IPsec is in
use for that particular IP session, so the security properties of the
new proposal are never worse than for existing IP.
9.2. Forged Identifier Attacks
In the deployed Internet, active attacks using packets with a forged
Source IP Address have been publicly known at least since early 1995
[CA-1995-01]. While these exist in the deployed Internet, they have
not been widespread. This is equivalent to the issue of a forged
Identifier value and demonstrates that this is not a new threat
created by ILNP.
One mitigation for these attacks has been to deploy Source IP Address
filtering [RFC2827] [RFC3704]. Jun Bi at Tsinghua University cites
Arbor Networks as reporting that this mechanism has less than 50%
deployment and cites an MIT analysis indicating that at least 25% of
the deployed Internet permits forged Source IP Addresses.
In [RFC6741], there is a discussion of an accidental use of a
duplicate Identifier on the Internet. However, this sub-section
instead focuses on methods for mitigating attacks based on packets
containing deliberately forged Source Identifier values.
Firstly, the recommendations of [RFC2827] and [RFC3704] remain. So,
any packets that have a forged Locator value can be easily filtered
using existing widely available mechanisms.
Secondly, the receiving node does not blindly accept any packet with
the proper Source Identifier and proper Destination Identifier as an
authentic packet. Instead, each ILNP node maintains an ILNP
Communication Cache (ILCC) for each of its correspondents, as
described in [RFC6741]. Information in the cache is used in
validating received messages and preventing off-path attackers from
succeeding. This process is discussed more in [RFC6741].
Thirdly, any node can distinguish different nodes using the same
Identifier value by other properties of their ILNP sessions. For
example, IPv6 Neighbor Discovery prevents more than one node from
using the same source I-LV at the same time on the same link
[RFC4861]. So, cases of different nodes using the same Identifier
value will involve nodes that have different sets of valid Locator
values. A node thus can demultiplex based on the combination of
Source Locator and Source Identifier if necessary. If IPsec is in
use, the combination of the Source Identifier and the Security
Parameter Index (SPI) value would be sufficient to demux two
different ILNP sessions.
Fourthly, deployments in high-threat environments also SHOULD use
IPsec to authenticate control traffic and data traffic. Because
IPsec for ILNP binds only to the Identifier values, and never to the
Locator values, a mobile or multihomed node can use IPsec even when
its Locator value(s) have just changed.
Lastly, note well that ordinary IPv4, ordinary IPv6, Mobile IPv4, and
also Mobile IPv6 already are vulnerable to forged Identifier and/or
forged IP Address attacks. An attacker on the same link as the
intended victim simply forges the victims MAC address and the
victim's IP Address. With IPv6, when Secure Neighbour Discovery
(SEND) and Cryptographically Generated Addresses (CGAs) are in use,
the victim node can defend its use of its IPv6 address using SEND.
With ILNP, when SEND and CGAs are in use, the victim node also can
defend its use of its IPv6 address using SEND. There are no standard
mechanisms to authenticate ARP messages, so IPv4 is especially
vulnerable to this sort of attack. These attacks also work against
Mobile IPv4 and Mobile IPv6. In fact, when either form of Mobile IP
is in use, there are additional risks, because the attacks work not
only when the attacker has access to the victim's current IP
subnetwork but also when the attacker has access to the victim's home
IP subnetwork. Thus, the risks of using ILNP are not greater than
exist today with IP or Mobile IP.
9.3. IP Security Enhancements
The IPsec standards are enhanced here by binding IPsec Security
Associations (SAs) to the Node Identifiers of the endpoints, rather
than binding IPsec SAs to the IP Addresses of the endpoints as at
present. This change enhances the deployability and interoperability
of the IPsec standards, but does not decrease the security provided
by those protocols. See Section 7 for a more detailed explanation.
9.4. DNS Security
The DNS enhancements proposed here are entirely compatible with, and
can be protected using, the existing IETF standards for DNS Security
[RFC4033]. The Secure DNS Dynamic Update mechanism used here is also
used unchanged [RFC3007]. So, ILNP does not change the security
properties of the DNS or of DNS servers.
9.5. Firewall Considerations
In the proposed new scheme, stateful firewalls are able to
authenticate ILNP-specific control messages arriving on the external
interface. This enables more thoughtful handling of ICMP messages by
firewalls than is commonly the case at present. As the firewall is
along the path between the communicating nodes, the firewall can
snoop on the ILNP Nonce being carried in the initial packets of an
ILNP session. The firewall can verify the correct ILNP Nonce is
present on incoming control packets, dropping any control packets
that lack the correct nonce value.
By always including the ILNP Nonce in ILNP-specific control messages,
even when IPsec is also in use, the firewall can filter out off-path
attacks against those ILNP messages without needing to perform
computationally expensive IPsec processing. In any event, a forged
packet from an on-path attacker will still be detected when the IPsec
input processing occurs in the receiving node; this will cause that
forged packet to be dropped rather than acted upon.
9.6. Neighbour Discovery Authentication
Nothing in this proposal prevents sites from using the Secure
Neighbour Discovery (SEND) proposal for authenticating IPv6 Neighbour
Discovery with ILNPv6 [RFC3971].
9.7. Site Topology Obfuscation
A site that wishes to obscure its internal topology information MAY
do so by deploying site border routers that rewrite the Locator
values for the site as packets enter or leave the site. This
operational scenario was presented in [ABH09a] and is discussed in
more detail in [RFC6748].
For example, a site might choose to use a ULA prefix internally for
this reason [RFC4193] [ID-ULA]. In this case, the site border
routers would rewrite the Source Locator of ILNP packets leaving the
site to a global-scope Locator associated with the site. Also, those
site border routers would rewrite the Destination Locator of packets
entering the site from the global-scope Locator to an appropriate
interior ULA Locator for the destination node [ABH08b] [ABH09a]
10. Privacy Considerations
ILNP has support for both:
- Location Privacy: to hide a node's topological location by
obfuscating the ILNP Locator information. (See also Section 7 of
- Identity Privacy: to hide a node's identity by allowing the use of
Node Identifier values that are not tied to the node in some
permanent or semi-permanent manner. (See also Section 11 of
A more detailed exposition of the possibilities is given in [BAK11].
10.1. Location Privacy
Some users have concerns about the issue of "location privacy",
whereby the user's location might be determined by others. The term
"location privacy" does not have a crisp definition within the
Internet community at present. Some mean the location of a node
relative to the Internet's routing topology, while others mean the
geographic coordinates of the node (i.e., latitude X, longitude Y).
The concern seems to focus on Internet-enabled devices, most commonly
handheld devices such as a smartphone, that might have 1:1 mappings
with individual users.
There is a fundamental trade-off here. Quality of a node's Internet
connectivity tends to be inversely proportional to the "location
privacy" of that node. For example, if a node were to use a router
with NAT as a privacy proxy, routing all traffic to and from the
Internet via that proxy, then (a) latency will increase as the
distance increases between the node seeking privacy and its proxy,
and (b) communications with the node seeking privacy will be more
vulnerable to communication faults -- both due to the proxy itself
(which might fail) and due to the longer path (which has more points
of potential failure than a more direct path would have).
Any Internet node that wishes for other Internet nodes to be able to
initiate transport-layer or network-layer sessions with it needs to
include associated address (e.g., A, AAAA) or Locator (e.g., L32,
L64, LP) records in the publicly accessible Domain Name System (DNS).
Information placed in the DNS is publicly accessible. Since the goal
of DNS is to distribute information to other Internet nodes, it does
not provide mechanisms for selective privacy. Of course, a node that
does not wish to be contacted need not be present in the DNS.
In some cases, various parties have attempted to create mappings
between IP Address blocks and geographic locations. The quality of
such mappings appears to vary [GUF07]. Many such mapping efforts are
driven themselves by efforts to comply with legal requirements in
various legal jurisdictions. For example, some content providers
reportedly have licenses authorising distribution of content in one
set of locations, but not in a different set of locations.
ILNP does not compromise user location privacy any more than base
IPv6. In fact, by its nature ILNP provides additional choices to the
user to protect their location privacy.
10.2. Identity Privacy
Both ILNP and IPv6 permit use of identifier values generated using
the IPv6 Privacy Address extension [RFC4941]. ILNP and IPv6 also
support a node having multiple unicast addresses/locators at the same
time, which facilitates changing the node's addresses/locators over
time. IPv4 does not have any non-topological identifiers, and many
IPv4 nodes only support one IPv4 unicast address per interface, so
IPv4 is not directly comparable with IPv6 or ILNP.
In normal operation with IPv4, IPv6, or ILNP, a mobile node might
intend to be accessible for new connection attempts from the global
Internet and also might wish to have both optimal routing and maximal
Internet availability, both for sent and received packets. In that
case, the node will want to have its addressing or location
information kept in the DNS and made available to others.
In some cases, a mobile node might only desire to initiate network-
layer or transport-layer sessions with other Internet nodes, and thus
not desire to be a responder, in which case that node need not be
present in the DNS. Some potential correspondent nodes might, as a
matter of local security policy, decline to communicate with nodes
that do not have suitable DNS records present in the DNS. For
example, some deployed IPv4-capable mail relays refuse to communicate
with an initiating node that lacks an appropriate PTR record in the
In some cases (for example, intermittent electronic mail access or
browsing specific web pages), support for long-lived network sessions
(i.e., where network-layer session lifetime is longer than the time
the node remains on the same subnetwork) is not required. In those
cases, support for node mobility (i.e., network-layer session
continuity even when the SNPA changes) is not required and need not
If an ILNP node that is mobile chooses not to use DNS for rendezvous,
yet desires to permit any node on the global Internet to initiate
communications with that node, then that node may fall back to using
Mobile IPv4 or Mobile IPv6 instead.
Many residential broadband Internet users are subject to involuntary
renumbering, usually when their ISP's DHCP server(s) deny a DHCP
RENEW request and instead issue different IP addressing information
to the residential user's device(s). In many cases, such users want
their home server(s) or client(s) to be externally reachable. Such
users today often use Secure DNS Dynamic Update to update their
addressing or location information in the DNS entries, for the
devices they wish to make reachable from the global Internet
[RFC2136] [RFC3007] [LA2006]. This option exists for those users,
whether they use IPv4, IPv6, or ILNP. Users also have the option not
to use such mechanisms.
11.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T.
Chown, "Default Address Selection for Internet Protocol
Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Engineering and Implementation
Considerations", RFC 6741, November 2012.
[RFC6742] Atkinson, R., Bhatti, S., and S. Rose, "DNS Resource
Records for the Identifier-Locator Network Protocol
(ILNP)", RFC 6742, November 2012.
[RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update
Message", RFC 6743, November 2012.
[RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
Option for the Identifier-Locator Network Protocol for
IPv6 (ILNPv6)", RFC 6744, November 2012.
[RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update
Message for the Identifier-Locator Network Protocol for
IPv4 (ILNPv4)", RFC 6745, November 2012.
[RFC6746] Atkinson, R. and S. Bhatti, "IPv4 Options for the
Identifier-Locator Network Protocol (ILNP)", RFC 6746,
[RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol
(ARP) Extension for the Identifier-Locator Network
Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
11.2. Informative References
[8+8] O'Dell, M., "8+8 - An Alternate Addressing Architecture
for IPv6", Work in Progress, October 1996.
[ABH07a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an
Integrated Service Through the Use of Naming",
Proceedings of ACM MobiArch 2007, August 2007, Kyoto,
[ABH07b] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for
Unifying Mobility with Multi-Homing, NAT, & Security",
Proceedings of ACM MobiWAC 2007, Chania, Crete. ACM,
[ABH08a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility
Through Naming: Impact on DNS", Proceedings of ACM
MobiArch 2008, August 2008, ACM, Seattle, WA, USA.
[ABH08b] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised
Resilience, Security, and Mobility Capability for IP",
Proceedings of IEEE Military Communications (MILCOM)
Conference, San Diego, CA, USA, November 2008.
[ABH09a] Atkinson, R., Bhatti, S., and S. Hailes, "Site-
Controlled Secure Multi-Homing and Traffic Engineering
For IP", Proceedings of IEEE Military Communications
(MILCOM) Conference, Boston, MA, USA, October 2009.
[ABH09b] Atkinson, R., Bhatti, S., and S. Hailes, "ILNP:
Mobility, Multi-Homing, Localised Addressing and
Security Through Naming", Telecommunications Systems,
Volume 42, Number 3-4, pp. 273-291, Springer-Verlag,
December 2009, ISSN 1018-4864.
[ABH10] Atkinson, R., Bhatti, S., S. Hailes, "Evolving the
Internet Architecture Through Naming", IEEE Journal on
Selected Areas in Communication (JSAC), vol. 28, no. 8,
pp. 1319-1325, IEEE, Piscataway, NJ, USA, Oct 2010.
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching",
Proceedings of IEEE Global Internet Symposium (GI2011),
Shanghai, P.R. China, 15 April 2011.
[BA12] Bhatti, S. and R. Atkinson, "Secure and Agile Wide-area
Virtual Machine Mobility", Proceedings of IEEE Military
Communications Conference (MILCOM), Orlando, FL, USA,
[BAK11] Bhatti, S., Atkinson, R., and J. Klemets, "Integrating
Challenged Networks", Proceedings of IEEE Military
Communications Conference (MILCOM), Baltimore, MD, USA,
[CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked Terminal
Connections", CERT Advisory 1995-01, Issued 23 Jan 1995,
Revised 23 Sep 1997.
[DIA] Defense Intelligence Agency, "Compartmented Mode
Workstation Specification", Technical Report
DDS-2600-6243-87, US Defense Intelligence Agency,
Bolling AFB, DC, USA.
[DoD85] US National Computer Security Center, "Department of
Defense Trusted Computer System Evaluation Criteria",
DoD 5200.28-STD, US Department of Defense, Ft. Meade,
MD, USA, December 1985.
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of
Defense, Ft. Meade, MD, USA, 31 July 1987.
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture
for IPv6", Work in Progress, February 1997.
[GUF07] Gueye, B., Uhlig, S., and S. Fdida, "Investigating the
Imprecision of IP Block-Based Geolocation", Lecture
Notes in Computer Science, Volume 4427, pp. 237-240,
Springer-Verlag, Heidelberg, Germany, 2007.
[ID-ULA] Hinden, R., Huston, G., and T. Narten, "Centrally
Assigned Unique Local IPv6 Unicast Addresses", Work in
Progress, June 2007.
[IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", Piscataway, NJ, USA, March
[IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the
Interconnection of Datagram Networks", Internet
Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, 29
July 1977, <http://www.rfc-editor.org/ien/ien1.pdf>.
[IEN19] Shoch, J., "Inter-Network Naming, Addressing, and
Routing", IEN 19, January 1978,
[IEN23] Cohen, D., "On Names, Addresses, and Routings", IEN 23,
January 1978, <http://www.rfc-editor.org/ien/ien23.pdf>.
[IEN31] Cohen, D., "On Names, Addresses, and Routings (II)", IEN
31, April 1978,
[IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in
the ARPA Internet Environment", IEN 135, March 1980,
[IPng95] Clark, D., "A thought on addressing", electronic mail
message to IETF IPng WG, Message-ID:
9501111901.AA28426@caraway.lcs.mit.edu, Laboratory for
Computer Science, MIT, Cambridge, MA, USA, 11 January
[LA2006] Liu, C. and P. Albitz, "DNS & Bind", 5th Edition,
O'Reilly & Associates, Sebastopol, CA, USA, May 2006,
[LABH06] Lad, M., Atkinson, R., Bhatti, S., and S. Hailes, "A
Proposal for Coalition Networking in Dynamic Operational
Environments", Proceedings of IEEE Military
Communications Conference, Washington, DC, USA, Nov.
[PHG02] Pappas, A., Hailes, S., and R. Giaffreda, "Mobile Host
Location Tracking through DNS", Proceedings of IEEE
London Communications Symposium, IEEE, London, England,
UK, September 2002.
[RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling
Mobile Networks Through Secure Naming", Proceedings of
IEEE Military Communications Conference (MILCOM),
Boston, MA, USA, October 2009.
[RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment
of Routing for Mobile Networks", Proceedings of IEEE
International Conference on Wireless and Mobile
Computing Networking and Communications (WiMob), IEEE,
Niagara Falls, ON, Canada, Oct. 2010.
[SBK01] Snoeren, A., Balakrishnan, H., and M. Frans Kaashoek,
"Reconsidering Internet Mobility", Proceedings of 8th
Workshop on Hot Topics in Operating Systems, IEEE,
Elmau, Germany, May 2001.
[SIPP94] Smart, B., "Re: IPng Directorate meeting in Chicago;
possible SIPP changes", electronic mail to the IETF SIPP
WG mailing list, Message-ID:
Commonwealth Scientific & Industrial Research
Organisation (CSIRO), Melbourne, VIC, 3001, Australia, 2
[SRC84] Saltzer, J., Reed, D., and D. Clark, "End to End
Arguments in System Design", ACM Transactions on
Computer Systems, Volume 2, Number 4, ACM, New York, NY,
USA, November 1984.
[RFC814] Clark, D., "Name, addresses, ports, and routes", RFC
814, July 1982.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993.
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address
Translator (NAT)", RFC 1631, May 1994.
[RFC1825] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, August 1995.
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826,
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The
Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002,
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
RFC 2956, October 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address
Translation (NAT) Compatibility Requirements", RFC 3715,
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated
Addresses (CGA) Extension Field Format", RFC 4581,
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, July 2007.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
"Report from the IAB Workshop on Routing and
Addressing", RFC 4984, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, September
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", RFC
5570, July 2009.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
[RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced
Deployment Scenarios for the Identifier-Locator Network
Protocol (ILNP)", RFC 6748, November 2012.
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa,
Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson,
Robin Whittle, and John Wroclawski (in alphabetical order) provided
review and feedback on earlier versions of this document. Steve
Blake provided an especially thorough review of an early version of
the entire ILNP document set, which was extremely helpful. We also
wish to thank the anonymous reviewers of the various ILNP papers for
Roy Arends provided expert guidance on technical and procedural
aspects of DNS issues.
Noel Chiappa graciously provided the authors with copies of the
original email messages cited here as [SIPP94] and [IPng95], which
enabled the precise citation of those messages herein.
San Jose, CA 95125
School of Computer Science
University of St Andrews
North Haugh, St Andrews
Fife KY16 9SX