RFC 6740
Identifier-Locator Network Protocol (ILNP) Architectural Description
Identifier-Locator Network Protocol (ILNP) Architectural Description 🎀
- RFC number: 6740
- Stream: Internet Research Task Force (IRTF) 🌸
- Authors: RJ Atkinson (Consultant) and SN Bhatti (U. St Andrews) 💖
- Category: Experimental 🧪
- ISSN: 2070-1721
- Date: November 2012 📅
- Obsoletes / Updates: the header lists no Obsoletes or Updates entries 🙈
Abstract
okay so this doc is the architectural description and concept of operations for the Identifier-Locator Network Protocol (ILNP) ✨ ILNP is an experimental, evolutionary upgrade to IP, and it's a product of the IRTF Routing Research Group 🦋
Status of This Memo
this is NOT an Internet Standards Track spec, babe 🙅♀️ it's published so people can examine it, try it out in experimental implementations, and evaluate it 🔬
it defines an Experimental Protocol for the Internet community 🧪 it's a product of the Internet Research Task Force (IRTF), which publishes research and development results related to the Internet 📚 those results might not be ready for deployment 💀 this RFC is just the individual opinion(s) of one or more members of the Routing Research Group of the IRTF 🗣️ docs approved for publication by the IRSG aren't a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅
if you want the current status, any errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc6740 🫶
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the date of publication 📜 please read those carefully, because they spell out your rights and restrictions for this document 👀
this document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English 🚫✏️
Table of Contents
1. Introduction ....................................................3
1.1. Document Roadmap ...........................................5
1.2. History ....................................................6
1.3. Terminology ................................................7
2. Architectural Overview ..........................................7
2.1. Identifiers and Locators ...................................7
2.2. Deprecating IP Addresses ...................................9
2.3. Session Terminology .......................................10
2.4. Other Goals ...............................................12
3. Architectural Changes Introduced by ILNP .......................12
3.1. Identifiers ...............................................12
3.2. Locators ..................................................14
3.3. IP Address and Identifier-Locator Vector (I-LV) ...........16
3.4. Notation ..................................................16
3.5. Transport-Layer State and Transport Pseudo-Headers ........18
3.6. Rationale for This Document ...............................18
3.7. ILNP Multicasting .........................................19
4. ILNP Basic Connectivity ........................................20
4.1. Basic Local Configuration .................................20
4.2. I-L Communication Cache ...................................21
4.3. Packet Forwarding .........................................22
4.4. Packet Routing ............................................23
5. Multihoming and Multi-Path Transport ...........................24
5.1. Host Multihoming (H-MH) ...................................25
5.2. Support for Multi-Path Transport Protocols ................27
5.3. Site Multihoming (S-MH) ...................................28
5.4. Multihoming Requirements for Site Border Routers ..........29
6. Mobility .......................................................30
6.1. Mobility / Multihoming Duality in ILNP ....................31
6.2. Host Mobility .............................................32
6.3. Network Mobility ..........................................34
6.4. Mobility Requirements for Site Border Routers .............36
6.5. Mobility with Multiple SBRs ...............................36
7. IP Security for ILNP ...........................................36
7.1. Adapting IP Security for ILNP .............................37
7.2. Operational Use of IP Security with ILNP ..................37
8. Backwards Compatibility and Incremental Deployment .............38
9. Security Considerations ........................................39
9.1. Authentication of Locator Updates .........................39
9.2. Forged Identifier Attacks .................................40
9.3. IP Security Enhancements ..................................42
9.4. DNS Security ..............................................42
9.5. Firewall Considerations ...................................42
9.6. Neighbour Discovery Authentication ........................42
9.7. Site Topology Obfuscation .................................43
10. Privacy Considerations ........................................43
10.1. Location Privacy .........................................43
10.2. Identity Privacy .........................................44
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................47
12. Acknowledgements ..............................................531. Introduction ✨
this doc is part of the ILNP document set, which got a LOT of review inside the IRTF Routing RG 🔍 ILNP is one of the recommendations the RG Chairs made 👑 and separately, a bunch of refereed research papers on ILNP have been published during this decade 📄 so the ideas here have been reviewed way beyond just the Routing RG 🌈 the views in this doc were considered controversial by the Routing RG, but the RG still reached consensus that it should get published 😭 the Routing RG has had remarkably little consensus on anything, so basically every Routing RG output is controversial 💀
rn the Internet research and development community is exploring different ways to evolve the Internet Architecture, to tackle a bunch of issues including (but not limited to) scalability of inter-domain routing [RFC4984] 🌍 other hot topics include site multihoming, node multihoming, site/subnet mobility, and node mobility 🚶♀️ the community is considering several classes of evolution 🧩 one class is often called "Map and Encapsulate", where traffic gets mapped and then tunnelled through the inter-domain core of the Internet 🚇 another class is sometimes known as "Identifier/Locator Split" ✂️ this doc is about a proposal in that second class of evolutionary approaches 💖
there's been a LOT of research on naming in the Internet over the years [IEN1] [IEN19] [IEN23] [IEN31] [IEN135] [RFC814] [RFC1498] [RFC2956] 📚 most of it shows that binding end-to-end transport-layer session state to one specific interface of a node at one specific location is undesirable 🙅♀️ for example, it creates avoidable issues for mobility, multihoming, and end-to-end security 🔐 more recently, the authors have been looking at enhancements to certain naming aspects of the Internet Architecture, and they're mindful of that important earlier work 🫶 this started well before the Routing RG was re-chartered to focus on inter-domain routing scalability 🕰️ separately, the Internet Architecture Board (IAB) recently looked at Internet evolution, including naming [RFC6250] 🧐
our ideas and progress so far are in the ongoing definition of an experimental protocol we call the Identifier-Locator Network Protocol (ILNP) 🦋
all the relevant material is up at http://ilnp.cs.st-andrews.ac.uk/ 🔗
at the time of writing, the main body of peer-reviewed research behind the ideas in this doc and its companions is in [LABH06], [ABH07a], [ABH07b], [ABH08a], [ABH08b], [ABH09a], [ABH09b], [RAB09], [ABH10], [RB10], [BA11], [BAK11], and [BA12] 📖✨
in this doc, we:
- a) describe the architectural concepts behind ILNP and how its various capabilities work 🧠 this doc deliberately focuses on the key architectural changes ILNP introduces, and it leaves the engineering discussion to separate documents 🗂️
other docs (listed below) do the rest:
- b) show how ILNP-based functions would work on today's Internet by proposing an instance of ILNP based on IPv6, which they call ILNPv6 (there's also a document describing ILNPv4, which is how ILNP could be applied to IPv4) 🌐
- c) discuss the salient operational and engineering issues that affect deploying ILNPv6 and its impact on the Internet 🛠️
- d) give architectural descriptions of optional advanced capabilities in advanced deployments based on the ILNP approach 🚀
1.1. Document Roadmap ✨
Okay so this doc is the architecture for ILNP (the Identifier-Locator Network Protocol), and it includes the concept of operations 🧠. The authors really want you to read and understand this one first, bestie, because it's the starting point for everything ILNP 💖
ILNP can have more than one engineering instantiation 🦋. You could imagine a "clean-slate" engineering design built on the ILNP architecture. Separate docs describe two specific engineering instances. "ILNPv6" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. "ILNPv4" refers precisely to an instance that is based upon, and backwards compatible with, IPv4.
A lot of the engineering stuff that ILNPv4 and ILNPv6 share is covered in [RFC6741] 🎀. A full engineering spec for either ILNPv6 or ILNPv4 is beyond the scope of this doc, so don't come looking for it here 🙈
If you want the details this doc skips, go check these related ILNP docs:
- a) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
- b) [RFC6742] defines additional DNS resource records that support ILNP.
- c) [RFC6743] defines a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
- d) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by inclusion within the initial packets of an ILNP session) that the node is operating in the ILNP mode and (2) to prevent off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages that are exchanged among ILNP correspondent nodes.
- e) [RFC6745] defines a new ICMPv4 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
- f) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages, and also defines a new IPv4 Identifier Option used by ILNPv4 nodes.
- g) [RFC6747] describes extensions to the Address Resolution Protocol (ARP) for use with ILNPv4.
- h) [RFC6748] describes optional engineering and deployment functions for ILNP. These are not required for the operation or use of ILNP and are provided as additional options.
1.2. History 📜
Okay, history time, and it's kind of a wild one 🕰️ In 1977, Internet researchers at University College London wrote the first Internet Experiment Note (IEN), which talked about issues with interconnecting networks [IEN1]. It flagged the inclusion of network-layer addresses in the transport-layer session state (e.g., TCP checksum) as a big problem for mobile and multihomed nodes and networks. It also proposed separating identity from location as a better approach when designing the TCP/IP protocol suite. Unfortunately, that separation never happened, so the deployed IPv4 and IPv6 Internet entangles upper-layer protocols (e.g., TCP, UDP) with network-layer routing and topology information (e.g., IP Addresses) [IEN1] [RFC768] [RFC793] 😭
The architectural idea behind ILNP comes from a June 1994 note by Bob Smart to the IETF SIPP WG mailing list [SIPP94]. Then in January 1995, Dave Clark sent a similar note to the IETF IPng WG mailing list, suggesting that the IPv6 address be split into separate Identifier and Locator fields [IPng95] 🌸
After that, Mike O'Dell pursued the concept in Internet-Drafts describing "8+8" [8+8] and "GSE" (Global, Site, and End-system) [GSE]. More recently, the IRTF Namespace Research Group (NSRG) studied this around the turn of the century. Unusually for an IRTF RG, the NSRG operated on the principle that unanimity was required for the NSRG to make a recommendation. Atkinson was a member of the IRTF NSRG. At least one other protocol, the Host Identity Protocol (HIP), also derives in part from the IRTF NSRG studies (and related antecedent work). This proposal differs from O'Dell's work in various ways, notably in that it does not require deployment or use of Locator rewriting 🧚
The key idea proposed for ILNP is to directly and specifically change the overloaded semantics of the IP Address. The Internet community has said explicitly, several times, that this overloading is a significant problem with the Internet protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984]. Main character problem, honestly 👑
Research folks have come up with a number of proposals that could provide solutions, but so far there has been little progress on changing the status quo 🥲
1.3. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Read these as the official spec words, not casual vibes 🫶
2. Architectural Overview 🏗️
ILNP takes a different approach to naming communication objects within the network stack. Two new data types are introduced, and they take over the role the IP Address plays at the network and transport layers in the current IP architecture 💅
2.1. Identifiers and Locators 🆔
ILNP straight up replaces the use of IP Addresses with two distinct name spaces, each with its own different semantics:
- a) Identifier: a non-topological name for uniquely identifying a node.
- b) Locator: a topologically bound name for an IP subnetwork.
Here's how the new namespaces compare to IP. Table 1 shows where existing names are used for state information in end-systems or protocols 👀
Layer | IP | ILNP
---------------+----------------------+---------------
Application | FQDN or IP Address | FQDN
Transport | IP Address | Identifier
Network | IP Address | Locator
Physical i/f | IP Address | MAC address
---------------+----------------------+---------------
FQDN = Fully Qualified Domain Name
i/f = interface
MAC = Media Access Control
Table 1: Use of Names for State Information in Various
Communication Layers for IP and ILNPAs Table 1 shows, if an application uses a Fully Qualified Domain Name at the application layer, rather than an IP Address or other lower-layer identifier, then the application sees no architectural difference between IP and ILNP. We call these applications "well-behaved" when it comes to naming, since use of the FQDN at the application layer is recommended in [RFC1958] ✨ Some other applications also avoid using IP Address information within the application-layer protocol, and those count as "well-behaved" too. Any well-behaved application should be able to run on ILNP without any changes. Also note that application-level use of IP Addresses includes application-level configuration information. For example, Apache web server (httpd) configuration files make extensive use of IP Addresses as a form of identity 🙃
ILNP does not require applications to be rewritten to use a new Networking Application Programming Interface (API). So existing well-behaved IP-based applications should be able to work over ILNP as is 🎉
In ILNP, transport-layer protocols use only an end-to-end, non-topological node Identifier in any transport-layer session state. It's really important to note that the node Identifier names the node, not a specific interface on the node. So it has different semantics and properties than the IPv4 address, the IPv6 address, or the IPv6 interface identifier [RFC791] [RFC4291] 🧠
Using the ILNP Identifier value within application-layer protocols is not recommended. Instead, use either a FQDN or some other topology-independent namespace, which is recommended 💜
At the network layer, Locator values, which have topological significance, are used for routing and forwarding of ILNP packets. Locators are not used in upper-layer protocols 🛣️
Another big difference, shown in Table 1, is that there's no binding of a routable name to an interface, or Sub-Network Point of Attachment (SNPA), like there is in IP. In IP, that binding effectively ties transport protocol flows to one specific interface on a node. Applications that put IP Addresses in their application-layer session state also effectively bind to one specific interface on a node [RFC2460] [RFC6724] 🔗
In ILNP, dynamic bindings exist between Identifier values and their associated Locator values, and also between {Identifier, Locator} pairs and (physical or logical) interfaces on the node 🌈
This change gives the Internet Architecture crisp, clear semantics for both the Identifier and the Locator, and it removes the overloaded semantics of the IP Address [RFC1992] [RFC4984]. It does this by updating end-system protocols, without requiring any router or backbone changes 🙌 In ILNP, the closest approximation to an IP Address is an I-L Vector (I-LV), which is a given binding between an Identifier and Locator pair, written as [I, L]. I-LVs are discussed in more detail below 🦋
Where IP packets today have:
- Source IP Address, Destination IP Address
instead, ILNP packets have:
- source I-LV, destination I-LV
Important: it must be emphasised that the I-LV and the IP Address are not equivalent 🚨
With these naming enhancements, the Internet Architecture gets explicit, harmonised support for lots of functions, such as multihoming, mobility, and IPsec 💖
2.2. Deprecating IP Addresses 🎀
okay so ILNP puts an explicit Locator and an Identifier right into the IP packet header, and they replace the usual IP Address 💅. Locators are tied to the topology of the network, so they can change a lot, like whenever the node or site changes its network connectivity 🦋. The node Identifier is way more static. It stays the same for the whole life of a transport-layer session, and it's often a lot longer ✨. There are different options for Identifier values, which [RFC6741] covers. The way I-LVs get encoded into packet headers is also different for IPv4 and IPv6, and [RFC6741] explains that too 🧚.
Identifiers and Locators for hosts get advertised explicitly in DNS, using new Resource Records (RRs) 💖. This is honestly such a logical and reasonable use of DNS, totally analogous to what DNS already does today 🫶. Right now, among other things, DNS maps an FQDN to a set of addresses. Since ILNP replaces IP Addresses with Identifiers and Locators, it's clearly rational to use DNS to map an FQDN to a set of Identifiers and a set of Locators for a node 🔥.
If a DNS owner name has ILNP Locators and Identifiers in the DNS, that's a signal to correspondents that they can try to set up an ILNP-based transport-layer session with that owner name 👑.
Now, in response to [RFC4984], ILNP improves routing scalability by helping multihomed sites work well with Provider Aggregated (PA) address prefixes 📈. Lots of multihomed sites today ask for provider-independent (PI) address prefixes so their sessions survive when one or more access links or Internet Service Providers (ISPs) fail 😭. ILNP gives that transport-layer survivability with a provider-independent Node Identifier (NID) value that is free of any topological semantics 🌸. That NID can be bound dynamically to a Provider Aggregated Locator (L) value, and the Locator is a topological name, i.e., a PA network prefix. Correspondents can switch around among multiple PA Locator values, and survivability still works because changing the L values doesn't need to break transport-layer sessions 🙌. So an ILNP multihomed site gets the full transport-layer and full network-layer session resilience that PI addressing offers today, while using the equivalent of PA addressing. That means the current need for globally visible PI routing prefixes for each multihomed site just goes away 🎉.
2.3. Session Terminology 📚
to make the ILNP spec documents clearer, this section defines the terms "network-layer session" and "transport-layer session" for both IP-based networks and ILNP-based networks 🤓.
Today, network-layer IP sessions have 2 components:
- Source IP Address (A_S)
- Destination IP Address (A_D)
For example, a tuple for an IP layer session would be:
<IP: A_S, A_D>Instead, network-layer ILNP sessions have 4 components:
- Source Locator(s) (L_S)
- Source Identifier(s) (I_S)
- Destination Locator(s) (L_D)
- Destination Identifier(s) (L_S)
and a tuple for an ILNP session would be:
<ILNP: I_S, L_S, I_D, L_D>The phrase "ILNP session" refers to an ILNP-based network-layer session, which has the 4 components in the definition above 💜.
For engineering efficiency, multiple transport-layer sessions between a pair of ILNP correspondents normally share a single ILNP session (I-LV pairs and associated Nonce values) 🍓. Also, for engineering convenience (and to cope with situations where different nodes, at different locations, might use the same I values), the specific implementations of ILNPv6 and ILNPv4 define the use of nonce values:
- Source-to-destination Nonce value (N_S)
- Destination-to-source Nonce value (N_D)
These are explained in more detail in [RFC6741], with [RFC6744] for ILNPv6 and [RFC6746] for ILNPv4 ✨.
Today, transport-layer sessions using IP include these 5 components:
- Source IP Address (A_S)
- Destination IP Address (A_D)
- Transport-layer protocol (e.g., UDP, TCP, SCTP)
- Source transport-layer port number (P_S)
- Destination transport-layer port number (P_D)
For example, a TCP tuple would be:
<TCP: P_S, P_D, A_S, A_D>Instead, transport-layer sessions using ILNP include these 5 components:
- Source Identifier (I_S)
- Destination Identifier (I_D)
- Transport-layer protocol (e.g., UDP, TCP, SCTP)
- Source transport-layer port number (P_S)
- Destination transport-layer port number (P_D)
and an example tuple:
<TCP: P_S, P_D, I_S, I_D>2.4. Other Goals 🌟
we're making big upgrades to the current Internet Architecture, but we still want ILNP instantiations to be:
- a) Backwards compatible: implementations of ILNP should be able to work with existing IPv6 or IPv4 deployments, without requiring application changes 🫶.
- b) Incrementally deployable: to deploy an implementation of ILNP, changes to the network nodes should only be for those nodes that choose to use ILNP. Nodes using ILNP don't require other nodes (that don't use ILNP) to be upgraded 🦋.
3. Architectural Changes Introduced by ILNP 🌈
in this section we go over the key changes made to the current Internet Architecture 🔍. These key changes impact end-systems, rather than routers 💻.
3.1. Identifiers 🪪
Identifiers, also called Node Identifiers (NIDs), are non-topological values that identify an ILNP node 💜. A node might be a physical node or a virtual node. For example, a single physical device might contain multiple independent virtual nodes. Or a single virtual device might be built from multiple physical devices 🧚. In the case of a Multi-Level Secure (MLS) system [DIA] [DoD85] [DoD87] [RFC5570], each valid Sensitivity Label of that system might be a separate virtual node 🔐.
A node MAY have multiple Identifier values associated with it, which MAY be used concurrently 💅.
In normal operation, when a node responds to a received ILNP packet that creates a new network-layer session, the correct NID value to use for that session with that correspondent node will be learned from the received ILNP packet 📬.
In normal operation, when a node starts communicating with a correspondent node, the correct I value to use for that session will be learned either through the application-layer naming, through DNS name resolution, or through some alternative name resolution system 🔎. Another option is that an application may be able to select different I values directly, since Identifiers are visible above the network layer via the transport protocol 🙌.
3.1.1. Node Identifiers Are Immutable during a Session 🔒
Once a Node Identifier (NID) value has been used to establish a transport-layer session, that Node Identifier value forms part of the end-to-end (invariant) transport-layer session state, so it MUST remain fixed for the duration of that session 💖. This means, for example, that throughout the duration of a given TCP session, the Source Node Identifier and Destination Node Identifier values will not change 🫶.
In normal operation, a node won't change its set of valid Identifier values frequently. However, a node MAY change its set of valid Identifier values over time, for example, in an effort to provide identity obfuscation 🕵️♀️, while still following the architectural rule of the preceding paragraph 📜. When a node has more than one Node Identifier value concurrently, the node might have multiple concurrent ILNP sessions with some correspondent node, in which case Node Identifier values MAY differ between the different concurrent ILNP sessions 🌈.
3.1.2. Syntax 🧩
ILNP Identifiers have the same syntax as IPv6 interface identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI], which helps with backwards compatibility 🙈. There is no semantic equivalent to an ILNP Identifier in IPv4 or IPv6 today.
The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6 interface identifiers contains a bit indicating whether the value has global scope or local scope [IEEE-EUI] [RFC4291] 🌍. ILNP Identifiers have either global scope or local scope. If they have global scope, they SHOULD be globally unique 🌟.
Regardless of whether an Identifier is global scope or local scope, an Identifier MUST be unique within the scope of a given Locator value to which it is bound for a given ILNP session or packet flow 🔐. As an example, with ILNPv6, the ordinary IPv6 Neighbour Discovery (ND) processes ensure that this is true, just as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork have the same IPv6 address at the same time 👀.
Both the IEEE EUI-64 specification and the Modified EUI-64 syntax also have a 'Group' bit [IEEE-EUI] [RFC4291]. For both ILNP node Identifiers and IPv6 interface identifiers, this Group bit is set to 0 🫧.
3.1.3. Semantics 🎯
Unicast ILNP Identifier values name the node, rather than naming a specific interface on that node 💅. So ILNP Identifiers have different semantics than IPv6 interface identifiers 🦋.
3.2. Locators 📍
Locators are topologically significant names, analogous to (sub)network routing prefixes. The Locator names the IP subnetwork that a node is connected to 🗺️. ILNP neither prohibits nor mandates in-transit modification of Locator values 🚦.
A host MAY have several Locators at the same time, for example, if it has a single network interface connected to multiple subnetworks (e.g., VLAN deployments on wired Ethernet) or has multiple interfaces each on a different subnetwork 🧃. Locator values normally have Locator Preference Indicator (LPI) values associated with them. These LPIs indicate that a specific Locator value has higher or lower preference for use at a given time ⭐. Local LPI values may be changed through local policy or via management interfaces. Remote LPI values are normally learned from the DNS, but the local copy of a remote LPI value might be modified by local policy relating to preferred paths or prefixes 🛣️.
Locator values are used only at the network layer. Locators are not used in end-to-end transport state, so they aren't used in transport-layer session state or application-layer session state 🙅♀️. However, this does not stop an end-system from setting up local dynamic bindings for a single transport flow to multiple Locator values concurrently 🌸.
The routing system only uses Locators, not Identifiers. For unicast traffic, ILNP uses longest-prefix match routing, just as the IP Internet does 🧭.
Section 4 below describes in more detail how Locators are used in forwarding and routing packets from a sending node on a source subnetwork to one or more receiving nodes on one or more destination subnetworks 📦.
A difference from earlier proposals [GSE] [8+8] is that, in normal operation, the originating host supplies both Source Locator and Destination Locator values in the packets it sends out 🙌.
Section 4.3 describes packet forwarding in more detail, while Section 4.4 describes packet routing in more detail 👑.
3.2.1. Locator Values Are Dynamic
okay so ILNP is super clear that Locators are topologically significant 🗺️ which basically means the set of Locator values a node has usually has to change when its connection to the Internet topology changes 🌐. like, a mobile or multihomed node is gonna have connectivity changes every so often, and its Locators change right along with them 🦋
when a node using a certain set of Locator values changes one or more of them, it has three jobs 💅:
- update its own local knowledge of its own Locator values 📝
- tell all its active Correspondent Nodes (CNs) about the change to its set of Locator values, so that ILNP session continuity stays intact 🫶
- if it expects incoming connections, update its Locator-related entries in the Domain Name System ☁️
[RFC6741] is the one that gets into the engineering and implementation details of all this, so go there if you want the nitty-gritty 🤓
3.2.2. Locator Updates
so Locator values can be dynamic, and they can change for a node in the middle of an ILNP session 😳 which means correspondents need to get notified when a Locator value changes for any existing ILNP session. to make that happen, a node that sees its Locator values have changed MUST send a Locator Update (LU) message to its correspondent nodes 📬 the details of how that works are covered in other ILNP documents: [RFC6741], [RFC6743], and [RFC6745].
(the change in Locator values may also need to be told to DNS, but that's discussed somewhere else 🙈)
3.2.3. Syntax
ILNP Locators have the same syntax as an IP unicast routing prefix 🎀 no new format here, bestie, it's the same vibe ✨
3.2.4. Semantics
ILNP unicast Locators have the same semantics as an IP unicast routing prefix, since they name a specific subnetwork 🏠 and ILNP neither prohibits nor requires in-transit modification of Locator values. so it doesn't ban it and it doesn't demand it either 🤷♀️
3.3. IP Address and Identifier-Locator Vector (I-LV)
okay so historically an IP Address has been treated as one atomic thing 🧱 even though everyone knows it actually has internal structure: the network prefix plus either the host ID (IPv4) or the interface identifier (IPv6). but end-system protocols never really used that internal structure. they just used all the bits 💀 (and also, in IPv4 the subnet mask borrows bits from the host ID, which is extra confusing structure-wise, even though it's a super useful engineering mechanism 🧠)
in ILNP, the IP Address gets replaced by an "Identifier-Locator Vector" (I-LV) ✨ it's a pairing of an Identifier value and a Locator value for that packet, written as [I, L]. every ILNP packet has Source Identifier, Source Locator, Destination Identifier, and Destination Locator values 🫶 the I value is used by upper-layer protocols (e.g., TCP, UDP, SCTP), so it needs to be immutable 🔒 Locators aren't used by upper-layer protocols at all. instead they're kinda like IP routing prefixes, and they only name a specific subnetwork 🗺️
it's possible to say an I-LV is an approximation of an IP Address of today, but you should understand that an I-LV:
- a) is not an atomic datum, since it's a pairing of two data types, an Identifier and a Locator 🫧
- b) has different semantics and properties to an IP Address, as is described in this document 💅
in our discussion it'll be handy to sometimes talk about an I-LV, and sometimes just about an Identifier value, or just a Locator value 🦋
and ILNP packets always contain a source I-LV and a destination I-LV 💖
3.4. Notation
so when we describe how capabilities get implemented in ILNP, we'll compare what the end-systems keep track of in IP versus ILNP, so the architectural changes really pop out 🌈
we define a formal notation for the data in the transport-layer session state 📐 we define:
A = IP Address
I = Identifier
L = Locator
P = Transport-layer port numberto tell the local and remote values apart, we also use suffixes, like:
_L = local
_R = remotewith IPv4 and IPv6 today, the invariant state at the transport layer for TCP can be written as this tagged tuple:
<TCP: A_L, A_R, P_L, P_R> --- (1)the tag values we'll use are:
IP Internet Protocol
ILNP Identifier-Locator Network Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocolso for example, with IP, a UDP packet would look like:
<UDP: A_L, A_R, P_L, P_R> --- (2)a TCP segment carried in an IP packet can be written as this tagged tuple binding:
<TCP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (3)and a UDP packet would have the tagged tuple binding:
<UDP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (4)in ILNP, the transport-layer state for TCP is:
<TCP: I_L, I_R, P_L, P_R> --- (5)and the binding for a TCP segment within an ILNP packet is:
<TCP: I_L, I_R, P_L, P_R><ILNP: L_L, L_R> --- (6)when you compare tuple expressions (3) and (6), you see that for IP, any change to network addresses hits the end-to-end state, but for ILNP, changes to Locator values don't touch the end-to-end state at all 🙌 this gives end-system session state invariance, which is a key ILNP feature compared to how IP gets used in some situations today 😤 ILNP takes the end-to-end approach for its architecture [SRC84] 💜 and as noted previously, nodes MAY have more than one Locator concurrently, and nodes MAY change their set of active Locator values as required 🔄
while these documents don't include SCTP examples, you can use the same notation by just swapping the string "SCTP" in for "TCP" or "UDP" in the examples above 🧚
3.5. Transport-Layer State and Transport Pseudo-Headers
in ILNP, protocols above the network layer don't use the Locator values 🙅♀️ so the transport layer only uses the I values for the transport-layer session state (e.g., TCP pseudo-header checksum, UDP pseudo-header checksum), as shown in expression (6) above 🎀
also, from a practical standpoint: even though the I values are only used by protocols above the network layer, it's convenient for them to ride along in network packets, so the namespace for the I values can be used by any transport-layer protocols running above the common network layer 🌸
3.6. Rationale for This Document
this document gives an architectural description of the core ILNP capabilities and functions 📖 it's built around example scenarios so practical issues can be highlighted 👀
in some cases there are illustrative suggestions and light discussion about engineering issues, but the detailed engineering discussion is deferred to other ILNP documents 📚
the order of the examples below is meant to let you build up an incremental technical understanding of ILNP 🪜 there's no other reason for the ordering, I promise 🙈
a lot of the descriptions use an example site network, shown in Figure 3.1 🏡
site . . . . +----+
network . .-----+ CN |
. . . . +------+ link1 . . +----+
. . | +------. .
. D . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | +------. .
. . . . +------+ link2 . .
. .
. . . .
CN = Correspondent Node
D = Device
H = Host
SBR = Site Border RouterFigure 3.1: A Simple Site Network for ILNP Examples
in some cases, hosts (H) or devices (D) act as end-systems within the site network, and they talk to (one or more) Correspondent Node (CN) instances that are beyond the site 🌍
note that the figure is illustrative and shows a logical view 🧠 for example, the CN may itself be on a site network, just like H or D 🫶
also, for the examples, we assume ILNPv6 is in use 🦋 it has the same packet header format (as viewed by routers) as IPv6, and it can be seen as a superset of IPv6 capabilities 💖
for simplicity, we assume name resolution goes via the deployed DNS, which has been updated to store DNS records for ILNP [RFC6742] 📇
and from an engineering viewpoint, this does NOT mean the DNS also has to be ILNP capable 🙌 existing IPv4 or IPv6 infrastructure can be used for DNS transport ✨
3.7. ILNP Multicasting
multicast forwarding and routing stay unchanged 🌊 this is so we don't need to change deployed IP routers and routing protocols 🛠️ ILNPv4 multicasting is the same as IETF Standards Track IPv4 multicasting [RFC1112] [RFC3376] 🎀 and ILNPv6 multicasting is the same as IETF Standards Track IPv6 multicasting [RFC4291] [RFC2710] [RFC3810] 💜
4. ILNP Basic Connectivity ✨
okay, now we get into the actual basic packet forwarding and routing in ILNP 🚀 we'll point out where it's similar to current IP, and where it's different from current IP 👀 we use examples to illustrate the intent and show that the approach is feasible 💅
for this section, Figure 4.1 shows H as a fixed host in a simple site network, and CN as a remote Correspondent Node outside the site 🌍 H and CN are ILNP-capable, while the Site Border Router (SBR) does not need to be ILNP-capable 🙌
site . . . . +----+
network . .-----+ CN |
. . . . +------+ . . +----+
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node
H = Host
SBR = Site Border RouterFigure 4.1: A Simple Site Network for ILNP Examples
4.1. Basic Local Configuration 🎀
Okay so this section uses the term "address management" 💅, which is a nod to what IP already does today. Here, address management is all about letting hosts plug into a subnetwork and talk at the network layer with each other, and it also covers:
- a) enabling identification of a node within a site ✨
- b) allowing basic routing/forwarding from a node acting as an end-system 🦋
If you look at Figure 4.1, picture host H getting connected to the site network 🌸. Administratively, it needs at least one I value and one L value before it can communicate. Periodt 💜.
Today, local administrative procedures hand out IP Addresses, often using protocol mechanisms like NETCONF-based router configuration, DHCP for IPv4, DHCP for IPv6, and IPv6 Router Advertisements 🧚. Similarly, local admin procedures can allocate I and L values as required, like I_H and L_H. This may be done through manual configuration 🛠️.
If H is expected or wants to receive incoming requests (say it's a server 👑), then the values I_H and L_H can be added to name services like DNS and NIS/YP. That way, FQDN lookups for H resolve to the right resource records (NID, L32, L64, and LP [RFC6742]) for node H 💖.
From a network operations point of view, this whole process can also be automated 🤖. For example, in Figure 3.1 the Site Border Router (SBR) is an IPv6-capable router, connected via link1 to an ISP that supports IPv6. The SBR will have been allocated one (or more) IPv6 prefixes, which it multicasts using IPv6 Routing Advertisements (RAs) into the site network, e.g., prefix L_1. L_1 is actually a local IPv6 prefix (/64), formed from an address assignment by the upstream ISP, according to [RFC3177] or [RFC6177]. Host H sees these RAs, for example on its local interface named eth0, can use that prefix as a Locator value, and caches that Locator value locally 🌈.
Also, node H can use the mechanism documented in Section 2.5.1 of [RFC4291], in [RFC3972], [RFC4581], [RFC4982], or in [RFC4941] to create a default I value (say I_H), just like an IPv6 host can ✨. For DNS, the I_H and L_1 values may be pre-configured in DNS by an administrator who already knows them. Or H can add them itself using Secure DNS Dynamic Update [RFC3007], to add or update the correct NID and L64 records in DNS for the FQDN for H 🫶.
4.2. I-L Communication Cache 🗂️
For the purposes of explaining the concept of operations, we talk about a local I-L Communication Cache (ILCC) 📚. This is an engineering convenience. It does not form part of the ILNP architecture, but it is used in our examples. More details on the ILCC can be found in [RFC6741]. The ILCC contains information that is required for the operation of ILNP 🔥. This includes, amongst other things, the current set of valid Identifier and Locator values in use by a node, the bindings between them, and the bindings between Locator values and interfaces 💅.
4.3. Packet Forwarding 📦
When the SBR needs to send a packet to H, it uses local address resolution mechanisms to discover the bindings between interface addresses and currently active I-LVs for H 🔍. For our example of Figure 3.1, IPv6 Neighbour Discovery (ND) can be used without modification, because the I-LV for ILNPv6 occupies the same bits as the IPv6 address in the IPv6 header 🙌. For packets going from H to SBR, the same basic mechanism applies, as long as SBR supports IPv6, and even if it is not ILNPv6-capable, because IPv6 ND is used unmodified for ILNPv6 💖.
For Figure 3.1, assuming:
- SBR advertises prefix
L_1locally, uses I valueI_S, and has an Ethernet MAC addressM_Son interface with local namesbr0 - H uses I value
I_H, and has an Ethernet MAC address ofM_Hon the interface with local nameeth0
then H will have in its ILCC:
[I_H, L_1] --- (7a)
L_1, eth0 --- (7b)After the IPv6 RA and ND mechanism has executed, the ILCC at H would contain, as well as expressions (7a) and (7b), the following entry for SBR:
[I_S, L_1], M_S --- (8)For ILNPv6, it does not matter that the SBR is not ILNPv6-capable, because the I-LV [I_S, L_1] is physically equivalent to the IPv6 address for the internal interface sbr0 🧠.
At SBR, which is not ILNP-capable, there would be the following entries in its local cache and configuration:
L_1:I_S --- (9a)
L_1, sbr0 --- (9b)Expression (9a) represents a valid IPv6 ND entry. In this case, the I_S value (which is 64 bits in ILNPv6) and the L_1 values are, effectively, concatenated and treated as if they were a single IPv6 address 🧩. Expression (9b) binds transmissions for L_1 to interface sbr0. (Again, sbr0 is a local, implementation-specific name, and such a binding is possible with standard tools today, for example, ifconfig(8). 🛠️)
4.4. Packet Routing 🛣️
If we assume host H is configured as in the previous section, it is now ready to send and receive ILNP packets 🎉.
Let us assume that, for Figure 4.1, it wishes to contact the node CN, which has FQDN cn.example.com and is ILNP-capable. A DNS query by H for cn.example.com will result in NID and L64 records for CN, with values I_CN and L_CN, respectively, being returned to H and stored in its ILCC:
[I_CN, L_CN] --- (10)This will be considered active as long as the TTL values for the DNS records are valid. If the TTL for an I or L value is zero, then the value is still usable but becomes stale as soon as it has been used once. However, it is more likely that the TTL value will be greater than zero [BA11] [SBK01] ⏰.
Once the CN's I value is known, the upper-layer protocol, e.g., the transport protocol, can set up suitable transport-layer session state 🦋:
<UDP: I_H, I_CN, P_H, P_CN> --- (11)For routing of ILNP packets, the destination L value in an ILNPv6 packet header is semantically equivalent to a routing prefix 🗺️. So, once a packet has been forwarded from a host to its first-hop router, only the destination L value needs to be used for getting the packet to the destination network. Once the packet has arrived at the router for the site network, local mechanisms and the packet-forwarding mechanism, as described above in Section 4.3, allow the packet to be delivered to the host 🎯.
For our example of Figure 4.1, H will send a UDP packet over ILNP as:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (12a)and CN will send UDP packets to H as:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (12b)The I value for H used in the transport-layer state (I_H in expression (12a)) selects the correct L value (L_1 in this case) from the bindings in the ILCC (expression (7a)). That, in turn, selects the correct interface from the ILCC (expression (7b)), as described in Section 4.2. This gets the packet to the first hop router. Beyond that, the ILNPv6 packet is treated as if it were an IPv6 packet 🌸✨.
5. Multihoming and Multi-Path Transport 🌐
Multihoming comes in three flavours to consider 🍓:
- a) Host Multihoming (H-MH): a single host is, individually, connected to multiple upstream links, via separate routing paths, and those multiple paths are used by that host as it wishes. That is, use of multiple upstream links is managed by the single host itself. For example, the host might have multiple valid Locator values on a single interface, with each Locator value being associated with a different upstream link (provider) 💜.
- b) Multi-Path Transport (MTP): This is similar to using ILNP's support for host multihoming (i.e., H-MH), so we describe multi-path transport here. (Indeed, for ILNP, this can be considered a special case of H-MH.) 🦄
- c) Site Multihoming (S-MH): a site network is connected to multiple upstream links via separate routing paths, and hosts on the site are not necessarily aware of the multiple upstream paths. That is, the multiple upstream paths are managed, typically, through a site border router, or via the providers 🏢.
Essentially, for ILNP, multihoming is implemented by enabling:
- a) multiple Locator values to be used simultaneously by a node
- b) dynamic, simultaneous binding between one (or more) Identifier value(s) and multiple Locator values 🔗
With respect to the requirements for hosts [RFC1122], the multihoming function provided by ILNP is very flexible. It is not useful to discuss ILNP multihoming strictly within the confines of the exposition presented in Section 3.3.4 of [RFC1122], because that text is couched in terms of relationships between IP Addresses and interfaces, which can be dynamic in ILNP 🙈. The closest relationship between ILNP multihoming and [RFC1122] would be that ILNP could certainly support the notion of "Multiple Logical Networks", "Multiple Logical Hosts", and "Simple Multihoming" 👑💅.
5.1. Host Multihoming (H-MH) 🦋
okay so host multihoming isn't super common in the deployed Internet yet 🥺. When TCP or UDP are running on an IP-based network-layer session, host multihoming can't give you session resilience, because the transport protocol's pseudo-header checksum locks the transport-layer session to one IP Address of the multihomed node, and so to one interface of that node 💀. SCTP has its own protocol-specific way to do node multihoming, and it can support session resilience both now and without any change to the proposed approach [RFC5061] 🌸.
Host multihoming in ILNP is built right into each host by ILNP itself ✨. The simplest way to think about H-MH for ILNP is that an ILNP-capable host can use several Locator values at once 💖. For example, it can have a binding between one I value and two different L values, so the ILCC might contain these I-LVs:
[I_1, L_1] --- (14a)
[I_1, L_2] --- (14b)A host can also use several I values at the same time, so the ILCC might contain these I-LVs:
[I_1, L_1] --- (15a)
[I_1, L_2] --- (15b)
[I_2, L_2] --- (15c)
[I_3, L_1] --- (15d)Architecturally, ILNP counts all of these as multihoming 🧚. The host is connected to more than one subnetwork, and each subnetwork is named by a different Locator value.
In the cases above, the choice of which I-LV to use is made through local policy or through management mechanisms 🍓. Also, suitably modified transport-layer protocols, like multi-path transport-layer protocol implementations, may use multiple I-LVs. Note that in that situation, how the multiple I-LVs get used is controlled by the higher-layer protocol 👑.
Now, L values also have preference, called LPI values 🎀. These LPI values can be used at the network layer, or by a transport-layer protocol implementation, to make use of L values in a specific way ✨.
Here's the practical bit 💅: ILNP dynamically binds L values to interfaces on a node, to show the SNPA for that L value. So the multihoming is super flexible. A node could have a single interface with several L values bound to it. For example, for expressions (14a) and (14b), if the end-system has a single interface named eth0, the ILCC entries will be:
L_1, eth0 --- (16a)
L_2, eth0 --- (16b)And if we assume that for expressions (15a-c) the end-system has two interfaces, eth0 and eth1, then these ILCC entries are possible:
L_1, eth0 --- (17a)
L_2, eth1 --- (17b)Let's look at the network in Figure 5.1 🦋.
site . . . .
network . .
. . . . +------+ L_1 . .
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. . | | . .
. H . | +------. .
. . . . +------+ L_2 . .
. .
. . . .
L_1 = global Locator value 1
L_2 = global Locator value 2
SBR = Site Border Router
Figure 5.1: A Simple Multihoming Scenario for ILNPWe assume that H has a single interface, eth0. SBR will advertise L_1 and L_2 internally to the site 🌈. Host H will configure these as both reachable via its single interface, eth0, using ILCC entries like expressions (16a) and (16b). When packets from H that are headed out of the site network reach SBR, it can make the right decisions about which link to use, based on the source Locator value (which H inserted) or based on other local policy 💜.
If, however, H has two interfaces, eth0 and eth1, then it can use ILCC entries like expressions (17a) and (17b) 🌸.
Note that the values L_1 and L_2 don't need to be PI-based Locator values. They can come from ISP-specific PA routing prefix allocations from the upstream ISPs providing the two links 🍓.
Of course, this example is illustrative 🫶. Lots of other configurations are possible, but the fundamental mechanism stays the same, as described above.
If any Locator values change, H will notice this when it sees new Locator values in RAs from SBR, and sees that L values it was using before are no longer advertised 😭. When this happens, H will:
- a) maintain existing active network-layer sessions: based on its current ILCC entries and active sessions, send Locator Update (LU) messages to CNs to notify them of the change of L values. (LU messages are synonymous to Mobile IPv6 Binding Updates.)
- b) if required, update its relevant DNS entries with the new L value in the appropriate DNS records, to enable correct resolution for new incoming session requests.
From an engineering viewpoint, H also updates its ILCC data, removing the old L value(s) and replacing them with new L value(s) as required 🔥.
Depending on the nature of the physical change in connectivity that the L value change represents, this may disrupt upper-level protocols, like a fibre cut 💀. Dealing with that kind of physical-level disruption is beyond the scope of ILNP. However, ILNP supports graceful changes in L values, and this is explained below in Section 6 in the discussion on mobility support ✨.
5.2. Support for Multi-Path Transport Protocols 🌈
ILNP supports the deployment and use of multi-path transport protocols, like the Multi-Path extensions to TCP (MP-TCP) being defined by the IETF TCPM Working Group 🎀. Specifically, ILNP supports the use of multiple paths because it allows a single I value to be bound to multiple L values. See Section 5.1, specifically expressions (15a) and (15b) 💖.
Of course, there will be specific mechanisms for:
- congestion control
- signalling for connection/session management
- path discovery and path management
- engineering and implementation issues
These transport-layer mechanisms are outside the scope of ILNP 🙈. They would be defined in the multi-path transport protocol specifications.
As far as the ILNP architecture is concerned, the transport protocol connection is simply using multiple I-LVs. They all have the same I value, but different L values, which means a multihomed host 🦋.
5.3. Site Multihoming (S-MH) 🏡
Site multihoming is common in the deployed Internet right now 💅. It's mostly done by advertising the site's routing prefix(es) to more than one upstream Internet service provider at the same time. That in turn requires de-aggregation of routing prefixes within the inter-domain routing system 😬. This increases the entropy of the inter-domain routing system (for example, the RIB/FIB size grows beyond the minimal RIB/FIB size that would be needed to reach all sites).
Site multihoming, in its simplest form in ILNP, is an extension of the H-MH scenario from Section 5.1 ✨. If we look at Figure 5.1 and assume there are many hosts in the site network, then each host can choose (a) whether or not to manage its own ILNP connectivity, and (b) whether or not to use multiple Locator values. This gives each host maximal control over its connectivity 👑.
Of course, with ILNPv6, just as any IPv6 router is required to generate IPv6 Router Advertisement messages with the correct routing prefix information for the link the RA is advertised on, the SBR is also required to generate RAs containing the correct Locator value(s) for the link the RA is advertised on 🧚. The correct values for these RA messages are typically configured by system administration, or might be passed down from the upstream provider.
To avoid a DNS Update burst when a site or (sub)network changes location, a DNS record optimisation is possible by using the new LP record for ILNP 🌸. This would change the number of DNS Updates required from Order(Number of nodes within the site/subnetwork that moved) to Order(1) [RFC6742] ✨.
5.3.1. A Common Multihoming Scenario - Multiple SBRs 💜
The scenario of Figure 5.1 is an example that illustrates how multihoming works architecturally for ILNP 🦋. For site multihoming, a scenario like the one in Figure 5.2 is also common. Here there are two SBRs, and each one has its own global connectivity 🌈.
site . . . .
network . .
. . . . +-------+ L_1 . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. . | | . .
. . +-------+ . .
. . ^ . .
. . | CP . Internet .
. . v . .
. . +-------+ L_2 . .
. . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
. .
. . . .
CP = coordination protocol
L_1 = global Locator value 1
L_2 = global Locator value 2
SBR_A = Site Border Router A
SBR_B = Site Border Router B
Figure 5.2: A Dual-Router Multihoming Scenario for ILNPUsing two physical routers gives an extra level of resilience compared to the scenario in Figure 5.1 🛡️. The coordination protocol (CP) between the two routers keeps their actions in sync, following whatever management policy is in place for the site network. Products already offer these capabilities today 💖. Note that, logically, there's little difference between Figures 5.1 and 5.2. But with two distinct routers in Figure 5.2, the interaction using CP is required. And of course, you can also have multiple interfaces in each router, and more than two routers 🔥.
5.4. Multihoming Requirements for Site Border Routers 👑
For multihoming, the SBR does NOT need to be ILNP-capable for host multihoming or site multihoming 🙌. This is true as long as the multihoming is left to individual hosts, as described above. In this approach, the SBR only needs to issue Routing Advertisements (RAs) that are correct with respect to its upstream connectivity. That means the SBR properly advertises routing prefixes (Locator values) to the ILNP hosts 🧚.
In that scenario, when hosts in the site network see new Locator values, and see that a previous Locator value is no longer being advertised, those hosts can update their ILCCs, send Locator Updates to CNs, and change connectivity as required 🦋✨.
6. Mobility 🧚
okay so ILNP does mobility directly 💅 It doesn't need special add-on mobility extensions the way IPv4 [RFC2002] (which was obsoleted by [RFC5944]) and IPv6 [RFC6275] do. We're literally building it in, bestie 🦋
There are two mobility cases to think about:
- a) Host Mobility: individual hosts can be mobile, moving across administrative or topological boundaries inside an IP-based network, or across the Internet. These hosts would need to manage their own mobility independently 🏃♀️
- b) Network (Site) Mobility: a whole site, meaning one or more IP subnetworks, can be mobile, moving across administrative or topological boundaries inside an IP-based network, or across the Internet. The site as a whole needs to keep its connectivity consistent 🚢
So essentially, for ILNP, mobility works by enabling:
- a) Locator values to be changed dynamically by a node, including for active network-layer sessions 🔄
- b) use of Locator Updates so active network-layer sessions can be kept alive 💖
- c) for hosts that expect incoming network-layer or transport-layer session requests (like servers), updates to the relevant DNS entries for those hosts 🌐
It's totally possible for a device to be both a mobile host and part of a mobile network, like a smartphone in a mobile site network 📱 ILNP handles this fine, because the mechanisms for mobile hosts and mobile networks are super similar and work in harmony ✨
For mobility, there are two general features that must be supported:
- a) Handover (or Hand-off): when a host changes its connectivity (for example, it gets a new SNPA as it moves into a new ILNP subnetwork), any active network-layer sessions for that host must be maintained with minimal disruption (so, transparently) to the upper-layer protocols 🦋
- b) Rendezvous: when a host that expects incoming network-layer or transport-layer session requests gets new connectivity (for example, a new SNPA as it moves into a new ILNP subnetwork), it needs to update its relevant DNS entries so that name resolution gives remote nodes the correct I and L values 🎀
6.1. Mobility / Multihoming Duality in ILNP 👯♀️
Okay this is my favourite part, mobility and multihoming are literally twins 🥹 They present the same set of issues for ILNP. The set of Locators tied to a node or site changes in both cases. The reason for the change might be different, but the effect on network-layer session state and on correspondents is identical ✨
ILNP supports mobility and multihoming using one shared set of mechanisms 💜 In both cases, different Locator values are used to identify different IP subnetworks. Also, ILNP nodes that expect incoming network-layer or transport-layer session requests are assumed to have a Fully Qualified Domain Name (FQDN) stored in the Domain Name System (DNS), just like what's already happening across the deployed Internet 🌍 ILNP mobility normally relies on the Secure Dynamic DNS Update standard so mobile nodes can update their location information in the DNS. Using DNS for rendezvous with mobile systems was proposed earlier by others [PHG02], so this idea isn't brand new 🙈
Host Mobility is about individual hosts that are each mobile, like a mobile phone being carried by someone walking around a city 🚶♀️ Network (Site) Mobility is about a group of hosts within a local topology that move together and periodically change their uplinks to the rest of the Internet. Think of a ship with wired connections on the inside but one or more wireless uplinks to the rest of the Internet 🚢🌊
For ILNP, Host Mobility is analogous to host multihoming (H-MH), and Network Mobility is analogous to site multihoming (S-MH). So mobility and multihoming capabilities can be used together, without conflict 💅👑
6.2. Host Mobility 📱
With Host Mobility, each individual end-system manages its own connectivity through its Locator values. (This is very similar to the situation described for H-MH in Section 5.1, so if you read that, this will feel so familiar 🥰)
Let's look at the network in Figure 6.1 🗺️
site . . . .
network A . .
. . . . +-------+ L_A . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. H(1) . | | . .
. . +-------+ . .
. . . . . . . .
. H(2) . . Internet .
. . . . . . . .
. . +-------+ L_B . .
. H(3) . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
site . .
network B . . . .
H(X) = host H at position X
L_A = global Locator value A
L_B = global Locator value B
SBR = Site Border Router
Figure 6.1: A Simple Mobile Host Scenario for ILNPHost H starts at position (1), so it's H(1) in site network A. This site network might be, for example, a single radio cell under administrative domain A. We assume the host will move into site network B, which might be a single radio cell under administrative domain B. We also assume the site networks have a region of overlap so connectivity can be maintained. Otherwise, of course, the host will lose connectivity 😬 And let's assume the host already has ILNP connectivity in site network A.
If site network A has connectivity via Locator value L_A, and H uses Identifier value I_H with a single interface ra0, then the host's ILCC will contain:
[I_H, L_A] --- (18a)
L_A, ra0 --- (18b)Notice how (18a) and (18b) are equivalent to expressions (15a) and (16a) for host multihoming. Same energy, different outfit 💅
Now the host moves into the overlap region of site networks A and B, and it's at position (2), so H(2) in Figure 6.1 🚶♀️✨ Since this region is now in site network B as well as site network A, H should see RAs from SBR_B for L_B, as well as the RAs for L_A from SBR_A. The host can now start using L_B for its connectivity. Here's what H must now do:
- a) Maintain existing active upper-layer sessions: based on its current ILCC entries and active sessions, send Locator Update (LU) messages to CNs to tell them about the change of L values. (LU messages are the same thing as Mobile IPv6 Binding Updates, so if you know those, you already know these 🫶)
- b) If required, update its relevant DNS entries: put the new L value into the appropriate DNS records, so that correct resolution works for new incoming network-layer or transport-layer session requests 🌐
But here's the tea ☕ H can pick one of two ways to do this:
- 1) Immediate handover: the host sends Locator Update (LU) messages to CNs, immediately stops using L_A, and switches to using L_B only. In this case, its ILCC entries change to:
[I_H, L_B] --- (19a)
L_B, ra0 --- (19b)There might be packets in flight to H that use L_A, and H MAY choose to ignore these on reception. 👀
- 2) Soft handover: the host sends Locator Update (LU) messages to CNS, but it keeps using both L_A and L_B until (i) it no longer receives incoming packets with destination Locator values set to L_A within a given time period, and (ii) it no longer sees RAs for L_A (meaning it has left the overlap region and so has left site network A). In this case, its ILCC entries change to:
[I_H, L_A] --- (20a)
L_A, ra0 --- (20b)
[I_H, L_B] --- (20c)
L_B, ra0 --- (20d)ILNP doesn't force you to pick one handover option over the other 🙌 A host can actually implement both, and decide (through local policy or other mechanisms, like under the control of a particular transport protocol implementation) to use one or the other for a specific transport-layer session, whenever it's needed. Flexibility is everything 💅
Note that if you're using soft handover, you're multihomed while you're in the overlap region 🧚 Soft handover is also likely to be less disruptive (for example, lower packet loss) than immediate handover, all other things being equal ✨
There's also a case where both the host and its correspondent node are mobile 🫨 In the unlikely event that both nodes' Locators change within a very small time period at the same moment, communication might get lost 😭 If the communication between the nodes was direct (one node started talking to the other through a DNS lookup), a node can use the DNS to discover the new Locator value(s) for the other node. If the communication went through some sort of middlebox providing a relay service, then communication is more likely to be disrupted only if the middlebox is also mobile 🛸
It's also possible that high packet loss causes Locator Updates to get lost, which could disrupt handover. However, this is an engineering issue and doesn't change the basic concept of operation. More discussion on this issue is in [RFC6741] 📚
And of course, for any handover, the new end-to-end path through SBR_B might have very different characteristics (for example, different end-to-end delay, packet loss, or throughput) 🎢 The physical connectivity on interface ra0, as well as through SBR_B's uplink, may also be different. Those impacts on end-to-end packet transfer are outside the scope of ILNP, so that's a problem for another day 💅💖
6.3. Network Mobility 🚐
okay so network mobility is when the WHOLE site is on the move 🚐💨 like, the SBRs from Figure 6.1 have a radio uplink on a moving vehicle. Inside the site, individual hosts may or may not be mobile themselves, which is a lowkey fun mix 🧚
In the simplest case, ILNP handles mobile networks the same way it handles site multihoming 🫶 The management of mobility gets delegated to each host in the site, so every host needs to be ILNP-capable 💅 Each host basically acts like it's a mobile host, even if it's not actually moving. Honestly this is giving multihoming vibes, because the mechanism is super similar 🦋 Let's look at the mobile network in Figure 6.2 ✨
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 6.2a: ILNP Mobile Network before Handover
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 6.2b: ILNP Mobile Network during Handover
site ISP_2
network SBR . . .
. . . . +------+ . .
. . | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ . .
. . .
Figure 6.2c: ILNP Mobile Network after Handover
H = host
L_1 = global Locator value 1
L_2 = global Locator value 2
SBR = Site Border Router
Figure 6.2: A Simple Mobile Network Scenario for ILNPIn Figure 6.2 we're assuming the site network is mobile and the SBR has two radio interfaces, ra1 and ra2 ✨ Real talk though, this particular figure was picked for simplicity and clarity, so other setups are possible too 🌈 For example, a single radio interface could use separate radio channels (separate carriers, coding channels, etc.) 📡 In the figure, ISP_1 and ISP_2 are separate, radio-based service providers, reachable via ra1 and ra2 respectively 💜
In Figure 6.2a, the SBR has connectivity via ISP_1 using Locator value L_1 🎀 The host H, with interface ra0 and Identifier I_H, already has an established connection via the SBR, so it has ILCC entries like the ones in (21) 👑
[I_H, L_1] --- (21a)
L_1, ra0 --- (21b)Notice this matches expressions (18a) and (18b) 🧚 Now, as the whole network moves, the SBR spots a new radio provider, ISP_2, and connects to it using ra2, as shown in Figure 6.2b 🚐 The service areas of ISP_1 and ISP_2 overlap at this point 🌸 ISP_2 provides Locator L_2, which the SBR advertises into the site network along with L_1 ✨ Same as with the mobile host scenario above, individual hosts can decide whether to do an immediate handover or a soft handover 💅 So the ILCC state for H will look like expressions (19a) and (19b) and (20a)-(20d), except with L_1 in place of L_A, and L_2 in place of L_B 🫶 Finally, as in Figure 6.2c, the site network moves on, is no longer served by ISP_1, and the handover is complete 🦋 Note that during the handover the site is multihomed, just like in Figure 6.2b 😭
6.4. Mobility Requirements for Site Border Routers 🛣️
Same as with multihoming, the SBR does NOT need to be ILNP-capable 💁♀️ It just needs to advertise the available routing prefixes into the site network, and that's it 🌸 The mobility capability is handled completely by the hosts 👑
6.5. Mobility with Multiple SBRs 🧚
Remember how Section 5.3.1 talks about using multiple routers for multihoming? Well, it's possible to have multiple routers for mobility in ILNP too 🫶 This works for both mobile hosts and mobile networks, so it's iconic and flexible 🔥
7. IP Security for ILNP 🔐
IP Security for ILNP [RFC6741] is, in principle, simpler than IPsec as it is today 🧠 That's because it's based on using IP Addresses as Identifiers 💖
7.1. Adapting IP Security for ILNP ✨
Here's the big idea 🦋 ILNP makes a very simple architectural change to IPsec: where IPsec SAs currently use IP Addresses, ILNP uses Node Identifier values instead 💜 Identifier values are immutable once they're in use, so they can maintain end-to-end state for any protocol that needs it 🌈 As we saw above, a host's Identifier values stay the same when multihoming and mobility are in use, so IPsec using ILNP can work in harmony with multihoming and mobility [ABH08b] [ABH09a] 🫶
Now, IPsec interoperability through a Network Address Translator (NAT) deployment [RFC1631] [RFC3022] is a whole thing 😭 Right now, UDP encapsulation of IPsec [RFC3948] is commonly used to deal with it, as of the date this document was published 🎀 With ILNP IPsec, this special-case handling for IPsec traffic traversing a NAT isn't needed 🙌
It would also get rid of the need for specialised IPsec NAT traversal mechanisms, which simplifies IPsec implementations while boosting deployability and interoperability [RFC3948] 🍓
This architectural change does NOT reduce the security IPsec provides 🛡️ In fact, if the Node Identifier namespace had existed back in the early 1990s, IPsec would always have bound to that location-independent Node Identifier, and never to IP Addresses 💅
7.2. Operational Use of IP Security with ILNP 🛠️
Operationally, switching SA bindings from IP Addresses to Identifiers causes some problems 😬 They show up with IPsec protocols going through IP Network Address Translation (NAT) devices, with mobile nodes (because a mobile node's IP Address changes at each network-layer handoff), and with multihomed nodes (because the network-layer IPsec session is bound to one particular interface of the multihomed node, rather than to the node itself) [RFC3027] [RFC3715] 💀
8. Backwards Compatibility and Incremental Deployment 🌈
ILNPv6 is fully backwards compatible with existing IPv6, and this is the best part 🎀 No router software or silicon changes are needed to support the proposed enhancements 🙌 An IPv6 router wouldn't even know whether it's forwarding classic IPv6 or the proposed ILNPv6 enhancement 🧚 IPv6 Neighbour Discovery works unchanged for ILNPv6 ✨ And ILNPv6 multicasting is the same as IETF standards-track IPv6 multicasting 💜
ILNPv4 is backwards compatible with existing IPv4 too 🫶 The IPv4 address fields get used as 32-bit Locators, and only the address prefix bits of that 32-bit space are used, so IPv4 routers wouldn't need changes either 🌸 An IPv4 router would be unaware whether the packet it's forwarding is classic IPv4 or the proposed ILNPv4 enhancement [RFC6746] 🦋 ARP [RFC826] does need enhancements to support ILNPv4 [RFC6747] [RFC6741] 😭 ILNPv4 multicasting is the same as IETF standards-track IPv4 multicasting 💅
If a node supports ILNP and wants to receive incoming network-layer or transport-layer sessions, its Fully Qualified Domain Name (FQDN) normally has one or more NID records and one or more Locator (i.e., L32, L64, and/or LP) records associated with it in the DNS [RFC6741] [RFC6742] 🔍
When an IP host ("initiator") starts a new network-layer session with a correspondent ("responder"), it normally does a DNS lookup to find the responder's address(es) 📬 An ILNP host normally looks for Node Identifier ("NID") and Locator (i.e., L32, L64, and LP) records in any DNS replies it gets back 🧚 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 learns from DNS information that the responder also supports ILNP, then the initiator generates an unpredictable ILNP Nonce value 🎲 It caches that value locally as part of the network-layer ILNP session, and includes the ILNP Nonce value in its initial packet(s) to the responder [RFC6741] [RFC6744] [RFC6746] 💖
If the initiator node doesn't find any ILNP-specific DNS resource records for the responder node, it uses classic IP for the new network-layer session, instead of trying ILNP for that session 🌷 Of course, multiple transport-layer sessions can share a single network-layer (e.g., IP or ILNP) session at the same time 🍓
If the responder node for a new network-layer session doesn't support ILNP, and it receives initial packet(s) containing the ILNP Nonce, then the responder drops the packet and sends 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, it learns that ILNP is in use for that network-layer session (by the presence of that ILNP Nonce) ✨
If the initiator node using ILNP doesn't get a response from the responder in a timely manner (e.g., within TCP timeout for a TCP session), and also doesn't 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 doesn't 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, an ILNP node is also a fully capable IP node, so it can use any standardised IP mechanisms to talk to a legacy IP-only node 🫶 So ILNP won't be worse than existing IP 💅 But when ILNP is actually used, the enhanced capabilities described in these ILNP documents become available 🚀
9. Security Considerations 🔒
This proposal outlines a proposed evolution for the Internet Architecture to provide improved capabilities 🌟 This section talks about the security considerations for this proposal, and it's serious business, bestie 😤
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 goes beyond that 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
Okay bestie, the big rule here is that every Locator Update message gets authenticated 🔐✨. ILNP requires an ILNP session nonce [RFC6744] [RFC6746] to stop off-path attacks 🛡️, and it also lets you bring in IPsec cryptography for extra-strong protection when you need it 💪.
Regular IP sessions are open to on-path attacks unless IPsec is turned on 😬. So the Nonce Destination Option is only there to guard against off-path attacks on an ILNP network-layer session. That makes it equal to a normal IP session that isn't using IPsec, nothing more and nothing less 💅.
Paths between two nodes on the Internet are often non-symmetric 🌊. To cut down on how many on-path nodes know the Nonce for a session, the nonce is unidirectional, not bidirectional 🦋. For example, in an ILNP session between nodes A and B, one nonce is used from A to B, and a different nonce is used from B to A. Nodes on the path won't learn both directions at once.
ILNP sessions in higher risk environments SHOULD also use IPsec cryptographic authentication in addition to the ILNP Nonce 🔥. Stacking those two is the move.
Also, a regular network-layer IP session is completely exposed to on-path attacks unless IPsec is in use for that particular session 😭. So the security of this new proposal is never worse than what IP already gives you 🫶.
9.2. Forged Identifier Attacks
Forged Source IP Addresses in active attacks have been publicly known since early 1995 at least [CA-1995-01] 🕵️♀️. They exist on the deployed Internet but they haven't been widespread, and a forged Identifier value is basically the same problem. So this isn't a brand-new threat that ILNP invented 🙅♀️.
One mitigation has been Source IP Address filtering [RFC2827] [RFC3704] 🧱. Jun Bi at Tsinghua University cites Arbor Networks saying that this filtering has less than 50% deployment 📉. They also cite an MIT analysis suggesting that at least 25% of the deployed Internet allows forged Source IP Addresses 😳.
[RFC6741] talks about an accidental duplicate Identifier on the Internet 🙈. This sub-section is different, though: it's about deliberately forged Source Identifier values 😈.
Here's the plan, in order 📝:
Firstly, the recommendations of [RFC2827] and [RFC3704] still apply 🧹. Any packets with a forged Locator value can be easily filtered with existing, widely available mechanisms.
Secondly, the receiving node doesn't blindly trust any packet that has the right Source Identifier and the right Destination Identifier 🙅♀️. Instead, each ILNP node keeps an ILNP Communication Cache (ILCC) for each of its correspondents, as described in [RFC6741] 🗂️. The cache helps validate received messages and stops off-path attackers from winning. More on this in [RFC6741] 📚.
Thirdly, any node can tell apart different nodes that share an Identifier value by looking at other properties of their ILNP sessions 👀. For example, IPv6 Neighbor Discovery stops more than one node from using the same source I-LV at the same time on the same link [RFC4861]. So if different nodes are using the same Identifier value, they'll have different sets of valid Locator values. A node can demultiplex on the combination of Source Locator and Source Identifier if needed 🧩. And if IPsec is in use, the combination of the Source Identifier and the Security Parameter Index (SPI) value is enough to separate two different ILNP sessions 🎀.
Fourthly, deployments in high-threat environments SHOULD also use IPsec to authenticate control traffic and data traffic 🚨. IPsec for ILNP binds only to the Identifier values and never to the Locator values 💖. So a mobile or multihomed node can keep using IPsec even right after its Locator value(s) change 🦋.
Lastly, ordinary IPv4, ordinary IPv6, Mobile IPv4, and Mobile IPv6 are all already vulnerable to forged Identifier and/or forged IP Address attacks 💀. An attacker on the same link as the victim can just forge the victim's MAC address and IP Address. With IPv6, if Secure Neighbour Discovery (SEND) and Cryptographically Generated Addresses (CGAs) are in use, the victim can defend its IPv6 address using SEND 🛡️. With ILNP, when SEND and CGAs are in use, the victim node can also defend its IPv6 address using SEND 🫶. There are no standard ways to authenticate ARP messages, so IPv4 is especially vulnerable to this kind of attack 😩. These attacks also work against Mobile IPv4 and Mobile IPv6. And when either form of Mobile IP is in use, the risks go up, because the attacks work not only when the attacker can reach the victim's current IP subnetwork but also when the attacker can reach the victim's home IP subnetwork 😱. So the risks of using ILNP are no greater than what already exists today with IP or Mobile IP ✨.
9.3. IP Security Enhancements
IPsec gets an upgrade here 🆙. IPsec Security Associations (SAs) are bound to the Node Identifiers of the endpoints, rather than to the IP Addresses of the endpoints like they are today 🪪. This makes IPsec more deployable and more interoperable, and it doesn't lower the security those protocols provide 💜. See Section 7 for the full explanation 📖.
9.4. DNS Security
The DNS enhancements here are completely compatible with the existing IETF DNS Security standards [RFC4033], and they can be protected using those same standards 🔐. The Secure DNS Dynamic Update mechanism used here is also used unchanged [RFC3007] 🔄. So ILNP doesn't change the security properties of DNS or of DNS servers 🌸.
9.5. Firewall Considerations
In the new scheme, stateful firewalls can authenticate ILNP-specific control messages that arrive on the external interface 🧱✨. That means firewalls can handle ICMP messages way more thoughtfully than they usually do today 🧠. Since the firewall sits on the path between the communicating nodes, it can snoop on the ILNP Nonce carried in the initial packets of an ILNP session 👂. It can then check that the correct ILNP Nonce is on incoming control packets, and drop any control packets that don't have the right nonce value 🚫.
Always including the ILNP Nonce in ILNP-specific control messages, even when IPsec is also in use, lets the firewall filter out off-path attacks against those ILNP messages without doing computationally expensive IPsec processing 🏎️. Either way, a forged packet from an on-path attacker still gets caught when IPsec input processing happens in the receiving node 🙌. That makes the forged packet get dropped instead of acted upon 💅.
9.6. Neighbour Discovery Authentication
Nothing in this proposal stops sites from using the Secure Neighbour Discovery (SEND) proposal to authenticate IPv6 Neighbour Discovery with ILNPv6 [RFC3971] 🫶.
9.7. Site Topology Obfuscation
A site that wants to hide its internal topology information MAY do so by deploying site border routers that rewrite the Locator values for the site as packets come in or go out 🕶️. This scenario was presented in [ABH09a] and is covered in more detail in [RFC6748] 🧐.
For example, a site might choose to use a ULA prefix internally for this reason [RFC4193] [ID-ULA] 🌙. In that 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 🌍. Those routers would also rewrite the Destination Locator of packets entering the site, changing it 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 of these 🎀:
- Location Privacy: hiding a node's topological location by obfuscating the ILNP Locator information 🗺️. (See also Section 7 of [RFC6748].)
- Identity Privacy: hiding a node's identity by using Node Identifier values that aren't tied to the node in some permanent or semi-permanent way 🥷. (See also Section 11 of [RFC6741].)
A more detailed breakdown of the possibilities is in [BAK11] 📚💜.
10.1. Location Privacy
Some users are worried about "location privacy", meaning that other people could figure out where they are 😰. The term "location privacy" doesn't have a crisp definition in the Internet community yet 🤷♀️. Some people mean the location of a node relative to the Internet's routing topology, while others mean its geographic coordinates (latitude X, longitude Y) 🌎. The concern mostly focuses on Internet-enabled devices, especially handhelds like smartphones, which can have 1:1 mappings with individual users 📱.
There's a fundamental trade-off here 🙃. A node's Internet connectivity quality tends to be inversely proportional to its "location privacy". For example, if a node used a router with NAT as a privacy proxy and routed all its Internet traffic through that proxy, then (a) latency goes up as the distance grows between the node seeking privacy and its proxy, and (b) communications with that node become more vulnerable to faults, both because the proxy itself might fail and because the longer path has more potential points of failure than a more direct path would 🐢💀.
If an Internet node wants other Internet nodes to be able to start transport-layer or network-layer sessions with it, it needs associated address (e.g., A, AAAA) or Locator (e.g., L32, L64, LP) records in the publicly accessible Domain Name System (DNS) 📡. Information in the DNS is publicly accessible. Since the goal of DNS is to distribute information to other Internet nodes, it doesn't provide mechanisms for selective privacy 🫣. Of course, a node that doesn't want to be contacted doesn't need to be in the DNS 🙅♀️.
People have tried to map IP Address blocks to geographic locations, and the quality of those mappings seems to vary [GUF07] 🗺️. Many of these mapping efforts are driven by efforts to comply with legal requirements in various jurisdictions ⚖️. For example, some content providers reportedly have licenses that allow distributing content in one set of locations but not in a different set 🎬.
ILNP doesn't compromise user location privacy any more than base IPv6 does 🙌. In fact, by its nature, ILNP gives users additional choices for protecting their location privacy 💖✨.
10.2. Identity Privacy ✨
okay bestie, so identity privacy is a whole vibe 🦋 ILNP and IPv6 both let you use identifier values made with the IPv6 Privacy Address extension [RFC4941] 💜 and they also both let one node have multiple unicast addresses/locators at the same time, which is seriously iconic because it makes it way easier to switch your addresses/locators over time 🔥 IPv4 doesn't have any non-topological identifiers though, and lots of IPv4 nodes only handle one IPv4 unicast address per interface, so IPv4 isn't really directly comparable with IPv6 or ILNP 🙈
In normal operation with IPv4, IPv6, or ILNP, a mobile node might want to be reachable for brand new connection attempts from the global Internet 🌍 and it might also want optimal routing and maximum Internet availability for both sent and received packets ✨ if that's the goal, the node is going to want its addressing or location info kept in the DNS and available to others 💖
Now, some mobile nodes only want to start network-layer or transport-layer sessions with other Internet nodes, and they don't want to be the responder 🎀 in that case the node doesn't need to be in the DNS at all 🧚 but heads up, some potential correspondent nodes might, as a matter of local security policy, refuse to talk to nodes that don't 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 (like intermittent email access or browsing specific web pages 🍓), long-lived network sessions aren't required, meaning sessions that last longer than the time the node stays on the same subnetwork 🌸 in those cases, support for node mobility (network-layer session continuity even when the SNPA changes) is not required and doesn't need to be used 💅
If an ILNP node that's mobile chooses not to use DNS for rendezvous, but still wants any node on the global Internet to be able to start communicating with it 👑, then that node MAY fall back to using Mobile IPv4 or Mobile IPv6 instead ✨
Many residential broadband Internet users get involuntary renumbering 😤, usually when their ISP's DHCP server(s) deny a DHCP RENEW request and hand the residential user's device(s) different IP addressing information instead 💔 a lot of these users want their home server(s) or client(s) to be reachable from outside, so they often use Secure DNS Dynamic Update to update the addressing or location info in the DNS entries for the devices they want reachable from the global Internet [RFC2136] [RFC3007] [LA2006] 🫶 this option exists for those users whether they use IPv4, IPv6, or ILNP, and users also get to choose NOT to use these 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 🙏✨
Huge thank-you bundle to 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) 💖 for reviewing and giving feedback on earlier versions of this document. Steve Blake gave an especially thorough review of an early version of the entire ILNP document set, and it was extremely helpful 🔥. We also want to thank the anonymous reviewers of the various ILNP papers for their feedback 🫶.
Roy Arends gave expert guidance on the technical and procedural side of DNS issues 🧚.
Noel Chiappa kindly sent the authors copies of the original email messages cited here as [SIPP94] and [IPng95], which let us cite those messages precisely 💌.
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📦 where this page comes from
- ietf: rfc6740 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms