[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [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: August 25, 2008                                    Feb 22, 2008


  Home Agent assisted Route Optimization between Mobile IPv4 Networks
                    draft-makela-mip4-nemo-haaro-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes a Home Agent assisted route optimization
   extension to IPv4 Network Mobility Protocol.









Makela & Korhonen        Expires August 25, 2008                [Page 1]


Internet-Draft                    HAaRO                         Feb 2008


Table of Contents

   1.  Introduction and motivations . . . . . . . . . . . . . . . . .  4
   2.  Terms and definitions  . . . . . . . . . . . . . . . . . . . .  6
   3.  Mobile IPv4 route optimization between mobile networks . . . .  7
     3.1.  Maintaining route optimization information . . . . . . . .  8
       3.1.1.  Advertising route-optimizable prefixes . . . . . . . .  8
       3.1.2.  Route Optimization cache . . . . . . . . . . . . . . .  9
       3.1.3.  Correspondent Router Mobility Bindings . . . . . . . . 10
     3.2.  Return routability procedure . . . . . . . . . . . . . . . 10
       3.2.1.  Router keys  . . . . . . . . . . . . . . . . . . . . . 11
       3.2.2.  Nonces . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Mobile-Correspondent Router operations . . . . . . . . . . 12
       3.3.1.  Triggering Route Optimization  . . . . . . . . . . . . 12
       3.3.2.  Mobile Router routing tables . . . . . . . . . . . . . 13
       3.3.3.  Inter-Mobile Router registration . . . . . . . . . . . 13
       3.3.4.  Inter-Mobile Router tunnels  . . . . . . . . . . . . . 14
       3.3.5.  Constructing route-optimized packets . . . . . . . . . 15
       3.3.6.  Handovers and Mobile Routers leaving network . . . . . 15
     3.4.  Convergence and synchronization issues . . . . . . . . . . 16
   4.  Data compression schemes . . . . . . . . . . . . . . . . . . . 17
     4.1.  Prefix compression . . . . . . . . . . . . . . . . . . . . 17
     4.2.  Realm compression  . . . . . . . . . . . . . . . . . . . . 19
   5.  New Mobile IPv4 messages and extensions  . . . . . . . . . . . 22
     5.1.  Route optimization prefix advertisement  . . . . . . . . . 22
     5.2.  Mobile router Route optimization capability  . . . . . . . 23
     5.3.  Home-Test Init message . . . . . . . . . . . . . . . . . . 24
     5.4.  Care-of-Test Init message  . . . . . . . . . . . . . . . . 24
     5.5.  Home Test message  . . . . . . . . . . . . . . . . . . . . 25
     5.6.  Care-of test message . . . . . . . . . . . . . . . . . . . 26
     5.7.  Mobile-Correspondent authentication extension  . . . . . . 26
     5.8.  Care-of address Extension  . . . . . . . . . . . . . . . . 27
   6.  Special Considerations . . . . . . . . . . . . . . . . . . . . 27
     6.1.  NATs and stateful firewalls  . . . . . . . . . . . . . . . 27
     6.2.  Foreign Agents . . . . . . . . . . . . . . . . . . . . . . 28
     6.3.  Multiple Home Agents . . . . . . . . . . . . . . . . . . . 28
     6.4.  Mutualness of Route Optimization . . . . . . . . . . . . . 29
     6.5.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . 29
   7.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . . . 30
   8.  Example signaling scenarios  . . . . . . . . . . . . . . . . . 30
     8.1.  Registration request . . . . . . . . . . . . . . . . . . . 31
     8.2.  Route optimization with return routability . . . . . . . . 31
     8.3.  Handovers  . . . . . . . . . . . . . . . . . . . . . . . . 33
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 35
     10.1. Trust relationships  . . . . . . . . . . . . . . . . . . . 35
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35



Makela & Korhonen        Expires August 25, 2008                [Page 2]


Internet-Draft                    HAaRO                         Feb 2008


     12.1. Normative References . . . . . . . . . . . . . . . . . . . 35
     12.2. Informative References . . . . . . . . . . . . . . . . . . 36
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 37















































Makela & Korhonen        Expires August 25, 2008                [Page 3]


Internet-Draft                    HAaRO                         Feb 2008


1.  Introduction and motivations

   Traditionally, there has been no method for route optimization in
   Mobile IPv4 [RFC3344].  Unlike Mobile IPv6 [RFC3775], where route
   optimization has been included from the start, Mobile IPv4 route
   optimization hasn't been addressed in a generalized scope.

   Even though general route optimization may not be of interest in IPv4
   world, there are still specific applications for route optimization
   in Mobile IPv4.  This draft proposes method to optimize routes
   between mobile networks behind mobile routers, as defined by NEMO
   [I-D.ietf-mip4-nemo-v4-base].

   From service provider perspective a common topology for enterprise
   customer network consists of one to several sites (typically
   headquarters and various branch offices).  These sites are typically
   connected via various Layer 2 technologies (ATM or Frame relay PVCs),
   MPLS VPNs or Layer 3 site-to-site VPNs.

   Recently, a trend has emerged where customers prefer to maintain
   connectivity via multiple service providers.  Reasons include
   redundancy, reliability and availability issues.  These kinds of
   multi-homing scenarios have traditionally been solved by using such
   technologies as multihoming BGP.  However, a more lightweight
   solution is desirable.

   Mobile IP, especially mobile routers, can accommodate for this.  The
   customer becomes a client of a virtual service provider, which does
   not take part in the actual access technology.  The service provider
   has a backend system and an IP pool that it distributes to customers.
   The drawback of this solution is that it creates a star topology; All
   Mobile IP tunnels end up at the service provider hosted home agent,
   causing heavy load at the backend.  Route optimization between mobile
   networks addresses this issue, by taking network load off the home
   agent and the backend.

   An example network is pictured below:














Makela & Korhonen        Expires August 25, 2008                [Page 4]


Internet-Draft                    HAaRO                         Feb 2008


           +----------------------------+
           |  Virtual Operator Backend  |
           +------------+         +-----+
           | Home Agent |         | AAA |
           +------------+---------+-----+
                        |
                      .--.
                    _(.   `)
                  _(   ISP `)_
                 (   Peering  `)
                ( `  . Point )  )
                 `--(_______)--'
           ____ /     |         \
          /           |          \
       .--.         .--.         .--.
     _(    `.     _(    `.     _(    `.
    (  ISP A )   (  ISP B )   (  ISP C )
   ( `  .  )  ) ( `  .  )  ) ( `  .  )  )
    `--(___.-'   `--(___.-'   `--(___.-'
        |     ______/    \       /
        |    /            \     /
        |   /              \   /
      +----+               +----+
      |MR A|               |MR B|
      +----+               +----+
        |                    |
       .--.                 .--.
     _(    `.             _(    `.
    ( Site A )           ( Site B )
   ( `  .  )  )         ( `  .  )  )
    `--(___.-'           `--(___.-'

            Virtual service provider architecture using NEMOv4

   In this case, organization network consists of two sites, that are
   connected via 2 ISPs for redundancy reasons.  Mobile IP allows fast
   handovers without problematics of multi-homing and BGP peering
   between each individual ISP and the organization.  The traffic
   however takes a non-optimal route through the virtual operator
   backend.

   Route optimization would address this issue, allowing traffic between
   Sites A and B to flow through ISP B's network, or in case of a link
   failure, via the ISP peering point (such as MAE-WEST).  The backend
   will not suffer from heavy loads.

   The primary design goal is to limit the load to the backend to
   minimum.  Additional design goals include extensibility to a more



Makela & Korhonen        Expires August 25, 2008                [Page 5]


Internet-Draft                    HAaRO                         Feb 2008


   generalized scope, beyond the need of a single, coordinating Home
   Agent.


2.  Terms and definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Home Agent (HA)

        Mobile IPv4 Home Agent

   Mobile Router (MR)

        Nemov4 Mobile Router

   Home Address (HoA)

        Mobile Router's home address

   Care-of Address (CoA)

        Mobile Router's Care-of Address.  Address serving as the current
        attachment point.

   Correspondent Router (CR)

        Nemov4 Mobile Router which is destination for a Mobile network-
        initiated flow.

   Mobile Network

        Network managed by a Mobile Router

   Route Optimization Cache

        Data structure held by Mobile Routers on Route Optimizable
        destinations.

   Route Optimization activation

        Procedure consisting of Return Routability check, registration,
        setting up tunnels (if necessary) and starting to route traffic
        along the tunnel.





Makela & Korhonen        Expires August 25, 2008                [Page 6]


Internet-Draft                    HAaRO                         Feb 2008


   Host Prefix

        Prefix with the mask of /32. eg. 192.0.2.254/32.

   Return Routability, RR

        Procedure to bind a Mobile Router's Home Address to a Care-of
        address on a Correspondent Router

   Mobility Binding

        The association of Home Address with a Care-of address, along
        with the lifetime remaining for that association, maintained by
        Home Agents and Correspondent Routers.

   Mobility Session

        Active connection to Home Agent and Correspondent Routers,
        maintained by Mobile Routers.


3.  Mobile IPv4 route optimization between mobile networks

   This section describes the changed functionality of Home Agent and
   Mobile Router compared to the base NEMOv4 operation defined in NEMO-
   base [I-D.ietf-mip4-nemo-v4-base].  The basic premise is still the
   same; Mobile Routers, when registering, inform the Home Agent of the
   mobile networks they are managing; However, instead of only remaining
   on the Home Agent this information will now be distributed to the
   Mobile Routers as well.

   The Home Agent-assisted route optimization is primarily intended for
   helping to optimize traffic patterns between multiple sites in an
   single organization or administrative domain; However, extranets can
   also be reached with optimized routes, as long as all Mobile Routers
   connect to the same Home Agent.  The procedure aim to maintain
   backwards compatibility; With legacy nodes or routers full
   connectivity is always preserved even though optimal routing cannot
   be guaranteed.

   The schema requires a Mobile Router to be able to receive messages
   from Home Agent and other Mobile Routers unsolicited - that is,
   without first initiating a request.  This behavior is similar to the
   registration revocation procedure [RFC3543].  Many of the mechanisms
   are same - including the fact that advertising route optimization
   support upon registration implies capability to receive registration
   requests and return routability messages from other Mobile Routers.




Makela & Korhonen        Expires August 25, 2008                [Page 7]


Internet-Draft                    HAaRO                         Feb 2008


   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 5.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 5.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 MAY include
   one 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 5.1.
   The extension consists of a list where each Mobile Router is listed
   with according prefix(es) and their respective realm(s).

   Each network prefix can be associated to a realm, usually of form
   '@organization.example.com'.  Besides the routers in customer's own
   organization, the prefix list may also include other Mobile Routers,
   e.g. default prefix (0.0.0.0/0) pointing towards Internet gateway for
   Internet connectivity, and possible extranets.  The realm information
   can be used to make policy decisions on the Mobile Router, such as
   preferring optimization within specific realm only.




Makela & Korhonen        Expires August 25, 2008                [Page 8]


Internet-Draft                    HAaRO                         Feb 2008


   In common scenarios, where prefixes are allocated to Mobile Routers
   connecting to a single Home Agent, the prefixes are usually either
   continuous or at least very close to each other.  Due to these
   qualities, a prefix compression mechanism is provided.  A similar
   schema is in use for realm information, where realms often share same
   higher-level domains.  These compression mechanisms are further
   examined in Section 4.

   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 they are included, any additional
   prefixes information SHALL also be inserted to the Route Optimization
   Cache.

   The Mobile Router MAY discard entries from a desired starting point
   onwards, due to memory or other policy related constraints.  The
   intention of listing the prefixes in order of priority is to provide
   implicit guidance for this decision.  If the capacity of the device
   allows, the Mobile Router SHOULD use information on all advertised
   prefixes.

3.1.2.  Route Optimization cache

   Mobile routers supporting route optimization will maintain a Route
   Optimization Cache.

   The Route Optimization Cache contains mappings between Correspondent
   Router HoA's, network(s) associated with each HoA and return
   routability procedure status.

   The Route Optimization Cache contains the following information for
   all Correspondent Routers:

   CR-HoA    Correspondent Router's Home Address.

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

   Realm     Destination realm.  May be empty, if realm is not provided
             by advertisement or configuration.

   NAT       The Correspondent Router is behind NAT/Firewall as seen
             from HA.  Set if 'O' bit is set in the received
             advertisement.  Affects tunnel establishment, see
             Section 3.3.4.  Also mandates use of UDP encapsulation.



Makela & Korhonen        Expires August 25, 2008                [Page 9]


Internet-Draft                    HAaRO                         Feb 2008


   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 .

   KRm       Registration management key.  Either established via return
             routability procedure or configured statically.  If
             configured statically, RRSTATE is permanently set to
             ACTIVE.

   HA        HA bit is set if this entry is learned from HA.  This
             implies that the entry can be trusted.  If not set, the
             entry has been learned from another Mobile Router and not
             yet verified from HA.  The entry may still be maintained
             while awaiting verification.

3.1.3.  Correspondent Router Mobility Bindings

   Each Correspondent Router will maintain Mobility Bindings, in a
   similar way to the Home Agent.

   The Mobility Binding for each Mobile Router contains

   HoA       Mobile Router's Home Address

   CoA       Mobile Router's Care-of Address

   Prefixes  A list of destination prefixes bound to this Mobile Router.
             Includes the Mobile Router itself as a host prefix, e.g.
             192.0.2.1/32.

   Realm     Destination realm.  May be empty, if realm not provided by
             advertisement or configuration.

   Tunnel    Tunnel interface associated with the Mobile Router.  The
             tunnel interface itself handles all the necessary
             operations to keep the tunnel operational, e.g. sends UDP
             keepalives.

3.2.  Return routability procedure

   The return routability procedure for Mobile IPv6 is described in
   [RFC3775].  Same principles apply to the Mobile IPv4 version: Two
   messages are sent to Correspondent Router's Home Address, one via
   Home Agent and the other directly from the Mobile Router CoA, with
   two responses coming through same routes.  Registration management



Makela & Korhonen        Expires August 25, 2008               [Page 10]


Internet-Draft                    HAaRO                         Feb 2008


   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 Return Routability procedure is a method provided by Mobile IP
   protocol to establish the KRm in a relatively lightweight fashion.
   If desired, the KRm's can be configured to Mobile Routers statically,
   or using an appropriate secure key provisioning mechanism.  If KRm's
   are known to the Mobile Routers via some other mechanism, Return
   Routability procedure can be skipped.  Such provisioning mechanisms
   are out of scope for this document.

   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
   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 5.3 through



Makela & Korhonen        Expires August 25, 2008               [Page 11]


Internet-Draft                    HAaRO                         Feb 2008


   Section 5.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.

   Upon completion of Return Routability procedure, the Routing
   Optimization Cache's RRSTATE field is set to ACTIVE.  The Mobile
   Router will establish a registration management key KRm:

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

   Like in Mobile IPv6, the Correspondent Router does not maintain any
   state for the Mobile Router until after receiving a registration
   request.

3.3.  Mobile-Correspondent Router operations

   This section deals with the operation of Mobile and Correspondent
   Routers performing route optimization.  Note that in a typical case
   all routers work as both Mobile Router and Correspondent Router.

   Especially compared to Mobile IPv6 route optimization there are two
   issues that are different regarding IPv4.  First of all, since Mobile
   IPv4 always uses tunnels, there must be a tunnel established between
   MR and CR's Care-of addresses.  This is accomplished with a new
   extension, "Care-of Address", in registration reply.  Second issue is
   rising from security standpoint: In a registration request, the
   Mobile Router claims to represent an arbitrary 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



Makela & Korhonen        Expires August 25, 2008               [Page 12]


Internet-Draft                    HAaRO                         Feb 2008


   established at any time; However a better general practice is to
   conduct Route Optimization activation on-demand only.  Route
   optimization SHOULD only be started when receiving a packet where
   destination address is local (and the subnet is registered as route
   optimizable) and source address exists in the Route Optimization
   Cache.

3.3.2.  Mobile Router routing tables

   Each Mobile Router maintains a routing table.  In a typical
   situation, it contains interface(s) to the local networks, interface
   to wide-area network (such as ISP), and a tunnel interface to the
   Home Agent.  Additional entries consist of route-optimized tunnel
   interfaces and networks associated with each tunnel.

3.3.3.  Inter-Mobile Router registration

   If route optimization between Mobile Router and Correspondent Router
   is desired, either Return Routability procedure must have been
   performed ( See Section 3.2), or key KRm must be pre-shared between
   the Mobile and Correspondent Router.  If a known KRm exists, 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 5.7 and Mobile Network Request Extension defined
   in [I-D.ietf-mip4-nemo-v4-base].  If timestamps are used, the
   Correspondent Router MUST check the identification field for
   validity.  The registration request MUST include Home Address.  The
   Authenticator field is hashed with the key KRm.

   The encapsulation can be set as desired, except in the case where the
   Correspondent Router's Route Optimization Cache Entry has NAT set or
   the Mobile Router itself is behind NAT or firewall.  If either of the
   conditions apply, registration request MUST specify UDP
   encapsulation.

   The Correspondent Router first checks the registration request's
   authentication against Kcr and nonce indexes negotiated during Return
   Routability procedure.  This ensures that the registration request is
   coming from a correct Mobile Router.  If the check passes, the
   Correspondent Router MUST check whether the Mobile Router already
   exists in it's Route Optimization Cache and is linked with the
   prefixes included in the request.

   If the prefixes don't match, the Correspondent Router SHOULD send a



Makela & Korhonen        Expires August 25, 2008               [Page 13]


Internet-Draft                    HAaRO                         Feb 2008


   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 arbitrary networks; However,
   since Home Agent provides trusted information, it can authorize
   Mobile Router's claim.  If the network is considered trusted, the
   Correspondent Router can, as a policy, accept registrations from
   without this check; however, this is NOT RECOMMENDED as a general
   practice.

   If the prefixes match, the Correspondent Router MAY accept the
   registration.  Upon receiving the registration reply, the Mobile
   Router MUST check if a tunnel to the Mobile Router already exists.
   Otherwise a tunnel MUST be established and Mobility Binding updated.
   This is covered in Section 3.3.4.

   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 6.4.

3.3.4.  Inter-Mobile Router tunnels

   Inter-Mobile Router tunnel establishment follows establishing
   standard reverse tunnels to the Home Agent.  The registration request
   to Correspondent Router includes information on the desired
   encapsulation.  In the case of GRE, IP over IP or minimal
   encapsulation no special considerations regarding the reachability
   are necessary; The tunnel has no stateful information; The packets
   are simply encapsulated within the GRE, IP, or minimal header.

   The tunnel origination point for the Correspondent Router is its
   Care-of Address, not the address where the registration requests were
   sent.  This is different from creation of the Reverse Tunnel to Home
   Agent.

   Special considerations rise from using UDP encapsulation, especially
   in cases where one of the Mobile Routers is located behind NAT or
   firewall.  If the Route Optimization Cache has NAT bit set for a
   specific network, the UDP tunnel establishment MUST be initiated from
   the Correspondent Router.  However, the procedure otherwise follows
   [RFC3519].  Once the first UDP keepalive is sent, the tunnel can be



Makela & Korhonen        Expires August 25, 2008               [Page 14]


Internet-Draft                    HAaRO                         Feb 2008


   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 6.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.

   Since typical routers act as both MR's and CR's, tunnels can be only
   torn down if there is no Mobility Bindings on the tunnel (in
   Correspondent Router role) AND no Mobility Sessions are bound to the
   tunnel (Mobile Router role).  Both Mobility Sessions and Mobility
   Bindings will go down when their lifetime expires.

3.3.5.  Constructing route-optimized packets

   All packets received by the Mobile Router are forwarded using normal
   routing rules according to the routing table.  There are no special
   considerations when constructing the packets, the interface procedure
   will encapsulate any packet automatically.

   If prefixes overlap each other, e.g. 192.0.2.128/25 and
   192.0.2.128/29, the standard longest match rule for routing is in
   effect.  However, overlapping private address SHOULD be considered an
   error situation.  Any aggregation for routes in private address space
   SHOULD be conducted only at HA.

3.3.6.  Handovers and Mobile Routers leaving network

   Handovers and connection breakdowns can be categorized as either
   ungraceful or graceful, or break-before-make and make-before-break
   situations.

   In a typical situation, router act as both Mobile Router and
   Correspondent Router for other routers' prefixes.

   When a Mobile Router wishes to leave network, it SHOULD send a re-



Makela & Korhonen        Expires August 25, 2008               [Page 15]


Internet-Draft                    HAaRO                         Feb 2008


   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 MUST 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 MUST realize
   that the old Mobility Session is no longer valid and establish a new
   one.  Thus, route optimization can resume.

3.4.  Convergence and synchronization 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.
   This will cause Mobile Routers to perform re-registrations and thus
   they will receive updates on-demand only.

   Consider a situation with three mobile networks, A, B, C handled by
   three Mobile Routers, MR A, MR B and MR C. If they register to a Home
   Agent in this order, the situation goes as follows:

   MR A registers; Receives no information on other networks from HA, as
   no other MR has registered yet.

   MR B registers; Receives information on mobile network A being
   reachable via MR A.

   MR C registers; Receives information on both of the other mobile
   networks.

   If a node in mobile network C receives traffic from mobile network A,
   the route optimization is straightforward; MR C already has network A
   in its Route Optimization Cache.  When it registers to MR A (after
   Return Routability procedure is completed), MR A does not have
   information on mobile network C; Thus it will perform a re-
   registration to the Home Agent on-demand.  This allows MR A to verify
   that MR C is indeed managing network C.

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



Makela & Korhonen        Expires August 25, 2008               [Page 16]


Internet-Draft                    HAaRO                         Feb 2008


   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
   possibilities concerning multiple Home Agents, see Section 6.3


4.  Data compression schemes

   This section defines the two compression formats used in Route
   Optimization Prefix Advertisement extensions.

4.1.  Prefix compression

   The prefix-compression is based on the idea that prefixes usually
   share common properties.  The scheme is simple delta-compression.  In
   the prefix information advertisement, Section 5.1, the D bit
   indicates whether receiving a "master" or a "delta" prefix.  This,
   combined with the Prefix Length information, allows for compression
   and decompression of prefix information.

   If D=0, what follows in the "Prefix" field are bits 1..n of the a new
   master prefix, where n is PLen.  This is rounded up to nearest full
   octet.  Thus, prefix lengths of /4 and /8 take 1 octet, /12 and /16
   take 2 octets, /20 and /24 three, and larger than that full 4 octets.

   If D=1, what follows in the "Prefix" field are bits m..PLen of the
   prefix, where m is the first changed bit of previous master prefix,
   with padding from master prefix filling the field to full octet.
   Maximum value of Plen-m is 8 (that is, delta MUST fit into one
   octet).  If this is not possible, a new master prefix has to be
   declared.

   Determining the order of prefix transmission should be based on
   saving maximum space during transmission.

   Example of compression and transmitted data, where network prefixes
   192.0.2.0/28, 192.0.2.64/26 and 192.0.2.128/25 are transmitted are
   illustrated.  Because of the padding to full octets, redundant
   information is also sent.  The bit-patterns being transmitted are:









Makela & Korhonen        Expires August 25, 2008               [Page 17]


Internet-Draft                    HAaRO                         Feb 2008


  =+= shows the prefix mask
  --- shows the master prefix for delta coded prefixes
  192.0.2.0/28, D=0

  0                   1                     2                     3
  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 2
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|0|0|0|0|0|0|0|
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+
  ^                                                                   ^
  +---------------------------- encoded ------------------------------+
                                                                ^     ^
                                                                +-pad-+
  192.0.2.64/26, D=1

  0                   1                     2                     3
  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 2
 +-------------------------------------------------------------+-+-+-+-+
 |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|1|0|0|0|0|0|0|
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+
                                          ^               ^
                                          +--- encoded ---+
                                          ^             ^
                                          +-- padding --+
  192.0.2.128/25, D=1

  0                   1                     2                     3
  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 2
 +-------------------------------------------------------------+-+-+-+-+
 |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0|
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+
                                        ^               ^
                                        +--- encoded ---+
                                        ^           ^
                                        +- padding -+


   First prefix, 192.0.2.0/28, is considered a master prefix and is
   transmitted in full.  The PLen of 28 bits determines that all four
   octets must be transmitted.  If the prefix would have been eg.
   192.0.2.0/24, three octets would have sufficed since 24 bits fit into
   3 octets.

   For the following prefixes, the D=1.  Thus, they are deltas of the
   previous prefix where D was zero.

   192.0.2.64/26 includes bits 19-26 (full octet).  Bits 19-25 are
   copied from master prefix, but bit 26 is changed to 1.  The final



Makela & Korhonen        Expires August 25, 2008               [Page 18]


Internet-Draft                    HAaRO                         Feb 2008


   notation in binary is "1001", or 0x09.

   192.0.2.128/25 includes bits 18-25 (full octet).  Bits 18-24 are
   copied from master prefix, but bit 25 is changed to 1.  The final
   notation in binary is "101", or 0x05.

   The final encoding thus becomes:

   +----------------+--------+-+---------------------+
   |     Prefix     |  Plen  |D| Transmitted Prefix  |
   +----------------+--------+-+---------------------+
   | 192.0.2.0/28   |  28    |0| 0xc0 0x00 0x02 0x00 |
   | 192.0.2.64/26  |  26    |1| 0x09                |
   | 192.0.2.128/25 |  25    |1| 0x05                |
   +----------------+--------+-+---------------------+

   It should be noted that in this case the order of prefix transmission
   would not affect compression efficiency.  If prefix 192.0.2.128/25
   would have been considered the master prefix and the others as deltas
   instead, the resulting encoding still fits into one octet for the
   subsequent prefixes.  There would be no need to declare a new master
   prefix.

4.2.  Realm compression

   In order to reduce the size of messages, the system utilizes a realm
   compression scheme, which reduces the size of realms in a message.
   In this scheme, an entire realm, a single label or a list of labels
   at the end of the realm is replaced with a pointer to a prior
   occurance of the same label.  The realm compression defined in this
   specification borrows ideas from the RFC 1035 [RFC1035] DNS domain
   name label compression.  Our algorithm is, however, slightly improved
   to allow single non-terminal labels.

   When compressing realms, the realms are first collected as a
   consecutive list of NUL ('\0') terminated strings.  This is different
   from the algorithm described in RFC 1035 which takes the whole DNS
   reply message as an input to the compressor.  The realms are
   compressed label by label or as a list of labels.  Refer the RFC 1035
   for the details of the search algorithm.

   A normal length indicator for an uncompressed run of octects
   representing a single label takes the form of a one octet:

    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0|   LENGTH    |



Makela & Korhonen        Expires August 25, 2008               [Page 19]


Internet-Draft                    HAaRO                         Feb 2008


   +-+-+-+-+-+-+-+-+

   This encoding allows label lengths up to 127 octets.  A label length
   of zero (0) indicates the end of the realm.

   The pointer to a prior occurance of a label takes the form of a two
   octet sequence.  This is a terminal offset meaning the sequence of
   encoded labels pointed by the offset are followed until a zero (0)
   length label is encountered.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|        OFFSET             | "terminal offset"
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It is also possible to have non-terminal offsets.  This means only
   the label pointed by this offset is followed and then the control is
   moved back to the encoded realm that contained this non-terminal
   offset.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1|        OFFSET             |  "non-terminal offset"
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first bit of a pointer is alway one.  This allows a pointer to be
   distinguished from a label, since the label must begin with one zero
   bit because labels are restricted to 127 octets or less.  The OFFSET
   field specifies an offset from the start of the concatenated list or
   realms.  A zero offset specifies the first byte of the first realm
   label, etc.

   The compression scheme allows a realm in a message to be represented
   as either:

   o  A sequence of labels ending in a zero octet

   o  A sequence of labels ending with a pointer

   o  A pointer

   o  A pointer followed by a sequence of labels or pointers

   Programs are free to avoid using realm compression in messages they
   generate, although this will reduce datagram capacity.  However all
   programs are required to understand arriving messages that contain



Makela & Korhonen        Expires August 25, 2008               [Page 20]


Internet-Draft                    HAaRO                         Feb 2008


   compressed realms.

   For example, a message might need to use the realms
   "foo.example.com", "bar.foo.example.com", "buz.foo.example.org" and
   "example.com".  These realms might be represented as:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        0 |       3       |      'f'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        2 |      'o'      |      'o'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        4 |       7       |      'e'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        6 |      'x'      |      'a'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        8 |      'm'      |      'p'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       10 |      'l'      |      'e'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       12 |       3       |      'c'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       14 |      'o'      |      'm'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       16 |       0       |      ...      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         ...

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      i+0 |       3       |      'b'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      i+2 |      'a'      |      'r'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      i+4 |1|0|           0               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         ...

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      j+0 |       3       |      'b'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      j+2 |      'u'      |      'z'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      j+4 |1|1|           0               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      j+6 |1|1|           4               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      j+6 |       3       |      'o'      |



Makela & Korhonen        Expires August 25, 2008               [Page 21]


Internet-Draft                    HAaRO                         Feb 2008


          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      j+8 |      'r'      |      'g'      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     j+10 |       0       |      ...      |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         ...

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      k+0 |1|0|           4               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


5.  New Mobile IPv4 messages and extensions

   This section describes the construction of all new information
   elements.

5.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
   registration request message.  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      |    Sub-type   |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1-n times the following information structure
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |O|D|M| Plen    |  Optional Mobile Router HoA, 4 octets         ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~               |  Optional Prefix, 1,2,3 or 4 octets           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                 Realm  (1-n characters)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type      TBA, Non-skippable (since it's explicitly requested)

   D         Delta.  If D=1, the prefix is a delta from last Prefix
             where D=0.  MUST be zero on first information structure,
             MAY be zero or one on subsequent information structures.
             If D=1, the Prefix field is one octet in length.  See
             Section 4.1 for details.



Makela & Korhonen        Expires August 25, 2008               [Page 22]


Internet-Draft                    HAaRO                         Feb 2008


   O         Outbound connections only.  This bit indicates that the
             target Mobile Router can only initiate, not receive,
             connections from it's CoA for this prefix.  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.

   M         Mobile Router HoA bit.  If M=1, the next field is Mobile
             Router HoA, and Prefix is omitted.  If M=0, the next field
             is Prefix, and Mobile Router HoA is omitted.  For the first
             information structure, M MUST be set to 1.  If M=1, the D
             and O bits are set to zero and ignored upon reception.

   PLen      Length of the prefix advertised. 5 bits, allows for values
             from 0 to 31.  If M=1, MUST be set to zero and ignored upon
             reception.

   Mobile router HoA  Mobile Router's Home address.  All prefixes in the
             following information structures where M=0 are maintained
             by this Mobile Router.

   Prefix    The IPv4 prefix advertised.  If D=0, the field length is
             Plen bits, rounded up to nearest full octet.  Least-
             significant bits starting off Plen (and are zeroes) are
             omitted.  If D=1, field length is one octet.

   Realm     The Realm that is associated with the advertised Mobile
             Router CoA and prefix.  If empty, MUST be set to '\0'.  For
             realm encoding and optional compression scheme, refer to
             Section 4.2

5.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                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Makela & Korhonen        Expires August 25, 2008               [Page 23]


Internet-Draft                    HAaRO                         Feb 2008


   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.

5.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                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

5.4.  Care-of-Test Init message








Makela & Korhonen        Expires August 25, 2008               [Page 24]


Internet-Draft                    HAaRO                         Feb 2008


     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.

5.5.  Home Test message

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |       Home Nonce Index        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Home Init Cookie                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Home Keygen Token                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type      TBA

   Home Nonce Index  This field will be echoed back by the Mobile Router
             to the Correspondent Router in a subsequent registration
             request.

   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.






Makela & Korhonen        Expires August 25, 2008               [Page 25]


Internet-Draft                    HAaRO                         Feb 2008


5.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.

5.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.
     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



Makela & Korhonen        Expires August 25, 2008               [Page 26]


Internet-Draft                    HAaRO                         Feb 2008


   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.

5.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.


6.  Special Considerations

6.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.



Makela & Korhonen        Expires August 25, 2008               [Page 27]


Internet-Draft                    HAaRO                         Feb 2008


   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 6.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.

6.2.  Foreign Agents

   Foreign Agents have to specifically support route optimization, ie.
   Return Routability procedure and establishment and maintenance of
   tunnel interfaces.  Optionally, Mobile Router and Foreign Agent can
   have a trust relationship 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.

6.3.  Multiple Home Agents

   In fact, Mobile Routers can negotiate and perform route optimization
   without the assistance of Home Agent - if they can discover each
   others existence.  This draft only addresses a single Home Agent that
   distributes network prefix information to the Mobile Routers.
   Problems arise from possible trust relationships; In this draft the
   Home Agent serves as a way to provide verification that a specific
   network is managed by a specific router.  For host-routes (route
   optimization between single nodes), the requirements may not be so
   strict.

   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 6.5 for information on
   possibility to generalize the method.

   Any discovery/probing protocols are out of scope for this draft.





Makela & Korhonen        Expires August 25, 2008               [Page 28]


Internet-Draft                    HAaRO                         Feb 2008


6.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, but this is not strictly necessary.  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 incoming 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 packets from network B to network A
   are sent over the direct tunnel, but the packets from A to B are
   transmitted via the Home Agent and reverse tunnels.  MR A now
   performs its own route optimization towards MR B. Upon completion, MR
   A notices that a tunnel to MR B already exists, but updates its
   routing table so that network B is now reachable via the MR A <-> MR
   B tunnel.  From this point onward, traffic is bidirectional.

   In this scenario, if MR A does NOT perform a separate route
   optimization (RR check and registration), but instead simply updates
   its routing table to reach network B via the tunnel, problems may
   arise if MR B has started to manage another network B' before the
   information has propagated to MR A. The end result is that MR B
   starts to receive packets for network B' via the Home Agent and for
   network B via direct tunnel.  If RPF checking or similar mechanism is
   in use on MR B, packets from network A could be blackholed.

6.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
   registration procedure (with the optional Return Routability part),
   which allows for Correspondent Routers to learn Mobile Router's
   Care-of Addresses is not strictly necessary; The CoA's could have



Makela & Korhonen        Expires August 25, 2008               [Page 29]


Internet-Draft                    HAaRO                         Feb 2008


   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.
   This can be performed by not including any prefixes in the
   information extension, just the HoA address of Mobile Router.

   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.


7.  Scalability

   Home Agent assisted Route Optimization scalability issues stem from
   the general Mobile IPv4 architecture which is based on tunnels.
   Creating, maintaining and destroying tunnel interfaces can cause load
   on the Mobile Routers.  However, the MRs can always fall back to
   normal, reverse tunnelled routing if resource constraints are
   apparent.

   If there is a large number of optimization-capable prefixes,
   maintaining state for all of these may be an issue also, due to
   limits on routing table sizes.

   Registration responses from Home Agent to Mobile Router may provide
   information on large number of network prefixes.  If thousands of
   networks are involved, the registration reply messages are bound to
   grow very large.  The prefix- and realm compression mechanisms
   defined in Section 4 mitigates this problem to an extent.  There
   will, however, be some practical upper limit after which point some
   other delivery mechanism for the prefix information will be needed.


8.  Example signaling scenarios






Makela & Korhonen        Expires August 25, 2008               [Page 30]


Internet-Draft                    HAaRO                         Feb 2008


8.1.  Registration request

   The following example signaling assumes that there are three Mobile
   Routers, MR A, B, C, each managing network prefixes A, B, and C. At
   the beginning, no networks are registered to the Home Agent.  Any AAA
   processing at the Home Agent is omitted from the diagram.
  +--------+ +--------+ +--------+ +--------------+
  | [MR A] | | [MR B] | | [MR C] | | [Home Agent] |
  +--------+ +--------+ +--------+ +--------------+
     |          |          |          |
     x------------------------------->|  Registration request,
     |          |          |          |  includes Mobile Router
     |          |          |          |  route optimization
     |          |          |          |  capability extension
     |          |          |          |
     |<-------------------------------x  Registration response,
     |          |          |          |  no known networks from HA
     |          |          |          |  in response
     |          |          |          |
     |          x-------------------->|  Registration request, similar
     |          |          |          |  to the one sent by MR A
     |          |          |          |
     |          |<--------------------x  Registration reply, includes
     |          |          |          |  network A in route optimization
     |          |          |          |  prefix advertisement extension
     |          |          |          |
     |          |          x--------->|  Registration request, similar
     |          |          |          |  the one sent by MR A
     |          |          |          |
     |          |          |<---------x  Registration reply, includes
     |          |          |          |  networks A and B in route
     |          |          |          |  optimization prefix
     |          |          |          |  advertisement extension.
     |          |          |          |  Network B is sent in
     |          |          |          |  compressed form.
     |          |          |          |


8.2.  Route optimization with return routability

   The following example signaling has same network setup as in
   Section 8.1 - Three mobile routers, each corresponding to their
   respective network.  Node A is in network A and Node C is in network
   C.

   At the beginning, no mobile routers know KRm's of each other.  If the
   KRm's would be pre-shared or provisioned with some other method, the
   Return Routability messages can be omitted.  Signaling in Section 8.1



Makela & Korhonen        Expires August 25, 2008               [Page 31]


Internet-Draft                    HAaRO                         Feb 2008


   has occured, thus MR A is not aware of the other networks, and MR C
   is aware of networks A and B.

   ======= Traffic inside Mobile IP tunnel to/from HA
   =-=-=-= Traffic inside Mobile IP tunnel between MRs
   ------- Traffic outside Mobile IP tunnel

 +----------+ +--------+ +------+ +--------+ +----------+
 | [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
 +----------+ +--------+ +------+ +--------+ +----------+
    |            |          |         |       |
    |<-----------O==========O=========O-------x  Mobile Router A is
    |            |          |         |       |  unaware of network C,
    |            |          |         |       |  thus, nothing happens
    |            |          |         |       |
    x------------O==========O=========O------>|  Mobile Router C
    |            |          |         |       |  notices packet from
    |            |          |         |       |  Net A - inits RO
    |            |          |         |       |
    |            |          |         |       |  Return Routability
    |            |          |         |       |  (If no preshared KRms)
    |            |          |         |       |
    |            |<=========O---------x       |  CoTI
    |            |<=========O=========x       |  HoTI
    |            |          |         |       |
    |            x==========O-------->|       |  CoT
    |            x==========O========>|       |  HoT
    |            |          |         |       |
    |            |          |         |       |  KRm between MR A <-> C
    |            |          |         |       |  established
    |            |          |         |       |
    |            |<=========O---------x       |  Registration request
    |            |          |         |       |
    |            x--------->|         |       |  Registration request
    |            |          |         |       |  to HA due to MR A
    |            |          |         |       |  being unaware of
    |            |          |         |       |  network C.
    |            |          |         |       |  Solicit bit set.
    |            |          |         |       |
    |            |<---------x         |       |  Registration reply,
    |            |          |         |       |  contains info on Net A
    |            |          |         |       |
    |            x==========O-------->|       |  Registration reply,
    |            |          |         |       |  includes MR A's CoA in
    |            |          |         |       |  Care-of-Address
    |            |          |         |       |  extension
    |            |          |         |       |
    |<-----------O=-=-=-==-=-=-=-==-=-O-------x  Packet from Node C -> A



Makela & Korhonen        Expires August 25, 2008               [Page 32]


Internet-Draft                    HAaRO                         Feb 2008


    |            |          |         |       |  routed to direct tunnel
    |            |          |         |       |  at MR C, based on
    |            |          |         |       |  MR C now knowing MR A's
    |            |          |         |       |  CoA and tunnel being up
    |            |          |         |       |
    x------------O=-=-=-==-=-=-=-==-=-O------>|  Packet from Node A -> C
    |            |          |         |       |  routed to direct tunnel
    |            |          |         |       |  at MR A, based on MR A
    |            |          |         |       |  now knowing MR C's CoA
    |            |          |         |       |  and tunnel being up



8.3.  Handovers

   In these example signalings, MR C changes care-of-address while Route
   Optimization between MR A is operating and data is being transferred.
   Both cases where the handover is graceful ("make before break") and
   ungraceful ("break before make") occur in similar fashion, except in
   the graceful version no packets get lost.































Makela & Korhonen        Expires August 25, 2008               [Page 33]


Internet-Draft                    HAaRO                         Feb 2008


   ======= Traffic inside Mobile IP tunnel to/from HA
   =-=-=-= Traffic inside Mobile IP tunnel between MRs
   ------- Traffic outside Mobile IP tunnel

 +----------+ +--------+ +------+ +--------+ +----------+
 | [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
 +----------+ +--------+ +------+ +--------+ +----------+
    |            |          |         |       |
    x------------O=-=-=-==-=-=-=-==-=-O------>| Nodes A and C
    |<-----------O=-=-=-==-=-=-=-==-=-O-------x exchanging traffic
    |            |          |         |       |
    |            |          xxxxxxxxxxx       | Break occurs: MR C
    |            |          |         |       | loses connectivity to
    |            |          |         |       | current attachment point
    |            |          |         |       |
    x------------O=-=-=-==-=-=-=->    |       | Traffic from A -> C
    |            |          |         |       | lost and
    |            |          |   x<=-=-O-------x vice versa
    |            |          |         |       |
    |            |          |<--------x       | MR C finds a new
    |            |          |         |       | point of attachment,
    |            |          |         |       | registers to HA, clears
    |            |          |         |       | routing tables
    |            |          |         |       |
    |            |          x-------->|       | Registration reply
    |            |          |         |       |
    x------------O=-=-=-==-=-=-=->    |       | Traffic from A -> C
    |            |          |         |       | lost
    |<-----------O==========O=========O-------| Traffic from C -> A
    |            |          |         |       | sent via HA
    |            |          |         |       |
    |            |<=========O---------x       | Registration request,
    |            |          |         |       | reusing still active KRm
    |            |          |         |       |
    |            x==========O-------->|       | Registration reply
    |            |          |         |       |
    x------------O=-=-=-==-=-=-=-==-=-O------>| Traffic from A -> C
    |            |          |         |       | forwarded again
    |<-----------O=-=-=-==-=-=-=-==-=-O-------x Traffic from C -> A
    |            |          |         |       | switches back to direct
    |            |          |         |       | tunnel
    |            |          |         |       |


9.  IANA Considerations

   New Mobile IP header extension and message type values are needed for
   the messages and extensions listed in Section 5.



Makela & Korhonen        Expires August 25, 2008               [Page 34]


Internet-Draft                    HAaRO                         Feb 2008


   Note to RFC Editor: this section may be removed on publication as an
   RFC.


10.  Security Considerations

   The Return Routability check has been established in the IPv6 world.

10.1.  Trust relationships

   The network of trust relationships in Home Agent assisted Route
   Optimization solve the issues where arbitrary Correspondent Router
   can trust an arbitrary Mobile Router that it is indeed the proper
   route to reach an arbitrary mobile network.

   It is assumed that all Mobile Routers have a trust relationship with
   the Home Agent.  Thus, they trust information provided by Home Agent.

   The Home Agent provides information matching Home Addresses and
   network prefixes.  Each Mobile Router trusts this information.

   Mobile Routers may perform Return Routability procedure between each
   other.  This creates a trusted association between Mobile Router Home
   Address and Care-of Address.  The Mobile Router also claims to
   represent a specific network.  This information is not trustworthy as
   such.

   The claim can be verified by checking the Home Address <-> network
   prefix information received, either earlier, or due to on-demand
   request, from the Home Agent.  If they match, the Mobile Router's
   claim is authentic.  If the network is considered trusted, a policy
   decision can be made to skip this check.  Exact definitions on
   situations where such decision can be made are out of scope of this
   draft.  The RECOMMENDED general practice is to perform the check.


11.  Acknowledgements

   Thanks to Jyrki Soini and Kari Laihonen for initial reviews.


12.  References

12.1.  Normative References

   [I-D.ietf-mip4-nemo-v4-base]
              Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
              "Network Mobility (NEMO) Extensions for Mobile IPv4",



Makela & Korhonen        Expires August 25, 2008               [Page 35]


Internet-Draft                    HAaRO                         Feb 2008


              draft-ietf-mip4-nemo-v4-base-10 (work in progress),
              February 2008.

   [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.

12.2.  Informative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC3543]  Glass, S. and M. Chandra, "Registration Revocation in
              Mobile IPv4", RFC 3543, August 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.


Authors' Addresses

   Antti Makela
   TeliaSonera Corporation.
   P.O.Box 777
   FIN-33101 Tampere
   FINLAND

   Phone: +358 40 824 4170
   Email: antti.makela@teliasonera.com


   Jouni Korhonen
   TeliaSonera Corporation.
   P.O.Box 970
   FIN-00051 Sonera
   FINLAND

   Phone: +358 40 534 4455
   Email: jouni.korhonen@teliasonera.com






Makela & Korhonen        Expires August 25, 2008               [Page 36]


Internet-Draft                    HAaRO                         Feb 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

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





Makela & Korhonen        Expires August 25, 2008               [Page 37]


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