RFC 6740
Identifier-Locator Network Protocol (ILNP) Architectural Description
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 Identifiers.
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] [RFC3715].
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 multicasting. 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] [RFC6746]. 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 Nonce). 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] [RFC6748].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 [RFC6748].) - 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 [RFC6741].) 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 DNS. 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.
[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.
[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, Japan. [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.
[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, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[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, <http://www.rfc-editor.org/ien/ien19.txt>. [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, <http://www.rfc-editor.org/ien/ien31.pdf>. [IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in the ARPA Internet Environment", IEN 135, March 1980, <http://www.rfc-editor.org/ien/ien135.pdf>. [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 1995. [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. 2006. [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: 199406020647.AA09887@shark.mel.dit.csiro.au, 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.
[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 1999. [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 2001. [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.
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [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 2005. [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 2007. [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 2011. [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 Consultant San Jose, CA 95125 USA EMail: rja.lists@gmail.com SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews Fife KY16 9SX Scotland, UK EMail: saleem@cs.st-andrews.ac.uk