tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6740


Identifier-Locator Network Protocol (ILNP) Architectural Description

Part 3 of 3, p. 36 to 53
Prev RFC Part


prevText      Top      Up      ToC       Page 36 
7.  IP Security for ILNP

   IP Security for ILNP [RFC6741] becomes simpler, in principle, than
   IPsec as it is today, based on the use of IP Addresses as

Top      Up      ToC       Page 37 
   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
   IP Addresses.

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]

Top      Up      ToC       Page 38 
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.

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
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].

Top      Up      ToC       Page 43 
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

Top      Up      ToC       Page 44 
   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

Top      Up      ToC       Page 45 
   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
   be used.

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

11.1.  Normative References

   [RFC768]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                August 1980.

   [RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [RFC793]     Postel, J., "Transmission Control Protocol", STD 7, RFC
                793, September 1981.

Top      Up      ToC       Page 46 
   [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,
                September 2007.

   [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,
                November 2012.

Top      Up      ToC       Page 47 
   [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,
                October 2007.

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

Top      Up      ToC       Page 48 
   [BA12]       Bhatti, S. and R. Atkinson, "Secure and Agile Wide-area
                Virtual Machine Mobility", Proceedings of IEEE Military
                Communications Conference (MILCOM), Orlando, FL, USA,
                Oct 2012.

   [BAK11]      Bhatti, S., Atkinson, R., and J. Klemets, "Integrating
                Challenged Networks", Proceedings of IEEE Military
                Communications Conference (MILCOM), Baltimore, MD, USA,
                November 2011.

   [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
                1997, <

Top      Up      ToC       Page 49 
   [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, <>.

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

   [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:
      , 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,
                ISBN 0-596-10057-4.

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

Top      Up      ToC       Page 50 
   [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
                June 1994.

   [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,
                August 1995.

   [RFC1827]    Atkinson, R., "IP Encapsulating Security Payload (ESP)",
                RFC 1827, August 1995.

Top      Up      ToC       Page 51 
   [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,
                October 1996.

   [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,
                January 2001.

   [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,
                March 2004.

Top      Up      ToC       Page 52 
   [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,
                October 2006.

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

Top      Up      ToC       Page 53 
   [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.

12.  Acknowledgements

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

   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.

Authors' Addresses

   RJ Atkinson
   San Jose, CA  95125


   SN Bhatti
   School of Computer Science
   University of St Andrews
   North Haugh, St Andrews
   Fife  KY16 9SX
   Scotland, UK