[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 draft-ietf-mip4-nemo-haaro

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 17, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   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

   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

   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

2.  Terms and definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

   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.

   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 ( 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

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.  Always contains at least a single
             entry, the CR-HoA host prefix in the form of

   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.

   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

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

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

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

   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

   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

   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. and, 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

   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

   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

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

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

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

   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

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

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

   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

              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

   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

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Makela & Korhonen        Expires March 17, 2008                [Page 27]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/