MEXT Working Group C. Bernardos Internet-Draft M. Calderon Intended status: Experimental I. Soto Expires: January 8, 2009 UC3M July 7, 2008 Correspondent Router based Route Optimisation for NEMO (CRON) draft-bernardos-mext-nemo-ro-cr-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2009. Abstract The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for Bernardos, et al. Expires January 8, 2009 [Page 1] Internet-Draft CR-based RO for NEMO July 2008 NEMO, based on the well-known concept of Correspondent Router. The solution aims at meeting the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. Based on the ideas that have been proposed in the past, as well as some other extensions, this document describes a Correspondent Router based solution, trying to identify the most important open issues. The main goal of this first version of the document is to describe an initial NEMO RO solution based on the deployment of Correspondent Routers and trigger the discussion within the MEXT WG about this kind of solution. This document (in an appendix) also analyses how a Correspondent Router based solution fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. Requirements Language 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 RFC 2119 [1]. Bernardos, et al. Expires January 8, 2009 [Page 2] Internet-Draft CR-based RO for NEMO July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Correspondent Router Prefix Option . . . . . . . . . . . . 7 4. Mobile Router operation . . . . . . . . . . . . . . . . . . . 8 4.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 8 4.2. Correspondent Router Discovery . . . . . . . . . . . . . . 9 4.3. Correspondent Router Binding . . . . . . . . . . . . . . . 10 5. Correspondent Router operation . . . . . . . . . . . . . . . . 12 5.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 12 5.2. Correspondent Router Binding . . . . . . . . . . . . . . . 13 5.3. Intercepting Packets from a Correspondent Node . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Analysis of CRON and the Aeronautics requirements . . 16 A.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 16 A.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 17 A.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 17 A.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 18 A.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 18 A.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 19 A.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 19 A.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 20 A.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 20 A.10. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 20 A.11. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 21 A.12. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 21 A.13. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 21 A.14. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Bernardos, et al. Expires January 8, 2009 [Page 3] Internet-Draft CR-based RO for NEMO July 2008 1. Introduction This document assumes that the reader is familiar with the terminology related to Network Mobility [5] and [6] (Figure 1), and with the Mobile IPv6 [2] and NEMO Basic Support [3] protocols. The goals of the Network Mobility (NEMO) Support are described in [7]. Basically, the main goal is to enable networks to move while preserving the communications of their nodes (Mobile Network Nodes, or MNNs), without requiring any mobility support on them. The NEMO Basic Support protocol [3] consists on setting a bi-directional tunnel (Figure 2) between the Mobile Router (MR) of the network (that connects the mobile network to the Internet) and its Home Agent (located at the Home Network of the mobile network). This is basically the Bi-directional Tunnel (BT) operation of Mobile IPv6 (MIPv6) [2], but without supporting Route Optimisation. Actually, the protocol extends the existing MIPv6 Binding Update (BU) message to inform the Home Agent (HA) of the current location of the mobile network (i.e. the MR's Care-of Address, CoA), through which the HA has to forward the packets addressed to the network prefix managed by the MR (Mobile Network Prefix, or MNP). --------- | HA_MR | --------- | ------ +-----------+---------+ | CN |----| Internet | ------ +---+-----------------+ | ------ ------------------------------ | AR | | AR: Access Router | ------ | CN: Correspondent Node | | | MR: Mobile Router | ===?========== | HA_MR: MR's Home Agent | MR | MNP: Mobile Network Prefix | | | MNN: Mobile Network Node | ===|========|====(MNP) ------------------------------ MNN MNN Figure 1: Basic scenario of Network Mobility Because of the bi-directional tunnel that is established between HA and MR to transparently enable the movement of networks, the NEMO Basic Support protocol introduces the following limitations: o It forces suboptimal routing (known as angular or triangular routing), since packets are always forwarded through the HA following a suboptimal path and therefore adding a delay in the Bernardos, et al. Expires January 8, 2009 [Page 4] Internet-Draft CR-based RO for NEMO July 2008 packet delivery. o It introduces non-negligible packet overhead, reducing the Path MTU (PMTU). An additional IPv6 header (40 bytes) is added to every packet because of the MRHA bi-directional tunnel. o The HA becomes a bottleneck of the communication. This is because, even if a direct path is available between a MNN and a CN, the NEMO Basic Support protocol forces traffic to follow the CN-HA=MR-MNN path. This may cause the Home Link to be congested, resulting in some packets discarded. In order to overcome such limitations, it is necessary to provide what have been called Route Optimisation for NEMO [8], [9], [10], [11]. __ _____ __ ___ | | | | | | | | |CN| |HA_MR| |MR| |MNN| |__| |_____| |__| |___| | | | | | ------------ | ------------------------------ | ------------ | | |S:CN,D:MNN| | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]| | |S:CN,D:MNN| | | | DATA | | | DATA | | | DATA | | | ------------ | ------------------------------ | ------------ | |-------------->|-------------------------------->|-------------->| | | | | | ------------ | ------------------------------ | ------------ | | |S:MNN,D:CN| | |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| | |S:MNN,D:CN| | | | DATA | | | DATA | | | DATA | | | ------------ | ------------------------------ | ------------ | |<--------------|<--------------------------------|<--------------| | | | | Figure 2: NEMO Basic Support protocol This document collects some ideas about a Route Optimisation scheme based on optimising the routing path between an MNN and a CN by setting up a bi-directional tunnel between the MR of the NEMO and a router topologically close to the CN, called Correspondent Router (CR). Packets of the communication between the MNN and the CN could then use this bi-directional tunnel instead of the default MRHA one, in this way optimising the resulting routing path. While this idea is far from being new ([12], [9]), the re-chartering of the MEXT WG (formerly NEMO WG) to specifically address and work on the design of a solution targeting a set of particular use case scenarios (namely aeronautics [13], vehicular [14] and consumer electronics [15]) makes worthwhile revisiting the idea of a CR-based NEMO RO solution and analyse whether this kind of approach would fit Bernardos, et al. Expires January 8, 2009 [Page 5] Internet-Draft CR-based RO for NEMO July 2008 the requirements of those scenarios. This document is a first attempt of doing so, focused on the requirements for Operational Use in Aeronautics and Space Exploration. 2. Protocol Overview The approach described in this document, called Correspondent Router based Route Optimisation for NEMO (CRON), is based on the idea of extending the NEMO Basic Support protocol [3] to enable the MR managing bindings not only with the HA, but also with special routers, called Correspondent Routers (CRs), so the MRHA tunnel can be bypassed for traffic addressed to CNs that are topologically close to a CR. CRON basically works as follows: an MR is forwarding packets to several communications between MNNs of the NEMO and CNs located in the Internet. For some of these communications, the MR may decide that it is better to try to avoid the use of the MRHA tunnel and try to set up a binding with a CR close to the other end-point of the communication (i.e. the CN). In order to do so, the MR needs to know whether there are any potential CRs that can be used and their IPv6 addresses. Once the MR knows that, it can select a CR among the potential ones (if any) and decide to establish a binding with it. To do so, a Binding Update/Binding Acknowledgement message exchange takes place. Once the signalling has occurred, the MR sets up a bi- directional tunnel with the CR and adds a routing entry towards the IPv6 prefix/address managed by the CR (the CN prefix), using the CR as next hop (through the established tunnel). Analogously, the CR sets up a routing entry towards the MNP/MNN IPv6 address, using the MR's CoA as next hop through the established tunnel. At this point, the traffic between the MNN (or set of MNNs with IPv6 addresses from a particular MNP) and the CN (or set of CNs with IPv6 addresses from a particular CN prefix) no longer traverses the HA, since the bi- directional tunnel established between the MR and the CR is used instead. Next sections of this document describe in more detail the operation of CRON. It is not the goal of this first version to provide a complete and exhaustive specification (many details are not included), but rather to list the key operations that would be required for such a CR-based solution work, and, more importantly, identify the key requirements/assumptions/open issues that remain to be solved. This last point would be potentially very dependant on the considered NEMO RO use case. Bernardos, et al. Expires January 8, 2009 [Page 6] Internet-Draft CR-based RO for NEMO July 2008 3. Message Formats 3.1. Correspondent Router Prefix Option The Correspondent Router Prefix Option is included in the Binding Updates to indicate to the Correspondent Router the CN prefix (could also be a host address) that is requested to be route optimised. This information and the prefix included in the Mobile Network Prefix Option ([3]) is used by the CR to know which packets have to be sent through the MR-CR bi-directional tunnel. There could be multiple Correspondent Router Prefix Options if the CR is able to route optimise traffic from different CN prefixes and the MR wants traffic from more than one of these prefixes to be optimised. This option is also included by the CR in the BA messages. The Correspondent Router Prefix Option has an alignment requirement of 8n+4. Its format is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Correspondent Router Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Number to be assigned by IANA. Length: Eight-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. Set to 18. Reserved: This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Prefix Length: Eight-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Correspondent Router Prefix: Bernardos, et al. Expires January 8, 2009 [Page 7] Internet-Draft CR-based RO for NEMO July 2008 A sixteen-byte field containing the Correspondent Router Prefix. 4. Mobile Router operation The Mobile Router operation defined by the NEMO Basic Support protocol [3] is extended in order to be able to set up bindings with different CRs and establish bi-directional tunnels with them, used to route part of the traffic as indicated by the MR's policies. The process of NEMO RO set-up MUST be initiated by the MR, and cannot be initiated by the CR. Next sections elaborate more on the different operations and mechanisms required to complete the whole NEMO RO. 4.1. Conceptual Data Structures In addition to the data structures defined in [3], the MR needs also to maintain the following information: o The MR extends the Binding Update List (BUL) to contain also some information per each communication that is being route optimised. Basically the added fields are the following: * A flag specifying whether the entry is a Correspondent Router entry or not. * Source IPv6 optimised prefix: this field contains the IPv6 address/prefix of those MNNs whose traffic is being optimised by using an MR-CR bi-directional tunnel with the CR. There could be multiple instances of this field in the BUL of the MR. These are basically the IPv6 addresses/prefixes included in the Mobile Network Prefix options carried in the BU/BA signalling exchanged by the MR and the CR. * Destination IPv6 optimised prefix: this field contains the IPv6 address/prefix of those CNs whose traffic is being optimised by using an MR-CR bi-directional tunnel with the CR. There could be multiple instances of this field in the BUL of the MR. These are basically the IPv6 addresses/prefixes included in the Correspondent Router Prefix options carried in the BU/BA signalling exchanged by the MR and the CR. o The MR SHOULD have a policy database that contains information regarding which communications should be route optimised and which not. It is up to the implementation the decision about the exact content of this database, as well as if it can be dynamically updated or it is pre-configured statically. Bernardos, et al. Expires January 8, 2009 [Page 8] Internet-Draft CR-based RO for NEMO July 2008 4.2. Correspondent Router Discovery Prior to the binding establishment and tunnel set-up between an MR and a CR, the MR MUST find out whether there exist a CR that can be used to optimise the route between an attached MNN (or set of MNNs, having IPv6 addresses from the same MNP) and a CN (or set of CNs, having IPv6 addresses from the same IPv6 prefix). Besides, if there exist such a CR, the MR needs to know some information about it, such CR's IPv6 address. This information may be known beforehand by the MR, by means of a static pre-configuration of the list of usable CRs and some additionally required information. Although it is up to the implementers to decide how this static information has to be processed and handled, the CR information MAY be indexed in a manner similar to a routing table, so when an MR has a target IPv6 address/ prefix to which it wants to search for a candidate CR, it can perform a look-up in the CR database and get the most suitable CR (that is, the CR that is topologically closest to the target, using the longest-match prefix rule). Although a static configuration might be enough for several scenarios, it seems desirable to support dynamic CR discovery. This is one of the hardest problems that a CR-based solution poses. There have been different proposals to tackle this problem. We next present the fundamentals of some of those, as well as some new ones: o If the CR is assumed to be always on the path between the MR to the CN (e.g., the CR is the gateway of the CN), the CR could inspect all received packets looking for a particular message. In this way, when there is a communication that is a candidate for being route optimised, the MR can send a BU message to the CN. If there is a CR available, the first CR on the path towards the CN would capture that packet (not forwarding it to the next hop) and process it accordingly. This approach seems to have severe limitations, since it assumes that available CRs will always be on the MR-CN path, but it deserves to be listed as it might be the case that this assumption is reasonable for some of the use cases currently considered by the MEXT WG. o Discovery based on/assisted by the DNS. The DNS service might be used in different ways, such as adding new type of registers, or including an 'A' register for the CR of each particular domain. In the latter case, the solution would work as follows: an MR attempting to optimise a certain MNN-CN communication would perform a reverse DNS query -- using the IPv6 address of the CN -- to obtain the qualified DNS name of the CN. Using the obtained name, the MR would perform a query of the name 'CR.domainname', where 'domainname' is the domain part of the previously obtained Bernardos, et al. Expires January 8, 2009 [Page 9] Internet-Draft CR-based RO for NEMO July 2008 name. The 'A' register of 'CR.domainname' would contain (if that CR exists) the IPv6 address(es) of the CR(s) of that domain. This solution has also some drawbacks, since it assumes that each potential CN has a domain name published in the DNS, and assumes that all nodes belonging to a topological domain share the same domain names. o Use of a CR anycast address. The ORC draft [12] proposes the definition of anycast addresses for the CRs. In this way, the MR learns the CR anycast address from the CN's prefix and the defined anycast suffix. Using this anycast address, the MR sends CR discovery requests, waiting for CR discovery replies, in a way similar to the DHAAD mechanism of Mobile IPv6 [2]. This mechanism shares the limitations of DHAAD. o Deployment of CR-resolver servers. Given that some of the currently addressed use cases involve kind-of controlled environments, where certain trust relationships might be safely assumed, the deployment of a (potentially distributed, even in a hierarchical way) CR-resolver service may be considered. These CR-resolver servers would keep the a repository of CR-related information, including the IPv6 address of the CRs managing a particular IPv6 prefix/address. Every CR should keep that repository updated, so MRs can send queries to look for candidate CRs (the CR-resolver service would return the best CR, that is the one serving the longest-match prefix). In order to ensure the integrity of the stored information, CRs MUST have some type of security relationship with the CR-resolver service, so only authorised CRs can modify the stored information. Analogously, MRs SHOULD also have some trust relationship, so the MR is provided with some security guarantees regarding the authenticity of the information retrieved from CR-resolvers. It is also worth evaluating if it would be better that the HA is the one querying the CR-resolvers, and that the obtained information is provided to the MR through the HA (it might reduce the bandwidth consumption on the MR wireless access links and also reduce the number of required trust relationships). Both the requirement of deploying this CR-resolver service and the assumption of the existence of trust relationships should be carefully analysed for each of the currently addressed NEMO RO scenarios, in order to evaluate whether they are reasonable or not. This CR discovery approach needs further work, TBD after gathering WG feedback about it. 4.3. Correspondent Router Binding Once the MR has learnt the IPv6 address of a CR that can be used to route optimise some traffic, it needs to perform the Binding Registration to this CR. The MR sends a Binding Update message protected with IPsec/IKE. It is assumed that MRs would have certificates that contain information regarding the Mobile Network Bernardos, et al. Expires January 8, 2009 [Page 10] Internet-Draft CR-based RO for NEMO July 2008 Prefixes they are authorised to manage and their Home Address. It is also assumed that CRs would trust on those certificates, for example by means of a shared PKI infrastructure. Again, it needs to be discussed whether this assumption is too strong or it is reasonable for a given NEMO RO scenario (it seems that for AOS domain this requirement is less strong than for ATS domains [16]). The Binding Update sent by the MR to the CR MUST have the Mobile Router (R) Flag set to 1, indicating to the CR that the BU is from an MR. The Home Registration (H) Flag MUST be set to 0. In this way, a CR that also implements the Home Agent functionality can differentiate Home Registration Binding requests from Correspondent Router Binding requests. All BUs sent by MRs to CRs requesting a Correspondent Router Binding MUST carry at least a Mobile Network Prefix Option, containing the IPv6 prefix/address of the MNN(s) whose traffic is requested to be optimised. Therefore, only explicit binding mode is supported. All BUs sent by MRs to CRs requesting a Correspondent Router Binding MUST carry at least a Correspondent Router Prefix Option, containing the IPv6 prefix/address of the CN(s) whose traffic is requested to be optimised. Traffic generated by nodes whose IPv6 addresses are not from the prefixes contained in these option, with destination the MNPs contained in the Mobile Network Prefix Option, MUST NOT be route optimised (the normal route MUST be used instead). An MR MUST generate a different BU message per each MNN-CN (or MNP-CN Prefix) pair that wants to be optimised. Note that a binding is not restricted to the optimisation of traffic between an individual MNN and an individual CN, and can be established on an MNP-CN prefix basis. The CRON mechanism aims at providing the flexibility required to support this granularity. Each BU contains the MNP prefix/MNN address information in the Mobile Network Prefix Options and the CN address/prefix information in the Correspondent Router Prefix Option. The CR should be able to validate the CoA ownership claimed by the MR (that is, that the MR is actually reachable at its CoA). Depending on the considered use case, it might not be enough to rely on ingress filtering techniques at the access network. In those scenarios, the MR MUST test the CoA reachability following the Return Routability procedure (this would involve only the CoTI/CoT), as specified in [2]. Once the CR has received and processed the BU message, it SHOULD send a Binding Acknowledgement message to the MR. If no BA is received, the MR MAY retransmit BU messages as long as some rate limitation is applied. The MR MUST stop retransmitting when it receives a BA. Bernardos, et al. Expires January 8, 2009 [Page 11] Internet-Draft CR-based RO for NEMO July 2008 When an MR receives a BA message from a CR, the MR MUST validate the message according to some tests. This needs further elaboration (TBD in future versions of this document). Any BA not satisfying all of those tests MUST be silently ignored. When an MR receives a packet carrying a valid BA, the MR MUST examine the Status field of the BA. If the status field indicates that the BU was accepted, the MR MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged. The MR MUST then set up a bi-directional tunnel with the IPv6 address of the CR as the other end-point of the tunnel, and add the entries to its routing table required to make use of the established tunnel in the forwarding of packets that match all of the following rules: o The IPv6 source address of the packet belongs to one of the IPv6 prefixes contained in the Mobile Network Prefix options included in the BA message. Note that this implies that source address based routing MAY be required in certain cases. o The IPv6 destination address of the packet belongs to one of the IPv6 prefixes contained in the Correspondent Router Prefix options included in the BA message. 5. Correspondent Router operation 5.1. Conceptual Data Structures Correspondent Routers MUST maintain a Binding Cache (BC) of bindings with MRs. This BC is similar to the one kept by CNs with RO support as defined in [2]. In addition to the fields contained in the BC defined for a CN, the CR needs also to maintain the following information: o A flag specifying whether the entry is a Correspondent Router entry or not (applicable only on nodes which support also MIPv6 RO, to differentiate from normal MIPv6 BCEs). o Source IPv6 optimised prefix: this field contains the IPv6 address/prefix of those nodes managed by the CR (i.e. CNs) whose traffic is being optimised by using an MR-CR bi-directional tunnel with the MR. There could be multiple instances of this field in the BCE. These are basically the IPv6 addresses/prefixes included in the Correspondent Router Prefix options carried in the BU/BA signalling exchanged by the CR and the MR. o Destination IPv6 optimised prefix: this field contains the IPv6 address/prefix of those nodes (i.e. MNNs) whose traffic is being optimised by using an MR-CR bi-directional tunnel with the MR. There could be multiple instances of this field in the BCE. These are basically the IPv6 addresses/prefixes included in the Mobile Bernardos, et al. Expires January 8, 2009 [Page 12] Internet-Draft CR-based RO for NEMO July 2008 Network Prefix options carried in the BU/BA signalling exchanged by the CR and the MR. o The CR MAY have a policy database that contains information regarding which communications can be route optimised and which not. It is up to the implementation the decision about the exact content of this database, as well as if it can be dynamically updated or it is pre-configured statically. 5.2. Correspondent Router Binding When a CR receives a BU message from an MR, the CR MUST validate the message according to some tests. This needs further elaboration (TBD in future versions of this document). Any BU not satisfying all of those tests MUST be silently ignored. Additionally, some other test MUST be performed (such as authorisation check, etc.). If some of these tests fail, the CR SHOULD return a BA to the MR including an appropriate value in the Status field (TBD). When a CR receives a packet carrying a valid BU, and all the tests are successful, the CR SHOULD add an entry on its BC and return a BA to the MR, setting the Status field to a value indicating success. This BA would also include all the Mobile Network Prefix and Correspondent Router Prefix Options included in the BU message. The CR MUST then set up a bi-directional tunnel with the MR's CoA as the other end-point of the tunnel, and add the entries in its routing table required to make use of this tunnel in the forwarding of packets that match all of the following rules: o The IPv6 source address of the packet belongs to the one of the IPv6 prefixes contained in the Correspondent Router Prefix options contained in the BA message. Note that this implies that source address based routing MAY be required in certain cases. o The IPv6 destination address of the packet belongs to the one of the IPv6 prefixes contained in the Mobile Network Prefix options included in the BA message. 5.3. Intercepting Packets from a Correspondent Node A Correspondent Router needs to intercept packets sent by all CNs from which it has a BCE, since the CR has to send those packets through the established MR-CR bi-directional tunnel. However, depending on the topological location of the CR, different operation may be needed in order to intercept packets from CNs. If the CR is the gateway of all the CNs it manages -- that is, it is always on the path between all CNs and any other node outside the domain --, nothing needs to be done in order to intercept packets that have to be route optimised, since all packets are already received by the CR. Bernardos, et al. Expires January 8, 2009 [Page 13] Internet-Draft CR-based RO for NEMO July 2008 If the CR is not the gateway of all the CNs, in order to intercept those packets that need to be route optimised, the CR MUST inject routes advertising the corresponding MNPs within the domain of the CR. This would make routers in the domain to forward the packets addressed to those MNPs to the CR, so it can forward them to the right MRs using the established MR-CN bi-directional tunnel. Further attention is needed in order to come up with a flexible mechanism to enable a CR in a domain receive only those packets that need to be route optimised, without impacting on the routing of the rest of the packets -- that should follow the normal route (towards the respective home networks) --. Mechanisms enabling that behaviour are subject of future versions of this document. 6. Security Considerations CRON assumes that trust relationships exist between the MR/HA and the CR, allowing IPsec/IKE to be used to secure Binding Updates. Certificates are used to prove ownership of prefixes by MRs and CRs. The Return Routability mechanism is used by the MR to prove CoA ownership to the CR. Given that CRON enables to change routing state at certain nodes, a more detailed security analysis is needed (TBD in a future version of this document). 7. IANA Considerations This document requires IANA to assign a number for a new Mobility Option type (Correspondent Router Prefix). 8. Acknowledgements This draft collects input from many previous works. The concept of Correspondent Router is known since at least 2002. Authors of the present document therefore would like to thank and acknowledge authors of these previous works. The work of Carlos J. Bernardos and Maria Calderon has been also partly supported by the Spanish Government under the POSEIDON (TSI2006-12507-C03-01) project. 9. References Bernardos, et al. Expires January 8, 2009 [Page 14] Internet-Draft CR-based RO for NEMO July 2008 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [4] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. 9.2. Informative References [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [6] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [7] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. [8] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007. [9] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [10] Zhao, F., "NEMO Route Optimization Problem Statement and Analysis", draft-zhao-nemo-ro-ps-01 (work in progress), February 2005. [11] Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route Optimization models in the Nemo Context", draft-thubert-nemo-ro-taxonomy-04 (work in progress), February 2005. [12] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", draft-wakikawa-nemo-orc-01 (work in progress), November 2004. [13] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Bernardos, et al. Expires January 8, 2009 [Page 15] Internet-Draft CR-based RO for NEMO July 2008 Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02 (work in progress), May 2008. [14] Baldessari, R., Ernst, T., and M. Lenardi, "Automotive Industry Requirements for NEMO Route Optimization", draft-ietf-mext-nemo-ro-automotive-req-00 (work in progress), February 2008. [15] Ng, C., Hirano, J., Petrescu, A., and E. Paik, "Consumer Electronics Requirements for Network Mobility Route Optimization", draft-ng-nemo-ce-req-02 (work in progress), February 2008. [16] Bauer, C. and S. Ayaz, "ATN Topology Considerations for Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 (work in progress), July 2008. [17] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [18] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", draft-ietf-shim6-failure-detection-13 (work in progress), June 2008. [19] Bernardos, C., Soto, I., Calderon, M., Boavida, F., and A. Azcorra, "VARON: Vehicular Ad-hoc Route Optimisation for NEMOO", Computer Communications, Volume 30, Issue 8, Pages 1765-1784 , June 2007. Appendix A. Analysis of CRON and the Aeronautics requirements This appendix looks at the Aeronautics requirements described in [13] and analyses how CRON fits each of them. If a certain requirement cannot be fulfilled by CRON as it is described in this document, possible modifications/extensions are also considered. This analysis aims at understanding if a CR-based solution could be a good candidate to be used as a NEMO RO solution for the aeronautics scenario. A.1. Req1 - Separability This requirement basically states that "an RO scheme MUST support configuration by a per-domain dynamic RO policy database. Entries in this database can be similar to those used in IPsec security policy databases in order to specify either bypassing or utilizing RO for Bernardos, et al. Expires January 8, 2009 [Page 16] Internet-Draft CR-based RO for NEMO July 2008 specific flows". This requirement is fulfilled by CRON, since the Route Optimisation can be performed on an MNN-CN basis (MNP-CN prefix optimisations can also be performed) and the decision about which communications are optimised is taken by the MR. Therefore, different approaches can be implemented in the MR (it is open to the particular CRON implementation how to do it) to take this decision: static and dynamic policies (using a protocol to update MR's policies), decisions based on current load of the MR, etc. A.2. Req2 - Multihoming This requirement states that "an RO solution MUST support an MR having multiple interfaces, and MUST allow a given domain to be bound to a specific interface. It MUST be possible to use different MNPs for different domains". Since CRON achieves the NEMO RO by performing bindings with different CRs, setting up bi-directional tunnels between a CR and an MR's CoA, it is possible to support multi-interfaced MRs and use different MNPs for different domains. Besides, CRON can potentially benefit directly from any mechanism developed for MIPv6 to support multiple interfaces (such as [4]). We should also mention that although CRON can benefit from multihoming solutions developed within the MEXT WG, multihoming issues in Network Mobility [17] should be tackled specifically by a general NEMO multihoming framework. Since CRON does not modify in any way the NEMO Basic Support operation, it will also be compatible with such a general NEMO multihoming solution. A.3. Req3 - Latency This requirement says: "while an RO solution is in the process of setting up or reconfiguring, packets of specified flows MUST be capable of using the MRHA tunnel". This means that an RO solution MUST NOT prevent data packets from being forwarded through the MRHA bi-directional tunnel while the required RO operations are being performed. This requirement is also fulfilled by CRON, since while the MR performs all the required signalling (i.e. CoTI/CoT and BU/BA), communications aimed at be route optimised still use the MRHA tunnel. Bernardos, et al. Expires January 8, 2009 [Page 17] Internet-Draft CR-based RO for NEMO July 2008 A.4. Req4 - Availability This requirement states that "an RO solution MUST be compatible with network redundancy mechanisms and MUST NOT prevent fall-back to the MRHA tunnel if an element in an optimized path fails". It is also stated that "an RO mechanism MUST NOT add any new single point of failure for communications in general". On the one hand, current NEMO Basic Support protocol [3] does not fulfil that today, and therefore needs additional work to be carried- out. On the other hand, CRON brings the role of the Correspondent Router into the picture. Therefore, a new potential point of failure is added: the CR. If a CR fails, communications being optimised would obviously be disrupted. Although CRON currently does not address this issue, additional mechanisms -- such as deploying several redundant or back- to-back CRs, or designing/reusing existing protocols to keep the RO state of several CRs synchronised -- might be used here. In any case, by using short lifetimes, the potential negative effect of such a CR failure may be reduced. Besides, protocols such as REAP [18] can be used to effectively detect failures between the MR and the CR (not only caused by a CR failure, but also by a problem on the path between them). In case an MR fails, if it is the only one deployed at the NEMO, this would obviously disrupt established connections. In the case of a multiple-MR NEMO, additional mechanisms would be required in order to guarantee that route optimised communications managed by a particular MR would survive in case this MR fails. Again, although CRON currently does not address this issue, additional mechanisms -- such as deploying back-to-back MRs in aircrafts or designing/reusing existing protocols to keep the RO state of several MRs synchronised -- might be used here. A.5. Req5 - Packet Loss This requirement says that "an RO scheme SHOULD NOT cause either loss or duplication of data packets during RO path establishment, usage, or transition, above that caused in the NEMO basic support case. An RO scheme MUST NOT itself create non-transient losses and duplications within a packet stream". The use of CRON does not add any significant delay nor causes any additional packet loss compared to the normal NEMO Basic Support protocol handover. It is worth to mention that some signalling is required to update the bindings at the CRs, and although this can be done in parallel with the Home Registration, a small delay can be Bernardos, et al. Expires January 8, 2009 [Page 18] Internet-Draft CR-based RO for NEMO July 2008 introduced because of this. Micro-mobility techniques can be used if required to mitigate that effect, if required. A.6. Req6 - Scalability This requirement says that "an RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. This explicitly forbids injection of BGP routes into the global Internet for purposes of RO". There are different aspects that may affect to the scalability of CRON: o Memory consumption at the MR. CRON needs some additional information to be stored at the MR, such extended BUL. The required memory to store this extended BUL is relatively small and grows linearly with the number of different route optimised communications. o Processing load at the MR. CRON requires more complex routing operations at the MR. The routing table of an MR performing RO operations would have more entries than a normal RFC 3963 MR, the MR should set-up and maintain more bi-directional tunnels, and source address based routing might be required. However, all of these operations do not add significant load, and in any case complexity grows linearly with the number of different route optimised communications. o Processing load and memory consumption at the CR. The same reasoning applies here. Besides, multiple CRs can be deployed on sites supporting a high load of route optimised traffic. o Impact on the global routing system. CRON does not have any impact on the global routing tables, and therefore it does not introduce any routing scalability issue, even with large deployments. A.7. Req7 - Efficient Signaling This requirement is related to the additional signalling required by a NEMO RO solution, and basically states that "an RO scheme MUST be capable of efficient signaling in terms of both size and number of individual signaling messages and the ensemble of signaling messages that may simultaneously be triggered by concurrent flows". With CRON, the amount of required signalling depends on the number and type of communications that are optimised. Since almost any granularity is supported by CRON, in those cases in which individual MNN-CN optimisations are not required -- and MNP-CN prefix ones are used instead -- the amount of signalling needed is very small. In Bernardos, et al. Expires January 8, 2009 [Page 19] Internet-Draft CR-based RO for NEMO July 2008 order to perform an optimisation (generally speaking, a MNP-CN prefix optimisation), a BU/BA message exchange is required (plus probably a CoTI/CoT exchange to test MR's CoA reachability). A.8. Req8 - Security This requirement is different depending on the considered traffic domain. For ATS/AOS domains, there are three sub-requirements: "a) The RO scheme MUST NOT further expose MNPs on the wireless link than already is the case for NEMO basic support; b) The RO scheme MUST permit the receiver of a BU to validate an MR's ownership of the CoAs claimed by an MR; and c) The RO scheme MUST ensure that only explicitly authorized MRs are able to perform a binding update for a specific MNP". For the PIES domain: "there are no additional requirements beyond those of normal Internet services and the same requirements for normal Mobile IPv6 RO apply". CRON meets all aforementioned requirements. a) Since BU/BA signalling is sent protected with IPsec, MNPs are not exposed, b) the MR's CoA ownership can be tested by means of the RR procedure (in particular, by means of the CoTI/CoT exchange), and c) by the use of certificates and local policies, only authorised MRs can perform a binding for a specific MNP. A.9. Req9 - Adaptability This requirement states that "applications using new transport protocols, IPsec, or new IP options MUST be possible within an RO scheme". Since CRON makes use of a bi-directional tunnel between the MR and the CR, encapsulating data packets into the tunnel -- without performing any modifications to them --, this requirement is also met. A.10. Des1 - Configuration This requirement is not considered as a strict one, and basically states that "it is desirable that a NEMO RO solution be as simple to configure as possible and also easy to automatically disable if an undesirable state is reached". CRON configuration is not detailed in this document, since it is open to implementation. However, even if complex policies are used to determine which communication are route optimised, CRON configuration would be as simple as configuring today's firewalls. Some coordination is needed though to configure properly MRs, CRs -- and likely additional infrastructure (such as CR-resolvers) -- in order Bernardos, et al. Expires January 8, 2009 [Page 20] Internet-Draft CR-based RO for NEMO July 2008 to effectively enable RO to take place. A.11. Des2 - Nesting This requirement is not considered as a strict one, and basically states that "it is desirable if the RO mechanism supports RO for nested MRs". CRON, as it is described in this document, does not provide RO capabilities for nested MRs. A.12. Des3 - System Impact This requirement is not considered as a strict one, and basically states that "low complexity in systems engineering and configuration management is desirable in building and maintaining systems using the RO mechanism". CRON requires changes on the MR, and the deployment of additional entities: the CRs (although this might be done by simply updating the software of some existing routers at the CN domains to support the CR functionality). The deployment of CRON also requires trust relationships between MRs/HAs and CRs to be in place. In order to help MRs in the discovery of CRs, the deployment of external services, such as CR-resolvers, might be required. A.13. Des4 - VMN Support This requirement is not considered as a strict one, and basically states that "it is strongly desirable for VMNs to be supported by the RO technique, but not strictly required". CRON is aimed at bypassing the MR's HA, but it does not avoid the traversal of VMNs' HAs. Therefore, a completely optimal path is not follow by packets of VMNs (only the MR's HA is bypassed). A.14. Des5 - Generality This requirement is not considered as a strict one, and basically states that "an RO mechanism that is "general purpose", in that it is also readily usable in other contexts outside of aeronautics and space exploration, is desirable". Correspondent Router approaches were designed as general NEMO RO frameworks, not being focused to address any particular scenario. Current CRON design has been tailored to address the particular scenario of aeronautics and space exploration. However, CRON -- with or without modifications/extensions -- could also be considered as a Bernardos, et al. Expires January 8, 2009 [Page 21] Internet-Draft CR-based RO for NEMO July 2008 solution for other scenarios such as the vehicular [14] one. Besides, extensions to enable the use of CRON without the requiring the deployment of certificates -- using techniques similar to the ones described in [19] -- are currently being analysed and will be included in future revisions of this document. These extensions would enable extending the applicability of CRON to other scenarios such as the consumer electronics one [15]. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es Maria Calderon Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8780 Email: maria@it.uc3m.es Ignacio Soto Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 5974 Email: isoto@it.uc3m.es Bernardos, et al. Expires January 8, 2009 [Page 22] Internet-Draft CR-based RO for NEMO July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Bernardos, et al. Expires January 8, 2009 [Page 23]