RFC 6748
Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
RFC 6748: Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) 🎀
Okay bestie, let's start with the basics 💅 This is RFC 6748, and it comes from the Internet Research Task Force (IRTF) stream. It's marked Experimental (ISSN 2070-1721) and was published in November 2012. The authors are RJ Atkinson (a consultant) and SN Bhatti (from U. St Andrews) 🫶 The title block doesn't list anything it obsoletes or updates, so it's standing on its own.
Abstract ✨
Okay so this doc gives an architectural description and the Concept of Operations for some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP) 🦋 ILNP is an evolutionary enhancement to IP, and it's giving main character energy. None of the functions described here is required for using or deploying ILNP. Instead, it describes engineering and deployment options that might bring extra capability or make administration and management of ILNP-based systems easier 🌸
Status of This Memo 📜
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation, so think of it as a test kitchen 🍓
This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment, so don't just yeet them into production 💀 This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6748 🧚
Copyright Notice 💜
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these documents 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. So hands off the original, besties 🙈
Table of Contents 📋
1. Introduction ....................................................4
1.1. Document Roadmap ...........................................5
1.2. Terminology ................................................6
2. Localised Numbering .............................................6
2.1. Localised Locators .........................................7
2.2. Mixed Local/Global Numbering ...............................9
2.3. Dealing with Internal Subnets with Locator Rewriting .......9
2.4. Localised Name Resolution with DNS ........................11
2.5. Use of mDNS ...............................................13
2.6. Site Network Name in DNS ..................................13
2.7. Site Interior Topology Obfuscation ........................14
2.8. Other SBR Considerations ..................................14
3. An Alternative for Site Multihoming ............................16
3.1. Site Multihoming (S-MH) Connectivity Using an SBR .........16
3.2. Dealing with Link/Connectivity Changes ....................17
3.3. SBR Updates to DNS ........................................18
3.4. DNS TTL Values for L32 and L64 Records ....................18
3.5. Multiple SBRs .............................................19
4. An Alternative for Site (Network) Mobility .....................20
4.1. Site (Network) Mobility ...................................20
4.2. SBR Updates to DNS ........................................22
4.3. DNS TTL Values for L32 and L64 Records ....................22
5. Traffic Engineering Options ....................................22
5.1. Load Balancing ............................................23
5.2. Control of Egress Traffic Paths ...........................24
6. ILNP in Datacentres ............................................26
6.1. Virtual Image Mobility within a Single Datacentre .........27
6.2. Virtual Image Mobility between Datacentres - Invisible ....28
6.3. Virtual Image Mobility between Datacentres - Visible ......29
6.4. ILNP Capability in the Remote Host for VM Image Mobility ..29
7. Location Privacy ...............................................30
7.1. Locator Rewriting Relay (LRR) .............................30
7.2. Options for Installing LRR Packet Forwarding State ........31
8. Identity Privacy ...............................................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
11. Acknowledgements ..............................................371. Introduction 🦋
Okay 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. Separately, various refereed research papers on ILNP have been published during this decade, so the ideas in here have been reviewed way beyond the Routing RG. The Routing RG found the views in this document controversial, but they still reached a consensus that it should get published. Honestly, the Routing RG has had remarkably little consensus on anything, so basically all of their outputs are considered controversial 😭
At the moment, the Internet research and development community is exploring different ways of evolving the Internet Architecture to tackle a bunch of issues, including (but not limited to) scalability of inter-domain routing [RFC4984] 🌈 Plenty of other issues are also active concerns right now, like site multihoming, node multihoming, site/subnet mobility, and node mobility. There are several classes of evolution being considered. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class is sometimes known as "Identifier/Locator Split". This document is about a proposal in that second class of evolutionary approaches ✨
ILNP is, in essence, an end-to-end architecture. The functions it requires are implemented in, and controlled by, only the end-systems that want to use ILNP, as described in [RFC6740] 🫶 Other nodes, like Site Border Routers (SBRs), only need to support IP to allow ILNP to operate. For example, an SBR should support IPv6 so that end-systems can run ILNPv6 within the site network the SBR serves [RFC6741] 💖
Here's the twist though: some features of ILNP could be optimised, from an engineering point of view, by using an intermediate system (a router, security gateway, or "middlebox") that modifies (rewrites) the Locator values of transit ILNP packets. It could also handle other control functions for an entire site, as an administrative convenience, like providing a centralised point of management for the site. For example, an SBR might manipulate the topological presence of the packet, which is an elegant way to provide things like site (network) mobility for a whole end site [ABH09a] 🔥
This document discusses several of these optional advanced deployment scenarios for ILNP. They typically use an ILNP-capable Site Border Router (SBR) 🎀
Nothing in this document is a requirement for any ILNP implementation or any ILNP deployment 🌸
Readers are strongly advised to read the ILNP Architecture Description [RFC6740] first, because this document uses the notation and terminology described or referenced there 📚
1.1. Document Roadmap 🗺️
This document covers engineering and implementation considerations that are common to ILNP for both IPv4 and IPv6 🧚
The ILNP architecture can have more than one engineering instantiation. For example, you could imagine a "clean-slate" engineering design based on the ILNP architecture. Separate documents describe two specific engineering instances of ILNP. The term "ILNPv6" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. The term "ILNPv4" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4 🦋
A bunch of engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document 💅
Readers are referred to other related ILNP documents for details not covered here:
- a) [RFC6740] is the main architectural description of ILNP, including the concept of operations.
- b) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
- c) [RFC6742] defines additional DNS resource records that support ILNP.
- d) [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.
- e) [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 🔐
- f) [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.
- g) [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.
- h) [RFC6747] describes extensions to Address Resolution Protocol (ARP) for use with ILNPv4.
1.2. Terminology 💅
Okay the BCP 14 key words are the big ones here, so pay attention 👑 In this document, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] 🫶
2. Localised Numbering ✨
okay so NAT [RFC3022] is used for a bunch of things, ngl. Its original big job was to stretch out the global IPv4 addresses by using the IPv4 private space [RFC1918], but it also gives site admins a super convenient way to manage addresses locally with local-scope/private space, like [RFC1918] for IPv4. 🏠
IPv6 is a different story, bestie. NAT isn't automatically needed there to slow down address depletion, because addresses aren't scarce the way they are in IPv4. 🌈 The IETF did standardise Unique Local IPv6 Unicast Addresses [RFC4193], which give end sites local-scope IPv6 unicast space. Even so, localised address management, like what IPv4 NAT and private space [RFC1918] give you, is still wanted for IPv6 [RFC5902], even though people still argue about whether it's actually a good idea [RFC4864]. 🤷♀️
Here's the tea. A lot of people have been bothered by NAT because it messes with end-to-end transport-layer and network-layer session state invariance, which the IAB still considers an important architectural principle [RFC4924]. 😤 But localised addressing is still super popular, and people want to keep using it in IPv6 too. Proposals like [RFC6296] are a good example. 💜
Here's the iconic part: ILNP can get the benefits of NAT-like functions without losing end-to-end state. ✨ That's the whole point of Locator rewriting in ILNP, and it's the foundation for lots of the optional functions in this document. In ILNP, we call this feature "localised numbering". 🎀
Quick reminder, a Locator value in ILNP has the same meaning as a routing prefix in IP. In ILNPv4 and ILNPv6 [RFC6741], the routing prefixes from IPv4 and IPv6 are used as Locator values. 🧚
Also, a deployment that uses private/local numbering can make centralised management of site multihoming and network mobility way easier, by deploying SBRs this way. We'll get into that below. 🫶
Please note, with this proposal, localised numbering (for example, using the equivalent of IP NAT on the ILNP Locator bits) works in harmony with multihoming, mobility (for individual hosts and whole networks), and IP Security (IPsec), plus the other advanced functions in this document [BA11] [LABH06] [ABH07a] [ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] [ABH10] [BAK11]. Main character energy, literally. 👑
2.1. Localised Locators
Okay, let's look at a simple example for the NAT-like function in ILNP, using Figure 2.1. 🦋
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node
H = Host
L_1 = global Locator value
L_L = local Locator value
SBR = Site Border RouterFigure 2.1: A Simple Localised Numbering Example for ILNP
So the SBR gets the global Locator value L_1 from the upstream provider. 🌸 Internally, though, it advertises a "local" Locator value, L_L. When we say "local," we mean the Locator value only matters inside the site network. Any packets that have L_L as their source Locator can't be forwarded beyond the SBR. 🚧 In engineering terms, in ILNPv6, L_L would be an IPv6 prefix based on the assignments possible under IPv6 Unique Local Addresses (ULAs) [RFC4193].
Now, if host H uses Identifier I_H, it'll use the Identifier-Locator Vector (I-LV) [I_H, L_L]. The correspondent node (CN) uses IL-V [I_CN, L_CN]. If H sends a UDP packet from its port P_H to CN's port P_CN, H could send a UDP/ILNP packet with this tuple expression:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (1a)When this packet reaches the SBR, the SBR knows L_L is a local Locator value. So it rewrites the source Locator on the egress packet to L_1 and sends it out the external-facing interface. 🚀 The value L_1 is a global prefix, so the packet can be routed globally:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (1b)This packet reaches CN through normal routing based on the Locator value L_1, since it's a routing prefix. 🗺️
Notice that from expressions (1a) and (1b), the end-to-end state (in the UDP tuple) doesn't change at all. End-to-end state invariance is honoured for UDP. 💖 CN would send a UDP packet to H like this:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a)Then the SBR rewrites the Locator value on the ingress packet before forwarding it on its internal interface:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (2b)Again, the end-to-end transport-layer session state invariance is preserved. 🙌
Because the Locator values aren't used in the ILNP transport-layer pseudo-header [RFC6741], the checksum doesn't have to be rewritten. 🧮 So the Locator rewriting function is stateless and has low overhead. Iconic. 💅
(A discussion on the generation of Identifier values for initial use is presented in [RFC6741].) 📖
2.2. Mixed Local/Global Numbering
It's totally possible for the SBR to advertise both L_1 and L_L inside the site. Hosts in the site can then have IL-Vs that use both L_1 and L_L. 🍓 For example, host H might have IL-Vs [I_H, L_1] and [I_H, L_L]. How this mix gets configured and used can be controlled through local policy. 🎀
2.3. Dealing with Internal Subnets with Locator Rewriting
Okay, here's where it gets a little spicy. If the site network uses subnets, packets still need to be routed correctly inside the site. 🧭 The site might have several internal Locator values, like L_La, L_Lb, and L_Lc. When an ingress packet has the I-LV [I_H, L_1], the SBR is expected to figure out the correct internal network for I_H, and therefore the correct internal Locator value to rewrite the ingress packet with. 🤔 This isn't obvious at all, because the I value and the L value aren't related in any way.
There are lots of ways the SBR could look up the correct internal Locator value. This document doesn't prescribe any specific method. ✨ Of course, we don't rule out mappings that go straight from Identifier values to internal Locator values.
Honestly, a "flat" mapping between Identifier values and Locators would work, but keeping that mapping up to date would be impractical for a large site. 😭 So, we propose the following solution.
Consider that the Locator value L_x is made of two parts, L_pp and L_ss. L_pp is a network prefix, and L_ss is a subnet selector. This structure also holds for the local Locator, L_L, as well as the global Locator, L_1. Then, the SBR only needs to know the mapping from the L_ss values seen in L_1 to the L_ss values used locally. 🧁
That mapping could be mechanical. For example, the L_ss part of L_L and L_1 could be the same, and only the L_pp part is different. 🪞 If that isn't desirable (for example, to obfuscate the interior topology), an administrator needs to configure a suitable mapping policy in the SBR. This could be a simple lookup table. Note that with such a policy, the L_pp for L_L and L_1 don't need to be the same size. 💜
From a practical perspective, this works for both ILNPv6 [RFC6177] and ILNPv4 [RFC4632]. For ILNPv6, remember that the Locator value is encoded to look syntactically similar to an IPv6 address prefix, as shown in Figure 2.2, which is taken from [RFC6741]. 🌈
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
L_pp = Locator prefix part (assigned IPv6 prefix)
L_ss = Locator subnet selector (locally managed subnet ID)Figure 2.2: IPv6 Address format [RFC3587] as used in ILNPv6, showing how subnets can be identified.
Notice that the subnet ID is part of the Locator value. Also, [RFC6177] allows the global routing prefix to be longer than 45 bits, which makes the subnet ID smaller, while still keeping the Locator at 64 bits overall. 🎀
For ILNPv4, the L_pp value overall is an IPv4 routing prefix, which is typically less than 32 bits. 🧠 But the ILNPv4 Locator value is carried in the 32-bit IP Address space, so the bits that aren't used for the routing prefix can be used for L_ss. For example, with a /24 IPv4 prefix, the situation looks like Figure 2.3, and L_ss can use any of the remaining 8 bits as needed. 🦋
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
L_pp = Locator prefix (assigned IPv4 prefix)
L_ss = Locator subnet selector (locally managed subnet ID)Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in ILNPv4, showing how subnets can be identified.
Here's a quick example. Say the interior topology isn't obfuscated. An interior "engineering" node might have an LP record pointing to eng.example.com, and eng.example.com might have L32/L64 records for a specific subnet inside the site. Meanwhile, an interior "operations" node might have an LP record pointing at "ops.example.com", which might have different L32/L64 records for that same subnet within the site. 🏢 So eng.example.com might have Locator value L_pp_1:L_ss_1, and ops.example.com might have Locator value L_pp_1:L_ss_2. But, just like IPv6 or IPv4 routing today, the routing for the site would only need to use L_pp_1, which is a routing prefix in either IPv6 (for ILNPv6) or IPv4 (for ILNPv4). 💅✨
2.4. Localised Name Resolution with DNS ✨
Okay bestie, so to make private numbering work with IPv4 and IPv6 right now, some sites run a split-horizon DNS service just for the site [appDNS]. 💅
If a site using localised numbering decides to deploy a split-horizon DNS server, the DNS server would hand the global-scope Locator(s) of the SBR (that's L_1 in our example above) to DNS clients outside the site. It would advertise the local-scope Locator(s) (L_L in our example above) for that specific internal node to DNS clients inside the site. 🦋 Split-horizon setups like this aren't unusual on the IPv4 Internet today. If an internal node (e.g., a portable computer) moves outside the site, it would follow the normal ILNP methods to update its authoritative DNS server with its current Locator set. In this model, the authoritative DNS server for that mobile device will be either the split-horizon DNS server itself or the master DNS server that feeds data to the split-horizon DNS server. 🌸
If a site using localised numbering chooses not to deploy a split-horizon DNS server, then each internal node would advertise the global-scope Locator(s) of the site border routers in its own DNS entries. To deliver packets from one internal node to another, the site would pick one of two options. It could use Layer 2 bridging (e.g., IEEE Spanning Tree or IEEE Rapid Spanning Tree [IEEE04], or a link-state Layer 2 algorithm such as the ones the IETF TRILL group or IEEE 802.1 are developing). Or the interior routers would forward packets up to the nearest site border router, which would then rewrite the Locators to the appropriate local-scope values and forward the packet toward the interior destination node. 🧚
Alternatively, for sites that use localised numbering but don't deploy a split-horizon DNS server, the DNS server could return all global-scope and local-scope Locators to all queriers. It would assume that nodes use their normal local address and route selection criteria to pick the best Locator for reaching a given remote node ([RFC3484] for older IPv6 nodes, [RFC6724] for newer IPv6 nodes). Hosts in the same site as the correspondent node would only have a ULA configured, so they would select the ULA destination Locator for the correspondent (L_L in our example). Hosts outside the site wouldn't have that same ULA configured (L_CN for the CN in our example). 🎀
However, ILNP allows the use of Locator Preference values [RFC6742] [RFC6743]. These values explicitly indicate the relative preference given to Locator values, so they can steer which Locator (and therefore which interface) gets used to send an outgoing packet. That choice determines the value inserted into the IPv6 Source Address field (see Section 3 of [RFC6741]). A similar argument, using Locator Preference values, applies to the value inserted into the IPv6 Destination Address field. Honestly, by using suitable Preference values for a host with multiple Locator values, you could get something that resembles the address selection rules in [RFC3484] and [RFC6724], and this could be controlled through DNS entries for ILNP nodes, for example. 💜
Indeed, with the right localised or site-wide policy, and the right mechanisms in the devices (e.g., in end host operating systems or in Site Border Routers), Preference values for Locator values within the DNS could support options for multihomed transport sessions and/or site-controlled traffic engineering [ABH09a]. The details for this are left for further study, though, and overall, the rules defined in [RFC3484] and [RFC6724] cannot be applied directly to ILNPv6 nodes. 😭
Note that for split-horizon operation, there needs to be a DNS management policy for mobile hosts. When such hosts are away from their "home" network, they will need to update DNS entries so that only the global-scope Locator(s) is (are) used, and these are consistent with the current topological position of the mobile host. Such updates would need to be done using Secure Dynamic DNS Update. 🔥
For an ILNP mobile network using LP records, there are likely to be separate LP records for internal and external use. 🫶
2.5. Use of mDNS 🎧
Multicast DNS (mDNS) [mDNS11] is super popular across lots of end-system OSs today, especially desktop ones like Windows, Mac OS X and Linux. It's used for localised name resolution with names that have a .local suffix, for both IPv4 and IPv6. This protocol would need to be modified so that when an ILNP-capable node advertises its .local name, another ILNP-capable node could see that it's ILNP-capable. Meanwhile, other non-ILNP nodes wouldn't be perturbed in operation. 🌈 The details of a mechanism for using mDNS to enable this feature are not defined here.
2.6. Site Network Name in DNS 🍓
In this scenario, if H expects incoming ILNP session requests, for example, then remote nodes will normally need to look up the appropriate Identifier and Locator information in the DNS. Just like for IP, and as already described in [RFC6740], a Fully Qualified Domain Name (FQDN) lookup for H should resolve to the correct NID and L32/L64 records. If there are lots of hosts like H that need to keep DNS records (for any reason, including allowing incoming ILNP session requests), then there could potentially be lots of these DNS resource records. 📚
As an optimisation, the network as a whole may be configured with one or more L32 and L64 records (to store the value L_1 from our example) that are resolved from an FQDN. Meanwhile, individual hosts now have an FQDN that returns one or more LP record entries [RFC6742] as well as NID records. The LP record points to the L32 or L64 records for the site. A multihomed site normally will have at least one L32 or L64 record for each distinct uplink (i.e., each link from a Site Border Router toward the global Internet), because ILNP uses provider-aggregatable addressing. 🦋
More than one L32 or L64 will be required if multiple Locator values are in use. For example, if an ILNPv6 site has multiple links for multihoming, it will use one L64 record for each Locator value it's using on each link. ✨
2.7. Site Interior Topology Obfuscation 🕵️♀️
Sometimes it can be desirable to obfuscate the details of the interior topology of an end site. Alternatively, sometimes local site policy requires that local-scope routing prefixes be used within the local site. ILNP can provide these capabilities through the ILNP local addressing capability described here, under the control of the SBR. 👑
As described in Section 2.3 above, locator rewriting can be used to hide the internal structure of the network with respect to the subnetting arrangement of the site network. Specifically, the procedure described in Section 2.3 would be followed, with the following additional modifications to how Locator values are used:
(1) Only the aggregated Locator value, i.e., L_pp, is advertised outside the site (e.g., in an L32 or L64 record), and L_ss is zeroed in that advertisement.
(2) The SBR needs to maintain a mapping table to restore the interior topology information for received packets, for example, by using a mapping table from I values to either L_ss values or internal Locator values.
(3) The SBR needs to zero the L_ss values for all Source Locators of egress packets, as well as perform a Locator rewriting that affects the L_pp bits of the Locator value. 💅
Of course, this only obscures the interior topology of the site, not the exterior connectivity of the site. For the site to be reachable from the global Internet, the site's DNS entries need to advertise Locator values for the site to the global Internet (e.g., in L32, L64 records). 🌸
2.8. Other SBR Considerations 🛠️
For backwards compatibility, the ICMP checksum is always calculated identically for ILNP as for IPv6 or IPv4. For ILNPv6, this means the SBR doesn't need to be aware that ILNPv6 is operating as described in [RFC6740] and [RFC6741]. For ILNPv4, again, the SBR doesn't need to be aware of the operation, since it won't need to inspect the extension header that carries the I value. 🥰
To support communication between two internal nodes that happen to be using global-scope addresses (for whatever reason), the SBR MUST support the "hair pinning" behaviour commonly used in existing NAT/NAPT devices. (This behaviour is described in Section 6 of RFC 4787 [RFC4787].) 🚨
In the near term, a more common deployment scenario will be to deploy ILNP incrementally, with some ordinary classic IP traffic still around. In this case, the SBR should maintain flow state that contains a flag for each flow, indicating whether or not that flow is using ILNP. If that flag indicates ILNP is enabled for a given flow, and ILNP local numbering is also enabled, then the SBR would know that it should perform the simpler ILNP Locator rewriting mapping. If that flag indicates ILNP is not enabled for a given flow, and IP NAT or IP NAPT is also enabled, then the SBR would know that it should perform the more complex NAT/NAPT translation (e.g., including TCP or UDP checksum recalculation). 🦋
NOTE: Existing commercial security-aware routers (e.g., Juniper SRX routers) already can maintain flow state for millions of concurrent IP flows. This feature would add one flag to each flow's state, so this approach is believed scalable today using existing commercial technology. 🤯
Applications that don't use IP Address values in application state or configuration data are considered to be "well behaved". For well-behaved applications, no further enhancements are required. Where application-layer protocols aren't well behaved, such as the File Transfer Protocol (FTP), the SBR might need to perform additional stateful processing, just like NAT and NAPT equipment needs to do today for FTP. See the description in Section 7.6 of [RFC6741]. 🙈
When the SBR rewrites a Locator in an ILNP packet, that obscures information about how well a particular path is working between the sender and the receiver of that ILNP packet. So the SBR that rewrites Locator values needs to include mechanisms to ensure that any packet with a new Destination Locator will travel along a valid path to the intended destination node. For ILNPv4, path liveness will be no worse than IPv4, and mechanisms already in use for IPv4 can be reused. For ILNPv6, path liveness will be no worse than for IPv6, and mechanisms already in use for IPv6 can be reused. 🔥
In the future, the Border Router Discovery Protocol (BRDP) also might be used in some deployments to indicate which routing prefixes are currently valid and which site border routers currently have a working uplink [BRDP11]. 🔮
3. An Alternative for Site Multihoming 🌈
The ILNP Architectural Description [RFC6740] describes the basic approach to enabling Site Multihoming (S-MH) with ILNP. However, as an option, it's possible to leave the control of S-MH to an ILNP-enabled SBR. This alternative is based on the use of the Localised Numbering function described in Section 2 of this document. 💖
3.1. Site Multihoming (S-MH) Connectivity Using an SBR ✨
okay so the approach to Site Multihoming (S-MH) using an SBR is honestly easiest to get with an example 🎀 peep Figure 3.1 👀
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | sbr1+------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
CN = Correspondent Node
H = Host
L_1 = global Locator value 1
L_2 = global Locator value 2
L_L = local Locator value
SBR = Site Border Router
sbrN = interface N on SBRFigure 3.1: Alternative Site Multihoming Example with an SBR
this is giving localised numbering example vibes 💅, except the SBR now has two external links 🌈. One uses Locator value L_1 and another uses Locator value L_2. these could, e.g., for ILNPv6, be separate, Provider Aggregated (PA) IPv6 prefixes from two different ISPs 💜. H has IL-V [I_H, L_L] and will forward a packet to CN as given in expression (1a). BUT when the packet hits the SBR, local policy decides whether it goes out on the link sbr1 using L_1 or on sbr2 using L_2. Of course, the correct Locator value gets rewritten into the egress packet in place of L_L 🦋
if only local numbering is being used, the SBR need never advertise any global Locator values. however, it could do, as described in Section 2.2 🌸
3.2. Dealing with Link/Connectivity Changes ✨
one of the key uses for multihoming is resilience to link failure 🫶. if either link breaks, the SBR can manage the change in connectivity locally. for example, say SBR has been configured to use sbr1 for all traffic, and sbr2 only as a backup link. so SBR directs packets from H to communicate with CN using sbr1, and CN will receive packets as in expression (1b) and respond with packets as in expression (2a) 💖
but if sbr1 goes down, SBR moves the communication to interface sbr2. H is not aware of what the SBR is doing, so the SBR must maintain some state about IL-V "pairs" in order to hand off the connectivity from sbr1 to sbr2 😭. so when moving the communication to sbr2, the SBR would firstly send a Locator Update (LU) message [RFC6745] [RFC6743] to CN, informing it that L_2 is now the valid Locator for the communication. this operation would not be visible to H, although there might be some disruption to transmission, e.g., packets being sent from CN to H that are in flight when sbr1 goes down may be lost. the SBR might also need to update DNS entries (see Section 3.3). since ILNP requires that all Locator Update messages be authenticated by the ILNP Nonce, the SBR will need to include the appropriate Nonce values as part of its cache of information about ILNP sessions traversing the SBR. (NOTE: Since commercial security gateways available as of this writing reportedly can handle full stateful packet inspection for millions of flows at multi-gigabit speeds, it should be practical for such devices to cache the ILNP flow information, including Nonce values.) 🤓
this approach has some efficiency gains over the approach for multihoming described in [RFC6740], where each host manages its own connectivity 🧚
if sbr1 gets reinstated, now with Locator value L_3, local policy determines whether the communication should move back to sbr1, with appropriate additional actions, such as transmission of LU messages with the new Locator values and also the updates to DNS 🍓
and the best bit: when an ILNP session moves across interfaces at the SBR, only Locator values in ILNP packets change. as already noted in [RFC6740], end-to-end transport-layer session state invariance is maintained 👑✨
3.3. SBR Updates to DNS ✨
when the SBR manages connectivity like this, the internal hosts, such as H, are not necessarily aware of any connectivity changes. honestly there is certainly no requirement for them to be aware 🙈. so if H was a server expecting incoming connections, the SBR must update the relevant DNS entries when the site connectivity changes 📡
there are two possibilities: each host could have its own L32 or L64 records, or the site might use a combination of LP and L32/L64 records (see Section 2.4). either way, the SBR needs to update the relevant DNS entries 💅. for our example, with ILNPv6 and LP records in use, the SBR would manage two L64 records (one for each uplink) that resolve from an FQDN, for example, site.example.com. meanwhile, individual hosts, such as H, have an FQDN that resolves to an NID value and an LP record containing the value site.example.com, which is then used to look up the two L64 records 🎀
if the SBR is multihomed, as in Figure 3.1, it will have (at least) two Locator values, one for each link, and local policy will need to be used to determine how preference values are applied in the relevant L32 and L64 records 🌈
3.4. DNS TTL Values for L32 and L64 Records ✨
imagine that in the scenario above, there's a link failure that results in sbr1 going down and sbr2 being used. existing ILNP sessions in progress would move to sbr2 as described above 🦋. BUT new incoming ILNP sessions to the site would need to know to use L_2 and not L_1 😳. L_1 and L_2 would be stored in DNS records (e.g., L32 for ILNPv4 or L64 for ILNPv6). if a remote host has already resolved from DNS that L_1 is the correct Locator for sending packets to the site, that host might be holding stale information 💀
DNS lets returned values be aged using Time-To-Live (TTL), which is specified in seconds ⏰. so that remote nodes do not hold on to stale values from DNS, the L64 records for our site should have low TTL values. an appropriate value must be considered carefully 🧐. for example, let's assume the site administrator knows that when sbr1 fails, it takes 20 seconds to failover to sbr2. then 20 s would seem to be an appropriate TTL for an L64 for the site: if a remote node had just resolved the value L_1 for the site, and the link to sbr1 went down, that remote node would not hold the stale value of L_1 for any longer than it takes the site to failover to sbr2 and use L_2 🫶
our studies for a university school site network show that low TTL values, as low as zero, are feasible for operational use [BA11] 🔥
NOTE: From 01 November 2010, the site network of the School of Computer Science, University of St Andrews, UK, has been running operational DNS with DNS A records that have TTL of zero. At the time of writing of this document (November 2012), a zero DNS TTL was still in use at the school.
3.5. Multiple SBRs ✨
for site multihoming with multiple SBRs, a situation may look like this (see also Section 5.3.1 in [RFC6740]) 🌸
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 PFigure 3.2: A Dual-Router Multihoming Scenario for ILNP
two physical routers give an extra level of resilience compared to the scenario of Figure 3.1 💜. the coordination protocol (CP) between the two routers keeps their actions in synchronisation according to whatever management policy is in place for the site network. such functions are available today in some commercial network security products 💅. note that, logically, there is little difference between Figures 5.1 and 3.2, but with two distinct routers in Figure 3.2, the interaction using CP is required 🙌. of course, it's also possible to have multiple interfaces in each router and more than two routers 🎀
4. An Alternative for Site (Network) Mobility ✨
the ILNP Architectural Description [RFC6740] describes the basic approach to enabling site (network) mobility with ILNP 🧚. however, as an option, it is possible to leave control of site mobility to an ILNP-enabled SBR by exploiting the alternative site multihoming feature described in Section 3 of this document 🦋
again, as described in [RFC6740], we exploit the duality between mobility and multihoming for ILNP 🌈💖
4.1. Site (Network) Mobility 🦋
okay so let's look at the mobile network in Figure 4.2, which is borrowed from [RFC6740] 🚗💨
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 4.1a: ILNP Mobile Network before Handover site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 4.1b: ILNP Mobile Network during Handover site ISP_2
network SBR . . .
. . . . +------+ . .
. . L_L | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . .
. . .
Figure 4.1c: ILNP Mobile Network after Handover H = host
L_1 = global Locator value 1
L_2 = global Locator value 2
L_L = local Locator value
raN = radio interface N
SBR = Site Border Router
Figure 4.1: An Alternative Mobile Network Scenario with an SBRso we're assuming the site network is mobile, and the SBR has two radio interfaces, ra1 and ra2 📡 in the figure, ISP_1 and ISP_2 are separate, radio-based service providers, reachable through interfaces ra1 and ra2. super clear vibes 💖
While the SBR goes from using one link (Figure 4.1a) to the handover overlap on both links (Figure 4.1b), and then back to using a single link again (Figure 4.1c), the host H keeps using only Locator value L_L, same as we already covered for Site Multihoming (S-MH) 🫶 during all of this, the actions the SBR takes are the same as already described in [RFC6740], except that the SBR:
a) also performs the ILNP localised numbering function described in Section 2.
b) doesn't need to advertise L_1 and L_2 internally if only local numbering is being used.
just like with S-MH, H doesn't need to know about the change in connectivity for the SBR if it's only using local numbering. the SBR would still send LU messages for H (to any correspondent nodes, which aren't shown in Figure 4.1), and it would update DNS entries as required 💅
the difference from the S-MH scenario we talked about earlier is that in the situation of Figure 4.1b, the SBR can choose to use soft handover, as previously described in [RFC6740] ✨
and yeah, there's an efficiency gain compared to the situation described in [RFC6740]: the SBR gives you one central spot to manage the movement of the whole site 🧚 also, in Figure 4.1b, the site is multihomed, which is kinda iconic 👑
same as S-MH, L_1 and L_2 could be advertised internally as a local policy decision, for hosts that need direct control of their connectivity 🎀
one more thing: for handover, immediate handover behaves a lot like a link outage, as described for S-MH. BUT ILNP allows soft-handover, and during the handover period, that should help reduce (or maybe even remove) packet loss 🙌
4.2. SBR Updates to DNS 🌸
same as S-MH, a similar discussion to Section 3.3 applies to mobile networks when it comes to updates to DNS. a mobile network is probably going to see more frequent connectivity changes than a multihomed network would, so LP DNS records are likely to be especially useful here 💜
4.3. DNS TTL Values for L32 and L64 Records 🍓
same deal as S-MH: a similar discussion to Section 3.4 applies to mobile networks with respect to the TTL of L32 and/or L64 records that are used for the name of the mobile network. for a mobile network, it makes sense to line the TTL up with the time for handover ⏱️
5. Traffic Engineering Options 🎯
ok this part is so cool bestie. Locator rewriting gives you some simple but really useful options for traffic engineering (TE) that you control from the edge-site through the SBR 😍 you don't need any cooperation from the service provider beyond basic connectivity services, like physical connectivity, allocation of IP Address prefixes and packet forwarding. this doesn't rule out other TE options that are already in use, like MPLS, but we're choosing to highlight the specific options you can control using only ILNP 💅
when a site network is multihomed, we've seen that Locator rewriting lets the SBR have packet-by-packet control when forwarding on external links. all sorts of configuration and policies can be applied at the SBR to control the egress and ingress traffic of the site network 🔥
5.1. Load Balancing ⚖️
let's look at Figure 5.1, and assume ILNP local numbering is in use: H1, H2, and H3 use Identifier values I_1, I_2 and I_3 respectively, and all of them use Locator value L_L 🌈
site . . . .
network SBR . .
. . . . +------+ L_1 . .
. . | sbr1+------. .
. H2 .L_L | | . .
. H3 .----+ | . Internet .
. . | | . .
. H1 . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
HN = host N
L_1 = global Locator value 1
L_2 = global Locator value 2
L_L = local Locator value
SBR = Site Border Router
sbrN = interface N on sbr
Figure 5.1: A Site Multihoming Scenario for Traffic Controlthe SBR could be configured, subject to local policy, to try to control load across the external links. for example, it could start out with these mappings:
srcI=I_1, sbr1 --- (3a)
srcI=I_2, sbr2 --- (3b)
srcI=I_3, sbr1 --- (3c)these mappings send packets matching course Identifier values to particular outgoing interfaces 🚦 as load changes, the mappings can be changed. for example, expression (3c) could become:
srcI=I_3, sbr2 --- (4)and the SBR would need to send an LU message to the correspondents of H3 (sbr to uses L_2 while sbr1 uses L_1) 📨 the egress connectivity is totally in the SBR's control under administrative policy, same as we already saw in the descriptions of multihoming and mobility in this document 💖
of course, more complex policies are possible, based on:
- whether ILNP sessions are incoming or outgoing
- time of day
- internal subnets
and any number of criteria already used to control traffic 😎
in expressions (3a,b,c) above, we used source I values. BUT:
- destination I values could be used
- source or destination L values could be used
- mappings could be to L values, not to specific interfaces
and again, any number of criteria could be used to manipulate the packet path, based on filtering of values in header fields and local policy 🧠
with ILNP, hosts don't need to be aware of how the SBR does this 🙈
also, note again that in this scenario, nothing stops the SBR from also advertising L_1 and L_2 into the site network. if needed, administrative controls can let selected hosts in the site network use L_1 and L_2 directly, as described in [RFC6740] 🫧
5.2. Control of Egress Traffic Paths 🛣️
extending the load-balancing scenario above, it is also be possible for the ILNP-capable SBR to direct traffic along specific network paths based on using different L values, i.e., by using multiple prefixes assigned from upstream providers 💫
of course, as we discussed before, these prefixes can be Provider Aggregated (PA) and don't have to be Provider Independent (PI) ✨
let's check out Figure 5.2 and assume ILNP local numbering is in use: H1, H2 and H3 use Identifier values I_1, I_2, and I_3 respectively, and all of them use Locator value L_L. let's also assume that the node CN uses IL-V [I_CN, L_CN] 🎀
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L1,L2 . . +----+
. . | sbr1+--------. .
. H2 .L_L | | . .
. H3 .----+ sbr2+--------. Internet .
. . | | L3,L4 . .
. . | | . .
. H1 . | sbr3+--------. .
. . . . +------+ L5,L6 . .
. .
. . . .
CN = correspondent node
HN = host N
LN = global Locator value N
L_L = local Locator value
SBR = Site Border Router
sbrN = interface N on sbr
Figure 5.2: A Site Multihoming Scenario for Traffic Controlthere are lots of configurations possible here 🤩 for example, for egress traffic:
srcI=I_2, L2 --- (5a)
srcI=I_3, L3 --- (5b)
dstI=I_CN, L6 --- (5c)
srcI=I_1 dstI=I_CN, L1 --- (5d)expression (5a) maps all egress packets from H2 to have their source Locator value rewritten to L2 (and implicitly to use interface sbr1) 💅 expression (5b) maps all egress packets from H3 to have their source Locator value rewritten to L3 (and implicitly to use interface sbr2) 💜 expression (5c) directs any traffic to CN to use Locator value L6 as the source Locator (and implicitly to use interface sbr3), and it may override (5a) and (5b), subject to local policy, when packets to CN are from H2 or H3 🫶
meanwhile, expression (5d) is a more specific rule: packets from H1 destined to CN should use Locator value L1 (and implicitly use interface sbr1) 🎯
note the implicit bindings to interfaces in expressions (5a,b,c,d), compared to the explicit bindings in expressions (3a,b,c). ILNP only requires that the Locator values are correctly rewritten and that packets are forwarded in line with the routing already configured for the Locator values 🛤️
and of course, these rules can be changed dynamically at the SBR, and the SBR will migrate ILNP sessions across Locator values, as already described above for mobility 🦋✨
6. ILNP in Datacentres ✨
okay so ILNP has first-class support for mobility AND multihoming, and it comes with flexible options for localised addressing 🫶 which means datacentres could be a huge match. the full details are in [BA12], and here's the highlight reel 🎀
There are a few scenarios that could be super beneficial for datacentres, helping with things like load balancing, resilience and fault tolerance, and resource management 💅:
- Same datacentre, internal Virtual Machine (VM) mobility: This could be beneficial in load balancing, dynamically, where load changes are taking place. The remote user does not see the VM has moved.
- Different datacentres, transparent mobility: This is where the datacentre resources may be geographically distributed, but the geographical movement is transparent to the remote user.
- Different datacentres, mobility is visible: This is where the datacentre resources may be geographically distributed, but the geographical movement is visible to the remote user.
These are three situations that may be supported by ILNP, but they are not the only ones 🌈 we're just giving these as examples, and they are not intended to be prescriptive. The point is only to show the flexibility that's possible through the use of ILNP ✨
This section describes some Virtual Machine (VM) mobility capabilities that are possible with ILNP 🦋 depending on the internal details and virtualisation model provided by a VM platform, it might be sufficient for the guest operating system to support ILNP. In some cases, again depending on the internal details and virtualisation model provided by a VM platform, the VM platform itself also might need to include support for ILNP 🧚
Details of how a particular VM platform works, and which virtualisation model(s) a VM platform supports, are beyond the scope of this document 🙈 Internal implementation details of VM platform support for ILNP are also beyond the scope of this document, just as internal implementation details for any other networked system supporting ILNP are beyond the scope of this document. Not our vibe to cover here, bestie 💜
6.1. Virtual Image Mobility within a Single Datacentre
Let's start with the scenario of Figure 6.1, noting its similarity to Figure 2.1 for use of localised numbering 🍓
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. H2 .L_L | | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node
V = Virtual machine image
Hx = Host x
L_1 = global Locator value
L_L = local Locator value
SBR = Site Border Router
Figure 6.1: A Simple Virtual Image Mobility Example for ILNPL_L is a Locator value used for the ILNP hosts H1 and H2 🌸 Here, the "V*H1" signifies that the virtual machine image V is currently resident on H1. Let us assume that V has Identifier I_V. Note that as H1 and H2 have the same Locator value (L_1), as far as CN is concerned, it does not matter if V is resident on H1 or H2. All transport packets between V and CN will have the same signature as far as CN is concerned, e.g., for a UDP flow (in analogy to (1a)):
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN> --- (6a)Now, if V was to migrate to H2, the migration would be an issue purely local to the site network, and the end-to-end integrity of the transport flow would be maintained 🔥
Of course, there are practical operating systems issues in enabling such a migration locally, but products exist today that could be modified and made ILNP-aware in order to enable such VM image mobility 💅
Note that for convenience, above, we have used localised numbering for ILNP, but if local Locator values were not used and the whole site simply used L_1, the principle would be the same 🦋
6.2. Virtual Image Mobility between Datacentres - Invisible
Now let's look at an extended version of the scenario above in Fig. 6.2 🌈 where there is a second site network, which is geographically distant to the first site network, and the two site networks are interconnected via their respective SBRs.
site . . . . +----+
network 1 SBR1 . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L1| | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +---+--+ . .
: . .
: . .
. . . . +---+--+ L_2 . .
. . | +------. .
. H2 .L_L2| | . .
. .----+ | . .
. . | | . .
. . | | . .
. . . . +------+ . .
site SBR2 . .
network 2 . . . .
: = logical inter-router link and coordination
CN = Correspondent Node
V = Virtual machine image
Hx = Host x
L_y = global Locator value y
L_Lz = local Locator value z
SBR = Site Border Router
Figure 6.2: A Simple Localised Numbering Example for ILNPNote that the logical inter-router link between SBR1 and SBR2 could be realised physically in many different ways that are available today and are not ILNP-specific, e.g., leased line, secure IP-layer or Layer 2 tunnel, etc. We assume that this link also allows coordination between the two SBRs. For now, we ignore external link L_2 on SBR2, and assume that the remote node, CN, is in communication with V through SBR1 ✨
When in initial communication, the packets have the signature given in expression (6a). When V moves to H2, it now uses Locator value L_L2, but all communication between V and CN is still routed via SBR1. So, the remote CN still sees that same packet signature as given in expression (6a). L_L1 and L_L2 are, effectively, two internal (private) subnetworks, and are not visible to CN 🎀
However, SBR2 and SBR1 must coordinate so that any further communication to V via SBR1 is routed across the inter-router link. Again, there are commercial products today that could be adapted to manage such shared state 💜
6.3. Virtual Image Mobility between Datacentres - Visible
Clearly, in the scenario of the section above, once V has moved to site network 2, it may be beneficial, for a number of reasons, for communication to V to be routed via SBR2 rather than SBR1 👑
When V moves from site network 1 to site network 2, this visibility of mobility could be by V sending ILNP Locator Update messages to the CN during the mobility process. Also, V would update any relevant ILNP DNS records, such as L64 records, for new ILNP session requests to be routed via SBR2 🧚
Indeed, let's now consider Figure 6.2 again, and assume that Local locators L_L1 and L_L2 are not in use on either site network, and each site network uses its own global Locator value, L_1 and L_2, respectively, internally. In that case, the packet flow signature for V when it is in site network 1, as viewed from CN, is again as given in expression (6a). However, when V moves to site network 2, it would simply use L_2 as its new Locator, send Locator Update messages to CN as would a normal mobile node for ILNP, and complete its migration to H2. Then, CN would see the packet signatures as in expression (6b) 🦋
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN> --- (6b)In this case, no "special" inter-router link is required for mobility -- the normal Internet connectivity between SBR1 and SBR2 would suffice. However, it is quite likely that some sort of tunnelled link would still be desirable to offer protection of the VM image as it migrates 🫶
6.4. ILNP Capability in the Remote Host for VM Image Mobility
For the remote host -- the CN -- the availability of ILNP would be beneficial 🌸 However, for the first two scenarios listed above, as the packet signature of the transport flows remains fixed from the viewpoint of the CN, it seems possible that the benefits of ILNP VM mobility could be used for datacentres even while CNs remain as normal IP hosts. Of course, a major caveat here is that the application level protocols should be "well behaved": that is, the application protocol or configuration should not rely on the use of IP Addresses ⭐
7. Location Privacy 🙈
Extending the Locator rewriting paradigm, it is possible to also enable Location privacy for ILNP by a modified version of the "onion routing" paradigm that is used for Tor [DMS04] [RSG98] 🌈
7.1. Locator Rewriting Relay (LRR)
okay so to make this work, we use a middlebox called the Locator Rewriting Relay 🎀 Here's how it works, with Figure 7.1 ✨
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (7a)
v
|
+--+--+
| | src=[I_H, L_1], L_X --- (7b)
| LRR | dst=[I_H, L_X], L_1 --- (7c)
| |
+--+--+
|
v
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (7d)
LRR = Locator Rewriting Relay
Figure 7.1: Locator Rewriting Relay (LRR) ExampleThe LRR is conceptually very simple 💅 We assume it already has the mappings in expressions (7b) and (7c) (see the next subsection). Expression (7b) says that packets with source IL-V [I_H, L_1] get their source Locator rewritten to L_X and then get forwarded. Expression (7c) is the complementary mapping, for packets with destination IL-V [I_H, L_1] (the reverse direction) 🦋
Expression (6a) is a UDP/ILNP packet like the one that could be sent in Figure 2.1 from H to CN. But instead of going straight to L_CN, the packet with destination Locator L_1 goes to an LRR first 🫶 Expression (7d) is what you get when packet (7a) is mapped using expression (7b).
Also, it's totally possible that the packet from expression (7d) then gets processed by another LRR for source Locator value L_X. Basically, this builds an LRR path for the packet, as an overlay path sitting on top of normal IP routing 🌈
So this gives you a level of protection for the packet's (topological) Location, without needing cryptographic techniques 🧚 An extremely well-resourced adversary could potentially backtrack the LRR path, but depending on which LRR overlay path gets created, it could be really hard to trace in reality 😭 The mechanism protects against off-path attacks, but if your threat situation includes on-path attacks, cryptographically protected tunnels between H and the LRR might be required 🔥
Again, the Locator value isn't part of the end-to-end state, so this mechanism is very general and has low overhead ✨
7.2. Options for Installing LRR Packet Forwarding State
There are so many options for managing the "network" of LRRs, if a system like this were used at large scale 🍓 That includes setting up and removing the LRR state used for packet relaying, like for expressions (7b) and (7c). The authors consider this function to be outside the scope of these ILNP specifications. Still, there are lots of existing mechanisms that could be modified for use, and lots of possibilities for new mechanisms that would be specific to ILNP LRRs 💜
(Note also that control and management communication with the LRR doesn't need to use ILNP. IPv4 or IPv6 could be used instead 🦋)
The host, H, could install the required state by itself, assuming it knew suitable information for contacting the LRR. The first packet in an ILNP session might contain a header option called a Locator Redirection Option (LRO) 🎀 The LRO would contain the Locator value that should be rewritten into the packet's source Locator. When an LRR receives a packet like that, it would install the required state 👑 This could be soft-state, meaning the LRO gets used periodically to keep the state alive in the LRR. The LRO could also be delivered in an ICMP ECHO packet sent from H to the LRR, again periodically, to keep the soft-state updated 🌸
It would, of course, be prudent to protect the LRR state control packets with some kind of authentication token 🙈 Otherwise an adversary could easily install false LRR state and cause packets from H or its correspondent to be hit with man-in-the-middle attacks or black-holing 💀 Again, these attacks aren't specific to ILNP or new to ILNP, so no panic, just be careful ✨
It would also be possible to use proprietary application level protocols, with strong authentication for controlling the LRR state 🧚 For example, an application level protocol based on XMPP (http://xmpp.org/) operating over SSL 💖
Above, we've given very brief and incomplete descriptions of some possibilities, and we don't necessarily mandate any one of them. They're just examples 🫶
8. Identity Privacy
For the sake of completeness, and as a complement to Section 6, here's something to know 🦋 ILNP can use either cryptographically verifiable Identifier values, or Identifier values that give a level of anonymity to protect a user's privacy 🌈 More details are in Sections 2 and 11 of [RFC6741] 💜
9. Security Considerations
The relevant security considerations for this document are the same as for the main ILNP Architectural Description [RFC6740] 🔥 The one extra point is that this document describes ILNP capability in the SBR, so adversaries who want to specifically subvert ILNP operation now have a target that could potentially disable an entire site 😭 However, this isn't an attack vector that's specific to ILNP. Today, disrupting an IPv4 or IPv6 SBR would have the same impact 💀
The security considerations for Section 7 (Location Privacy) are already documented in [DMS04] and [RSG98] 🙈 One possibility is that the LRR mechanism itself could be used by an adversary to launch an attack and hide their own (topological) Location, for example. This is already possible for IPv4 and IPv4 with a Tor-like system today, so it's not new to ILNP 👑
10. References
10.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
and E. Klein, "Local Network Protection for IPv6", RFC
4864, May 2007.
[RFC4924] Aboba, B., Ed., and E. Davies, "Reflections on Internet
Transparency", RFC 4924, 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.
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts
on IPv6 Network Address Translation", RFC 5902, July
2010.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March
2011.
[RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
November 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.10.2. Informative References
Okay bestie, these are the extra reading sources, the ones the spec points to for background but doesn't depend on to work 📚✨ Here they all are, details exactly as written:
[ABH07a]Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch), ACM SIGCOMM, Kyoto, Japan. 27 Aug 2007. 🦋[ABH07b]Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of 2nd ACM Workshop on Mobility Management and Wireless Access (MobiWAC), ACM, Chania, Crete, Oct 2007. ISBN: 978-1-59593-809-1 🌸[ABH08a]Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", Proceedings of 3rd ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch), ACM SIGCOMM, Seattle, WA, USA. Aug 2008. 🧚[ABH08b]Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of the IEEE Military Communications Conference (MILCOM), IEEE, San Diego, CA, USA, Nov 2008. 💅[ABH09a]Atkinson, R, Bhatti, S., and S. Hailes, "Site- Controlled Secure Multi-Homing and Traffic Engineering For IP", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009. 🎀[ABH09b]Atkinson, R., Bhatti, S., and S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming"", Telecommunication Systems", vol. 42, no. 3-4, pp 273-291, Springer-Verlag, Dec 2009. 🔥[ABH10]Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC), vol. 28, no. 8, pp 1319-1325, IEEE, Oct 2010. 💖[appDNS]Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", Work in Progress, July 2012. 🌈[BA11]Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proceedings of IEEE Global Internet Symposium (GI2011), Shanghai, P.R. China, 15 Apr 2011. ⭐[BA12]Bhatti, S. and R. Atkinson, "Secure & 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), IEEE, Baltimore, MD, USA, Nov 2011. 🫶[BRDP11]Boot, T. and A. Holtzer, "BRDP Framework", Work in Progress, January 2011. 🌸[DMS04]Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", Proceedings of 13th USENIX Security Symposium, USENIX Association, San Diego, CA, USA, 2004. 🧅[IEEE04]"IEEE 802.1D - IEEE Standard for Local and Metropolitan Area Networks, Media Access Control (MAC) Bridges", IEEE Standards Association, New York, NY, USA, 9 June 2004. Print: ISBN 0-7381-3881-5 SH95213. PDF: ISBN 0-7381-3982-3 SS95213. 📘[LABH06]Atkinson, R., Lad, M., Bhatti, S., and S. Hailes, "A Proposal for Coalition Networking in Dynamic Operational Environments", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Washington, DC, USA, Nov 2006. 👑[mDNS11]Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, December 2011. 🦋[RAB09]Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009. 💜[RB10]Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of 6th IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada, Oct 2010. 🎀[RFC4193]Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. 🌈[RFC6296]Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. ✨[RSG98]Reed, M., Syverson, P., and D. Goldschlag, "Anonymous Connections and Onion Routing", IEEE Journal on Selected Areas in Communications, Vol. 16, No. 4, IEEE, Piscataway, NJ, USA, May 1998. 🧚
11. Acknowledgements 🫶
Big thank-you energy going out to these legends, who gave review and feedback on earlier versions of this doc (listed alphabetically, no favourites 💖): 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. Steve Blake gave an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful 😭🔥. The authors 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, and he is absolutely iconic for it 👑✨.
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: rfc6748 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms