Optional Advanced Deployment Scenarios for ILNP
Author(s): R. Atkinson, SN Bhatti
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...
Internet Draft RJ Atkinson draft-irtf-rrg-ilnp-adv-06.txt Consultant Expires: 10 Jan 2013 SN Bhatti Category: Experimental U. St Andrews 10 July 2012 Optional Advanced Deployment Scenarios for ILNP draft-irtf-rrg-ilnp-adv-06.txt Status of this Memo Distribution of this memo is unlimited. 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other Atkinson & Bhatti Expires in 6 months [Page 1] Internet Draft ILNP ADV 10 JUL 2012 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is not on the IETF standards-track and does not specify any level of standard. This document merely provides information for the Internet community. 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. Table of Contents 1. Introduction......................................? 2. Localised Numbering...............................? 3. An Alternative For Site Multi-Homing..............? 4. An Alternative For Site (Network) Mobility........? 5. Traffic Engineering Options.......................? 6. ILNP in Datacentres ..............................? 7. Location Privacy..................................? 8. Identity Privacy..................................? 9. Security Considerations...........................? 10. IANA Considerations...............................? 11. References........................................? 1. INTRODUCTION At present, the Internet research and development community are 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 Atkinson & Bhatti Expires in 6 months [Page 2] Internet Draft ILNP ADV 10 JUL 2012 range of other issues (e.g. site multi-homing, node multi-homing, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research & 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 [ILNP-ARCH]. 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 [ILNP-ENG]. 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]. 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 [ILNP-ARCH], 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 both ILNPv4 and ILNPv6. The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" Atkinson & Bhatti Expires in 6 months [Page 3] Internet Draft ILNP ADV 10 JUL 2012 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 [ILNP-ENG]. 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) [ILNP-ARCH] is the main architectural description of ILNP, including the concept of operations. b) [ILNP-ENG] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6. c) [ILNP-DNS] defines additional DNS resource records that support ILNP. d) [ILNP-ICMPv6] 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) [ILNP-NONCEv6] 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) [ILNP-ICMPv4] 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) [ILNP-v4OPTS] 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) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. Atkinson & Bhatti Expires in 6 months [Page 4] Internet Draft ILNP ADV 10 JUL 2012 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 [RFC2119]. 2. LOCALISED NUMBERING Today, Network Address Translation [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 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 re-writing 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 [ILNP-ENG], routing prefixes from IPv4 and IPv6, respectively, are used as Locator values. We note that a deployment using private/local numbering can also Atkinson & Bhatti Expires in 6 months [Page 5] Internet Draft ILNP ADV 10 JUL 2012 provide a convenient solution to centralised management of site multi-homing 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, 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. 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 (ULA) [RFC4193]. Atkinson & Bhatti Expires in 6 months [Page 6] Internet Draft ILNP ADV 10 JUL 2012 We assume that H uses Identifier I_H then it will use Identifier-Locator Vector (IL-V) [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: <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (1a) When this packet reaches the SBR, it knows that L_L is a local Locator value and so re-writes 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: <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (1b) This packet reaches CN using normal routing based on the Locator value L_1, as it is a routing prefix. 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: <UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a) and the SBR would re-write the Locator value on the ingress packet before forwarding the packet on its internal interface: <UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (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 [ILNP-ENG], the checksum would not have to be re-written. That is, the Locator re-writing function is stateless and has low overhead. (A discussion on the generation of Identifier values for initial use is presented in [ILNP-ENG].) 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. Atkinson & Bhatti Expires in 6 months [Page 7] Internet Draft ILNP ADV 10 JUL 2012 2.3 Dealing with internal subnets with Locator re-writing 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 re-write 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. 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 to 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 which 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 [ILNP-ENG]. /* IPv6 */ | 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+-----------+-------------------------+ |001|global routing prefix| subnet ID | Interface Identifier | +---+---------------------+-----------+-------------------------+ Atkinson & Bhatti Expires in 6 months [Page 8] Internet Draft ILNP ADV 10 JUL 2012 /* 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 routing prefix could be used for L_ss, e.g. for a /24 IPv4 prefix, the situation would be as shown in Fig 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" which 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) Atkinson & Bhatti Expires in 6 months [Page 9] Internet Draft ILNP ADV 10 JUL 2012 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 [ID-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. If a site using localised numbering chooses not to deploy a split-horizon DNS server, then each internal nodes 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 either choose to 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 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]. Hosts within the same site as the correspondent node would only have a ULA configured, and hence 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). Note that RFC3484 probably needs to be updated to indicate that the longest-prefix matching rule is inadequate when comparing ULA- based Locators with global-scope Locators: to choose a ULA for a correspondent, a node must have a Locator that matches all ULA Atkinson & Bhatti Expires in 6 months [Page 10] Internet Draft ILNP ADV 10 JUL 2012 bits of the target Locator value. 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) [ID-mDNS11] is popularly used in many end- system OSs today, especially desktop OSs (such as Windows, MacOSX 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 [ILNP-ARCH], 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 [ILNP-DNS] as well as NID records. The LP record points to the L32 or L64 records for the site. A multi-homed 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 Atkinson & Bhatti Expires in 6 months [Page 11] Internet Draft ILNP ADV 10 JUL 2012 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 multi-homing, it will use one L64 record for each Locator value it is using on each link. 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 Sec. 2.3 above, locator re-writing can be used to hid the internal structure of the network with respect to the sub-netting arrangement of the site network. Specifically, the procedure described in Sec 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 to internal Locator values. (3) the SBR needs to zero the L_ss values for all Source Locators of egress packets, as well as performing an Locator re-writing effecting 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 Atkinson & Bhatti Expires in 6 months [Page 12] Internet Draft ILNP ADV 10 JUL 2012 as described in [ILNP-ARCH] and [ILNP-ENG]. 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 RFC4787 [RFC4787].) 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 that flow is using ILNP or not. 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 re-writing 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 [ILNP-ENG]. 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 re-used. For ILNPv6, the path liveness will be no worse than for IPv6, and mechanisms already in use for Atkinson & Bhatti Expires in 6 months [Page 13] Internet Draft ILNP ADV 10 JUL 2012 IPv6 can be re-used. 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 [ID-BRDP11]. 3. AN ALTERNATIVE FOR SITE MULTI-HOMING The ILNP Architectural Description [ILNP-ARCH] describes the basic approach to enabling site multi-homing (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 multi-homing (S-MH) connectivity using an SBR The approach to Site Multi-Homing (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 multi-homing 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) Atkinson & Bhatti Expires in 6 months [Page 14] Internet Draft ILNP ADV 10 JUL 2012 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 re- written into the egress packet in place of L_L. 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 multi-homing 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 hand-off the connectivity from sbr1 to sbr2. So, when moving the the communication to sbr2, the SBR would firstly send a Locator Update (LU) message [ILNP-ICMPv4] [ILNP-ICMPv6], 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 multi-homing described in [ILNP-ARCH], where each hosts manages its own connectivity. If sbr1 was to be re-instated, 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 Atkinson & Bhatti Expires in 6 months [Page 15] Internet Draft ILNP ADV 10 JUL 2012 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 [ILNP-ARCH], end-to-end transport-layer session state invariance is maintained. 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) which would resolve from a FQDN, for example, site.example.com. Meanwhile, individual hosts, such as H, have an FQDN which resolves to an NID value and an LP record that would contain the value site.example.com, which then would be used to lookup the two L64 records. If the SBR is multi-homed, as in Fig 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 Atkinson & Bhatti Expires in 6 months [Page 16] Internet Draft ILNP ADV 10 JUL 2012 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, 20s 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. 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 Nov 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 note (05 Jan 2011), a zero DNS TTL was still in use at the school. 3.5 Multiple SBRs For site multi-homing, with multiple SBRs, a situation may be as follows (see also Sec 5.3.1 in [ILNP-ARCH]). site . . . . network . . . . . . +-------+ L_1 . . . . | +------. . . . | | . . . .---+ SBR_A | . . . . | | . . . . | | . . . . +-------+ . . . . ^ . . . . | CP . Internet . . . v . . . . +-------+ L_2 . . . . | +------. . . . | | . . . .---+ SBR_B | . . . . | | . . . . | | . . . . . . +-------+ . . . . . . . . Atkinson & Bhatti Expires in 6 months [Page 17] Internet Draft ILNP ADV 10 JUL 2012 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 multi-homing scenario for ILNP. The use of two physical routers provides an extra level of resilience compared to the scenario of Fig 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 Fig 5.1 and Fig 3.2, but with two distinct routers in Fig 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 [ILNP-ARCH] 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 multi-homing feature described in Section 3 of this document. Again, as described in [ILNP-ARCH], we exploit the duality between mobility and multi-homing for ILNP. 4.1 Site (network) mobility Let us consider the mobile network in Figure 4.2, which is taken from [ILNP-ARCH]. site ISP_1 network SBR . . . . . . . +------+ L_1 . . . . L_L | ra1+------. . . .----+ | . . . H . | ra2+-- . . . . . . +------+ . . . . . Figure 4.1a: ILNP mobile network before handover. site ISP_1 Atkinson & Bhatti Expires in 6 months [Page 18] Internet Draft ILNP ADV 10 JUL 2012 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 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 (Fig. 4.1a) to the hand-over overlap on both links (Fig 4.1b), to only using a single link again (Fig 4.1c), the host H continues to use only Locator value L_L, as already described for site multi-homing (S-MH). During this time the actions taken by the SBR are the same as already described in [ILNP-ARCH], 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. Atkinson & Bhatti Expires in 6 months [Page 19] Internet Draft ILNP ADV 10 JUL 2012 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 Fig 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 Fig 4.1b, the SBR can opt to use soft handover has previously described in [ILNP-ARCH]. Again, there is an efficiency gain compared to the situation described in [ILNP-ARCH]: the SBR provides a convenient point at which to centrally manage the movement of the site as a whole. Note that in Fig 4.1b, the site is multi-homed. 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.3 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 multi-homed network would due to connectivity changes, the use of LP DNS records is likely to be particularly advantageous here. 4.4 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 re-writing 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 Atkinson & Bhatti Expires in 6 months [Page 20] Internet Draft ILNP ADV 10 JUL 2012 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 multi-homed, we have seen that the use of the Locator re-writing 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. 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 multi-homing 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) Atkinson & Bhatti Expires in 6 months [Page 21] Internet Draft ILNP ADV 10 JUL 2012 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 multi-homing 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 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 [ILNP-ARCH]. 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. Atkinson & Bhatti Expires in 6 months [Page 22] Internet Draft ILNP ADV 10 JUL 2012 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]. 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 multi-homing 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 re-written to L2 (and implicitly to use interface sbr1). Expression (5b) maps all egress packets from H3 to have their source Locator value re-written to L3 (and implicitly to use interface sbr2). Expression (5c) directs ay 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 Atkinson & Bhatti Expires in 6 months [Page 23] Internet Draft ILNP ADV 10 JUL 2012 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 re-written and packets forwarded in conformance with the routing already configured for the Locator values. 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 multi-homing, 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 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 which 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 Atkinson & Bhatti Expires in 6 months [Page 24] Internet Draft ILNP ADV 10 JUL 2012 platform, it might be sufficient for the guest operating system to support ILNP. In a 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. 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 an 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)): Atkinson & Bhatti Expires in 6 months [Page 25] Internet Draft ILNP ADV 10 JUL 2012 <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 data centres - 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 Atkinson & Bhatti Expires in 6 months [Page 26] Internet Draft ILNP ADV 10 JUL 2012 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. 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 data centres - 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 Fig 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 Atkinson & Bhatti Expires in 6 months [Page 27] Internet Draft ILNP ADV 10 JUL 2012 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 correspondent node (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 re-writing 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 Re-writing Relay (LRR) To enable this function, we use a middlebox which we call the the Locator Re-writing Relay. The function of this unit is described by the use of 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 Atkinson & Bhatti Expires in 6 months [Page 28] Internet Draft ILNP ADV 10 JUL 2012 <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (7d) LRR = Locator Re-writing Relay Figure 7.1: Locator Re-Writing 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 sub-section). Expression (7b) says that for packets with src IL-V [I_H, L_1], the packet's source Locator value should be re-written 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). 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. Atkinson & Bhatti Expires in 6 months [Page 29] Internet Draft ILNP ADV 10 JUL 2012 (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 re-written 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 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 Section 2 and 11 of [ILNP-ENG]. 9. SECURITY CONSIDERATIONS The relevant security considerations to this document are the same as for the main ILNP Architectural Description [ILNP-ARCH]. 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 Atkinson & Bhatti Expires in 6 months [Page 30] Internet Draft ILNP ADV 10 JUL 2012 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. 10. IANA Considerations There are no IANA considerations for this document. (Note to RFC Editor: please remove this section prior to publication.) 11. REFERENCES 11.1. Normative References [RFC1918] Y. Rekther, B. Moskowitz, D. Karrenberg & G. J. de Groot, "Address Allocation for Private Internets", RFC1918, Feb 1996 [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. [RFC3022] P. Srisuresh & K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC3022, Jan 2011. [RFC3484] R. Draves, "Default Address Selection for IPv6", RFC3484, Feb 2003. [RFC4193] R. Hinden and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC4193, October 2005. [RFC4632] V. Fuller and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", RFC4632, August 2006. [RFC4787] F. Audet & C. Jennings, "NAT Behavioural Atkinson & Bhatti Expires in 6 months [Page 31] Internet Draft ILNP ADV 10 JUL 2012 Requirements for Unicast UDP", RFC4787, January 2007. [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter & E. Klein, "Local Network Protection for IPv6", RFC4864, May 2007 [RFC4924] B. Adoba & E. Davbies (eds), "Reflections on Internet Transparency", RFC4924, Jul 2007 [RFC5902] D. Thaler, L. Zhang & G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC5902, Jul 2010 [RFC6177] T. Narten, G. Huston, L. Roberts, "IPv6 Address Assignment to End Sites", RFC6177 (BCP157), March 2011. [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architectural Description", draft-irtf-rrg-ilnp-arch, 10 July 2012. [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, "DNS Resource Records for ILNP", draft-irtf-rrg-ilnp-dns, 10 July 2012. [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, "ILNP Engineering and Implementation Considerations", draft-irtf-rrg-ilnp-eng, 10 July 2012. [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, "ICMPv4 Locator Update message" draft-irtf-rrg-ilnp-icmpv4, 10 July 2012. [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, "ICMPv6 Locator Update message" draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, "IPv6 Nonce Destination Option for ILNPv6", draft-irtf-rrg-ilnp-noncev6, 10 July 2012. [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, Atkinson & Bhatti Expires in 6 months [Page 32] Internet Draft ILNP ADV 10 JUL 2012 "IPv4 Options for ILNP", draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 11.2. Informative References [ABH07a] R. Atkinson, S. Bhatti, & 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] R. Atkinson, S. Bhatti, & 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] R. Atkinson, S. Bhatti, & 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] R. Atkinson, S. Bhatti, & 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] R. Atkinson, S. Bhatti, & 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] R. Atkinson, S. Bhatti, S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming"", Telecommunication Systems, vol. 42, no. 3-4, pp273-291, Springer-Verlag, Dec 2009. [ABH10] R. Atkinson, S. Bhatti, S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC), vol. 28, no. 8, pp1319-1325, IEEE, Oct 2010. [BA11] S. Bhatti & R. Atkinson, "Reducing DNS Caching", Proceedings of IEEE Atkinson & Bhatti Expires in 6 months [Page 33] Internet Draft ILNP ADV 10 JUL 2012 Global Internet Symposium (GI2011), Shanghai, P.R. China. 15 Apr 2011. [BA12] S. N. Bhatti & R. Atkinson, "Secure & Agile Wide-area Virtual Machine Mobility", Proceedings of IEEE Military Communications Conference (MILCOM), Orlando, FL, USA. Oct 2012. [BAK11] S. N. Bhatti, R. Atkinson, J. Klemets, "Integrating Challenged Networks", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Baltimore, MD, USA. Nov 2011. [DMS04] R. Dingledine, N. Mathewson, & P. Syverson, "Tor: the second-generation onion router", Proceedings of 13th USENIX Security Symposium, USENIX Association, San Diego, CA, USA. 2004. [ID-appDNS] O. Kolman, J. Peterson, H. Tschofenig & B. Aboba, "Architectural Considerations on Application Features in the DNS", draft-iab-dns-applications, March 2012. [ID-BRDP11] T. Boot & A. Holtzer, "Border Router Discovery Protocol (BRDP) Framework", draft-boot-brdp-framework-00, Internet-Draft, 31 Jan 2011. [ID-mDNS11] S. Cheshire, M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-15, 09 Dec 2011. [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] R. Atkinson, M. Lad, S. Bhatti, 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. [RAB09] D. Rehunthan, R. Atkinson, S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009 Atkinson & Bhatti Expires in 6 months [Page 34] Internet Draft ILNP ADV 10 JUL 2012 [RB10] D. Rehunathan, S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Procedings of 6th IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada. Oct 2010. [RSG98] Michael G. Reed, Paul F. Syverson, and David M. Goldschlag, "Anonymous Connections and Onion Routing", IEEE Journal on Selected Areas in Communications, Vol. 16, No. 4, IEEE, Piscataway, NJ, USA, May 1998. [RFC4193] R. Hinden and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC4193, October 2005. [RFC6296] W. Wasserman, F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC6296, June 2011. 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. RFC EDITOR NOTE This section is to be removed prior to publication. Please note that this document is written in British English, so British English spelling is used throughout. This is consistent with existing practice in several other RFCs, for example RFC-5887. This document tries to be very careful with history, in the interest of correctly crediting ideas to their earliest identifiable author(s). So in several places the first published RFC about a topic is cited rather than the most recent published RFC about that topic. Atkinson & Bhatti Expires in 6 months [Page 35] Internet Draft ILNP ADV 10 JUL 2012 Author's Address RJ Atkinson Consultant San Jose, CA 95125 USA Email: firstname.lastname@example.org SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews Fife, Scotland KY16 9SX, UK Email: email@example.com Expires: 10 JAN 2013 Atkinson & Bhatti Expires in 6 months [Page 36]