Mobile IPv4
MIP4 Working Group                                     Rajeev                                        Rajeev. Koodli
INTERNET DRAFT                                           Charles E.
Internet-Draft                                          Charles. Perkins
Intended status: Experimental                      Nokia Research Center
6
Expires: August 27, 2007                               February 23, 2007

                       Mobile IPv4 Fast Handovers
                        draft-ietf-mip4-fmipv4-03.txt
                     draft-ietf-mip4-fmipv4-04.txt

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.

   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 document is a submission of the Internet-Draft will expire on August 27, 2007.

Copyright Notice

   Copyright (C) The IETF MIP4 WG. Comments should
    be directed to the MIP4 WG mailing list, mip4@ietf.org. Trust (2007).

Abstract

   This document adapts the Mobile IPv6 Fast Handovers [1] to improve delay
   and packet loss resulting from Mobile IPv4 handover operations.
   Specifically, this document addresses movement detection, IP address
   configuration and location update latencies during a handover.  For
   reducing the IP address configuration latency, the document proposes
   that the new Care-of Address is always made to be the new access
   router's IP address.  Additional mechanisms may be defined in the
   future versions of this document.

Table of Contents

Abstract                                                                   i

   1.  Introduction                                                          2 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Factors Affecting Handover                                            3

 3.  Protocol . . . . . . . . . . . . . . . . . .  4
      3.1.
   4.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Overview . . . . . . . . . . . . . . . . .   4
      3.2. . . . . . . . .  5
     4.2.  Operation  . . . . . . . . . . . . . . . . .    5

 4.  Use of . . . . . . .  6
   5.  Using Previous FA Notification Extension                             8

 5. . . . . . . . . . . .  9
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  9
      5.1.
     6.1.  Fast Binding Update (FBU)  . . . . . . . . . . . . . . . .  9
      5.2.
     6.2.  Fast Binding Acknowledgment (FBAck)  . . . . . . . . . 11
      5.3. . . 10
     6.3.  Router Solicitation for Proxy Advertisement (RtSolPr)  .       13
      5.4. . 12
     6.4.  Proxy Router Advertisement (PrRtAdv) . . . . . . . . 15
      5.5. . . . 13
     6.5.  Inter-Access Router Messages . . . . . . . . . .   17
             5.5.1. . . . . . 16
       6.5.1.  Handover Initiate (HI) . . . . . . . . .   17
             5.5.2. . . . . . . . 16
       6.5.2.  Handover Acknowledge (HAck)  . . . . . . . .   19

 6.  Option formats                                                       22
      6.1.  Link-Layer Address . . . . . 17
   7.  Option Format Formats . . . . . . . . .  22
      6.2.  New IPv4 Address Option Format . . . . . . . . . . 23
      6.3. . . . . . 19
     7.1.  Link-Layer Address Option Format . . . . . . . . . . . . . 19
     7.2.  New IPv4 Address Option Format . . . . . . . . . . . . . . 20
     7.3.  New Router Prefix Information Option . . . . . . . . 24

 7. . . . 21
   8.  Security Considerations                                               25

 8.  . . . . . . . . . . . . . . . . . . . 22
   9.  IANA Considerations                                                   25

 9.  . . . . . . . . . . . . . . . . . . . . . 23
   10. Acknowledgement                                                       25  . . . . . . . . . . . . . . . . . . . . . . . 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property Statement                                            27

Disclaimer of Validity                                                     27 and Copyright Statement                                                        28

Acknowledgment                                                             28 Statements . . . . . . . . . . 26

1.  Introduction

   This document adapts the fast handover specification [1] [rfc4068] to
   IPv4 networks.  The fast handover protocol specified in this document
   is particularly interesting for operation over wireless links such as IEEE 802
   wireless links.  Fast handovers are not typically needed for wired
   media due to the relatively large delays attributable to establishing
   new connections in today's wired networks.  Mobile IPv4 [2] [rfc3344]
   registration messages are re-used (with new type numbers) in this
   document to enable faster implementation using existing Mobile IPv4
   software.  This draft does not rely on link-layer triggers for
   protocol operation, but performance will typically be enhanced by
   using the appropriate triggers when they are available.  This
   document assumes that the reader is familiar with the basic operation
   and terminology of Mobile IPv4 [1] [rfc3344] and Fast Handovers for
   Mobile IPv6 [1]. [rfc4068].

   The active agents that enable continued packet delivery to a mobile
   node (MN) are the access routers on the networks that the mobile node
   connects to.  Handover means that the mobile node changes its network
   connection, and we consider the scenario in which this change means
   change in access routers.  The mobile node utilizes the access
   routers as default routers in the normal sense, but also as partners
   in mobility management.  Thus, when the mobile node moves to a new
   network, it processes handover-related signaling in order to identify
   and develop a relationship with a new access router.  In this
   document, we call the previous access router PAR and the new access
   router NAR, consistent with the terminology in [1]. [rfc4068].  Unless
   otherwise mentioned, a PAR is also a Previous Foreign Agent (PFA) and
   a NAR is also a New Foreign Agent (NFA).

   On a particular network, a mobile node may obtain its IP address via
   DHCP [6] [rfc2131] (i.e., Co-located Care-of Address) or use the Foreign
   Agent CoA.  During a handover, the new CoA (NCoA) is always made to
   be that of NAR.  This allows a mobile node to receive and send
   packets using its previous CoA (PCoA), so that delays resulting from
   IP configuration (such as DHCP address acquisition delay) subsequent
   to attaching to the new link are disengaged from affecting the
   existing sessions.

    2.

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

2.  Terminology

   The terminology used in this document in based on [rfc4068] and
   [rfc3344].  We provide some definitions below for convenience.

      Mobile Node (MN): A Mobile IPv6 host.

      Access Point (AP): A Layer 2 device connected to an IP subnet that
      offers wireless connectivity to an MN.  An Access Point Identifier
      (AP-ID) refers to the AP's L2 address.  Sometimes, AP-ID is also
      referred to as a Base Station Subsystem ID (BSSID).

      Access Router (AR): The MN's default router.

      Previous Access Router (PAR): The MN's default router prior to its
      handover.

      New Access Router (NAR): The MN's default router subsequent to its
      handover.

      Previous CoA (PCoA): The MN's Care of Address valid on PAR's
      subnet.

      New CoA (NCoA): The MN's Care of Address valid on NAR's subnet.

      Handover: A process of terminating existing connectivity and
      obtaining new IP connectivity.

      (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
      addresses, and the prefix valid on the interface to which the
      Access Point (identified by AP-ID) is attached.  The triplet
      [Router's L2 address, Router's IP address, Prefix] is called "AR-
      Info".

3.  Factors Affecting Handover

   Both the link-layer operations and IP layer procedures affect the
   perceived handover performance.  However, the overall performance is
   also (always) a function of specific implementation of the technology
   as well as the system configuration.  This document only specifies IP
   layer protocol operations.  The purpose of this section is to provide
   an illustration of events that affect handover performance, but it is
   purely informative.

   The IP layer handover delay and packet loss are influenced by
   latencies due to movement detection, IP address configuration and
   Mobile IP registration procedure.  Movement detection latency comes
   from the need to reliably detect movement to a new subnet.  This is a
   function of frequency of router advertisements as well as default
   agent reachability.  IP address configuration latency depends on the
   particular IP CoA being used.  If co-located mode with DHCP is used,
   the latency is quite likely going to be higher and unacceptable for
   real-time applications such as Voice over IP.  Finally, the Mobile IP
   registration procedure needs a round-trip of delay between the Mobile
   Node and its Home Agent over the Internet.  This delay is incurred
   after the mobile node performs movement detection and IP
   configuration.

   Underlying the IP operations are link-layer procedures.  These are
   clearly technology-specific.  For instance in IEEE 802.11, the
   handover operation typically involves scanning access points over all
   available channels, selecting a suitable access point, and
   associating with it.  It may also involve performing access control
   operations such as those specified in IEEE 802.1X [4]. [ieee-802.1x].
   These delays contribute to the handover performance.  Optimizations
   are being proposed for standardization in IEEE, for instance see [5]
   [ieee-802.11r] and [3]. [ieee-802.21].  Together with appropriate
   implementation techniques, these optimizations can provide the
   required level of delay support at the link-layer for real-time
   applications.

    3.

4.  Protocol

    3.1.

4.1.  Overview

   The design of the protocol is the same as for Mobile IPv6 [1]. [rfc4068].
   Readers should consult [1] [rfc4068] for details, and here we provide a
   summary.

   The protocol avoids the delay due to movement detection and IP
   configuration and disengage disengages Mobile IP registration delay from the
   time-critical path.  The protocol provides the surrounding network network
   neighborhood information so that a mobile node can determine whether
   it is moving to a new subnet even before the handover.  The
   information provided and the signaling exchanged between the local
   mobility agents allows the mobile node to send and receive packets
   immediately after handover.  In order to disengage the Mobile IP
   registration latency, the protocol provides routing support for the
   continued use of a mobile node's previous CoA.

   After a mobile node obtains its IPv4 care-of address, it builds a
   neighborhood access point and subnet map using the Router
   Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
   Advertisement (PrRtAdv) messages.  The mobile node may scan for
   access points (APs) based on the configuration policy in operation
   for its wireless network interface.  If a scan results in a new AP
   discovery, the mobile node resolves the corresponding AP Identifier
   to subnet information using the RtSolPr and PrRtAdv messages
   mentioned above.

   At some point, the mobile node decides to undergo handover.  It sends
   an FBU message to PAR from the previous link or from the new link.
   FBU message enables creation of a binding between the mobile node's
   previous CoA and the new CoA.

   The coordination between the access routers is done by way of the
   Handover Initiate (HI) and Handover Acknowledge (HAck) messages
   defined in [1]. [rfc4068].  After these signals have been exchanged
   between the previous and new access routers (PAR and NAR), data
   arriving at PAR will be tunneled to NAR for delivery to the newly
   arrived mobile node.  The purpose of HI is to securely deliver the
   routing parameters for establishing this tunnel.  The tunnel is
   created by the access routers in response to the delivery of the FBU
   from the mobile node.

    3.2.

4.2.  Operation

   In response to a handover trigger or indication, the mobile node
   sends a Fast Binding Update message to Previous Access Router (PAR)
   (see Section 5.1). Section 6.1).  Depending on whether the Mobile IP mode of
   operation, the PCoA is either the Home Address (in FA CoA mode) or
   co-located CoA (in CCoA mode).  The FBU message SHOULD be sent when
   the mobile node is still connected to PAR.  When sent in this
    ``predictive''
   "predictive" mode, the fields in the FBU are used as follows:

     -  ``Home Address''

      "Home Address" field must be the PCoA (which can be either the
      Home Address or the co-located CoA)

     -

      Home Agent field, even though redundant, must be set to PAR's IP
      address

     -

      Care-of Address field must be the NAR's IP address discovered via
      PrRtAdv message

     -

      Destination IP address must be PAR's IP address

     -

      Source IP address must be the PCoA (which can be either the Home
      Address or the co-located CoA)

   As a result of processing the FBU, PAR creates a binding between PCoA
   and NAR's IP address in its routing table.  The PAR sends an FBack
   message (see 5.2) Section Section 6.2) as a response to the mobile node.

   The timeline for the predictive mode of operation (adapted from [1])
   [rfc4068]) is shown in Figure Figure 1.

                 MN                    PAR                  NAR
                  |                     |                    |
                  |------RtSolPr------->|                    |
                  |<-----PrRtAdv--------|                    |
                  |                     |                    |
                  |------FBU----------->|--------HI--------->|
                  |                     |<------HAck---------|
                  |          <--FBack---|--FBack--->         |
                  |                     |                    |
               disconnect             forward                |
                  |                   packets===============>|
                  |                     |                    |
                  |                     |                    |
              connect                   |                    |
                  |                     |                    |
                  |--------- FBU --------------------------->|
                  |<=================================== deliver packets
                  |                     |<-----FBU-----------|

                    Figure 1: Predictive Fast Handover

   The mobile node sends the FBU regardless of its previous transmission
   when attachment to a new link is detected.  This minimally allows NAR
   to detect mobile node's attachment, but also the retransmission of
   FBU when an FBack has not been received yet.  When sent in this ``reactive''
   "reactive" mode, the following fields in FBU are set differently
   compared to the predictive mode:

     -

      Destination IP address must be NAR's IP address

     -

      Source IP address must be PCoA (either the Home Address or the
        co-located co-
      located CoA)

   When NAR receives FBU, it may already have processed the HI message
   and created a host route entry for the PCoA.  In that case, NAR
   should immediately forward arriving and buffered packets including
   the FBAck message.  In any case, NAR MUST forward the contents of
   this message, starting from the Type field, to PAR, which means the
   Source and Destination IP addresses in the new packet now contain the
   IP addresses of NAR and PAR respectively.

   The reactive mode of operation (adapted from [1]) [rfc4068]) is
   illustrated in Figure Figure 2.

                 MN                    PAR                  NAR
                  |                     |                    |
                  |------RtSolPr------->|                    |
                  |<-----PrRtAdv--------|                    |
                  |                     |                    |
               disconnect               |                    |
                  |                     |                    |
                  |                     |                    |
               connect                  |                    |
                  |-----------FBU-------|------------------->|
                  |                     |<-----FBU-----------|
                  |                     |------FBack-------->|
                  |                   forward                |
                  |                   packets===============>|
                  |                     |                    |
                  |<=================================== deliver packets
                  |                                          |

                     Figure 2: Reactive Fast Handover

   The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
   serve to establish a bidirectional tunnel between the routers to
   support packet forwarding for PCoA.  The tunnel itself is established
   as a response to the FBU message.  The PAR sends HI message with Code
   = 0 when it receives FBU with source IP address set to PCoA.  The PAR
   sends HI with Code = 1 when it receives FBU with source IP address
   not set to PCoA (i.e., when received from NAR).  This allows NAR to
   disambiguate HI message processing sent as a response to predictive
   and reactive modes of operation.  If NAR receives a HI message with
   Code = 1, and it has already set up a host route entry and a reverse
   tunnel for PCoA, it should silently discard the HI message.

   The protocol provides an option for NAR to return NCoA for use by the
   mobile node.  When NAR can provide an NCoA for exclusive use of the
   mobile node, the address is supplied in the HAck message.  The PAR
   includes this NCoA in FBack.  Exactly how NAR manages the address
   pool from which it supplies NCoA is not specified in this document.
   Nevertheless, the MN should be prepared to use this address instead
   of performing DHCP or similar operations to obtain an IPv4 address.

   Even though the mobile node can obtain this NCoA from the NAR, it is
   unaware of the address at the time it sends an FBU.  Hence, it binds
   PCoA to NAR's IP address as before.

                MN                    PAR                  NAR
                 |                     |                    |
                 |------RtSolPr------->|                    |
                 |<-----PrRtAdv--------|                    |
                 |                     |                    |
              disconnect               |                    |
                 |                     |                    |
                 |                     |                    |
              connect                  |                    |
                 |-----------FBU-------|------------------->|
                 |                     |<-----FBU-----------|
                 |                     |------FBack-------->|
                 |                   forward                |
                 |                   packets===============>|
                 |                      |                   |
                 |<=================================== deliver packets
                 |                                          |

                      Figure 2: Reactive Fast Handover

    4. Use of

5.  Using Previous FA Notification Extension

   Sending FBU from the new link (i.e., reactive mode) is similar to
   using the extension defined in [2]. [draft-mip4-ro].  However, with the
   neighborhood information gathered using the proxy router messages
   (see Section 5.3, Section 5.4), 6.3, Section Section 6.4), movement detection
   and router discovery delays are avoided even in the reactive case.
   The FBU and FBAck messages defined in this document can be naturally
   used even when no neighborhood information is available.

    5.

6.  Message Formats

    5.1.

6.1.  Fast Binding Update (FBU)

   The FBU format is bitwise identical to the Registration Request
   format in RFC 3344. [rfc3344].  The same destination port number, 434, is used,
   but the FBU and FBAck messages in this specification have new message
   type numbers.

       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      |x|x|D|M|G|r|T|x| reserved  |     Lifetime      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Home Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Home Agent                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Care-of Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Identification                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extensions ...
      +-+-+-+-+-+-+-+-

                Figure 3: Fast Binding Update (FBU) Message
       IP fields:
      Source address address: The interface address from which the message is
      sent.  Either PCoA (co-located or Home Address), or NAR's IP
      address (when forwarded from NAR to PAR).

      Destination Address Address: The IP address of the Previous Access Router
      or the New Access Router.

      Source Port Port: variable

      Destination port port: 434

       Type

         Type: To be assigned by IANA

       Flags

         Flags: See RFC 3344

       reserved [rfc3344].  The 'S' and 'B' flags in [rfc3344] are
         sent as zero, and ignored on reception.

         reserved: Sent as zero, ignored on input

       Lifetime

         Lifetime: The number of seconds remaining before binding
         expires.  MUST NOT exceed 10 seconds.

         Home Address Address: MUST be PCoA (i.e., PCoA, which can either be the co-located
         CoA or the Home Address) Address

         Home Agent Agent: The Previous Access Router's global IP address

         Care-of Address Address: The New Access Router's global IP address

       Identification         See RFC 3344

       Extensions

         Identification: a 64-bit number used for matching an FBU with
         FBack.  Identical to usage in [rfc3344]

         Extensions: MUST contain the MN - PAR Authentication Extension
    5.2.

6.2.  Fast Binding Acknowledgment (FBAck)

   The FBAck format is bitwise identical to the Registration Reply
   format in [2]. [rfc3344].

       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      |     Code      | reserved  |     Lifetime      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Home Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Home Agent                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Identification                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extensions ...
      +-+-+-+-+-+-+-+-

          Figure 4: Fast Binding Acknowledgment Acknowledgement (FBAck) Message
       IP fields:

      Source address address: Typically copied from the destination address of
      the FBU message

      Destination Address Address: Copied from the Source IP address in FBU
      message

      Source Port Port: variable

      Destination port port: copied from the source port in FBU message

       Type

         Type: To be assigned by IANA

       Code

         Code: Indicates the result of processing FBU message.  Code = 0
         means Fast Binding Update accepted.  Code = 1 means Fast
         Binding Update accepted but NCoA is supplied as an extension.

       reserved

         reserved: Sent as zero, ignored on input

       Lifetime

         Lifetime: The granted number of seconds remaining before
         binding expires.   MUST NOT exceed 10
                              seconds.

         Home Address Address: PCoA (i.e., either co-located CoA or Home
         Address)

         Home Agent Agent: The Previous Access Router's global IP address

       Identification
         Identification: a 64-bit number used for matching FBU. See
                              RFC 3344.

       Extensions  Copied
         from the field in FBU for which this FBack is a reply.

         Extensions: The PAR - MN Authentication extension MUST be
         present.  In addition, an NCoA option MUST be present when NAR
         supplies the NCoA.

   If the FBAck message indicates that the new care-of address is a
   Foreign Agent care-of address [2], [rfc3344], then the mobile node MUST
   set the 'D' bit in its Registration Request message that it uses to
   register the NCoA with its home agent.

    5.3.

6.3.  Router Solicitation for Proxy Advertisement (RtSolPr)

   Mobile Nodes send Router Solicitation for Proxy Advertisement in
   order to prompt routers for Proxy Router Advertisements.  All the
   link-layer address options have the format defined in 6.1. Section 7.1.
   The message format and processing rules are identical to those
   defined in [1].   We only provide the format here for convenience. [rfc4068].

      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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Subtype     |   Reserved    |          Identifier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

      Figure 5: Router Solicitation for Proxy Advertisement (RtSolPr)
                                  Message

      IP Fields:

         Source Address Address: An IP address assigned to the sending interface

         Destination Address Address: The address of the Access Router or the
         all routers multicast address.

     Time-to-Live

         Time-to-Live: At least 1.  See RFC 1256. [rfc1256].

      ICMP Fields:

     Type

         Type: To be assigned by IANA

     Code

         Code: 0

     Checksum

         Checksum: The 16-bit one's complement of the one's complement
         sum of the ICMP message, start- start ing with the ICMP Type.  For
         computing the checksum, the Checksum and the Reserved fields
         are set to 0.  See RFC 1256.

     Subtype [rfc1256].

         Subtype: To be assigned by IANA

     Reserved

         Reserved: MUST be set to zero by the sender and ignored by the
         receiver.

     Identifier

         Identifier: MUST be set by the sender so that replies can be
         matched to this Solicitation.

      Valid Options:

         New Access Point Link-layer Address Address: The link-layer address or
         identification of the access point for which the MN requests
         routing advertisement information.  It MUST be included in all
         RtSolPr messages.  More than one such address or identifier can
         be present.  This field can also be a wildcard address with all bits set to zero.

    5.4. (see
         Section 7.1).

6.4.  Proxy Router Advertisement (PrRtAdv)

   Access routers send out Proxy Router Advertisement message
   gratuitously if the handover is network-initiated or as a response to
   RtSolPr message from a mobile node, providing the link-layer address,
   IP address and subnet prefixes of neighboring routers.  All the link-layer link-
   layer address options have the format defined in 6.1. Section 7.1.

   The message format and processing rules are identical to those
   defined in [1].   We only provide the format here for convenience. [rfc4068].

      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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Subtype     |   Reserved    |          Identifier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

          Figure 6: Proxy Router Advertisement (PrRtAdv) Message

      IP Fields:

         Source Address Address: An IP address assigned to the sending interface

         Destination Address Address: The Source Address of an invoking Router
         Solicitation for Proxy Advertisement or the address of the node
         the Access Router is instructing to handover.

         Time-to-Live At least 1.  See RFC 1256. [rfc1256].

      ICMP Fields:

     Type

         Type: To be assigned by IANA

         Code 0, 1, 2, 3 or 4.  See below.

     Checksum

         Checksum: The 16-bit one's complement of the one's complement
         sum of the ICMP message, start- ing with the ICMP Type.  For
         computing the checksum, the Checksum and the Reserved fields
         are set to 0.  See RFC 1256.

     Subtype [rfc1256].

         Subtype: To be assigned by IANA.

     Reserved

         Reserved: MUST be set to zero by the sender and ignored by the
         receiver.

     Identifier

         Identifier: Copied from Router Solicitation for Proxy
         Advertisement or set to Zero if unsolicited.

      Valid Options in the following order:

         New Access Point Link-layer Address Address: The link-layer address or
         identification of the access point is copied from RtSolPr
         message.  This option MUST be present.

         New Router's Link-layer Address Address: The link-layer address of the
         Access Router for which this message is proxied for.  This
         option MUST be included when Code is 0 or 1.

         New Router's IP Address Address: The IP address of NAR.  This option
         MUST be included when Code is 0 or 1.

         New Router Prefix Information Option Option: The number of leading
         bits that define the network number of the corresponding
         Router's IP Address option (see above).

         New CoA Option Option: MAY be present when PrRtAdv is sent
         unsolicited.  PAR MAY compute new CoA using NAR's prefix
         information and the MN's L2 address, or by any other means.

    5.5. Inter-Access Router Messages

    5.5.1.  Handover Initiate (HI)

    The Handover Initiate (HI) is an ICMP message sent by an Access
    Router (typically PAR) to another Access Router (typically NAR) to
    initiate  In
         any case, the process of a mobile node's handover.

    The message format and processing rules are identical MN should be prepared to those
    defined in [1].   We only provide the format here for convenience.

    IP Fields:

     Source Address
                     The IP use this address instead
         of performing DHCP or similar operations to obtain an IPv4
         address.

   A PrRtAdv with Code 0 means that the PAR

     Destination Address MN should use the [AP-ID, AR-
   Info] tuple present in the options above.  In this case, the Option-
   Code field (see Section 7.1) in the New AP LLA option is 1,
   reflecting the LLA of the access point for which the rest of the
   options are related, and the Option-Code for the New Router's LLA
   option is 3.  Multiple tuples may be present.

   A PrRtAdv with Code 1 means that the message is sent unsolicited.  If
   a New IPv4 option (see Figure 10) is present following the New Router
   Prefix Information option (see Section 7.3), the MN SHOULD use the
   supplied NCoA and send the FBU immediately or else stand to lose
   service.  This message acts as a network-initiated handover trigger.
   The IP address Option-Code field (see Section 7.1) in the New AP LLA option in
   this case is 1 reflecting the LLA of the NAR access point for which the
   rest of the options are related.

   A Proxy Router Advertisement with Code 2 means that no new router
   information is present.  The LLA option contains an Option-Code value
   that indicates a specific reason (see Section 7.1).

   A Proxy Router Advertisement with Code 3 means that new router
   information is only present for a subset of access points requested.
   The Option-Code values in the LLA option distinguish different
   outcomes (see Section 7.1).

   A Proxy Router Advertisement with Code 4 means that the subnet
   information regarding neighboring access points is sent unsolicited,
   but the message is not a handover trigger, unlike when the message is
   sent with Code 1.  Multiple tuples may be present.

   When a wildcard AP identifier is supplied in the RtSolPr message, the
   PrRtAdv message should include any 'n' [Access Point Identifier,
   Link-Layer Address option, Prefix Information Option] tuples
   corresponding to the PAR's neighborhood.

6.5.  Inter-Access Router Messages

6.5.1.  Handover Initiate (HI)

   The Handover Initiate (HI) is an ICMP message sent by an Access
   Router (typically PAR) to another Access Router (typically NAR) to
   initiate the process of a mobile node's handover.

   The message format and processing rules are identical to those
   defined in [rfc4068].

      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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Subtype     |S|U| Reserved  |          Identifier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

                 Figure 7:  Handover Initiate (HI) Message

     Time-to-Live

      IP Fields:

         Source Address: The IP address of the PAR

         Destination Address: The IP address of the NAR

         Time-to-Live: At least 1.  See RFC 1256. [rfc1256].

      ICMP Fields:

     Type

         Type: To be assigned by IANA

     Code

         Code: 0 or 1.  See below

     Checksum
         Checksum: The 16-bit one's complement of the one's complement
         sum of the ICMP message, start- ing with the ICMP Type.  For
         computing the checksum, the Checksum and the Reserved fields
         are set to 0.  See RFC 1256.

     Subtype [rfc1256].

         Subtype: To be assigned by IANA

     S

         S: Assigned address configuration flag.  When set, this message
         requests a new CoA to be returned by the destination.  May be
         set when Code = 0.  MUST be 0 when Code = 1.

     U

         U: Buffer flag.  When set, the destination SHOULD buffer any
         packets towards the node indicated in the options of this
         message.  Used when Code = 0, SHOULD be set to 0 when Code = 1.

     Reserved

         Reserved: MUST be set to zero by the sender and ignored by the
         receiver.

     Identifier

         Identifier: MUST be set by the sender so replies can be matched
         to this message.

      Valid Options:

         Link-layer address of MN MN: The link-layer address of the MN that
         is undergoing handover to the destination (i.e., NAR).  This
         option MUST be included so that the destination can recognize
         the MN.

         Previous Care of Address Address: The IP address used by the MN while
         attached to the originating router.  This option
                      SHOULD MUST be
         included so that a host route can be established in case necessary. on the NAR.

         New Care of Address
                      The IP address Address: This option MAY be present when the MN
         wishes to use a new IP address when connected to the
         destination.  When the `S' 'S' bit is set, NAR MAY assign provide this
         address in HAck, in which case t he MN should be prepared to
         use this address instead of performing DHCP or similar
         operations to obtain an IPv4 address.

    5.5.2.

6.5.2.  Handover Acknowledge (HAck)

   The Handover Acknowledgment message is a new ICMP message that MUST
   be sent (typically by NAR to PAR) as a reply to the Handover Initiate
   (HI) (see section 5.5.1) Section Section 6.5.1) message.

   The message format and processing rules are identical to those
   defined in [1].   We only provide the format here for convenience. [rfc4068].

      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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Subtype     |    Reserved   |          Identifier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

              Figure 8:  Handover Acknowledge (HAck) Message

      IP Fields:

         Source Address Address: Copied from the destination address of the
         Handover Initiate Message to which this message is a response.

         Destination Address Address: Copied from the source address of the
         Handover Initiate Message to which this message is a response.

     Time-to-Live

         Time-to-Live: At least 1.  See RFC 1256. [rfc1256].

      ICMP Fields:

     Type

         Type: To be assigned by IANA

     Code

         Code:

            0: Handover Accepted, NCoA valid Accepted
            1: Handover Accepted, NCoA not valid
            2: Handover Accepted, NCoA in use
            3: Handover Accepted, NCoA assigned (used in Assigned
               addressing)
            4: Handover Accepted, NCoA not assigned
                       (used in Assigned addressing)
            128: Handover Not Accepted, reason unspecified
            129: Administratively prohibited
            130: Insufficient resources

     Checksum

         Checksum: The 16-bit one's complement of the one's complement
         sum of the ICMP message, start- ing with the ICMP Type.  For
         computing the checksum, the Checksum and the Reserved fields
         are set to 0.  See RFC 1256.

     Subtype [rfc1256].

         Subtype: To be assigned by IANA.

     Reserved

         Reserved: MUST be set to zero by the sender and ignored by the
         receiver.

     Identifier

         Identifier: Copied from the corresponding field in the Handover
         Initiate message this message is in response to.

      Valid Options:

         New Care of Address Address: If the S 'S' flag in the Handover Initiate HI message is set,
         this option MUST be used to provide NCoA the MN should use when
         connected to this router.  This option MAY be included even
         when `S' 'S' bit is not set, e.g., Code 2 above.

    6.  The MN should be
         prepared to use this address instead of performing DHCP or
         similar operations to obtain an IPv4 address.

   The Code 0 is the expected average case of a handover being accepted
   and the routing support provided for the use of PCoA.  The rest of
   the Code values pertain to the use of NCoA (which is common in
   [rfc4068]).  Code values 1 and 2 are for cases when the MN proposes
   an NCoA and the NAR provides a response.  Code 3 is when the NAR
   provides NCoA (which could be the same as that proposed by the MN).
   Code 4 is when the NAR does not provide NCoA, but instead provides
   routing support for PCoA.

7.  Option formats Formats

   The options in this section are specified as optional extensions for the HI
   and HAck messages, as well as for the Router Proxy
    Solicitation PrRtSol and Router Proxy Advertisement messages..

    6.1. PrRtAdv messages.

7.1.  Link-Layer Address Option Format

      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     |     Link-Layer Address  Option-Code  |     LLA ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: Link-Layer Link Layer Address Option Format

      Fields:

       Type
                        1    Mobile Node Link-layer

         Type: To be assigned by IANA
         Option-Code:

            0: wildcard requesting resolution for all nearby access
               points
            1: Link-Layer Address
                        2 of the New Access Point Link-layer
            2: Link-Layer Address
                        3 of the MN
            3: Link-Layer Address of the NAR Link-layer
            4: Link-Layer Address

       Length of the source of the RtSolPr or
               PrRtAdv message
            5: The access point identified by the LLA belongs to the
               current interface of the router
            6: No prefix information available for the access point
               identified by the LLA
            7: No fast handovers support available for the access point
               identified by the LLA

         Length: The length of the option (including the type Type, Length
         and
                        length Option-Code fields) in units of 8 octets.   For example,
                        the length for IEEE 802 addresses is 1 [IPv6-
                        ETHER].

         Link-Layer Address Address: The variable length link-layer address.
         The content and format of this field (including byte and bit
         ordering) depends on the specific link-layer in use.

    6.2.

   Depending on the size of the individual LLA option, appropriate
   padding MUST be used to ensure that the entire option size is a
   multiple of 8 octets.

7.2.  New IPv4 Address Option Format

   This option is used to provide the new router's IPv4 address in
    PrRtAdv.   When it is also used to provide NCoA, it MUST appear
    after provide the new router's IPv4 address to distinguish or the two
    addresses.
   NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck messages.

      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     |  Option-Code  |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      New IPv4 Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 10: New IPv4 Address Option Format
      Fields:

       Type

         Type: To be assigned by IANA

       Length

         Length: The length of the option (including the type Type, Length
         and
                        length Option-Code fields) in units of 8 octets.

      Reserved

         Option-Code:

            1: Previous CoA
            2: New CoA
            3: NAR's IP Address

         Reserved: Set to zero.

         New IPv4 Address Address: NAR's IPv4 address or the NCoA assigned by
         NAR.

    6.3.

7.3.  New Router Prefix Information Option

   This option is the same as the ``Prefix-Lengths Extension'' used in RFC
    3344 (Section 2.1.2). the PrRtAdv 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     |  Option-Code  | Prefix-Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 11: New Router Prefix Information Option Format

      Fields:

       Type

         Type: To be assigned by IANA

         Length: The length of the option (including the Type, Length           1
         and Option-Code fields) in units of 8 octets.

         Option-Code: 0

         Prefix-Length The number of leading bits that define the
         network number of the corresponding Router's IP Address option.

      Reserved

         Reserved: Set to zero.

    7.

8.  Security Considerations

    The

   As outlined in [rfc4068], the following vulnerabilities are
   identified and the solutions mentioned.

   Insecure FBU:

   Failure to protect the FBU message could result in packets meant for
   an address being stolen or redirected to some unsuspecting node.
   This concern is similar to that in Mobile Node and Home Agent
   relationship.

   Hence, the FBU and FBack messages MUST be protected using a security
   association shared between a mobile node and its access router.  In
   particular, the MN - PAR Authentication Extension MUST be present in
   each of these messages.   Failure to include this extension can
    lead to a bogus node claiming  This document does not specify how the
   security association is established between a genuine mobile node's address MN and binding it to an arbitrary address.   When the NCoA is NAR's
    address, there AR/FA.

   Secure FBU, malicious or inadvertent redirection:

   Even if the MN - PAR authentication extension is no risk of present in an FBU, a genuine mobile node misdirecting
    traffic, either inadvertently
   MN may indevertently or intentionally, maliciously attempt to bind its PCoA to an unsuspecting
    node
   unintended address on NAR's subnet.   When NCoA link, and cause traffic flooding to an
   unsuspecting node.

   This vulnerability is other than avoided by always binding the PCoA to the NAR's
   IP address, even when the NAR
    MUST supplies an NCoA to use for the MN.  It
   is still possible to jam NAR's buffer with redirected traffic.
   However, the handover state corresponding to the MN's PCoA has a
   finite lifetime, and can be configured to be a few multiples of the
   anticipated handover latency.  Hence, the extent of this
   vulnerability is small.

   Communication between the access routers:

   The access routers communicate using HI and HAck messages in order to
   establish a temporary routing path for the MN undergoing handover.
   This message exchange needs to be secured to ensure that the proposed NCoA in routing updates
   take place as intended.

   The HI is conflict-free, and
    MUST indicate the disposition in the HAck message.   If there is a
    conflict, PAR MUST NOT tunnel packets messages need to be secured using a pre-existing
   security association between the address in question.
    Instead, PAR SHOULD tunnel packets access routers to the address specified in
    HAck, if any is provided.

    8. ensure at least
   message integrity and authentication, and should also include
   encryption.

9.  IANA Considerations

   All the messages and the option formats specified in this document
   require Type assignment from IANA.

    9.  Specifically, the Types, Sub-
   types and the Codes need assignment from ICMP, Mobile IP and
   Experimental Mobility Type [rfc4065] registries.

10.  Acknowledgement

   Thanks to all those who expressed interest in having a Fast Handovers
   for Mobile IPv4 protocol along the lines of [1]. [rfc4068].  Thanks to
   Vijay Devarapalli, Keng Leung, Alex Petrescu Leung for their review and input.  Kumar
   Viswanath and Uday Mohan implemented an early version of this
   protocol.  Many thanks to Alex Petrescu for his thorough review that
   improved this document.

11.  References

11.1.  Normative References

    [1] R. (Editor) Koodli.   Fast Handovers for Mobile IPv6.   Request

   [RFC2119]  Bradner, S., "Key words for Comments 4068, Internet Engineering Task Force, July 2005.

    [2] C. use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [rfc1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
              September 1991.

   [rfc3344]  Perkins (Editor).   IP (Editor), C., "IP Mobility Support for IPv4.   Request
        for Comments (Proposed Standard) IPv4",
              RFC 3344, Internet Engineering
        Task Force, August 2002.

   [rfc4065]  Kempf, J., "Instructions for Seamoby and Experimental
              Mobility Protocol IANA Allocations", RFC 4065, July 2005.

   [rfc4068]  Koodli (Editor), R., "Fast Handovers for Mobile IPv6",
              RFC 4068, July 2005.

11.2.  Informative References

    [3] The IEEE 802.21 group. http://www.ieee802.org/21.   Technical
        report, IEEE.

    [4] IEEE Standard for Local

   [draft-mip4-ro]
              Perkins, C. and Metropolitan Area Networks:
        Port-Based Network Access Control.   Technical report, IEEE.

    [5] IEEE D. Johnson, "Route Optimization in Mobile
              IP (work in progress).   Internet Draft, Internet
              Engineering Task Force", February 2000.

   [ieee-802.11r]
              "IEEE Standard forLocal and Metropolitan Area Networks:
              Fast Roaming/Fast BSS Transition, the IEEE Task Group TGr.
              Technical report, IEEE.

    [6] R. Droms.   Dynamic IEEE.".

   [ieee-802.1x]
              "IEEE Standard for Local and Metropolitan Area Networks:
              Port-Based Network Access Control. Technical report,
              IEEE.".

   [ieee-802.21]
              "The IEEE 802.21 group. http://www.ieee802.org/21.".

   [rfc2131]  Droms, R., "Dynamic Host Configuration Protocol.   Request for
        Comments (Draft Standard) Protocol",
              RFC 2131, Internet Engineering Task
        Force, March 1997.

    [7] C. Perkins

Appendix A.  Change Log

   Addressed the following Last Call and D. Johnson.   Route Optimization subsequent reviews:

      Provided all the Code values in Mobile IP
        (work PrRtAdv message to cover various
      cases involving neighborhood discovery.  Harmonized the option
      formats with [rfc4068].

      Added the Terminology Section

      Added text regarding FBU message flags 'S' and 'B'

      Revised text in progress).   Internet Draft, Internet Engineering Task
        Force.
        draft-ietf-mobileip-optim-09.txt, February 2000.

    Questions about this memo can be directed Security Considerations

      Clarified text in different places based on ML comments (including
      "forwarding", MN's use of assigned addresses in lieu of DHCP, and
      so on.)

      Clarified using ICMPv4 checksum for RtSolPr, PrRtAdv, HI and HAck

      Added Figures illustrating predictive and reactive handovers

      Added references to IEEE 802.21 and IEEE 802.11r

      All id nits (attempt to the authors: move from LaTex to xml turned out to be
      quite a task, sigh..)

Authors' Addresses

   Rajeev Koodli                           Charles E. Perkins
       Nokia Research Center
   Nokia Research Center
   975 Page Mill Road, 200
   Palo Alto, CA  94304
   USA

   Email: rajeev.koodli@nokia.com

   Charles Perkins
   Nokia Research Center
   975 Page Mill Road, 200
   Palo Alto, California CA  94304             Palo Alto, California 94304
       USA
   USA
       Phone:   +1-650 625-2359                Phone:   +1-650 625-2986
       EMail:   rajeev.koodli@nokia.com        EMail:   charliep@iprg.nokia.com
       Fax:   +1 650 625-2502                  Fax:   +1 650 625-2502

   Email: charles.perkins@nokia.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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

Intellectual Property Statement

   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.

    Disclaimer of Validity

    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.

    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.

Acknowledgment

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