Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6521

Home Agent-Assisted Route Optimization between Mobile IPv4 Networks

Pages: 53
Experimental
Part 1 of 2 – Pages 1 to 23
None   None   Next

Top   ToC   RFC6521 - Page 1
Internet Engineering Task Force (IETF)                         A. Makela
Request for Comments: 6521                       Aalto University/Comnet
Category: Experimental                                       J. Korhonen
ISSN: 2070-1721                                   Nokia Siemens Networks
                                                           February 2012


  Home Agent-Assisted Route Optimization between Mobile IPv4 Networks

Abstract

This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6521.
Top   ToC   RFC6521 - Page 2
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Introduction and Motivations ....................................3 2. Terms and Definitions ...........................................6 3. Mobile IPv4 Route Optimization between Mobile Networks ..........8 3.1. Maintaining Route Optimization Information .................9 3.1.1. Advertising Route-Optimizable Prefixes ..............9 3.1.2. Route Optimization Cache ...........................11 3.2. Return Routability Procedure ..............................13 3.2.1. Router Keys ........................................15 3.2.2. Nonces .............................................15 3.2.3. Updating Router Keys and Nonces ....................16 3.3. Mobile-Correspondent Router Operations ....................16 3.3.1. Triggering Route Optimization ......................17 3.3.2. Mobile Router Routing Tables .......................17 3.3.3. Inter-Mobile Router Registration ...................18 3.3.4. Inter-Mobile Router Tunnels ........................20 3.3.5. Constructing Route-Optimized Packets ...............21 3.3.6. Handovers and Mobile Routers Leaving Network .......21 3.4. Convergence and Synchronization Issues ....................22 4. Data Compression Schemes .......................................23 4.1. Prefix Compression ........................................23 4.2. Realm Compression .........................................25 4.2.1. Encoding of Compressed Realms ......................25 4.2.2. Searching Algorithm ................................27 4.2.3. Encoding Example ...................................27
Top   ToC   RFC6521 - Page 3
   5. New Mobile IPv4 Messages and Extensions ........................30
      5.1. Mobile Router Route Optimization Capability Extension .....30
      5.2. Route Optimization Reply ..................................31
      5.3. Mobile-Correspondent Authentication Extension .............32
      5.4. Care-of Address Extension .................................33
      5.5. Route Optimization Prefix Advertisement Extension .........34
      5.6. Home Test Init Message ....................................36
      5.7. Care-of Test Init Message .................................36
      5.8. Home Test Message .........................................37
      5.9. Care-of Test Message ......................................38
   6. Special Considerations .........................................39
      6.1. NATs and Stateful Firewalls ...............................39
      6.2. Handling of Concurrent Handovers ..........................40
      6.3. Foreign Agents ............................................40
      6.4. Multiple Home Agents ......................................40
      6.5. Mutualness of Route Optimization ..........................41
      6.6. Extensibility .............................................42
      6.7. Load Balancing ............................................43
   7. Scalability ....................................................43
   8. Example Signaling Scenarios ....................................44
      8.1. Registration Request ......................................44
      8.2. Route Optimization with Return Routability ................45
      8.3. Handovers .................................................46
   9. Protocol Constants .............................................48
   10. IANA Considerations ...........................................48
   11. Security Considerations .......................................50
      11.1. Return Routability .......................................50
      11.2. Trust Relationships ......................................51
   12. Acknowledgements ..............................................51
   13. References ....................................................51
      13.1. Normative References .....................................51
      13.2. Informative References ...................................52

1. Introduction and Motivations

Traditionally, there has been no method for route optimization in Mobile IPv4 [RFC5944] apart from an early attempt [MIP-RO]. Unlike Mobile IPv6 [RFC6275], where route optimization has been included from the start, with Mobile IPv4, route optimization hasn't been addressed in a generalized scope. Even though general route optimization may not be of interest in the scope of IPv4, there are still specific applications for route optimization in Mobile IPv4. This document proposes a method to optimize routes between networks behind Mobile Routers (MRs), as defined by Network Mobility (NEMO) [RFC5177]. Although NAT and the pending shortage of IPv4 addresses make widespread deployment of end- to-end route optimization infeasible, using route optimization from
Top   ToC   RFC6521 - Page 4
   MR to MR is still a practical scenario.  Note that the method
   specified in this document is only for route optimization between
   MRs; any network prefix not advertised by an MR would still be routed
   via the home agent, although an MR could advertise very large address
   spaces, e.g., by acting as an Internet gateway.

   A particular use case concerns setting up redundant yet economical
   enterprise networks.  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 multihoming scenarios have traditionally been solved
   by using such technologies as multihoming BGP.  However, a more
   lightweight and economical solution is desirable.

   From a service provider perspective, a common topology for an
   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 Permanent Virtual Circuits (PVCs)), MPLS VPNs, or Layer 3
   site-to-site VPNs.  With a Service Level Agreement (SLA), a customer
   can obtain very reliable and well-supported intranet connectivity.
   However, compared to the cost of "consumer-grade" broadband Internet
   access, the SLA-guaranteed version can be considered very expensive.
   These consumer-grade options, however, are not a reliable approach
   for mission-critical applications.

   Mobile IP, especially MRs, can be used to improve reliability of
   connectivity even when implemented over consumer-grade Internet
   access.  The customer becomes a client for a virtual service
   provider, which does not take part in the actual access technology.
   The service provider has a backend system and an IP address pool that
   it distributes to customers.  Access is provided by multiple,
   independent, possibly consumer-grade ISPs, with Mobile IP providing
   seamless handovers if service from a specific ISP fails.  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 a heavy load at the backend.  Route optimization between
   mobile networks addresses this issue, by taking the network load off
   of the home agent and the backend.
Top   ToC   RFC6521 - Page 5
   An example network is pictured below:

                       +----------------------------+
                       |  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 example case, the organization network consists of two sites
   that are connected via two ISPs for redundancy reasons.  Mobile IP
   allows fast handovers without the problems of multihoming 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 addresses this issue, allowing traffic between
   Sites A and B to flow directly through ISP B's network, or in case of
   a link failure, via the ISP peering point (such as the Metropolitan
   Area Ethernet (MAE), e.g., MAE-West).  The backend will not suffer
   from heavy loads.
Top   ToC   RFC6521 - Page 6
   The specification in this document is meant to be Experimental, with
   the primary design goal of keeping the load on the backend to a
   minimum.  Additional design goals include extensibility to a more
   generalized scope, such as not requiring all MRs to be homed on the
   same home agent.  Experiences are mostly sought regarding
   applicability to real-world operations, and protocol-specific issues
   such as signaling scalability, interworking with other Mobile IP
   extensions not specifically addressed in this document, and behavior
   of end-user applications over route-optimized paths.

   The aforementioned use case is the original application.  Moving this
   specification to Standards Track should be considered after enough
   deployment experience has been gathered.  Besides the aforementioned
   issues, additional elements that might require refinement based on
   real-world experiences are delivery of information on networks
   managed by peer MRs; conducting MR <-> MR authentication; reaction
   to, and recovery methods for, connectivity breakdowns and other
   break-before-make topology changes; keepalive timer intervals;
   formats of signaling extensions; behavior in NAT/firewalled
   environments; and the prefix and realm compression algorithms.

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]. Care-of Address (CoA) RFC 5944 [RFC5944] defines a care-of address as the termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of CoA: a "foreign agent care-of address", which is an address of a foreign agent with which the mobile node is registered, and a "co-located care-of address", which is an externally obtained local address that the mobile node has associated with one of its own network interfaces. However, in the case of Network Mobility, foreign agents are not used, so no foreign CoAs are used either. Correspondent Router (CR) RFC 5944 [RFC5944] defines a correspondent node as a peer with which a mobile node is communicating. A CR is a peer MR that MAY also represent one or more entire networks.
Top   ToC   RFC6521 - Page 7
   Home Address (HoA)

      RFC 5944 [RFC5944] defines a home address as an IP address that is
      assigned for an extended period of time to a mobile node.  It
      remains unchanged regardless of where the node is attached to the
      Internet.

   Home Agent (HA)

      RFC 5944 [RFC5944] defines a home agent as a router on a mobile
      node's home network that tunnels datagrams for delivery to the
      mobile node when it is away from home and maintains current
      location information for the mobile node.  For this application,
      the "home network" sees limited usage.

   Host Network Prefix

      A host network prefix is a network prefix with a mask of /32,
      e.g., 192.0.2.254/32, consisting of a single host.

   Mobility Binding

      RFC 5944 [RFC5944] defines Mobility Binding as the association of
      an HoA with a CoA, along with the lifetime remaining for that
      association.

   Mobile Network Prefix

      RFC 5177 [RFC5177] defines a mobile network prefix as the network
      prefix of the subnet delegated to an MR as the mobile network.

   Mobile Router (MR)

      RFC 5177 [RFC5177] and RFC 5944 [RFC5944] define a mobile router
      as a mobile node that can be a router that is responsible for the
      mobility of one or more entire networks moving together, perhaps
      on an airplane, a ship, a train, an automobile, a bicycle, or a
      kayak.

   Route Optimization Cache

      A Route Optimization Cache is defined as a data structure,
      maintained by MRs, containing possible destinations for route
      optimization.  The cache contains information (HoAs) on potential
      CRs and their associated mobile networks.
Top   ToC   RFC6521 - Page 8
   Return Routability (RR)

      Return routability is defined as a procedure to bind an MR's HoA
      to a CoA on a CR with a degree of trust.

   | (Concatenation)

      Some formulas in this specification use the symbol "|" to indicate
      bytewise concatenation, as in A | B.  This concatenation requires
      that all of the octets of the datum A appear first in the result,
      followed by all of the octets of the datum B.

   First (size, input)

      Some formulas in this specification use a functional form "First
      (size, input)" to indicate truncation of the "input" data so that
      only the first "size" bits remain to be used.

3. Mobile IPv4 Route Optimization between Mobile Networks

This section describes the changed functionality of the HA and the MR compared to the base NEMOv4 operation defined in [RFC5177]. The basic premise is still the same; MRs, when registering with the HA, may inform the HA of the mobile network prefixes they are managing (explicit mode), or the HA already knows the prefix assignments. However, instead of prefix <-> MR mapping information only remaining on the HA and the single MR, this information will now be distributed to the other MRs as well. Home agent-assisted route optimization is primarily intended for helping to optimize traffic patterns between multiple sites in a single organization or administrative domain; however, extranets can also be reached with optimized routes, as long as all MRs connect to the same HA. The procedure aims to maintain backward compatibility; with legacy nodes or routers, full connectivity is always preserved, even though optimal routing cannot be guaranteed. The scheme requires an MR to be able to receive messages from other MRs unsolicited -- that is, without first initiating a request. This behavior -- accepting unsolicited messages -- is similar to the registration revocation procedure [RFC3543]. Many of the mechanisms are the same, including the fact that advertising route optimization support upon registration implies the capability to receive Registration Requests and Return Routability messages from other MRs.
Top   ToC   RFC6521 - Page 9
   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 registering MR MAY request information on route-optimizable network prefixes. The MR MAY also allow redistribution of information on its managed network prefixes regardless of whether they are explicitly registered or already configured. These are indicated with a Mobile Router Route Optimization Capability Extension; see Section 5.1. If the HA accepts the request for route optimization, this is indicated with a Route Optimization Reply Extension (Section 5.2) in the Registration Reply. Note that the redistribution of network prefix information from the HA happens only during the registration signaling. There are no "routing updates" from the HA except during re-registrations triggered by handovers, registration timeouts, and specific solicitation. The solicitation re-registration MAY occur if a CR receives a Registration Request from an unknown MR (see Section 3.3.3).

3.1.1. Advertising Route-Optimizable Prefixes

As noted, an HA that supports NEMO already maintains information on which network prefixes are reachable behind specific MRs. The only change to this functionality is that this information can now be distributed to other MRs upon request. This request is implied by including a Route Optimization Capability Extension (Section 5.1) and setting the 'R' bit. When an HA receives a Registration Request, standard authentication and authorization procedures are conducted. If registration is successful and the Route Optimization Capability Extension was present in the Registration Request, the reply message MUST include the Route Optimization Reply Extension (Section 5.2) to indicate that the Route Optimization Capability Extension was understood. Furthermore, the extension also informs the MR whether NAT was detected between the HA and the MR using the procedure in RFC 3519 [RFC3519], which is based on the discrepancy between the requester's indicated CoA and the packet's source address.
Top   ToC   RFC6521 - Page 10
   The reply message MAY also include one Route Optimization Prefix
   Advertisement Extension, which informs the MR of existing mobile
   network prefixes and the MRs that manage them, if eligible for
   redistribution.  The networks SHOULD be included in order of
   priority, with the prefixes determined, by policy, as most desirable
   targets for route optimization listed first.  The extension is
   constructed as shown in Section 5.5.  The extension consists of a
   list where each MR, identified by its HoA, is listed with
   corresponding prefix(es) and their respective realm(s).

   Each network prefix can be associated with a realm [RFC4282], usually
   in the form 'organization.example.com'.  Besides the routers in the
   customer's own organization, the prefix list may also include other
   MRs, e.g., a default prefix (0.0.0.0/0) pointing toward an Internet
   gateway for Internet connectivity or additional prefixes belonging to
   possible extranets.  The realm information can be used to make policy
   decisions on the MR, such as preferring optimization within a
   specific realm only.  Furthermore, the unique realm information can
   be used to differentiate between overlapping address spaces utilized
   by the same or different organizations concurrently and adjusting
   forwarding policies accordingly.

   In a typical scenario, where network prefixes are allocated to MRs
   connecting to a single HA, the prefixes are usually either continuous
   or at least very close to each other.  Due to these characteristics,
   an optional prefix compression mechanism is provided.  Another
   optional compression scheme is in use for realm information, where
   realms often share the same higher-level domains.  These compression
   mechanisms are further explained in Section 4.

   Upon receiving a Registration Reply with a Route Optimization Prefix
   Advertisement Extension, the MR SHALL insert the MR HoAs included in
   the extension as host-prefixes to the local Route Optimization Cache
   if they do not already exist.  If present, any additional prefix
   information SHALL also be inserted into the Route Optimization Cache.

   The MR MAY discard entries from a desired starting point onward, 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 MR SHOULD use information on all advertised prefixes.
Top   ToC   RFC6521 - Page 11

3.1.2. Route Optimization Cache

MRs supporting route optimization will maintain a Route Optimization Cache. The Route Optimization Cache contains mappings between potential CR HoAs, network(s) associated with each HoA, information on reachability related to NAT and other divisions, and information related to the RR procedure. The cache is populated based on information received from the HA in Route Optimization Prefix Advertisement Extensions and in registration messages from CRs. Portions of the cache may also be configured statically. The Route Optimization Cache contains the following information for all known CRs. Note that some fields may contain multiple entries. For example, during handovers, there may be both old and new CoAs listed. CR-HoA Correspondent router's home address. Primary key identifying each CR. CR-CoA(s) Correspondent router's care-of address(es). May be empty if none known. Potential tunnel's destination address(es). MR-CoA Mobile router's care-of address currently used with this CR. Tunnel's source address. Tunnels Tunnel interface(s) associated with this CR. The tunnel interface itself handles all the necessary operations to keep the tunnel operational, e.g., sending keepalive messages required by UDP encapsulation. NAT states A table of booleans. Contains entries for all pairs of potential MR-CoAs and CR-CoAs that are known to require NAT awareness. The table is populated either statically or based on information received during operation. A setting of true indicates that the MR can establish a UDP tunnel toward the CR, using this pair of CoAs. A received advertisement can indicate that the value should
Top   ToC   RFC6521 - Page 12
      be set to false for all of the respective CR's CoAs.  Settings in
      this table affect tunnel establishment direction; see
      Section 3.3.4 and the registration procedure when deciding which
      CoAs to include in the Care-of Address Extension in the
      Registration Reply.  The existence of an entry mandates the use of
      UDP encapsulation.

   RRSTATEs

      Return routability state for each CR-HoA - MR-CoA pair.  States
      are INACTIVE, IN PROGRESS, and ACTIVE.  If state is INACTIVE, the
      RR procedure must be completed before forwarding route-optimized
      traffic.  If state is IN PROGRESS or ACTIVE, the information
      concerning this CR MUST NOT be removed from the Route Optimization
      Cache as long as a tunnel to the CR is established.

   KRms

      Registration management key for each CR-HoA - MR-CoA pair.  This
      field is only used if configured statically -- if the KRm was
      computed using the RR procedure, it is calculated in situ based on
      nonces and the router key.  If configured statically, RRSTATE is
      permanently set to ACTIVE.

   Care-of nonce indices

      If the KRm was established with the RR procedure, contains the
      care-of nonce index for each MR-CoA - CR-HoA pair.

   Care-of keygen token

      If the KRm was established with the RR procedure, contains the
      care-of keygen token for each MR-CoA - CR-HoA pair.

   Home nonce indices

      If the KRm was established with the RR procedure, contains the
      Home nonce index for each CR-HoA.

   Home keygen token

      If the KRm was established with the RR procedure, contains the
      home keygen token for each CR-HoA.
Top   ToC   RFC6521 - Page 13
   Network prefixes

      A list of destination network prefixes reachable via this CR.
      Includes network and prefix length, e.g., 192.0.2.0/25.  Always
      contains at least a single entry: the CR-HoA host network prefix
      in the form of 192.0.2.1/32.

   Realms

      Each prefix may be associated with a realm.  May also be empty, if
      the realm is not provided by advertisement or configuration.

   Prefix_Valid

      Boolean field for each prefix - CR-HoA pair, which is set to true
      if this prefix's owner has been confirmed.  The host network
      prefix consisting of the CR itself does not need validation beyond
      the RR procedure.  For other prefixes, the confirmation is done by
      soliciting the information from the HA.  Traffic for prefixes that
      have unconfirmed ownership should not be routed through the
      tunnel.

   Information that is no longer valid due to expirations or topology
   changes MAY be removed from the Route Optimization Cache as desired
   by the MR.

3.2. Return Routability Procedure

The purpose of the RR procedure is to establish CoA <-> HoA bindings in a trusted manner. The RR procedure for Mobile IPv6 is described in [RFC6275]. The same principles apply to the Mobile IPv4 version: two messages are sent to the CR's HoA -- one via the HA using the MR's HoA, and the other directly from the MR's CoA, with two responses coming through the same routes. The 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). The RR procedure is a method provided by Mobile IP to establish the KRm in a relatively lightweight fashion. If desired, the KRms can be configured on MRs statically, or by using a desired external secure key provisioning mechanism. If KRms are known to the MRs via some other mechanism, the RR procedure can be skipped. Such provisioning mechanisms are out of scope for this document.
Top   ToC   RFC6521 - Page 14
   The main assumption on traffic patterns is that the MR that initiates
   the RR procedure can always send outbound messages, even when behind
   a NAT or firewall.  This basic assumption made for NAT Traversal in
   [RFC3519] is also applicable here.  In the case where the CR is
   behind such obstacles, it receives these messages via the reverse
   tunnel to the CR's HoA; thus, any problem regarding the CR's
   connectivity is addressed during registration with the HA.

   The RR procedure consists of four Mobile IP messages: Home Test Init
   (HoTI), Care-of Test Init (CoTI), Home Test (HoT), and Care-of Test
   (CoT).  They are constructed as shown in Sections 5.6 through 5.9.
   If the MR has included the Mobile Router Route Optimization
   Capability Extension in its Registration Request, it MUST be able to
   accept Return Routability messages.  The messages are delivered as
   Mobile IP signaling packets.  The destination address of the HoTI and
   CoTI messages is set to the CR's HoA, with the sources being the MR's
   HoA and CoA, respectively.

   The RR procedure begins with the MR sending HoTI and CoTI messages,
   each containing a (different) 64-bit random value -- the cookie.  The
   cookie is used to bind a specific signaling exchange together.

   Upon receiving the HoTI or CoTI message, the CR MUST have a secret
   correspondent router key (Kcr) and nonce.  If it does not have this
   material yet, it MUST produce it before continuing with the RR
   procedure.

   The CR responds to HoTI and CoTI messages by constructing HoT and CoT
   messages, respectively, as replies.  The HoT message contains a home
   init cookie, current home nonce index, and home keygen token.  The
   CoT message contains a care-of init cookie, current care-of nonce
   index, and care-of keygen token.

   The home keygen token is constructed as follows:

   Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address |
      nonce | 0)))

   The care-of keygen token is constructed as follows:

   Care-of keygen token = First (64, HMAC_SHA1 (Kcr, (care-of address |
      nonce | 1)))

   Note that the CoA in this case is the source address of the received
   CoTI message packet.  The address may have changed in transit due to
   network address translation.  This does not affect the registration
   process; subsequent Registration Requests are expected to arrive from
   the same translated address.
Top   ToC   RFC6521 - Page 15
   The RR procedure SHOULD be initiated when the Route Optimization
   Cache's RRSTATE field for the desired CoA with the target CR is
   INACTIVE.  If the state was INACTIVE, the state MUST be set to IN
   PROGRESS when the RR procedure is initiated.  In the case of a
   handover occurring, the MR SHOULD only send a CoTI message to obtain
   a new care-of keygen token; the home keygen token may still be valid.
   If the reply to a registration indicates that one or both of the
   tokens have expired, the RRSTATE MUST be set to INACTIVE.  The RR
   procedure may then be restarted as needed.

   Upon completion of the RR procedure, the Route Optimization Cache's
   RRSTATE field is set to ACTIVE, allowing for Registration Requests to
   be sent.  The MR will establish a KRm.  By default, this will be done
   using the SHA1 hash algorithm, as follows:

   KRm = SHA1 (home keygen token | care-of keygen token)

   When de-registering (by setting the Registration Request's lifetime
   to zero), the care-of keygen token is not used.  Instead, the KRm is
   generated as follows:

   KRm = SHA1 (home keygen token)

   As in Mobile IPv6, the CR does not maintain any state for the MR
   until after receiving a Registration Request.

3.2.1. Router Keys

Each MR maintains a Kcr, which MUST NOT be shared with any other entity. The Kcr is used for authenticating peer MRs in the situation where an MR is acting as a CR. This is analogous to the node key (Kcn) in Mobile IPv6. A CR uses its router key to verify that the keygen tokens sent by a peer MR in a Registration Request are the CR's own. The router key MUST be a random number, 16 octets in length, generated with a good random number generator [RFC4086]. The MR MAY generate a new key at any time to avoid persistent key storage. If desired, it is RECOMMENDED that the keys be expired in conjunction with nonces; see Section 3.2.3.

3.2.2. Nonces

Each MR also maintains one or more indexed nonces. Nonces SHOULD be generated periodically with a good random number generator [RFC4086]. The MR may use the same nonces with all MRs. Nonces MAY be of any length, with the RECOMMENDED length being 64 bits.
Top   ToC   RFC6521 - Page 16

3.2.3. Updating Router Keys and Nonces

The router keys and nonce updating guidelines are similar to those for Mobile IPv6. MRs keep both the current nonce and the small set of valid previous nonces whose lifetimes have not expired yet. A nonce should remain valid for at least MAX_TOKEN_LIFETIME seconds (see Section 9) after it has first been used in constructing an RR response. However, the CR MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 9) after the first use. As the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds. The node can then continue to accept keygen tokens that have been based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This results in keygen tokens being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30-second period. Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This is possible as long as the correspondent node keeps track of how long ago the nonces were used for the first time and does not generate new nonces on every return routability request. If the Kcr is being updated, the update SHOULD be done at the same time as the nonce is updated. This way, nonce indexes can be used to refer to both Kcrs and nonces.

3.3. Mobile-Correspondent Router Operations

This section deals with the operation of mobile and correspondent routers performing route optimization. Note that in the context of this document, all routers work as both MR and CR. The term "mobile router" applies to the router initiating the route optimization procedure, and "correspondent router" indicates the peer router. There are two issues regarding IPv4 that are different when compared to Mobile IPv6 route optimization. First of all, since Mobile IPv4 always uses tunnels, there must be a tunnel established between the MR's and the CR's CoAs. The CR learns of the MR's CoA, because it is included in the Registration Request. The MR learns the CR's CoA via a new extension, "Care-of Address", in the Registration Reply. The second issue is a security consideration: In a Registration Request, the MR claims to represent an arbitrary IPv4 network. If the CR has not yet received this information (HoA <-> network prefix), it SHOULD perform a re-registration with the HA to verify the claim.
Top   ToC   RFC6521 - Page 17
   An additional aspect is that the MR MAY use a different CoA for
   different CRs (and the HA).  This is useful in situations where the
   network provides only partial-mesh connectivity and specific
   interfaces must be used to reach specific destinations.  In addition,
   this allows for load balancing.

3.3.1. Triggering Route Optimization

Since each MR knows the eligible route-optimizable networks, the route optimization between all CRs can be established at any time; however, a better general practice is to conduct route optimization only on demand. It is RECOMMENDED that route optimization be started only when sending a packet that originates from a local managed network (and if the network is registered as route optimizable) and whose destination address falls within the network prefixes of the Route Optimization Cache. With a small number of MRs, such on-demand behavior may not be necessary, and full-mesh route optimization may be in place constantly.

3.3.2. Mobile Router Routing Tables

Each MR maintains a routing table. In a typical situation, the MR has one or more interface(s) to the local networks, one or more interface(s) to wide-area networks (such as those provided by ISPs), and a tunnel interface to the HA. Additional tunnel interfaces become activated as route optimization is being performed. The routing table SHOULD typically contain network prefixes managed by CRs associated with established route-optimized tunnel interfaces. A default route MAY point to the reverse tunnel to the HA if not overridden by prefix information. The routing table MAY also include additional routes if required by the tunneling implementation. The routes for the HoAs of any CRs SHOULD also be pointing toward their respective tunnels that are using the optimized path. If two 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 addresses SHOULD be considered an error situation. Any aggregation for routes in private address space SHOULD be conducted only at the HA.
Top   ToC   RFC6521 - Page 18

3.3.3. Inter-Mobile Router Registration

If route optimization between an MR and a CR is desired, either the RR procedure must have been performed (see Section 3.2), or the KRm must be pre-shared between the MR and the CR. If either condition applies, an MR MAY send a Registration Request to the CR's HoA from the desired interface. The Registration Request's Source Address and Care-of Address fields are set to the address of the desired outgoing interface on the MR. The address MAY be the same as the CoA used with the HA. The Home Agent field is set to the HA of the MR. The Registration Request MUST be sent to (have a destination address of) the HoA of the CR. The Registration Request MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and SHOULD include a Mobile Network Request Extension (defined in [RFC5177]). If present, the Mobile Network Request Extension MUST contain the network prefixes, as if registering in explicit mode. If timestamps are used, the CR MUST check the Identification field for validity. The Authenticator field is hashed with the KRm. The CR replies to the request with a Registration Reply. The Registration Reply MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and, if a Mobile Network Request Extension was present in the request, a Mobile Network Acknowledgement Extension. The encapsulation can be set as desired, except in the case where the Route Optimization Cache Entry has NAT entries for the CR, or the MR itself is known to be behind a NAT or firewall. If either condition applies, the Registration Request MUST specify UDP encapsulation. It is RECOMMENDED that UDP encapsulation always be used to facilitate detection of path failures via a keepalive mechanism. The CR first checks the Registration Request's authentication against Kcr and nonce indexes negotiated during the RR procedure. This ensures that the Registration Request is coming from a valid MR. If the check fails, an appropriate Registration Reply code is sent (see Section 10). If the failure is due to the nonce index expiring, the MR sets RRSTATE for the CR to INACTIVE. The RR procedure MAY then be initiated again. If the check passes, the CR MUST then check its Route Optimization Cache to determine whether the MR exists and is associated with the prefixes included in the request (i.e., whether prefixes are present
Top   ToC   RFC6521 - Page 19
   and the 'HA' flag is true for each prefix).  Note that the viewpoint
   is always local; the CR compares CR-HoA entries against the MR's HoA
   -- from the CR's perspective, the MR is also a "correspondent
   router".

   If the check against the cache fails, the CR SHOULD send a
   re-Registration Request to the HA with the 'S' (solicitation) bit
   set, thus obtaining the latest information on network prefixes
   managed by the incoming MR.  If, even after this update, the prefixes
   still don't match, the reply's Mobile Network Acknowledgement code
   MUST be set to "MOBNET_UNAUTHORIZED".  The registration MAY also be
   rejected completely.  This verification is done to protect against
   MRs claiming to represent arbitrary networks; however, since the HA
   is assumed to provide trusted information, it can authorize the MR's
   claim.  If the environment itself is considered trusted, the CR can,
   as a policy, accept registrations without this check; however, this
   is NOT RECOMMENDED as a general practice.

   If the prefixes match, the CR MAY accept the registration.  If the CR
   chooses to accept, the CR MUST check to determine if a tunnel to the
   MR already exists.  If the tunnel does NOT exist or has wrong
   endpoints (CoAs), a new tunnel MUST be established and the Route
   Optimization Cache updated.  The reply MUST include a list of
   eligible CoAs (see Section 5.4) with which the MR may establish a
   tunnel.  The reply MUST also include the Mobile-Correspondent
   Authentication Extension (see Section 5.3).

   Upon receiving the Registration Reply, the MR MUST check to determine
   if a tunnel to the CR already exists.  If the tunnel does NOT exist
   or has wrong endpoints (CoAs), a new tunnel MUST be established and
   the Route Optimization Cache updated.  This is covered in detail in
   Section 3.3.4.

   The CR's routing table MUST be updated to indicate that the MR's
   networks are reachable via the direct tunnel to the MR.

   After the tunnel is established, the MR MAY update its routing tables
   to reach all of the CR's Prefixes via the tunnel, although it is
   RECOMMENDED that time be given for the CR to perform its own,
   explicit registration.  This is primarily a policy decision,
   depending on the network environment.  See Section 6.5.

   Due to the fact that the route optimization procedures may occur
   concurrently at both MRs, each working as each other's CR, 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
   HoA (meaning a normal 32-bit integer comparison treating IPv4
   addresses as 32-bit unsigned integers) receives a Registration
Top   ToC   RFC6521 - Page 20
   Request (in the CR role) while its own Registration Request (sent in
   the MR role) is pending, the attempt should be accepted with reply
   code "concurrent registration" (Value 2).  If receiving such an
   indication, the recipient SHOULD consider the registration a success
   but only act on it once the peer has completed its own registration.

3.3.4. Inter-Mobile Router Tunnels

Inter-MR tunnel establishment follows establishing standard reverse tunnels to the HA. The Registration Request to the CR includes information on the desired encapsulation. It is RECOMMENDED that UDP encapsulation be used. In the cases of Generic Router Encapsulation (GRE) [RFC2784], IP over IP [RFC2003], or minimal encapsulation [RFC2004], no special considerations regarding 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 CR is its CoA, not the HoA where the Registration Requests were sent. This is different from the creation of the reverse tunnel to the HA, which reuses the channel from registration signaling. Special considerations rise from using UDP encapsulation, especially in cases where one of the MRs is located behind a NAT or firewall. A deviation from RFC 3519 [RFC3519] is that keepalives should be sent from both ends of the tunnel to detect path failures after the initial keepalive has been sent -- this allows both the MR and CR to detect path failures. The initial UDP keepalive SHOULD be sent by the MR. Only after the first keepalive is successfully completed SHOULD the tunnel be considered eligible for traffic. If a reply to the initial keepalive is not received, the MR may opt to attempt sending the keepalive to other CoAs provided by the Registration Reply to check whether they provide better connectivity; or, if all of these fail, the MR may perform a re-registration via an alternative interface, or deregister completely. See Section 6.1. Once the initial keepalive packet has reached the CR and a reply has been sent, the CR MAY start sending its own keepalives. The original specification for UDP encapsulation suggests a keepalive interval default of 110 seconds. However, to provide fast response time and switching to alternate paths, it is RECOMMENDED, if power and other constraints allow, that considerably shorter periods be used, adapting to the perceived latency as needed. However, the maximum amount of keepalives SHOULD at no point exceed
Top   ToC   RFC6521 - Page 21
   MAX_UPDATE_RATE times per second.  The purpose of the keepalive is
   not to keep NAT or firewall mappings in place but to serve as a
   mechanism to provide fast response in case of path failures.

   If both the MR and the CR are behind separate NATs, route
   optimization cannot be performed between them.  Possible ways to set
   up mutual tunneling when both routers are behind NATs are outside the
   scope of this document.  However, some of these issues are addressed
   in Section 6.1.

   The designations "MR" and "CR" only apply to the initial tunnel
   establishment phase.  Once a tunnel is established between two
   routers, either of them can opt to either tear down the tunnel or
   perform a handover.  Signaling messages have to be authenticated with
   a valid KRm.

3.3.5. Constructing Route-Optimized Packets

All packets received by the MR are forwarded using normal routing rules according to the routing table. There are no special considerations when constructing the packets; the tunnel interface's own processes will encapsulate any packet automatically.

3.3.6. Handovers and Mobile Routers Leaving Network

Handovers and connection breakdowns can be categorized as either ungraceful or graceful, also known as "break-before-make" (bbm) and "make-before-break" (mbb) situations. As with establishment, the "mobile router" discussed here is the router wishing to change connectivity state, with the "correspondent router" being the peer. When an MR wishes to join its home link, it SHOULD, in addition to sending the Registration Request to the HA with lifetime set to zero, also send such a request to all known CRs, to their HoAs. The CR(s), upon accepting this request and sending the reply, will check whether the Route Optimization Cache contains any prefixes associated with the requesting MR. These entries should be removed and the routing table updated accordingly (traffic for the prefixes will be forwarded via the HA again). The tunnel MUST then be destroyed. A short grace period SHOULD be used to allow possible in-transit packets to be received correctly. In the case of a handover, the CR simply needs to update the tunnel's destination to the MR's new CoA. The MR SHOULD keep accepting packets from both old and new CoAs for a short grace period, typically on the order of ten seconds. In the case of UDP
Top   ToC   RFC6521 - Page 22
   encapsulation, it is RECOMMENDED that the same port numbers be used
   for both registration signaling and tunneled traffic, if possible.
   The initial keepalive message sent by the MR will verify that direct
   connectivity exists between the MR and CR -- if the keepalive fails,
   the MR SHOULD attempt alternate paths.

   If the MR was unable to send the re-Registration Request before
   handover, it MUST send it immediately after handover has been
   completed and a tunnel with the HA is established.  Since the
   changing of CoA(s) invalidates the KRm, it is RECOMMENDED that
   partial return routability be conducted by sending a CoTI message via
   the new CoA and obtaining a new care-of keygen token.  In all cases,
   necessary tokens also have to be acquired if the existing tokens have
   expired.

   If a reply is not received for a Registration Request to a CR, any
   routes to the network prefixes managed by the CR MUST be removed from
   the routing table, thus causing the user traffic to be forwarded via
   the HA.

3.4. Convergence and Synchronization Issues

The information the HA maintains on mobile network prefixes and the MRs' Route Optimization Caches does not need to be explicitly synchronized. This is based on the assumption that at least some of the traffic between nodes inside mobile networks is always bidirectional. If using on-demand route optimization, this also implies that when a node in a mobile network talks to a node in another mobile network, if the initial packet does not trigger route optimization, the reply packet will. Consider a situation with three mobile networks, A, B, and C, handled by three mobile routers, MR A, MR B, and MR C, respectively. If they register with an HA in this order, the situation goes as follows: MR A registers and receives no information on other networks from the HA, as no other MR has registered yet. MR B registers and receives information on mobile network A being reachable via MR A. MR C registers and receives information on both of the other mobile networks. If a node in mobile network C is about to send traffic to mobile network A, the route optimization is straightforward; MR C already has network A in its Route Optimization Cache. Thus, packet transmission triggers route optimization toward MR A. When MR C
Top   ToC   RFC6521 - Page 23
   registers with MR A (after the RR procedure is completed), MR A does
   not have information on mobile network C; thus, it will perform a
   re-registration with the HA on demand.  This allows MR A to verify
   that MR C is indeed managing network C.

   If a node in mobile network B sends traffic to mobile network C, MR B
   has no information on network C.  No route optimization is triggered.
   However, when the node in network C replies and the reply reaches MR
   C, route optimization happens as above.  Further examples of
   signaling are in Section 8.

   Even in the very rare case of completely unidirectional traffic from
   an entire network, re-registrations with the HA caused by timeouts
   will eventually cause convergence.  However, this should be treated
   as a special case.

   Note that all MRs are connected to the same HA.  For possibilities
   concerning multiple HAs, see Section 6.4.



(page 23 continued on part 2)

Next Section