Network Working Group A. Makela Internet-Draft J. Korhonen Intended status: Experimental TeliaSonera Expires: March 17, 2008 Sep 14, 2007 Home Agent assisted Route Optimization between Mobile IPv4 Networks draft-makela-mip4-nemo-haaro-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 March 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a Home Agent assisted route optimization extension to IPv4 Network Mobility Protocol. Makela & Korhonen Expires March 17, 2008 [Page 1]
Internet-Draft HAaRO Sep 2007 Table of Contents 1. Introduction and motivations . . . . . . . . . . . . . . . . . 3 2. Terms and definitions . . . . . . . . . . . . . . . . . . . . 5 3. Mobile IPv4 route optimization between mobile networks . . . . 6 3.1. Maintaining route optimization information . . . . . . . . 7 3.1.1. Advertising route-optimizable prefixes . . . . . . . . 7 3.1.2. Route Optimization cache . . . . . . . . . . . . . . . 8 3.1.3. Correspondent Router Mobility Bindings . . . . . . . . 9 3.2. Return routability procedure . . . . . . . . . . . . . . . 9 3.2.1. Router keys . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Mobile-Correspondent Router operations . . . . . . . . . . 11 3.3.1. Triggering Route Optimization . . . . . . . . . . . . 11 3.3.2. Mobile Router routing tables . . . . . . . . . . . . . 11 3.3.3. Inter-Mobile Router registration . . . . . . . . . . . 12 3.3.4. Inter-Mobile Router tunnels . . . . . . . . . . . . . 13 3.3.5. Constructing route-optimized packets . . . . . . . . . 14 3.3.6. Handovers and Mobile Routers leaving network . . . . . 14 3.4. Convergence and syncronization issues . . . . . . . . . . 14 4. New Mobile IPv4 messages and extensions . . . . . . . . . . . 15 4.1. Route optimization prefix advertisement . . . . . . . . . 15 4.2. Mobile router Route optimization capability . . . . . . . 17 4.3. Home-Test Init message . . . . . . . . . . . . . . . . . . 17 4.4. Care-of-Test Init message . . . . . . . . . . . . . . . . 18 4.5. Home Test message . . . . . . . . . . . . . . . . . . . . 18 4.6. Care-of test message . . . . . . . . . . . . . . . . . . . 19 4.7. Mobile-Correspondent authentication extension . . . . . . 19 4.8. Care-of address Extension . . . . . . . . . . . . . . . . 20 5. Special Considerations . . . . . . . . . . . . . . . . . . . . 21 5.1. NATs and stateful firewalls . . . . . . . . . . . . . . . 21 5.2. Foreign Agents . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Multiple Home Agents . . . . . . . . . . . . . . . . . . . 21 5.4. Mutualness of Route Optimization . . . . . . . . . . . . . 22 5.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 23 6. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8.1. Trust relationships . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Makela & Korhonen Expires March 17, 2008 [Page 2]
Internet-Draft HAaRO Sep 2007 1. Introduction and motivations Traditionally, there has been no method for route optimization in Mobile IPv4 [RFC3344]. Unlike Mobile IPv6 [RFC3775], where route optimization has been included from the start, Mobile IPv4 route optimization hasn't been addressed in a generalized scope. Even though general route optimization may not be of interest in IPv4 world, there are still specific applications for route optimization in Mobile IPv4. This draft proposes method to optimize routes between mobile networks behind mobile routers, as defined by NEMO [I-D.ietf-mip4-nemo-v4-base]. From service provider perspective a common topology for enterprise customer network consists of one to several sites (typically headquarters and various branch offices). These sites are typically connected via various Layer 2 technologies (ATM or Frame relay PVCs), MPLS VPNs or Layer 3 site-to-site VPNs. Recently, a trend has emerged where customers prefer to maintain connectivity via multiple service providers. Reasons include redundancy, reliability and availability issues. These kinds of multi-homing scenarios have traditionally been solved by using such technologies as multihoming BGP. However, a more lightweight solution is desirable. Mobile IP, especially mobile routers, can accommodate for this. The customer becomes a client of a virtual service provider, which does not take part in the actual access technology. The service provider has a backend system and an IP pool that it distributes to customers. The drawback of this solution is that it creates a star topology; All Mobile IP tunnels end up at the service provider hosted home agent, causing heavy load at the backend. Route optimization between mobile networks addresses this issue, by taking network load off the home agent and the backend. An example network is pictured below: Makela & Korhonen Expires March 17, 2008 [Page 3]
Internet-Draft HAaRO Sep 2007 +----------------------------+ | Virtual Operator Backend | +------------+ +-----+ | Home Agent | | AAA | +------------+---------+-----+ | .--. _(. `) _( ISP `)_ ( Peering `) ( ` . Point ) ) `--(_______)--' ____ / | \ / | \ .--. .--. .--. _( `. _( `. _( `. ( ISP A ) ( ISP B ) ( ISP C ) ( ` . ) ) ( ` . ) ) ( ` . ) ) `--(___.-' `--(___.-' `--(___.-' | ______/ \ / | / \ / | / \ / +----+ +----+ |MR A| |MR B| +----+ +----+ | | .--. .--. _( `. _( `. ( Site A ) ( Site B ) ( ` . ) ) ( ` . ) ) `--(___.-' `--(___.-' Virtual service provider architecture using NEMOv4 In this case, organization network consists of two sites, that are connected via 2 ISPs for redundancy reasons. Mobile IP allows fast handovers without problematics of multi-homing and BGP peering between each individual ISP and the organization. The traffic however takes a non-optimal route through the virtual operator backend. Route optimization would address this issue, allowing traffic between Sites A and B to flow through ISP B's network, or in case of a link failure, via the ISP peering point (such as MAE-WEST). The backend will not suffer from heavy loads. The primary design goal is to limit the load to the backend to minimum. Additional design goals include extensiblity to a more Makela & Korhonen Expires March 17, 2008 [Page 4]
Internet-Draft HAaRO Sep 2007 generalized scope, beyond the need of a single, coordinating Home Agent. 2. Terms and definitions 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 [RFC2119]. Home Agent (HA) Mobile IPv4 Home Agent Mobile Router (MR) Nemov4 Mobile Router Home Address (HoA) Mobile Router's home address Care-of Address (CoA) Mobile Router's Care-of Address. Address serving as the current attachment point. Correspondent Router (CR) Nemov4 Mobile Router which is destination for a Mobile network- initiated flow. Mobile Network Network managed by a Mobile Router Route Optimization Cache Data structure held by Mobile Routers on Route Optimizable destinations. Route Optimization activation Procedure consisting of Return Routability check, registration, setting up tunnels (if necessary) and starting to route traffic along the tunnel. Makela & Korhonen Expires March 17, 2008 [Page 5]
Internet-Draft HAaRO Sep 2007 Host Prefix Prefix with the mask of /32. eg. 192.0.2.254/32. Return Routability, RR Procedure to bind a Mobile Router's Home Address to a Care-of address on a Correspondent Router Mobility Binding The association of Home Address with a Care-of address, along with the lifetime remaining for that association, maintained by Home Agents and Correspondent Routers. Mobility Session Active connection to Home Agent and Correspondent Routers, maintained by Mobile Routers. 3. Mobile IPv4 route optimization between mobile networks This section describes the changed functionality of Home Agent and Mobile Router compared to the base NEMOv4 operation defined in NEMO- base [I-D.ietf-mip4-nemo-v4-base]. The basic premise is still the same; Mobile Routers, when registering, inform the Home Agent of the mobile networks they are managing; However, instead of only remaining on the Home Agent this information will now be distributed to the Mobile Routers as well. The Home Agent-assisted route optimization is primarily intended for helping to optimize traffic patterns between multiple sites in an single organization or administrative domain; However, extranets can also be reached with optimized routes, as long as all Mobile Routers connect to the same Home Agent. The procedure aim to maintain backwards compatibility; With legacy nodes or routers full connectivity is always preserved even though optimal routing cannot be guaranteed. The schema requires a Mobile Router to be able to receive messages from Home Agent and other Mobile Routers unsolicited - that is, without first initiating a request. This behavior is similar to the registration revocation procedure [RFC3543]. Many of the mechanisms are same - including the fact that advertising route optimization support upon registration implies capability to receive registration requests and return routability messages from other Mobile Routers. Makela & Korhonen Expires March 17, 2008 [Page 6]
Internet-Draft HAaRO Sep 2007 Compared to IPv6, where Mobile Node <-> Correspondent node bindings are maintained via Mobility Routing header and Home Address options, Mobile IPv4 always requires the use of tunnels. Therefore, inter- mobile-router tunnel establishment has to be conducted. 3.1. Maintaining route optimization information During registration, a joining Mobile Router MAY request information on route-optimizable networks and let the Home Agent allow re- distribution of information of its own networks. This is indicated with Mobile Router route optimization capability extension, see Section 4.2. Note that the redistribution of networks from the Home Agent happens only during the registration phase. There are no "routing updates" from Home Agent except in the form of re-registration. Besides timeouts, the re-registration may occur if a Correspondent Router receives a registration request from a unknown Mobile Router (see Section 3.3.3). 3.1.1. Advertising route-optimizable prefixes A NEMO-supporting Home Agent already maintains information on which network(s) are reachable behind certain Mobile Routers. Only change to this functionality is that this information can now be distributed to other nodes upon request. This request is defined in Section 4.2. When a Home Agent receives a registration request, it conducts the normal authentication and authorization procedures. If registration is successful and the route optimization request was present in the registration request, the reply message includes zero or more route optimization prefix advertisement extensions which inform the Mobile Router of all existing mobile networks and the Mobile Routers that manage them. The networks SHOULD be included in order of priority, with the networks most desired to conduct optimization listed first. The extension is constructed as shown in Section 4.1. Each extension informs the Mobile Router of one prefix; Each prefix requires a separate extension. Each network can also be associated to a realm, usually of form '@organization.example.com'. Besides the routers in customer's own organization, the prefix list may also include other Mobile Routers, e.g. default prefix (0.0.0.0/0) pointing towards Internet gateway for Internet connectivity, and possible extranets. The realm information can be used to make policy decisions on the Mobile Router, such as preferring optimization within specific realm only. Makela & Korhonen Expires March 17, 2008 [Page 7]
Internet-Draft HAaRO Sep 2007 Upon receiving registration reply with the route optimization prefix advertisement extension, the Mobile Router SHALL insert the Mobile Router HoA as a host-prefix to the local Route Optimization Cache if it does not already exist. If the route is NOT host-route only, any additional prefixes information SHALL also be inserted to the Route Optimization Cache. The Mobile Router MAY discard entries from a desired starting point onwards, due to memory or other policy related constraints. The intention of listing the prefixes in order of priority is to provide implicit guidance for this decision. If the capacity of the device allows, the Mobile Router SHOULD use information on all advertised prefixes. 3.1.2. Route Optimization cache Mobile routers supporting route optimization will maintain a Route Optimization Cache. The Route Optimization Cache contains mappings between Correspondent Router HoA's, network(s) associated with each HoA and return routability procedure status. The Route Optimization Cache contains the following information for all Correspondent Routers: CR-HoA Correspondent Router's Home Address. Prefixes A list of destination prefixes reachable via this Correspondent Router. Includes network and prefix length, e.g. 192.0.2.0/25. Always contains at least a single entry, the CR-HoA host prefix in the form of 192.0.2.1/32. Realm Destination realm. May be empty, if realm is not provided by advertisement or configuration. NAT The Correspondent Router is behind NAT/Firewall as seen from HA. Set if 'O' bit is set in the received advertisement. Affects tunnel establisment, see Section 3.3.4. Also mandates use of UDP encapsulation. RRSTATE Return routability state. States are INACTIVE, IN PROGRESS and ACTIVE. If state is INACTIVE, return routability procedure must be completed before forwarding route- optimized traffic. If state is IN PROGRESS or ACTIVE, this entry MUST NOT be removed from Route Optimization Cache as long as tunnel to the Correspondent Router is established . Makela & Korhonen Expires March 17, 2008 [Page 8]
Internet-Draft HAaRO Sep 2007 KRm Return routability registration management key. HA HA bit is set if this entry is learned from HA. This implies that the entry can be trusted. If not set, the entry has been learned from another Mobile Router and not yet verified from HA. The entry may still be maintained while awaiting verification. 3.1.3. Correspondent Router Mobility Bindings Each Correspondent Router will maintain Mobility Bindings, in a similar way to the Home Agent. The Mobility Binding for each Mobile Router contains HoA Mobile Router's Home Address CoA Mobile Router's Care-of Address Prefixes A list of destination prefixes bound to this Mobile Router. Includes the Mobile Router itself as a host prefix, e.g. 192.0.2.1/32. Realm Destination realm. May be empty, if realm not provided by advertisement or configuration. Tunnel Tunnel interface associated with the Mobile Router. The tunnel interface itself handles all the necessary operations to keep the tunnel operational, e.g. sends UDP keepalives. 3.2. Return routability procedure The return routability procedure for Mobile IPv6 is described in [RFC3775]. Same principles apply to the Mobile IPv4 version: Two messages are sent to Correspondent Router's Home Address, one via Home Agent and the other directly from the Mobile Router CoA, with two responses coming through same routes. Registration management key is derived from token information carried on these messages. This registration management key (KRm) can then be used to authenticate registration requests (comparable to Binding Updates in Mobile IPv6). Assumption on traffic patterns is that the Mobile Router that initiates the RR procedure can always send outbound messages, even when behind NAT or firewall. This basic assumption made for NAT Traversal in [RFC3519] is also applicable here. In case the Correspondent Router is behind such obstacles, it receives these Makela & Korhonen Expires March 17, 2008 [Page 9]
Internet-Draft HAaRO Sep 2007 messages via the reverse tunnel to CR's Home Address, thus any problem regarding the CR's connectivity is addressed during the registration phase. 3.2.1. Router keys Each Correspondent Router maintains a router key, Kcr, which is not shared with anyone else. This is analogous to node key, Kcn, in Mobile IPv6. Correspondent Router uses router key to verify that the keygen tokens sent by Mobile Router in registration request are its own. The router key MUST be a random number, 96 bits in length. 3.2.2. Nonces Each Correspondent Router also maintains one or more indexed nonces. Nonces should be generated periodically with a good random number generator. The Correspondent Router may use same nonces with all Mobile Routers. Correspondent Routers keep both the current nonce and small set of valid previous nonces whose lifetime have not expired yet. Return Routability procedure may be initiated only when the Route Optimization Cache's RRSTATE field for the Correspondent Router is INACTIVE. When Return Routability procedure is initiated, the state MUST be set to IN PROGRESS. The Return Routability procedure consists of four new Mobile IP messages: Home Test Init, Care-of Test Init, Home Test and Care-of Test. They are constructed as shown in Section 4.3 through Section 4.6. If the Mobile Router has included the Mobile Router optimization capability extension in its Registration Request, it MUST be able to accept Return Routability messages. The messages are delivered as standard Mobile IP packets. The addresses are set to Correspondent Router's HoA and Mobile Router's CoA. The return routability procedure begins with the Mobile Router sending HoTI and CoTI messages, each containing a cookie. Upon receiving the HoTI or CoTI message the Correspondent Router MUST have a secret Kcr. If the Kcr does not exist, it must be produced before continuing with the return routability procedure. Correspondent Router responds to HoTI and CoTI messages by constructing HoT and CoT messages, respectively, as replies. HoT message contains current home nonce index and CoT message contains current care-of nonce index. Makela & Korhonen Expires March 17, 2008 [Page 10]
Internet-Draft HAaRO Sep 2007 Upon completion of Return Routability procedure, the Routing Optimization Cache's RRSTATE field is set to ACTIVE. The Mobile Router will establish a registration management key Krm: Krm = SHA1 (home keygen token | care-of keygen token) Like in Mobile IPv6, the Correspondent Router does not maintain any state for the Mobile Router until after receiving a registration request. 3.3. Mobile-Correspondent Router operations This section deals with the operation of Mobile and Correspondent Routers performing route optimization. Note that in a typical case all routers work as both Mobile Router and Correspondent Router. Especially compared to Mobile IPv6 route optimization there are two issues that are different regarding IPv4. First of all, since Mobile IPv4 always uses tunnels, there must be a tunnel established between MR and CR's Care-of addresses. This is accomplished with a new extension, "Care-of Address", in registration reply. Second issue is rising from security standpoint: In a registration request, the Mobile Router claims to represent an arbitary IPv4 network. If the CR has not yet received this information (HoA <-> Network prefix), it SHOULD perform a re-registration to Home Agent to verify the claim. 3.3.1. Triggering Route Optimization Since each Mobile Router knows all the route-optimizable networks, the route optimization between all Correspondent Routers can be established at any time; However a better general practice is to conduct Route Optimization activation on-demand only. Route optimization SHOULD only be started when receiving a packet where destination address is local (and the subnet is registered as route optimizable) and source address exists in the Route Optimization Cache. 3.3.2. Mobile Router routing tables Each Mobile Router maintains a routing table. In a typical situation, it contains interface(s) to the local networks, interface to wide-area network (such as ISP), and a tunnel interface to the Home Agent. Additional entries consist of route-optimized tunnel interfaces and networks associated with each tunnel. Makela & Korhonen Expires March 17, 2008 [Page 11]
Internet-Draft HAaRO Sep 2007 3.3.3. Inter-Mobile Router registration If route optimization between Mobile Router and Correspondent Router is desired, Return Routability procedure must have been performed ( See Section 3.2.) After completion of the procedure, a Mobile Router MAY send a registration request to the Correspondent Router's HoA. The registration request's source address and Care-of address field are set to the Mobile Router's Care-of address. The registration request MUST include Mobile-Correspondent Authentication extension defined in Section 4.7 and Mobile Network Request Extension defined in [I-D.ietf-mip4-nemo-v4-base]. If timestamps are used, the Correspondent Router MUST check the identification field for validity. The registration request MUST include Home Address. The Authenticator field is hashed with the key Krm. The encapsulation can be set as desired, except in the case where the Correspondent Router's Route Optimization Cache Entry has NAT set or the Mobile Router itself is behind NAT or firewall. If either of the conditions apply, registration request MUST specify UDP encapsulation. The Correspondent Router first checks the registration request's authentication against Kcr and nonce indexes negotiated during Return Routability procedure. This ensures that the registration request is coming from a correct Mobile Router. If the check passes, the Correspondent Router MUST check whether the Mobile Router already exists in it's Route Optimization Cache and is linked with the prefixes included in the request. If the prefixes don't match, the Correspondent Router SHOULD send a re-registration request to Home Agent with the 'S' (solicitation) bit set, thus obtaining the latest information on mobile prefixes managed by incoming Mobile Router. If, even after this update, the prefixes still don't match, the Correspondent Router MUST reject the registration request. This verification is done to protect against Mobile Router claiming to represent arbitary networks; However, since Home Agent provides trusted information, it can authorize Mobile Router's claim. If the network is considered trusted, the Correspondent Router can, as a policy, accept registrations from without this check; however, this is NOT RECOMMENDED as a general practice. If the prefixes match, the Correspondent Router MAY accept the registration. Upon receiving the registration reply, the Mobile Router MUST check if a tunnel to the Mobile Router already exists. Otherwise a tunnel MUST be established and Mobility Binding updated. This is covered in Section 3.3.4. Makela & Korhonen Expires March 17, 2008 [Page 12]
Internet-Draft HAaRO Sep 2007 The Correspondent Router's routing table MUST be updated to include the Mobile Router's networks are reachable via the tunnel to the Mobile Router. After the tunnel is established, the Mobile Router MAY update it's routing tables to reach all Correspondent Router's Prefixes via the tunnel. This is primarily a policy decision depending on the network environment. See section Section 5.4. 3.3.4. Inter-Mobile Router tunnels Inter-Mobile Router tunnel establishment follows establishing standard reverse tunnels to the Home Agent. The registration request to Correspondent Router includes information on the desired encapsulation. In the case of GRE, IP over IP or minimal encapsulation no special considerations regarding the reachability are necessary; The tunnel has no stateful information; The packets are simply encapsulated within the GRE, IP, or minimal header. The tunnel origination point for the Correspondent Router is its Care-of Address, not the address where the registration requests were sent. This is different from creation of the Reverse Tunnel to Home Agent. Special considerations rise from using UDP encapsulation, especially in cases where one of the Mobile Routers is located behind NAT or firewall. If the Route Optimization Cache has NAT bit set for a specific network, the UDP tunnel establishment MUST be initiated from the Correspondent Router. However, the procedure otherwise follows [RFC3519]. Once the first UDP keepalive is sent, the tunnel can be considered active. If both the Mobile Router and the Correspondent Router are behind NAT, route optimization cannot be performed between them. Possibilities to set up mutual tunneling when both routers are behind NAT, are outside the scope of this draft. However, some of these issues are addressed in Section 5.1. Due to the fact that the route optimization procedures may occur concurrently at two Mobile Routers, each working as each other's Correspondent Router, there may be a situation where two routers are attempting to establish separate tunnels between them at the same time. If a router with a smaller Home Address receives a registration request (in CR role) while its own registration request (sent in MR role) has not been answered yet, the reply must be held until the tunnel initiated by its registration request is up. This avoids the problem of maintaining two separate tunnels forming concurrently between two Mobile Routers. Makela & Korhonen Expires March 17, 2008 [Page 13]
Internet-Draft HAaRO Sep 2007 Since typical routers act as both MR's and CR's, tunnels can be only torn down if there is no Mobility Bindings on the tunnel (in Correspondent Router role) AND no Mobility Sessions are bound to the tunnel (Mobile Router role). Both Mobility Sessions and Mobility Bindings will go down when their lifetime expires. 3.3.5. Constructing route-optimized packets All packets received by the Mobile Router are forwarded using normal routing rules according to the routing table. There are no special considerations when constructing the packets, the interface procedure will encapsulate any packet automatically. If prefixes overlap each other, e.g. 192.0.2.128/25 and 192.0.2.128/29, the standard longest match rule for routing is in effect. However, overlapping private address SHOULD be considered an error situation. Any aggregation for routes in private address space SHOULD be conducted only at HA. 3.3.6. Handovers and Mobile Routers leaving network Handovers and connection breakdowns can be categorized as either ungraceful or graceful, or break-before-make and make-before-break situations. In a typical situation, router act as both Mobile Router and Correspondent Router for other routers' prefixes. When a Mobile Router wishes to leave network, it SHOULD send a re- registration request to all Correspondent Routers with the lifetime set to zero. If the Correspondent Router is also acting as a Mobile Router with active Route Optimization with the leaving router, it SHOULD send a similar re-registration request with the lifetime set to zero. This causes both the Mobility Bindings and active Mobility Sessions to go down, allowing for teardown of the tunnel. If the Mobile Router was unable to send the re-registration request before handover, it SHOULD send it immediately after handover is completed and binding with the Home Agent is up. In a similar fashion, Correspondent Router acting as a Mobile Router SHOULD realize that the old Mobility Session is no longer valid and establish a new one. Thus, route optimization can resume. 3.4. Convergence and syncronization issues Home Agent state and Mobile Routers' Route Optimization Caches do not need to be explicitly synchronized. The assumption is that at least some of the traffic between mobile networks is always bidirectional. Makela & Korhonen Expires March 17, 2008 [Page 14]
Internet-Draft HAaRO Sep 2007 This will cause Mobile Routers to perform re-registrations and thus they will receive updates on-demand only. Consider a situation with three mobile networks, A, B, C handled by three Mobile Routers, MR A, MR B and MR C. If they register to a Home Agent in this order, the situation goes as follows: MR A registers; Receives no information on other networks from HA, as no other MR has registered yet. MR B registers; Receives information on mobile network A being reachable via MR A. MR C registers; Receives information on both of the other mobile networks. If a node in mobile network C receives traffic from mobile network A, the route optimization is straightforward; MR C already has network A in its Route Optimization Cache. When it registers to MR A (after Return Routability procedure is completed), MR A does not have information on mobile network C; Thus it will perform a re- registration to the Home Agent on-demand. This allows MR A to verify that MR C is indeed managing network C. If a node in mobile network B receives to traffic from mobile network C, MR B has no information on network C. No route optimization is triggered. However, when network B's reply reaches MR C, route optimization happens as above. Even in the very rare case of completely unidirectional traffic from an entire network, the re-registrations caused by timeouts will eventually cause convergence. However, this should be treated as a special case. Note that all Mobile Routers are connected to same Home Agent. For possiblities concering multiple Home Agents, see Section 5.3 4. New Mobile IPv4 messages and extensions This section describes the construction of all new information elements. 4.1. Route optimization prefix advertisement This non-skippable extension MAY be sent by a Home Agent to a Mobile Router in the registration reply message. The extension is only included when explicitly requested by the Mobile Router in the Makela & Korhonen Expires March 17, 2008 [Page 15]
Internet-Draft HAaRO Sep 2007 registration request message. The extension MAY be included multiple times; one extension for each prefix. Implicit prioritization of prefixes is caused by the order of extensions. Route optimization prefix advertisement extension 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 | Sub-Type |x|O|H| PLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Router HoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional Realm ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA, Non-skippable (since it's explicitly requested) H Host route only. If this bit is set, the route optimization is advertised only to the Mobile Router itself. No mobile networks are included. In this case the length field is ignored. This also indicates that this is the only Route optimization prefix advertisement extension in the packet. O Outbound connections only. This bit indicates that only the target Mobile Router can only initiate, not receive, connections from it's CoA. This is set if Home Agent has determined that the Mobile Router is behind NAT, or the Mobile Router has explicitly requested it using the UDP Tunnel Request extension defined in RFC 3519 [RFC3519] with the Force flag set. PLen Length of the prefix advertised. 5 bits, allows for values from 0 to 32. Mobile router HoA Mobile Router's Home address Prefix The IPv4 prefix advertised. Realm The Realm that is associated with the advertised Mobile Router CoA and prefix. x MUST be set to zero. Ignored on reception. Reserved for future use. Makela & Korhonen Expires March 17, 2008 [Page 16]
Internet-Draft HAaRO Sep 2007 4.2. Mobile router Route optimization capability This skippable extension MAY be sent by a Mobile Router to a Home Agent in the registration request message. 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 | Sub-Type |A|R|S| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional Mobile Router HoA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA. Skippable; If Home Agent does not support route optimization advertisements, it can ignore this request and simply not include any information in the reply. A Advertise my networks. If 'A' bit is set, the Home Agent is allowed to advertise the networks managed by this Mobile Router to other Mobile Routers.This also indicates that the Mobile Router is capable of receiving route optimization binding updates. In effect, this allows the Mobile Router to work in Correspondent Router role. R Request mobile network information. If 'R' bit is set, the Home Agent MAY respond with information about mobile networks in the same domain. S Solicitating prefixes managed by specific Mobile Router. The Mobile Router is specified in the Optional Mobile Router HoA field. Reserved Set to zero, MUST be ignored on reception. Optional Mobile Router HoA Other Mobile Router's Home Address. 4.3. Home-Test Init message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Makela & Korhonen Expires March 17, 2008 [Page 17]
Internet-Draft HAaRO Sep 2007 Type TBA. Reserved Set to zero, MUST be ignored on reception. Home Init Cookie 64-bit field which contains a random value, the Home Init Cookie. 4.4. Care-of-Test Init message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Reserved Set to zero, MUST be ignored on reception. Care-of Init Cookie 64-bit field which contains a random value, the Care-of Init Cookie. 4.5. Home Test message 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 | Home Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Home Nonce Index This field will be echoed back by the Mobile Router to the Correspondent Router in a subsequent registration request. Makela & Korhonen Expires March 17, 2008 [Page 18]
Internet-Draft HAaRO Sep 2007 Home Init Cookie 64-bit field which contains a random value, the Home Init Cookie. Home Keygen Token This field contains the 64 bit home keygen token used in the Return Routability procedure. Generated from cookie + nonce. 4.6. Care-of test message 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 | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Care-of Nonce Index This field will be echoed back by the Mobile Router to the Correspondent Router in a subsequent registration request. Care-of Init Cookie 64-bit field which contains a random value, the Home Init Cookie. Care-of Keygen Token This field contains the 64 bit home keygen token used in the Return Routability procedure. 4.7. Mobile-Correspondent authentication extension Nonce indices extension is used in registration requests sent from Mobile Router to Correspondent Router Mobile-Correspondent authentication extension is included in registration requests sent from Mobile Router to Correspondent Router. It may also be used with Foreign Agents. The format is similar to the other Authentication Extensions defined in [RFC3344], with SPI's replaced by Nonce Indexes. Makela & Korhonen Expires March 17, 2008 [Page 19]
Internet-Draft HAaRO Sep 2007 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 | Home Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Nonce Index | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Home Nonce Index field tells the Correspondent Router which nonce value to use when producing the home keygen token. The Care-of Nonce Index field is ignored in requests to remove a binding. Otherwise, it tells the Correspondent Router which nonce value to use when producing the Care-of Keygen Token. Type TBA Home Nonce Index Home Nonce Index in use. Care-of Nonce Index Care-of Index in use. Authenticator Authenticator field, constructed by issuing HMAC_SHA1 (Krm, Protected Data) The protected data, just like on other cases where Authenticator is used, consists of o the UDP payload (i.e., the Registration Request or Registration Reply data), o all prior Extensions in their entirety, and o the Type, Length, and Nonce Indexes of this Extension. 4.8. Care-of address Extension 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Care-of Address extension is added to a registration reply sent by the Correspondent Router to inform the Mobile Router of the upcoming tunnel endpoint. Makela & Korhonen Expires March 17, 2008 [Page 20]
Internet-Draft HAaRO Sep 2007 5. Special Considerations 5.1. NATs and stateful firewalls Mechanisms described in MIP NAT traversal [RFC3519] allow the Home Agent to be aware of mobile networks managed by a Mobile Router behind NAT. This information is passed on to the other Mobile Routers with the 'O' flag. In the case of one of the routers behing behind NAT or similarly impaired, the tunnel establishment procedure takes this into account. If Mobile Router and Correspondent Router are behind same NAT from HA's point of view, it is possible to establish tunnel between them. This may also be the situation in the case of nested NATs. This calls for development of some sort of "Route optimization discovery" protocol (see Section 5.5) , or more information in the Route Optimization capability advertisements. If both the Mobile Router and the Correspondent Router are behind two separate NATs, some sort of proxy or hole-punching technique may be needed. This is out of scope of this draft. 5.2. Foreign Agents Foreign Agents have to specifically support route optimization, ie. Return Routability procedure and establishment and maintainance of tunnel interfaces. Optionally, Mobile Router and Foreign Agent can have a trust relationshi to ensure that security is not affected. In RFC 3344 [RFC3344], there are separate type codes for Authenticator extensions depending on the message being sent between Mobile Node and Home Agent, Mobile Node and Foreign Agent, or Foreign Agent and Home Agent. In this draft, all possible combinations (Mobile-Correspondent, Mobile-Foreign, Foreign-Correspondent) use same authenticator extension type code. 5.3. Multiple Home Agents In fact, Mobile Routers can negotiate and perform route optimization without the assistance of Home Agent - if they can discover each others existence. This draft only addresses a single Home Agent that distributes network prefix information to the Mobile Routers. Problems arise from possible trust relationships; In this draft the Home Agent serves as a way to provide verification that a specific network is managed by a specific router. For host-routes (route optimization between single nodes), the requirements may not be so strict. Makela & Korhonen Expires March 17, 2008 [Page 21]
Internet-Draft HAaRO Sep 2007 Several possibilities exist for achieving Route Optimization between Mobile Routers attached to separate Home Agents, such as a discovery/ probing protocol, routing protocol between Home Agents or DNS SRV records, or a common AAA architecture. There already is a framework for HA to retrieve information from AAA so it can be considered as the most viable possibility. See Section 5.5 for information on possibility to generalize the method. Any discovery/probing protocols are out of scope for this draft. 5.4. Mutualness of Route Optimization The procedure as specified is asymmetric; That is, if bidirectional route optimization is desired while maintaining consistency, the route optimization (RR check and registration) has to be performed in both directions. This is primarily a policy decision depending on how often the mobile prefixes are reconfigured. Consider the case where two networks, A and B, are handled by Mobile Routers A and B respectively. If the route optimization is triggered by receiving packet from a network in Route Optimization Cache, the following occurs if a node in network A starts pinging a node in network B. MR B sees the echo request message. It sees that the destination is in network B, and furthermore, source is in network A. MR B completes RR procedure and registration with MR A, which is now acting as Correspondent Router. A tunnel is created between the routers. MR A updates its routing table so that network B is reachable via MR A <-> MR B tunnel. The traffic pattern is now that echo request packets from network A to network B are sent over the tunnel, but the echo replies are transmitted via the Home Agent and reverse tunnels. MR A may now perform its own route optimization towards MR B. MR B notices that a tunnel to MR A already exists, but updates its routing table so that network A is now reacable via the MR A <-> MR B tunnel. In this scenario, if MR A does NOT perform a separate route optimization (RR check and registration), due to MR B simply updating it's routing table to reach network A via the tunnel, problems may arise if MR A has started to managed another network A' before the information has propagated to MR B. Unless routing on MR A is based on both source and destination, the end result is that MR B starts to receive packets from network A' via the MR A <-> B tunnel even though it expects to receive them from the reverse tunnel towards the Home Agent. If Reverse Path Forwarding or other antispoofing check is Makela & Korhonen Expires March 17, 2008 [Page 22]
Internet-Draft HAaRO Sep 2007 used, the packets may end up blackholed. 5.5. Extensibility The design considerations include several mechanisms which might not be strictly necessary if Route Optimization would only be desired between individual customer sites in a managed network. The Return Routability procedure, which allows for Correspondent Routers to learn Mobile Router's Care-of Addresses is not strictly necessary; The CoA's could have been provided by HA directly. However, this approach allows the method to be extended to a more generic route optimization. The primary driver for having Home Agent to work as a centralized information distributer is to provide Mobile Routers with the knowledge of not only the other routers, but to provide information on which networks are managed by which routers. The Home Agent provides the information on all feasible nodes with which it is possible to establish Route Optimization. If representing a whole Mobile Network is not necessary, in effect the typical Mobile Node <-> Correspondent Node situation, the mechanisms in this draft work just as well - only problem is discovering if the target Correspondent Node can provide Route Optimization capability. The "Host route only" flag is present for this very reason. Correspondent node/router discovery protocols (whether they are based on probing or a centralized directory beyond the single Home Agent) are outside the scope of this draft. 6. Scalability Home Agent assisted Route Optimization scalability issues stem from the general Mobile IPv4 architechture which is based on tunnels. Creating, maintaining and destroying tunnel interfaces can cause load on the Mobile Routers. However, the MRs can always fall back to normal, reverse tunnelled routing if resource constraints are apparent. If there is a large number of optimization-capable prefixes, maintaining state for all of these may be an issue also, due to limits on routing table sizes. Registration responses from Home Agent to Mobile Router may provide information on large number of network prefixes. If thousands of networks are involved, the registration reply messages are bound to grow very large. There will be some practical upper limit after which point some other delivery mechanism for the prefix information Makela & Korhonen Expires March 17, 2008 [Page 23]
Internet-Draft HAaRO Sep 2007 will be needed. However, this should still work at least to around hundred prefixes, which is of practical use to many organizations still. 7. IANA Considerations New Mobile IP header extension and message type values are needed for the messages and extensions listed in Section 4. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations The Return Routability check has been established in the IPv6 world. 8.1. Trust relationships The network of trust relationships in Home Agent assisted Route Optimization solve the issues where arbitary Correspondent Router can trust an arbitary Mobile Router that it is indeed the proper route to reach an arbitary mobile network. It is assumed that all Mobile Routers have a trust relationship with the Home Agent. Thus, they trust information provided by Home Agent. The Home Agent provides information matching Home Addresses and network prefixes. Each Mobile Router trusts this information. Mobile Routers may perform Return Routability procedure between each other. This creates a trusted association between Mobile Router Home Address and Care-of Address. The Mobile Router also claims to represent a specific network. This information is not trustworthy as such. The claim can be verified by checking the Home Address <-> network prefix information received, either earlier, or due to on-demand request, from the Home Agent. If they match, the Mobile Router's claim is authentic. If the network is considered trusted, a policy decision can be made to skip this check. Exact definitions on situations where such decision can be made are out of scope of this draft. The RECOMMENDED general practice is to perform the check. Makela & Korhonen Expires March 17, 2008 [Page 24]
Internet-Draft HAaRO Sep 2007 9. Acknowledgements Thanks to Jyrki Soini and Kari Laihonen for initial reviews. 10. References 10.1. Normative References [I-D.ietf-mip4-nemo-v4-base] Leung, K., "Network Mobility (NEMO) Extensions for Mobile IPv4", draft-ietf-mip4-nemo-v4-base-02 (work in progress), September 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003. 10.2. Informative References [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Antti Makela TeliaSonera Corporation. P.O.Box 777 FIN-33101 Tampere FINLAND Phone: +358 40 824 4170 Email: antti.makela@teliasonera.com Makela & Korhonen Expires March 17, 2008 [Page 25]
Internet-Draft HAaRO Sep 2007 Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Makela & Korhonen Expires March 17, 2008 [Page 26]
Internet-Draft HAaRO Sep 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Makela & Korhonen Expires March 17, 2008 [Page 27]