GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4988

Network Working Group R. Koodli Request for Comments: 4988 C. Perkins Category: Experimental Nokia Siemens Networks

                                                          October 2007
                     Mobile IPv4 Fast Handovers

Status of This Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Abstract

 This document adapts the Mobile IPv6 Fast Handovers 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.

Koodli & Perkins Experimental [Page 1] RFC 4988 MIP4 Fast Handovers October 2007

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................4
 3. Factors Affecting Handover ......................................5
 4. Protocol ........................................................6
    4.1. Overview ...................................................6
    4.2. Operation ..................................................7
 5. Message Formats ................................................10
    5.1. Fast Binding Update (FBU) .................................10
    5.2. Fast Binding Acknowledgment (FBAck) .......................12
    5.3. Router Solicitation for Proxy Advertisement (RtSolPr) .....13
    5.4. Proxy Router Advertisement (PrRtAdv) ......................14
    5.5. Handover Initiate (HI) ....................................17
    5.6. Handover Acknowledge (HAck) ...............................19
 6. Option Formats .................................................20
    6.1. Link-Layer Address Option Format ..........................20
    6.2. New IPv4 Address Option Format ............................22
    6.3. New Router Prefix Information Option ......................22
 7. Security Considerations ........................................23
 8. IANA Considerations ............................................24
 9. Acknowledgments ................................................25
 10. References ....................................................25
    10.1. Normative References .....................................25
    10.2. Informative References ...................................26

Koodli & Perkins Experimental [Page 2] RFC 4988 MIP4 Fast Handovers October 2007

1. Introduction

 This document adapts the fast handover specification [rfc4068] to
 IPv4 networks.  The fast handover protocol specified in this document
 is particularly interesting for operation over 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 [rfc3344]
 registration messages are reused (with new type numbers) in this
 document to enable faster implementation using existing Mobile IPv4
 software.  This document does not require 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 [rfc3344] and Fast Handovers for
 Mobile IPv6 [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 [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 [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.
 Unlike in Mobile IPv6, a Mobile IPv4 host may rely on its Foreign
 Agent to provide a Care-of Address.  Using the protocol specified in
 this document, the binding at the PAR is always established between
 the on-link address the mobile node is using and a new CoA that it
 can use on the NAR's link.  When FA-CoA is used, the on-link address
 is the MN's home address, not the FA-CoA itself, which needs to be

Koodli & Perkins Experimental [Page 3] RFC 4988 MIP4 Fast Handovers October 2007

 bound to the NCoA.  So, when we say "a binding is established between
 PCoA and NCoA", it is actually the home address of the mobile node
 that is bound to the NCoA in the FA-CoA mode.
 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 IPv4 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 IP address of the MN 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".

Koodli & Perkins Experimental [Page 4] RFC 4988 MIP4 Fast Handovers October 2007

3. Factors Affecting Handover

 Both 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
 the Mobile IP registration procedure.  Movement detection latency
 comes from the need to reliably detect movement to a new subnet.
 This is a function of the 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
 potentially unacceptable for real-time applications such as Voice
 over IP.  Finally, the Mobile IP registration procedure introduces 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
 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 [ieee-802.1x].
 These delays contribute to the handover performance.  See [fh-ccr]
 and Chapters 20 and 22 in [mi-book].  Optimizations are being
 proposed for standardization in IEEE; for instance, see
 [ieee-802.11r] and [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.

Koodli & Perkins Experimental [Page 5] RFC 4988 MIP4 Fast Handovers October 2007

4. Protocol

4.1. Overview

 The design of the protocol is the same as for Mobile IPv6 [rfc4068].
 Readers should consult [rfc4068] for details; here we provide a
 summary.
 The protocol avoids the delay due to movement detection and IP
 configuration and disengages Mobile IP registration delay from the
 time-critical path.  The protocol provides the surrounding 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 allow 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 detects a new AP, 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
 a Fast Binding Update (FBU) message to PAR from the previous link or
 from the new link.  An 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 [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.

Koodli & Perkins Experimental [Page 6] RFC 4988 MIP4 Fast Handovers October 2007

4.2. Operation

 In response to a handover trigger or indication, the mobile node
 sends a Fast Binding Update message to the Previous Access Router
 (PAR) (see Section 5.1).  Depending on the Mobile IP mode of
 operation, the source IP address is either the Home Address (in FA
 CoA mode) or co-located CoA (in CCoA mode).  The FBU message SHOULD
 (when possible) be sent while the mobile node is still connected to
 PAR.  When sent in this "predictive" mode, the fields in the FBU MUST
 be set as follows:
    The Home Address field is either the Home Address or the co-
    located CoA whenever the mobile node has a co-located CoA.
    The Home Agent field is set to PAR's IP address.
    The Care-of Address field is the NAR's IP address (as discovered
    via a PrRtAdv message).
    The fields in the IP header MUST be set as follows:
    The Destination IP address is PAR's IP address.
    The Source IP address is either the Home Address or the co-located
    CoA whenever the mobile node has a co-located CoA.
 As a result of processing the FBU, PAR creates a binding between the
 address given by the mobile node in the Home Address field and NAR's
 IP address in its routing table.  The PAR sends an FBack message (see
 Section 5.2) as a response to the mobile node.
 The timeline for the predictive mode of operation (adapted from
 [rfc4068]) is shown in Figure 1.

Koodli & Perkins Experimental [Page 7] RFC 4988 MIP4 Fast Handovers October 2007

           MN                    PAR                  NAR
            |                     |                    |
            |------RtSolPr------->|                    |
            |<-----PrRtAdv--------|                    |
            |                     |                    |
            |------FBU----------->|--------HI--------->|
            |                     |<------HAck---------|
            |          <--FBack---|--FBack--->         |
            |                     |                    |
         disconnect             forward                |
            |                   packets===============>|
            |                     |                    |
            |                     |                    |
        connect                   |                    |
            |                     |                    |
            |--------- FBU --------------------------->|
            |<=================================== deliver packets
            |                     |              (including FBack)
            |                     |<-----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 the mobile node's attachment, but also
 the retransmission of FBU when an FBack has not been received yet.
 When sent in this "reactive" mode, the Destination IP address in the
 IP header MUST be NAR's IP address; the rest of the fields in the FBU
 are the same as in the "predictive" case.
 When NAR receives FBU, it may already have processed the HI message
 and created a host route entry for the mobile node, using either the
 home address or the co-located care-of address as provided by PAR.
 In that case, NAR SHOULD immediately forward arriving and buffered
 packets as well as the FBAck message.  In any case, NAR MUST forward
 the contents of the FBU message, starting from the Type field, to
 PAR; 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 [rfc4068]) is
 illustrated in Figure 2.  Even though the Figure does not show the HI
 and HAck messages illustrated in Figure 1, these messages could
 already have been exchanged (in the case when the PAR has already
 processed the FBU sent from the previous link); if not, the PAR sends
 a HI message to the NAR.  The FBack packet is forwarded by the NAR to
 the MN along with the data packets.

Koodli & Perkins Experimental [Page 8] RFC 4988 MIP4 Fast Handovers October 2007

               MN                    PAR                  NAR
                |                     |                    |
                |------RtSolPr------->|                    |
                |<-----PrRtAdv--------|                    |
                |                     |                    |
             disconnect               |                    |
                |                     |                    |
                |                     |                    |
             connect                  |                    |
                |-----------FBU-------|------------------->|
                |                     |<-----FBU-----------|
                |                     |------FBack-------->|
                |                   forward                |
                |                   packets===============>|
                |                     |                    |
                |<=================================== deliver packets
                |                                    (including FBack)
                |                                          |
                     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 the 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 still respond with a HAck
 message, using an appropriate Code value defined in Section 5.6.
 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.

Koodli & Perkins Experimental [Page 9] RFC 4988 MIP4 Fast Handovers October 2007

5. Message Formats

 This section specifies the formats for messages used in this
 protocol.  The Code values below are the same as those in [rfc4068],
 and do not require any assignment from IANA.

5.1. Fast Binding Update (FBU)

 The FBU format is bitwise identical to the Registration Request
 format in [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: 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: The IP address of the Previous Access
       Router (PAR) or the New Access Router (NAR).
       Source Port: variable
       Destination port: 434

Koodli & Perkins Experimental [Page 10] RFC 4988 MIP4 Fast Handovers October 2007

    Message Fields:
       Type: 20
       Flags: See [rfc3344].  The 'S' and 'B' flags in [rfc3344] are
       sent as zero, and ignored on reception.
       reserved: Sent as zero, ignored on reception
       Lifetime: The number of seconds remaining before the binding
       expires.  This value MUST NOT exceed 10 seconds.
       Home Address: MUST be either the co-located CoA or the Home
       Address itself (in FA-CoA mode)
       Home Agent: The Previous Access Router's global IP address
       Care-of Address: The New Access Router's global IP address.
       Even when a New CoA is provided to the MN (see Section 5.4),
       NAR's IP address MUST be used for this field.
       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
       (see Section 8)
 The MN-PAR Authentication Extension is the Generalized Mobile IP
 Authentication Extension in [rfc4721] with a new Subtype for MN-PAR
 Authentication.  The Authenticator field in the Generalized Mobile IP
 Authentication Extension is calculated using a shared key between the
 MN and the PAR.  However, the key distribution itself is beyond the
 scope of this document, and is assumed to be performed by other means
 (for example, using [rfc3957]).

Koodli & Perkins Experimental [Page 11] RFC 4988 MIP4 Fast Handovers October 2007

5.2. Fast Binding Acknowledgment (FBAck)

 The FBAck format is bitwise identical to the Registration Reply
 format in [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 (FBAck)
    IP Fields:
       Message Source address: Typically copied from the destination
       address of the FBU message
       Destination Address: Copied from the Source IP address in FBU
       message
       Source Port: variable
       Destination port: Copied from the source port in FBU message
    Message Fields:
       Type: 21
       Code: Indicates the result of processing FBU message.
          0: FBU Accepted
          1: FBU Accepted, NCoA supplied
          128: FBU Not Accepted, reason unspecified
          129: Administratively prohibited
          130: Insufficient resources
       reserved: Sent as zero, ignored on reception

Koodli & Perkins Experimental [Page 12] RFC 4988 MIP4 Fast Handovers October 2007

       Lifetime: The granted number of seconds remaining before
       binding expires.
       Home Address: either the co-located CoA or the Home Address
       itself (in FA-Coa mode)
       Home Agent: The Previous Access Router's global IP address
       Identification: a 64-bit number used for matching FBU.  Copied
       from the field in FBU for which this FBack is a reply.
       Extensions: The MN-PAR Authentication extension MUST be present
       (see Section 8).  In addition, a New IPv4 Address Option, with
       Option-Code 2, MUST be present when NAR supplies the NCoA (see
       Section 6.2).

5.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 Section 6.1.
 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     |   Reserved    |          Identifier           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-
    Figure 5: Router Solicitation for Proxy Advertisement (RtSolPr)
                                Message
    IP Fields:
       Source Address: An IP address assigned to the sending interface
       Destination Address: The address of the Access Router or the
       all routers multicast address.
       Time-to-Live: At least 1.  See [rfc1256].

Koodli & Perkins Experimental [Page 13] RFC 4988 MIP4 Fast Handovers October 2007

    ICMP Fields:
       Type: 41.  See Section 3 in [rfc4065].
       Code: 0
       Checksum: The 16-bit one's complement of the one's complement
       sum of the ICMP message, starting with the ICMP Type.  For
       computing the checksum, the Checksum and the Reserved fields
       are set to 0.  See [rfc1256].
       Subtype: 6
       Reserved: MUST be set to zero by the sender and ignored by the
       receiver.
       Identifier: MUST be set by the sender so that replies can be
       matched to this Solicitation.
    Valid Options:
       New Access Point Link-layer 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 (see
       Section 6.1).

5.4. Proxy Router Advertisement (PrRtAdv)

 Access routers send out a 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 access routers.  All
 the link-layer address options have the format defined in Section
 6.1.
 The message format and processing rules are identical to those
 defined in [rfc4068].

Koodli & Perkins Experimental [Page 14] RFC 4988 MIP4 Fast Handovers October 2007

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Subtype     |   Reserved    |          Identifier           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-
        Figure 6: Proxy Router Advertisement (PrRtAdv) Message
    IP Fields:
       Source Address: An IP address assigned to the sending interface
       Destination 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 [rfc1256].
    ICMP Fields:
       Type: 41.  See Section 3 in [rfc4065].
       Code 0, 1, 2, 3, or 4.  See below.
       Checksum: The 16-bit one's complement of the one's complement
       sum of the ICMP message, starting with the ICMP Type.  For
       computing the checksum, the Checksum and the Reserved fields
       are set to 0.  See [rfc1256].
       Subtype: 7
       Reserved: MUST be set to zero by the sender and ignored by the
       receiver.
       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: The link-layer address
       (LLA) or identification of the access point.  When there is no
       wildcard in RtSolPr, this is copied from the LLA (for which the
       router is supplying the [AP-ID, AR-Info] tuple) present in

Koodli & Perkins Experimental [Page 15] RFC 4988 MIP4 Fast Handovers October 2007

       RtSolPr.  When a wildcard is present in RtSolPr, PAR uses its
       neighborhood information to populate this field.  This option
       MUST be present.
       New Router's Link-layer Address: The link-layer address of the
       Access Router for which this message is proxied.  This option
       MUST be included when Code is 0 or 1.
       New Router's IP Address: The IP address of NAR.  This option
       MUST be included when Code is 0 or 1.
       New Router Prefix Information Option: The number of leading
       bits that define the network number of the corresponding
       Router's IP Address option (see above).
       New CoA Option: MAY be present, typically when PrRtAdv is sent
       unsolicited.  PAR MAY compute new CoA by communicating with the
       NAR or by means not specified in this document.  In any case,
       the MN should be prepared to use this address instead of
       performing DHCP or similar operations to obtain an IPv4
       address.  Even when it uses the New CoA provided, the MN MUST
       bind its current on-link address (PCoA) to that of NAR in the
       FBU message.
 A PrRtAdv with Code 0 means that the MN should use the [AP-ID,
 AR-Info] tuple present in the options above.  In this case, the
 Option-Code field (see Section 6.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 6.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 Option-Code field (see Section 6.1) in the New AP LLA option in
 this case is 1 reflecting the LLA of the 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 6.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 6.1).

Koodli & Perkins Experimental [Page 16] RFC 4988 MIP4 Fast Handovers October 2007

 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 all available [Access Point
 Identifier, Link-Layer Address option, Prefix Information Option]
 tuples corresponding to the PAR's neighborhood.
 The New CoA option may also be used when the PrRtAdv is sent as a
 response to a RtSolPr message.  However, the solicited RtSolPr and
 PrRtAdv exchange for neighborhood discovery is logically decoupled
 from the actual handover phase involving the FBU and FBack messages
 (above) as well as HI and HAck messages (see below).  This means the
 access routers have to carefully manage the supplied address due to
 the relative scarcity of addresses in IPv4.

5.5. 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
    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 [rfc1256].

Koodli & Perkins Experimental [Page 17] RFC 4988 MIP4 Fast Handovers October 2007

    ICMP Fields:
       Type: 41.  See Section 3 in [rfc4065].
       Code: 0 or 1.  See below
       Checksum: The 16-bit one's complement of the one's complement
       sum of the ICMP message, starting with the ICMP Type.  For
       computing the checksum, the Checksum and the Reserved fields
       are set to 0.  See [rfc1256].
       Subtype: 8
       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: 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: MUST be set to zero by the sender and ignored by the
       receiver.
       Identifier: MUST be set by the sender so replies can be matched
       to this message.
    Valid Options:
       Link-layer address of 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: The IP address used by the MN while
       attached to the originating router.  This option MUST be
       included so that a host route can be established on the NAR.
       New Care-of Address: This option MAY be present when the MN
       wishes to use a new IP address when connected to the
       destination.  When the 'S' bit is set, NAR MAY provide this
       address in HAck, in which case the MN should be prepared to use
       this address instead of performing DHCP or similar operations
       to obtain an IPv4 address.
 PAR uses Code = 0 when it processes the FBU received with PCoA as
 source IP address.  PAR uses Code = 1 when the FBU is received with
 NAR's IP address as the source IP address.

Koodli & Perkins Experimental [Page 18] RFC 4988 MIP4 Fast Handovers October 2007

5.6. 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) message.
 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     |    Reserved   |          Identifier           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-
               Figure 8:  Handover Acknowledge (HAck) Message
    IP Fields:
       Source Address: Copied from the destination address of the
       Handover Initiate Message to which this message is a response.
       Destination Address: Copied from the source address of the
       Handover Initiate Message to which this message is a response.
       Time-to-Live: At least 1.  See [rfc1256].
    ICMP Fields:
       Type: 41.  See Section 3 in [rfc4065].
       Code:
          0: Handover 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
          128: Handover Not Accepted, reason unspecified
          129: Administratively prohibited
          130: Insufficient resources

Koodli & Perkins Experimental [Page 19] RFC 4988 MIP4 Fast Handovers October 2007

       Checksum: The 16-bit one's complement of the one's complement
       sum of the ICMP message, starting with the ICMP Type.  For
       computing the checksum, the Checksum and the Reserved fields
       are set to 0.  See [rfc1256].
       Subtype: 9
       Reserved: MUST be set to zero by the sender and ignored by the
       receiver.
       Identifier: Copied from the corresponding field in the Handover
       Initiate message this message is in response to.
    Valid Options:
       New Care-of Address: If the 'S' flag in the 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' bit is not set, e.g., Code 2 above.  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.

6. Option Formats

 The options in this section are specified as extensions for the HI
 and HAck messages, as well as for the PrRtSol and PrRtAdv messages.
 The Option-Code values below are the same as those in [rfc4068], and
 do not require any assignment from IANA.

6.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     |  Option-Code  |     LLA ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 9: Link-Layer Address Option Format

Koodli & Perkins Experimental [Page 20] RFC 4988 MIP4 Fast Handovers October 2007

    Fields:
       Type: 20
       Option-Code:
          0: Wildcard requesting resolution for all nearby access
             points
          1: Link-Layer Address of the New Access Point
          2: Link-Layer Address of the MN
          3: Link-Layer Address of the NAR
          4: Link-Layer Address 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, Length
       and Option-Code fields) in units of 8 octets.
       Link-Layer 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.
 There is no length field for the LLA itself.  Implementations MUST
 determine the length of the LLA based on the specific link technology
 where the protocol is run.  The total size of the LLA option itself
 MUST be a multiple of 8 octets.  Hence, padding may be necessary
 depending on the size of the LLA used.  In such a case, the padN
 option [rfc2460] MUST be used.  As an example, when the LLA is 6
 bytes (meaning 7 bytes of padding is necessary to bring the LLA
 option length to 2), the padN option will have a length field of 5
 and 5 bytes of zero-valued octets (see [rfc2460]).

Koodli & Perkins Experimental [Page 21] RFC 4988 MIP4 Fast Handovers October 2007

6.2. New IPv4 Address Option Format

 This option is used to provide the new router's IPv4 address or the
 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: 21
       Length: The length of the option (including the Type, Length
       and Option-Code fields) in units of 8 octets.
       Option-Code:
          1: Previous CoA
          2: New CoA
          3: NAR's IP Address
       Reserved: Set to zero.
       New IPv4 Address: NAR's IPv4 address or the NCoA assigned by
       NAR.

6.3. New Router Prefix Information Option

 This option is used in 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

Koodli & Perkins Experimental [Page 22] RFC 4988 MIP4 Fast Handovers October 2007

    Fields:
       Type: 22
       Length: The length of the option (including the Type, Length
       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: Set to zero.

7. Security Considerations

 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.  This document does not specify how the
 security association is established between an MN and the AR/FA.
 Secure FBU, malicious or inadvertent redirection:
 Even if the MN-PAR authentication extension is present in an FBU, an
 MN may inadvertently or maliciously attempt to bind its PCoA to an
 unintended address on NAR's link, and cause traffic flooding to an
 unsuspecting node.
 This vulnerability is avoided by always binding the PCoA to the NAR's
 IP address, even when the NAR 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.  It is possible to trace the culprit MN with
 an established security association at the access router.

Koodli & Perkins Experimental [Page 23] RFC 4988 MIP4 Fast Handovers October 2007

 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 routing updates
 take place as intended.
 The HI and HAck messages need to be secured using a preexisting
 security association between the access routers to ensure at least
 message integrity and authentication, and SHOULD also include
 encryption.  IPsec ESP SHOULD be used.

8. IANA Considerations

 The IANA assignments made for messages, extensions, and options
 specified in this document are described in the following paragraphs.
 This document defines two new messages that use the Mobile IPv4
 control message format [rfc3344].  These message details are as
 follows:
                 +------+-------------+-------------+
                 | Type | Description |  Reference  |
                 +------+-------------+-------------+
                 |  20  |     FBU     | Section 5.1 |
                 |  21  |    FBAck    | Section 5.2 |
                 +------+-------------+-------------+
 This document defines four new experimental ICMP messages that use
 the ICMP Type 41 for IPv4.  See Section 3 in [rfc4065].  The new
 messages specified in this document have been assigned Subtypes from
 the registry in [rfc4065]:
                +---------+-------------+-------------+
                | Subtype | Description |  Reference  |
                +---------+-------------+-------------+
                |    6    |   RtSolPr   | Section 5.3 |
                |    7    |   PrRtAdv   | Section 5.4 |
                |    8    |      HI     | Section 5.5 |
                |    9    |     HAck    | Section 5.6 |
                +---------+-------------+-------------+
 This document defines three new options that have been assigned Types
 from the Mobile IP Extensions for ICMP Router Discovery messages
 [rfc3344].  These options are as follows:

Koodli & Perkins Experimental [Page 24] RFC 4988 MIP4 Fast Handovers October 2007

               +------+------------------+-------------+
               | Type |    Description   |  Reference  |
               +------+------------------+-------------+
               |  20  |        LLA       | Section 6.1 |
               |  21  | New IPv4 Address | Section 6.2 |
               |  22  |  NAR Prefix Info | Section 6.3 |
               +------+------------------+-------------+
 The MN-PAR Authentication Extension described in Sections 5.1 and 5.2
 is a Generalized Mobile IP Authentication Extension defined in
 Section 5 of [rfc4721].  The MN-PAR Authentication has been assigned
 a Subtype from the registry specified in [rfc4721].  The Extension
 details are as follows:
    +---------+-----------------------+--------------------------+
    | Subtype |      Description      |         Reference        |
    +---------+-----------------------+--------------------------+
    |    4    | MN-PAR Auth Extension |        Section 5.1       |
    +---------+-----------------------+--------------------------+

9. Acknowledgments

 Thanks to all those who expressed interest in having a Fast Handovers
 for Mobile IPv4 protocol along the lines of [rfc4068].  Thanks to
 Vijay Devarapalli, Kent Leung, and Domagoj Premec 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.  Thanks to Pete McCann
 for the proofreading, and to Jari Arkko for the review, which have
 helped improve this document.  Thanks to Francis Dupont and Hannes
 Tschofenig for the GEN-ART and TSV-DIR reviews.
 Sending FBU from the new link (i.e., reactive mode) is similar to
 using the extension defined in [mip4-ro]; however, this document also
 addresses movement detection and router discovery latencies.

10. References

10.1. Normative References

 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [rfc1256]      Deering, S., Ed., "ICMP Router Discovery Messages",
                RFC 1256, September 1991.
 [rfc2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
                6 (IPv6) Specification", RFC 2460, December 1998.

Koodli & Perkins Experimental [Page 25] RFC 4988 MIP4 Fast Handovers October 2007

 [rfc3344]      Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
                3344, August 2002.
 [rfc4065]      Kempf, J., "Instructions for Seamoby and Experimental
                Mobility Protocol IANA Allocations", RFC 4065, July
                2005.
 [rfc4068]      Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
                4068, July 2005.
 [rfc4721]      Perkins, C., Calhoun, P., and J. Bharatia, "Mobile
                IPv4 Challenge/Response Extensions (Revised)", RFC
                4721, January 2007.

10.2. Informative References

 [fh-ccr]       R. Koodli and C. E. Perkins, "Fast Handovers and
                Context Transfers in Mobile Networks", ACM Computer
                Communications Review Special Issue on Wireless
                Extensions to the Internet, October 2001.
 [ieee-802.11r] IEEE, "IEEE Standard for Local and Metropolitan Area
                Networks:  Fast Roaming/Fast BSS Transition, IEEE Std
                802.11r", September 2006.
 [ieee-802.1x]  IEEE, "IEEE Standards for Local and Metropolitan Area
                Networks: Port-based Network Access Control, IEEE Std
                802.1X-2001", June 2001.
 [ieee-802.21]  The IEEE 802.21 group, http://www.ieee802.org/21.
 [mi-book]      R. Koodli and C. E. Perkins, "Mobile Internetworking
                with IPv6: Concepts, Principles and Practices", John
                Wiley & Sons, June 2007.
 [mip4-ro]      Perkins, C. and D. Johnson, "Route Optimization in
                Mobile IP", Work in Progress, September 2001.
 [rfc2131]      Droms, R., "Dynamic Host Configuration Protocol", RFC
                2131, March 1997.
 [rfc3957]      Perkins, C. and P. Calhoun, "Authentication,
                Authorization, and Accounting (AAA) Registration Keys
                for Mobile IPv4", RFC 3957, March 2005.

Koodli & Perkins Experimental [Page 26] RFC 4988 MIP4 Fast Handovers October 2007

Authors' Addresses

 Rajeev Koodli
 Nokia Siemens Networks
 313 Fairchild Driive
 Mountain View, CA 94043
 USA
 EMail: rajeev.koodli@nokia.com
 Charles Perkins
 Nokia Siemens Networks
 313 Fairchild Driive
 Mountain View, CA 94043
 USA
 EMail: charles.perkins@nokia.com

Koodli & Perkins Experimental [Page 27] RFC 4988 MIP4 Fast Handovers October 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Koodli & Perkins Experimental [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4988.txt · Last modified: 2007/10/25 23:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki