From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6748.txt | 2075 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2075 insertions(+) create mode 100644 doc/rfc/rfc6748.txt (limited to 'doc/rfc/rfc6748.txt') diff --git a/doc/rfc/rfc6748.txt b/doc/rfc/rfc6748.txt new file mode 100644 index 0000000..181546c --- /dev/null +++ b/doc/rfc/rfc6748.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Research Task Force (IRTF) RJ Atkinson +Request for Comments: 6748 Consultant +Category: Experimental SN Bhatti +ISSN: 2070-1721 U. St Andrews + November 2012 + + + Optional Advanced Deployment Scenarios for the + Identifier-Locator Network Protocol (ILNP) + +Abstract + + This document provides an Architectural description and the Concept + of Operations of some optional advanced deployment scenarios for the + Identifier-Locator Network Protocol (ILNP), which is an evolutionary + enhancement to IP. None of the functions described here is required + for the use or deployment of ILNP. Instead, it offers descriptions + of engineering and deployment options that might provide either + enhanced capability or convenience in administration or management of + ILNP-based systems. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the individual + opinion(s) of one or more members of the Routing Research Group of + the Internet Research Task Force (IRTF). Documents approved for + publication by the IRSG are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6748. + + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 1] + +RFC 6748 ILNP ADV November 2012 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 2] + +RFC 6748 ILNP ADV November 2012 + + +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 ..............................................37 + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 3] + +RFC 6748 ILNP ADV November 2012 + + +1. Introduction + + This document is part of the ILNP document set, which has had + extensive review within the IRTF Routing RG. ILNP is one of the + recommendations made by the RG Chairs. Separately, various refereed + research papers on ILNP have also been published during this decade. + So, the ideas contained herein have had much broader review than the + IRTF Routing RG. The views in this document were considered + controversial by the Routing RG, but the RG reached a consensus that + the document still should be published. The Routing RG has had + remarkably little consensus on anything, so virtually all Routing RG + outputs are considered controversial. + + At present, the Internet research and development community is + exploring various approaches to evolving the Internet Architecture to + solve a variety of issues including, but not limited to, scalability + of inter-domain routing [RFC4984]. A wide range of other issues + (e.g., site multihoming, node multihoming, site/subnet mobility, node + mobility) are also active concerns at present. Several different + classes of evolution are being considered by the Internet research + and development community. 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 being + considered is sometimes known as "Identifier/Locator Split". This + document relates to a proposal that is in the latter class of + evolutionary approaches. + + ILNP is, in essence, an end-to-end architecture: the functions + required for ILNP are implemented in, and controlled by, only those + end-systems that wish to use ILNP, as described in [RFC6740]. Other + nodes, such as Site Border Routers (SBRs) need only support IP to + allow operation of ILNP, e.g., an SBR should support IPv6 in order to + enable end-systems to operate ILNPv6 within the site network for + which an SBR provides a service [RFC6741]. + + However, some features of ILNP could be optimised, from an + engineering perspective, by the use of an intermediate system (a + router, security gateway or "middlebox") that modifies (rewrites) + Locator values of transit ILNP packets. It would also perform other + control functions for an entire site, as an administrative + convenience, such as providing a centralised point of management for + a site. For example, an SBR might manipulate the topological + presence of the packet, providing an elegant solution to the + provision of functions such as site (network) mobility for an entire + end site [ABH09a]. + + + + + + +Atkinson & Bhatti Experimental [Page 4] + +RFC 6748 ILNP ADV November 2012 + + + This document discusses several such optional advanced deployment + scenarios for ILNP. These 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 first read the ILNP Architecture + Description [RFC6740], as this document uses the notation and + terminology described or referenced in that document. + +1.1. Document Roadmap + + This document describes 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, one can imagine a "clean-slate" + engineering design based on the ILNP architecture. In separate + documents, we 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. + + Many 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 + described 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. + + + + + + + +Atkinson & Bhatti Experimental [Page 5] + +RFC 6748 ILNP ADV November 2012 + + + 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 + + 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]. + +2. Localised Numbering + + Today, Network Address Translation (NAT) [RFC3022] is used for a + number of purposes. Whilst one of the original intentions of NAT was + to reduce the rate of use of global IPv4 addresses, through use of + IPv4 private address space [RFC1918], NAT also offers to site + administrators a convenient localised address management capability + combined with a local-scope/private address space, for example, + [RFC1918] for IPv4. + + For IPv6, NAT would not necessarily be required to reduce the rate of + IPv6 address depletion, because the availability of addresses is not + such an issue as for IPv4. The IETF has standardised Unique Local + IPv6 Unicast Addresses [RFC4193], which provide local-scope IPv6 + unicast address space that can be used by end sites. However, + localised address management, in a manner similar to that provided by + + + + + + + + + +Atkinson & Bhatti Experimental [Page 6] + +RFC 6748 ILNP ADV November 2012 + + + IPv4 NAT and private address space [RFC1918], is still desirable for + IPv6 [RFC5902], even though there is debate about the efficacy of + such an approach [RFC4864]. + + One of the major concerns that many have had with NAT is the loss of + end-to-end transport-layer and network-layer session state + invariance, which is still considered an important architectural + principle by the IAB [RFC4924]. Nevertheless, the use of localised + addressing remains in wide use and there is interest in its continued + use in IPv6, e.g., proposals such as [RFC6296]. + + It is possible to have the benefits of NAT-like functions for ILNP + without losing end-to-end state. Indeed, such a mechanism -- the use + of Locator rewriting in ILNP -- forms the basis of many of the + optional functions described in this document. In ILNP, we call this + feature "localised numbering". + + Recall, that a Locator value in ILNP has the same semantics as a + routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [RFC6741], routing + prefixes from IPv4 and IPv6, respectively, are used as Locator + values. + + We note that a deployment using private/local numbering can also + provide a convenient solution to centralised management of site + multihoming and network mobility by deploying SBRs in this manner -- + this is described below. + + Please note that with this proposal, localised numbering (e.g., using + the equivalent of IP NAT on the ILNP Locator bits) would work in + harmony with multihoming, mobility (for individual hosts and whole + networks), and IP Security (IPsec), plus the other advanced functions + described in this document [BA11] [LABH06] [ABH07a] [ABH07b] [ABH08a] + [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] [ABH10] [BAK11]. + +2.1. Localised Locators + + For ILNP, the NAT-like function can best be descried by using a + simple example, based on Figure 2.1. + + + + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 7] + +RFC 6748 ILNP ADV November 2012 + + + 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 Router + + Figure 2.1: A Simple Localised Numbering Example for ILNP + + In this scenario, the SBR is allocated global locator value L_1 from + the upstream provider. However, the SBR advertises internally a + "local" Locator value L_L. By "local" we mean that the Locator value + only has significance within the site network, and any packets that + have L_L as a source Locator cannot be forwarded beyond the SBR with + value L_L as the source Locator. In engineering terms, L_L would, + for example, in ILNPv6, be an IPv6 prefix based on the assignments + possible according to IPv6 Unique Local Addresses (ULAs) [RFC4193]. + + If we assume that H uses Identifier I_H, then it will use Identifier- + Locator Vector (I-LV) [I_H, L_L], and that the correspondent node + (CN) uses IL-V [I_CN, L_CN]. If we consider that H will send a UDP + packet from its port P_H to CN's port P_CN, then H could send a + UDP/ILNP packet with the tuple expression: + + --- (1a) + + When this packet reaches the SBR, it knows that L_L is a local + Locator value and so rewrites the source Locator on the egress packet + to L_1 and forwards that out onto its external-facing interface. The + value L_1 is a global prefix, which allows the packet to be routed + globally: + + --- (1b) + + This packet reaches CN using normal routing based on the Locator + value L_1, as it is a routing prefix. + + + + +Atkinson & Bhatti Experimental [Page 8] + +RFC 6748 ILNP ADV November 2012 + + + Note that from expressions (1a) and (1b), the end-to-end state (in + the UDP tuple) remains unchanged -- end-to-end state invariance is + honoured, for UDP. CN would send a UDP packet to H as: + + --- (2a) + + and the SBR would rewrite the Locator value on the ingress packet + before forwarding the packet on its internal interface: + + --- (2b) + + Again, this preserves the end-to-end transport-layer session state + invariance. + + As the Locator values are not used in the transport-layer pseudo- + header for ILNP [RFC6741], the checksum would not have to be + rewritten. That is, the Locator rewriting function is stateless and + has low overhead. + + (A discussion on the generation of Identifier values for initial use + is presented in [RFC6741].) + +2.2. Mixed Local/Global Numbering + + It is possible for the SBR to advertise both L_1 and L_L within the + site, and for hosts within the site to have IL-Vs using both L_1 and + L_L. For example, host H may have IL-Vs [I_H, L_1] and [I_H, L_L]. + The configuration and use of such a mechanism can be controlled + through local policy. + +2.3. Dealing with Internal Subnets with Locator Rewriting + + Where the site network uses subnets, packets will need to be routed + correctly, internally. That is, the site network may have several + internal Locator values, e.g., L_La, L_Lb, and L_Lc. When an ingress + packet has I-LV [I_H, L_1], it is expected that the SBR is capable of + identifying the correct internal network for I_H, and so the correct + Locator value to rewrite for the ingress packet. This is not obvious + as the I value and the L value are not related in any way. + + There are numerous ways the SBR could facilitate the correct lookup + of the internal Locator value. This document does not prescribe any + specific method. Of course, we do not preclude mappings directly + from Identifier values to internal Locator values. + + Of course, such a "flat" mapping (between Identifier values and + Locators) would serve, but maintaining such a mapping would be + impractical for a large site. So, we propose the following solution. + + + +Atkinson & Bhatti Experimental [Page 9] + +RFC 6748 ILNP ADV November 2012 + + + Consider that the Locator value, L_x consists of two parts, L_pp and + L_ss, where L_pp is a network prefix and L_ss is a subnet selector. + Also, consider that this structure is true for both the local + identifier, L_L, as well as the global Identifier, L_1. Then, an SBR + need only know the mapping from the values of L_ss as visible in L_1 + and the values of L_ss used locally. + + Such a mapping could be mechanical, e.g., the L_ss part of L_L and + L_1 are the same and it is only the L_pp part that is different. + Where this is not desirable (e.g., for obfuscation of interior + topology), an administrator would need to configure a suitable + mapping policy in the SBR, which could be realised as a simple lookup + table. Note that with such a policy, the L_pp for L_L and L_1 do not + need to be of the same size. + + From a practical perspective, this is possible for both ILNPv6 + [RFC6177] and ILNPv4 [RFC4632]. For ILNPv6, recall that the Locator + value is encoded to be syntactically similar to an IPv6 address + prefix, as shown in Figure 2.2, 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. + + Note that the subnet ID forms part of the Locator value. Note also + that [RFC6177] allows the global routing prefix to be more than 45 + bits, and for the subnet ID to be smaller, but still preserving the + 64-bit size of the Locator overall. + + For ILNPv4, the L_pp value overall is an IPv4 routing prefix, which + is typically less than 32 bits. However, the ILNPv4 Locator value is + carried in the 32-bit IP Address space, so the bits not used for the + + + + + +Atkinson & Bhatti Experimental [Page 10] + +RFC 6748 ILNP ADV November 2012 + + + routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix, + the situation would be as shown in Figure 2.3, and L_ss could use any + of the remaining 8-bits as required. + + 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. + + As an example, for the case where the interior topology is not + 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" that might have different L32/L64 records for that + specific subnet within the site. That is, 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. However, just as for 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 + + To support private numbering with IPv4 and IPv6 today, some sites use + a split-horizon DNS service for the site [appDNS]. + + If a site using localised numbering chooses to deploy a split-horizon + DNS server, then the DNS server would return the global-scope + Locator(s) (L_1 in our example above) of the SBR to DNS clients + outside the site, and would advertise the local-scope Locator(s) (L_L + in our example above) specific to that internal node to DNS clients + inside the site. Such deployments of split-horizon DNS servers are + not unusual in the IPv4 Internet today. If an internal node (e.g., + 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 deployment model, the authoritative DNS server + for that mobile device will be either the split-horizon DNS server + itself or the master DNS server providing data to the split-horizon + DNS server. + + + + + +Atkinson & Bhatti Experimental [Page 11] + +RFC 6748 ILNP ADV November 2012 + + + 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 respective + DNS entries. To deliver packets from one internal node to another + internal node, the site would choose to use either Layer 2 bridging + (e.g., IEEE Spanning Tree or IEEE Rapid Spanning Tree [IEEE04], or a + link-state Layer 2 algorithm such as 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 in turn would then + rewrite the Locators to appropriate local-scope values, and forward + the packet towards the interior destination node. + + Alternately, for sites using localised numbering but not deploying a + split-horizon DNS server, the DNS server could return all global- + scope and local-scope Locators to all queriers, and assume that nodes + would use normal, local address/route selection criteria to choose + the best Locator to use to reach a given remote node ([RFC3484] for + older IPv6 nodes, [RFC6724] for newer IPv6 nodes). Hosts within the + same site as the correspondent node would only have a ULA configured; + hence, they would select the ULA destination Locator for the + correspondent (L_L in our example). Hosts outside the site would not + have the same ULA configured (L_CN for the CN in our example). + + However, ILNP allows use of Locator Preference values [RFC6742] + [RFC6743]. These values would indicate explicitly the relative + preference value given to Locator values and so result in the + selection of the appropriate Locator (and therefore interface) to use + for the transmission of an outgoing packet with respect to the value + to be inserted into the IPv6 Source Address field (see Section 3 of + [RFC6741]). A similar argument, with respect to use of Locator + preference values, applies to the value to be inserted into the IPv6 + Destination Address field. Certainly, by using appropriate + Preference values for a host with multiple Locator values, it would + be possible to emulate some level of resemblance to the address + selection rules in [RFC3484] and [RFC6724], and this could be + controlled via DNS entries for ILNP nodes, for example. + + Indeed, with appropriate use of localised or site-wide policy, and + appropriate mechanisms in the devices (e.g. in end hosts operating + systems or in Site Border Routers), Preference values for Locator + values within the DNS could be used for allowing options for multi- + homed transport sessions and/or site-controlled traffic engineering + [ABH09a]. However, the details for this are left for further study, + and overall, the rules defined in [RFC3484] and [RFC6724] cannot be + applied directly to ILNPv6 nodes. + + + + + + +Atkinson & Bhatti Experimental [Page 12] + +RFC 6748 ILNP ADV November 2012 + + + Note that for split-horizon operation, there needs to be a DNS + management policy for mobile hosts, as when such hosts are away from + their "home" network, they will need to update DNS entries so that + the global-scope Locator(s) only 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 + separate LP records for internal and external use. + +2.5. Use of mDNS + + Multicast DNS (mDNS) [mDNS11] is popularly used in many end-system + OSs today, especially desktop OSs (such as Windows, Mac OS X and + Linux). It is used for localised name resolution using names with 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 would be able to see that it is an + ILNP-capable, but other, non-ILNP nodes would not be perturbed in + operation. The details of a mechanism for using mDNS to enable such + a 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 normally will need to look up appropriate + Identifier and Locator information in the DNS. Just as 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 many hosts like H that need to keep DNS + records (for any reason, including to allow incoming ILNP session + requests), then, potentially, there are many such 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. At the same time, 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., link from a + Site Border Router towards 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 is + using on each link. + + + +Atkinson & Bhatti Experimental [Page 13] + +RFC 6748 ILNP ADV November 2012 + + +2.7. Site Interior Topology Obfuscation + + In some situations, it can be desirable to obfuscate the details of + the interior topology of an end site. Alternately, in some + situations, 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 modification of the use of Locator values: + + (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. In order 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, for ILNP, the ICMP checksum is always + calculated identically as for IPv6 or IPv4. For ILNPv6, this means + that the SBR need not be aware if ILNPv6 is operating as described in + [RFC6740] and [RFC6741]. For ILNPv4, again, the SBR need not be + aware of the operation if ILNPv4 is operating as it will not need to + inspect the extension header carrying the I value. + + In order 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].) + + + +Atkinson & Bhatti Experimental [Page 14] + +RFC 6748 ILNP ADV November 2012 + + + In the near-term, a more common deployment scenario will be to deploy + ILNP incrementally, with some ordinary classic IP traffic still + existing. 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 indicated ILNP were enabled for a given + flow, and ILNP local numbering were also enabled, then the SBR would + know that it should perform the simpler ILNP Locator rewriting + mapping. If that flag indicated ILNP were not enabled for a given + flow and IP NAT or IP NAPT were 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. + + Those applications that do not 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 are not well behaved, for example, + the File Transfer Protocol (FTP), then the SBR might need to perform + additional stateful processing -- just as 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, the path liveness + will be no worse than IPv4, and mechanisms already in use for IPv4 + can be reused. For ILNPv6, the 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]. + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 15] + +RFC 6748 ILNP ADV November 2012 + + +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 is 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 + + The approach to Site Multihoming (S-MH) using an SBR is best + illustrated through an example, as shown in 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 SBR + + Figure 3.1: Alternative Site Multihoming Example with an SBR + + The situation here is similar to the localised numbering example, + except that the SBR now has two external links, with using Locator + value L_1 and another using 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). However, when the packet reaches + the SBR, local policy will decide whether the packet is forwarded on + the link sbr1 using L_1 or on sbr2 using L_2. Of course, the correct + Locator value will be rewritten into the egress packet in place of + L_L. + + + + + + +Atkinson & Bhatti Experimental [Page 16] + +RFC 6748 ILNP ADV November 2012 + + + If only local numbering is being used, then 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 providing resilience to link + failure. If either link breaks, then the SBR can manage the change + in connectivity locally. For example, assume SBR has been configured + to use sbr1 for all traffic, and sbr2 only as 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). + + However, if sbr1 goes down then SBR will move the communication to + interface sbr2. As H is not aware of the actions of the SBR, 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 hosts manages its own + connectivity. + + If sbr1 was to be reinstated, now with Locator value L_3, then local + policy would determine if the communication should be moved back to + sbr1, with appropriate additional actions, such as transmission of LU + messages with the new Locator values and also the updates to DNS. + + Note that in such movement of an ILNP session across interfaces at + the SBR, only Locator values in ILNP packets are changed. As already + noted in [RFC6740], end-to-end transport-layer session state + invariance is maintained. + + + + + +Atkinson & Bhatti Experimental [Page 17] + +RFC 6748 ILNP ADV November 2012 + + +3.3. SBR Updates to DNS + + When the SBR manages connectivity as described above, the internal + hosts, such as H, are not necessarily aware of any connectivity + changes. Indeed, 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 would need to update + the relevant DNS entries. For our example, with ILNPv6 and LP + records in use, the SBR would need to manage two L64 records (one for + each uplink) that would resolve from a 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 that would + contain the value site.example.com, which then would be used to look + up the two L64 records. + + If the SBR is multihomed, as in Figure 3.1, then 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 described above, there was a link + failure that resulted in sbr1 going down and sbr2 was used. Existing + ILNP sessions in progress would move to sbr2 as described above. + However, 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, then that host might be holding stale + information. + + DNS allows values returned to be aged using Time-To-Live (TTL), which + is specified in the time unit of 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 us assume that 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 time to use for the TTL + value of 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. + + + +Atkinson & Bhatti Experimental [Page 18] + +RFC 6748 ILNP ADV November 2012 + + + 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 be as + follows (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 P + + Figure 3.2: A Dual-Router Multihoming Scenario for ILNP + + The use of two physical routers provides 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 + + + +Atkinson & Bhatti Experimental [Page 19] + +RFC 6748 ILNP ADV November 2012 + + + 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 + is 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 the 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 + + Let us consider the mobile network in Figure 4.2, which is taken 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 + + + + + +Atkinson & Bhatti Experimental [Page 20] + +RFC 6748 ILNP ADV November 2012 + + + 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 SBR + + We assume that 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, accessible via interfaces + ra1 and ra2. + + While the SBR makes the transition from using a single link (Figure + 4.1a) to the handover overlap on both links (Figure 4.1b), to only + using a single link again (Figure 4.1c), the host H continues to use + only Locator value L_L, as already described for Site Multihoming + (S-MH). During this time the actions taken by the SBR are the same + as already described in [RFC6740], except that the SBR: + + a) also performs that ILNP localised numbering function described in + Section 2. + + b) does not need to advertise L_1 and L_2 internally if only local + numbering is being used. + + As for the case of S-MH above, H need not be aware of the change in + connectivity for the SBR if it is only using local numbering, and the + SBR would send LU messages for H (for any correspondent nodes, not + shown in Figure 4.1), and would update DNS entries as required. + + The difference to the S-MH scenario described earlier in this + document is that in the situation of Figure 4.1b, the SBR can opt to + use soft handover has previously described in [RFC6740]. + + + + + +Atkinson & Bhatti Experimental [Page 21] + +RFC 6748 ILNP ADV November 2012 + + + Again, there is an efficiency gain compared to the situation + described in [RFC6740]: the SBR provides a convenient point at which + to centrally manage the movement of the site as a whole. Note that + in Figure 4.1b, the site is multihomed. + + As for S-MH, L_1 and L_2 could be advertised internally, as a local + policy decision, for those hosts that require direct control of their + connectivity. + + Note that for handover, immediate handover will have a similar + behaviour to a link outage as described for S-MH. However, as ILNP + allows soft-handover, during the handover period, this should help to + reduce (perhaps even remove) packet loss. + +4.2. SBR Updates to DNS + + As for S-MH, a similar discussion to Section 3.3 applies for mobile + networks with respect to the updates to DNS. As a mobile network is + likely to have more frequent changes to its connectivity than a + multihomed network would due to connectivity changes, the use of LP + DNS records is likely to be particularly advantageous here. + +4.3. DNS TTL Values for L32 and L64 Records + + As for S-MH, a similar discussion to Section 3.4 applies for mobile + networks with respect to the TTL of L32 and/or L64 records that are + used for the name of the mobile network. In the case of the mobile + network, it makes sense for the TTL to be aligned to the time for + handover. + +5. Traffic Engineering Options + + The use of Locator rewriting provides some simple yet useful options + for traffic engineering (TE) controlled from the edge-site via the + SBR, requiring no cooperation from the service provider other than + the provision of basic connectivity services, e.g., physical + connectivity, allocation of IP Address prefixes and packet + forwarding. This does not preclude other TE options that are already + in use, such as use of MPLS, but we choose to highlight here the + specific options available and controllable solely through the use of + ILNP. + + When a site network is multihomed, we have seen that the use of the + Locator rewriting function permits the SBR to have packet-by-packet + control when forwarding on external links. Various configuration and + policies could be applied at the SBR in order to control the egress + and ingress traffic to the site network. + + + + +Atkinson & Bhatti Experimental [Page 22] + +RFC 6748 ILNP ADV November 2012 + + +5.1. Load Balancing + + Let us consider Figure 5.1, and assume ILNP local numbering is in + use; that H1, H2, and H3 use, respectively, Identifier values, I_1, + I_2 and I_3; 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 Control + + The SBR could be configured, subject to local policy, to try to + control load across the external links. For example, it could be + configured initially with the following mappings: + + srcI=I_1, sbr1 --- (3a) + srcI=I_2, sbr2 --- (3b) + srcI=I_3, sbr1 --- (3c) + + These mappings direct packets matching course Identifier values to + particular outgoing interfaces. As load changes, these mappings + could be changed. For example, expression (3c) could be changed to: + + srcI=I_3, sbr2 --- (4) + + and the SBR would need to send LU message to the correspondents of H3 + (sbr to uses L_2 while sbr1 uses L_1). The egress connectivity is + totally within control of the SBR under administrative policy, as + already seen in the descriptions of multihoming and mobility in this + document. + + + + + +Atkinson & Bhatti Experimental [Page 23] + +RFC 6748 ILNP ADV November 2012 + + + 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 in use for control of traffic. + + In expressions (3a,b,c) above, source I values are used. However: + + - 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 do not need to be aware of the operation of the SBR + in this manner. + + Note, again, that in this scenario, there is nothing to prevent SBR + from also advertising L_1 and L_2 into the site network. If + required, administrative controls could be used to enable selective + hosts in the site network to use L_1 and L_2 directly as described in + [RFC6740]. + +5.2. Control of Egress Traffic Paths + + Extending the scenario for load-balancing described above, it is also + be possible for the ILNP-capable SBR to direct traffic along specific + network paths based on the use of different L values, i.e., by using + multiple prefixes assigned from upstream providers. + + Of course, as previously discussed, these prefixes can be Provider + Aggregated (PA) and need not be Provider Independent (PI). + + Let us consider Figure 5.2 and assume ILNP local numbering is in use; + that H1, H2 and H3 use, respectively, Identifier values, I_1, I_2, + and I_3; and all of them use Locator value L_L. Let us also assume + that the node CN uses IL-V [I_CN, L_CN]. + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 24] + +RFC 6748 ILNP ADV November 2012 + + + 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 Control + + Here, many configurations are possible. 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 may + override (5a) and (5b), subject to local policy, when packets to CN + are from H2 or H3. + + Meanwhile, in expression (5d), we see a further, more specific rule, + in that packets from H1 destined to CN should use Locator value L1 + (and implicitly to 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 packets + forwarded in conformance with the routing already configured for the + Locator values. + + + +Atkinson & Bhatti Experimental [Page 25] + +RFC 6748 ILNP ADV November 2012 + + + 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 + + As ILNP has first class support for mobility and multihoming, and + supports flexible options for localised addressing, there is great + potential for it to be used in datacentre scenarios. Further details + of possibilities are in [BA12], with a summary presented here. + + There are several scenarios that could be beneficial to datacentres, + in order to provide functions such as 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 provide these here as examples, and they + are not intended to be prescriptive. The intention is only to show + the flexibility that is 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. + + + + + +Atkinson & Bhatti Experimental [Page 26] + +RFC 6748 ILNP ADV November 2012 + + +6.1. Virtual Image Mobility within a Single Datacentre + + Let us consider first 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 ILNP + + L_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)): + + --- (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. + + + +Atkinson & Bhatti Experimental [Page 27] + +RFC 6748 ILNP ADV November 2012 + + +6.2. Virtual Image Mobility between Datacentres - Invisible + + Let us now consider an extended version of the scenario above in Fig. + 6.2, where we see that 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 ILNP + + Note 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. + + + + + + +Atkinson & Bhatti Experimental [Page 28] + +RFC 6748 ILNP ADV November 2012 + + + When in initial communication, the packets have the signature is + 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 us now consider again Figure 6.2, and assume now that + Local locators L_L1 and L_L2 are not in use on either site network, + and each site networks 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). + + --- (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 + + + +Atkinson & Bhatti Experimental [Page 29] + +RFC 6748 ILNP ADV November 2012 + + + 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) + + To enable this function, we use a middlebox that we call the Locator + Rewriting Relay. The function of this unit is described by the use + of Figure 7.1. + + --- (7a) + + v + | + +--+--+ + | | src=[I_H, L_1], L_X --- (7b) + | LRR | dst=[I_H, L_X], L_1 --- (7c) + | | + +--+--+ + | + v + --- (7d) + + LRR = Locator Rewriting Relay + + Figure 7.1: Locator Rewriting Relay (LRR) Example + + The operation of the LRR is conceptually very simple. We assume that + the LRR first has mappings as given in expressions (7b) and (7c) (see + next subsection). Expression (7b) says that for packets with src + IL-V [I_H, L_1], the packet's source Locator value should be + rewritten to value L_X and then forwarded. Expression (7c) has the + complimentary mapping for packets with destination IL-V [I_H, L_1] + (for the reverse direction). + + Expression (6a) is a UDP/ILNP packet as might be sent in Figure 2.1 + from H to CN. However, instead of going directly to L_CN, the packet + with destination Locator L_1 goes to a LRR. Expression (7d) is the + result of the mapping of packet (7a) using expression (7b). + + + +Atkinson & Bhatti Experimental [Page 30] + +RFC 6748 ILNP ADV November 2012 + + + Note that it is entirely possible that the packet of expression (7d) + then is processed by another LRR for source Locator value L_X. + Effectively, this creates and LRR path for the packet, as an overlay + path on top of the normal IP routing. + + In this way, there is a level of protection, without the need for + cryptographic techniques, for the (topological) Location of the + packet. Of course, an extremely well-resourced adversary could, + potentially, backtrack the LRR path, but, depending on the LRR + overlay path that is created, could be very difficult to trace in + reality. For example, the mechanism will protect against off-path + attacks, but where the threat regime includes the potential for on- + path attacks, cryptographically protected tunnels between H and LRR + might be required. + + Again, as the Locator value is not part of the end-to-end state, this + mechanism is very general and has a low overhead. + +7.2. Options for Installing LRR Packet Forwarding State + + There are many options for managing the "network" of LRRs that could + be in place if such a system was used on a large scale, including the + setting up and removal of LRR state for packet relaying, as for + expressions (7b) and (7c). We consider this function to be outside + the scope of these ILNP specifications, but note that there are many + existing mechanisms that could modified for use, and also many + possibilities for new mechanisms that would be specific to the use of + ILNP LRRs. + + (Note also that the control/management communication with the LRR + does not need to use ILNP: IPv4 or IPv6 could be used.) + + The host, H, by itself could install the required state, assuming it + was aware of suitable information to contact 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 source Locator of the packet. + When a LRR receives such a packet, it would install the required + state. Such a mechanism could be soft-state, requiring periodic use + of the LRO in order to maintain the state in the LRR. The LRO could + also be delivered using an ICMP ECHO packet sent from H to the LRR, + periodically, again to maintain a soft-state update. + + It would, of course, be prudent to protect the LRR state control + packets with some sort of authentication token, to prevent an + adversary from easily installing false LRR state and causing packets + + + + + +Atkinson & Bhatti Experimental [Page 31] + +RFC 6748 ILNP ADV November 2012 + + + from H or its correspondent to be subject to man-in-the-middle + attacks, or black-holing. Again, such attacks are not specific to + ILNP or new to ILNP. + + It would also be possible to use proprietary application level + protocols, with strong authentication for the control of the LRR + state. For example, an application level protocol based on XMPP + (http://xmpp.org/) operating over SSL. + + Above, we have offered very brief and incomplete descriptions of some + possibilities, and we do not necessarily mandate any one of them: + they serve only as examples. + +8. Identity Privacy + + For the sake of completeness, and in complement to Section 6, it + should be noted that ILNP can use either cryptographically verifiable + Identifier values, or use Identifier values that provide a level of + anonymity to protect a user's privacy. More details are given in + Sections 2 and 11 of [RFC6741]. + +9. Security Considerations + + The relevant security considerations to this document are the same as + for the main ILNP Architectural Description [RFC6740]. The one + additional point to note is that this document describes ILNP + capability in the SBR and so those adversaries wishing to subvert the + operation of ILNP specifically, have a target that would, + potentially, disable an entire site. However, this is not an attack + vector that is specific to ILNP: today, disruption of 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 his own (topological) Location, for example. This is + already possible for IPv4 and IPv4 with a Tor-like system today, so + is not new to ILNP. + + + + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 32] + +RFC 6748 ILNP ADV November 2012 + + +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. + + + + +Atkinson & Bhatti Experimental [Page 33] + +RFC 6748 ILNP ADV November 2012 + + + [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 + + [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 + + + + + + +Atkinson & Bhatti Experimental [Page 34] + +RFC 6748 ILNP ADV November 2012 + + + [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. + + + +Atkinson & Bhatti Experimental [Page 35] + +RFC 6748 ILNP ADV November 2012 + + + [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. + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 36] + +RFC 6748 ILNP ADV November 2012 + + +11. Acknowledgements + + Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, + Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, + Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, + Robin Whittle, and John Wroclawski (in alphabetical order) provided + review and feedback on earlier versions of this document. Steve + Blake provided an especially thorough review of an early version of + the entire ILNP document set, which was extremely helpful. We also + wish to thank the anonymous reviewers of the various ILNP papers for + their feedback. + + Roy Arends provided expert guidance on technical and procedural + aspects of DNS issues. + +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 + + + + + + + + + + + + + + + + + + +Atkinson & Bhatti Experimental [Page 37] + -- cgit v1.2.3