draft-ietf-mip4-fmipv4-03.txt   draft-ietf-mip4-fmipv4-04.txt 
Mobile IPv4 Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins MIP4 Working Group Rajeev. Koodli
Experimental Nokia Research Center Internet-Draft Charles. Perkins
6 February 2007 Intended status: Experimental Nokia Research Center
Expires: August 27, 2007 February 23, 2007
Mobile IPv4 Fast Handovers 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 By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note Task Force (IETF), its areas, and its working groups. Note that
that other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a submission of the IETF MIP4 WG. Comments should This Internet-Draft will expire on August 27, 2007.
be directed to the MIP4 WG mailing list, mip4@ietf.org.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document adapts the Mobile IPv6 Fast Handovers [1] to This document adapts the Mobile IPv6 Fast Handovers to improve delay
improve delay and packet loss resulting from Mobile IPv4 handover and packet loss resulting from Mobile IPv4 handover operations.
operations. Specifically, this document addresses movement Specifically, this document addresses movement detection, IP address
detection, IP address configuration and location update latencies configuration and location update latencies during a handover. For
during a handover. For reducing the IP address configuration reducing the IP address configuration latency, the document proposes
latency, the document proposes that the new Care-of Address is that the new Care-of Address is always made to be the new access
always made to be the new access router's IP address. Additional router's IP address. Additional mechanisms may be defined in the
mechanisms may be defined in the future versions of this document. future versions of this document.
Contents Table of Contents
Abstract i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Factors Affecting Handover . . . . . . . . . . . . . . . . . . 4
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Using Previous FA Notification Extension . . . . . . . . . . . 9
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 9
6.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 10
6.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 12
6.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . . 13
6.5. Inter-Access Router Messages . . . . . . . . . . . . . . . 16
6.5.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 16
6.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 17
7. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Link-Layer Address Option Format . . . . . . . . . . . . . 19
7.2. New IPv4 Address Option Format . . . . . . . . . . . . . . 20
7.3. New Router Prefix Information Option . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 2 1. Introduction
2. Factors Affecting Handover 3 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 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 [rfc3344] and Fast Handovers for
Mobile IPv6 [rfc4068].
3. Protocol 4 The active agents that enable continued packet delivery to a mobile
3.1. Overview . . . . . . . . . . . . . . . . . 4 node (MN) are the access routers on the networks that the mobile node
3.2. Operation . . . . . . . . . . . . . . . . . 5 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).
4. Use of Previous FA Notification Extension 8 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.
5. Message Formats 9 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
5.1. Fast Binding Update (FBU) . . . . . . . . . . . . 9 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
5.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . 11 document are to be interpreted as described in [RFC2119].
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) . 13
5.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . 15
5.5. Inter-Access Router Messages . . . . . . . . . . 17
5.5.1. Handover Initiate (HI) . . . . . . . . . 17
5.5.2. Handover Acknowledge (HAck) . . . . . . . . 19
6. Option formats 22 2. Terminology
6.1. Link-Layer Address Option Format . . . . . . . . . 22
6.2. New IPv4 Address Option Format . . . . . . . . . . 23
6.3. New Router Prefix Information Option . . . . . . . . 24
7. Security Considerations 25 The terminology used in this document in based on [rfc4068] and
[rfc3344]. We provide some definitions below for convenience.
8. IANA Considerations 25 Mobile Node (MN): A Mobile IPv6 host.
9. Acknowledgement 25 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).
Intellectual Property Statement 27 Access Router (AR): The MN's default router.
Disclaimer of Validity 27 Previous Access Router (PAR): The MN's default router prior to its
handover.
Copyright Statement 28 New Access Router (NAR): The MN's default router subsequent to its
handover.
Acknowledgment 28 Previous CoA (PCoA): The MN's Care of Address valid on PAR's
1. Introduction subnet.
This document adapts the fast handover specification [1] to New CoA (NCoA): The MN's Care of Address valid on NAR's subnet.
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] registration messages are re-used (with
new type numbers) 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] and Fast Handovers for
Mobile IPv6 [1].
The active agents that enable continued packet delivery to a mobile Handover: A process of terminating existing connectivity and
node (MN) are the access routers on the networks that the mobile obtaining new IP connectivity.
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]. 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 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
via DHCP [6] (i.e., Co-located Care-of Address) or use the Foreign addresses, and the prefix valid on the interface to which the
Agent CoA. During a handover, the new CoA (NCoA) is always made Access Point (identified by AP-ID) is attached. The triplet
to be that of NAR. This allows a mobile node to receive and send [Router's L2 address, Router's IP address, Prefix] is called "AR-
packets using its previous CoA (PCoA), so that delays resulting Info".
from IP configuration (such as DHCP address acquisition delay)
subsequent to attaching to the new link are disengaged from
affecting the existing sessions.
2. Factors Affecting Handover 3. Factors Affecting Handover
Both the link-layer operations and IP layer procedures affect the Both the link-layer operations and IP layer procedures affect the
perceived handover performance. However, the overall performance perceived handover performance. However, the overall performance is
is also (always) a function of specific implementation of the also (always) a function of specific implementation of the technology
technology as well as the system configuration. This document as well as the system configuration. This document only specifies IP
only specifies IP layer protocol operations. The purpose of layer protocol operations. The purpose of this section is to provide
this section is to provide an illustration of events that affect an illustration of events that affect handover performance, but it is
handover performance, but it is purely informative. purely informative.
The IP layer handover delay and packet loss are influenced by The IP layer handover delay and packet loss are influenced by
latencies due to movement detection, IP address configuration and latencies due to movement detection, IP address configuration and
Mobile IP registration procedure. Movement detection latency Mobile IP registration procedure. Movement detection latency comes
comes from the need to reliably detect movement to a new subnet. from the need to reliably detect movement to a new subnet. This is a
This is a function of frequency of router advertisements as well function of frequency of router advertisements as well as default
as default agent reachability. IP address configuration latency agent reachability. IP address configuration latency depends on the
depends on the particular IP CoA being used. If co-located mode particular IP CoA being used. If co-located mode with DHCP is used,
with DHCP is used, the latency is quite likely going to be higher the latency is quite likely going to be higher and unacceptable for
and unacceptable for real-time applications such as Voice over IP. real-time applications such as Voice over IP. Finally, the Mobile IP
Finally, the Mobile IP registration procedure needs a round-trip of registration procedure needs a round-trip of delay between the Mobile
delay between the Mobile Node and its Home Agent over the Internet. Node and its Home Agent over the Internet. This delay is incurred
This delay is incurred after the mobile node performs movement after the mobile node performs movement detection and IP
detection and IP configuration. configuration.
Underlying the IP operations are link-layer procedures. These are Underlying the IP operations are link-layer procedures. These are
clearly technology-specific. For instance in IEEE 802.11, the clearly technology-specific. For instance in IEEE 802.11, the
handover operation typically involves scanning access points over handover operation typically involves scanning access points over all
all available channels, selecting a suitable access point, and available channels, selecting a suitable access point, and
associating with it. It may also involve performing access control associating with it. It may also involve performing access control
operations such as those specified in IEEE 802.1X [4]. These operations such as those specified in IEEE 802.1X [ieee-802.1x].
delays contribute to the handover performance. Optimizations are These delays contribute to the handover performance. Optimizations
being proposed for standardization in IEEE, for instance see [5] are being proposed for standardization in IEEE, for instance see
and [3]. Together with appropriate implementation techniques, [ieee-802.11r] and [ieee-802.21]. Together with appropriate
these optimizations can provide the required level of delay support implementation techniques, these optimizations can provide the
at the link-layer for real-time applications. required level of delay support at the link-layer for real-time
applications.
3. Protocol 4. Protocol
3.1. Overview 4.1. Overview
The design of the protocol is the same as for Mobile IPv6 [1]. The design of the protocol is the same as for Mobile IPv6 [rfc4068].
Readers should consult [1] for details, and here we provide a Readers should consult [rfc4068] for details, and here we provide a
summary. summary.
The protocol avoids the delay due to movement detection and IP The protocol avoids the delay due to movement detection and IP
configuration and disengage Mobile IP registration delay from configuration and disengages Mobile IP registration delay from the
the time-critical path. The protocol provides the surrounding time-critical path. The protocol provides the surrounding network
network network neighborhood information so that a mobile node can neighborhood information so that a mobile node can determine whether
determine whether it is moving to a new subnet even before the it is moving to a new subnet even before the handover. The
handover. The information provided and the signaling exchanged information provided and the signaling exchanged between the local
between the local mobility agents allows the mobile node to send mobility agents allows the mobile node to send and receive packets
and receive packets immediately after handover. In order to immediately after handover. In order to disengage the Mobile IP
disengage the Mobile IP registration latency, the protocol provides registration latency, the protocol provides routing support for the
routing support for the continued use of a mobile node's previous continued use of a mobile node's previous CoA.
CoA.
After a mobile node obtains its IPv4 care-of address, it builds After a mobile node obtains its IPv4 care-of address, it builds a
a neighborhood access point and subnet map using the Router neighborhood access point and subnet map using the Router
Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
Advertisement (PrRtAdv) messages. The mobile node may scan for Advertisement (PrRtAdv) messages. The mobile node may scan for
access points (APs) based on the configuration policy in operation access points (APs) based on the configuration policy in operation
for its wireless network interface. If a scan results in a new AP for its wireless network interface. If a scan results in a new AP
discovery, the mobile node resolves the corresponding AP Identifier discovery, the mobile node resolves the corresponding AP Identifier
to subnet information using the RtSolPr and PrRtAdv messages to subnet information using the RtSolPr and PrRtAdv messages
mentioned above. mentioned above.
At some point, the mobile node decides to undergo handover. It At some point, the mobile node decides to undergo handover. It sends
sends an FBU message to PAR from the previous link or from the new an FBU message to PAR from the previous link or from the new link.
link. FBU message enables creation of a binding between the mobile FBU message enables creation of a binding between the mobile node's
node's previous CoA and the new CoA. previous CoA and the new CoA.
The coordination between the access routers is done by way of the The coordination between the access routers is done by way of the
Handover Initiate (HI) and Handover Acknowledge (HAck) messages Handover Initiate (HI) and Handover Acknowledge (HAck) messages
defined in [1]. After these signals have been exchanged between defined in [rfc4068]. After these signals have been exchanged
the previous and new access routers (PAR and NAR), data arriving between the previous and new access routers (PAR and NAR), data
at PAR will be tunneled to NAR for delivery to the newly arrived arriving at PAR will be tunneled to NAR for delivery to the newly
mobile node. The purpose of HI is to securely deliver the routing arrived mobile node. The purpose of HI is to securely deliver the
parameters for establishing this tunnel. The tunnel is created by routing parameters for establishing this tunnel. The tunnel is
the access routers in response to the delivery of the FBU from the created by the access routers in response to the delivery of the FBU
mobile node. from the mobile node.
3.2. Operation 4.2. Operation
In response to a handover trigger or indication, the mobile node In response to a handover trigger or indication, the mobile node
sends a Fast Binding Update message to Previous Access Router (PAR) sends a Fast Binding Update message to Previous Access Router (PAR)
(see Section 5.1). Depending on whether the Mobile IP mode of (see Section Section 6.1). Depending on the Mobile IP mode of
operation, the PCoA is either the Home Address (in FA CoA mode) operation, the PCoA is either the Home Address (in FA CoA mode) or
or co-located CoA (in CCoA mode). The FBU message SHOULD be sent co-located CoA (in CCoA mode). The FBU message SHOULD be sent when
when the mobile node is still connected to PAR. When sent in this the mobile node is still connected to PAR. When sent in this
``predictive'' mode, the fields in the FBU are used as follows: "predictive" mode, the fields in the FBU are used as follows:
- ``Home Address'' field must be the PCoA (which can be either "Home Address" field must be the PCoA (which can be either the
the Home Address or the co-located CoA) Home Address or the co-located CoA)
- Home Agent field, even though redundant, must be set to PAR's Home Agent field, even though redundant, must be set to PAR's IP
IP address address
- Care-of Address field must be the NAR's IP address discovered Care-of Address field must be the NAR's IP address discovered via
via PrRtAdv message PrRtAdv message
- Destination IP address must be PAR's IP address Destination IP address must be PAR's IP address
- Source IP address must be the PCoA (which can be either the Source IP address must be the PCoA (which can be either the Home
Home Address or the co-located CoA) Address or the co-located CoA)
As a result of processing the FBU, PAR creates a binding between As a result of processing the FBU, PAR creates a binding between PCoA
PCoA and NAR's IP address in its routing table. The PAR sends an and NAR's IP address in its routing table. The PAR sends an FBack
FBack message (see 5.2) as a response to the mobile node. message (see Section Section 6.2) as a response to the mobile node.
The timeline for the predictive mode of operation (adapted The timeline for the predictive mode of operation (adapted from
from [1]) is shown in Figure 1. [rfc4068]) is shown in Figure Figure 1.
MN PAR NAR MN PAR NAR
| | | | | |
|------RtSolPr------->| | |------RtSolPr------->| |
|<-----PrRtAdv--------| | |<-----PrRtAdv--------| |
| | | | | |
|------FBU----------->|--------HI--------->| |------FBU----------->|--------HI--------->|
| |<------HAck---------| | |<------HAck---------|
| <--FBack---|--FBack---> | | <--FBack---|--FBack---> |
| | | | | |
skipping to change at page 6, line 29 skipping to change at page 7, line 29
| | | | | |
| | | | | |
connect | | connect | |
| | | | | |
|--------- FBU --------------------------->| |--------- FBU --------------------------->|
|<=================================== deliver packets |<=================================== deliver packets
| |<-----FBU-----------| | |<-----FBU-----------|
Figure 1: Predictive Fast Handover Figure 1: Predictive Fast Handover
The mobile node sends the FBU regardless of its previous The mobile node sends the FBU regardless of its previous transmission
transmission when attachment to a new link is detected. This when attachment to a new link is detected. This minimally allows NAR
minimally allows NAR to detect mobile node's attachment, but also to detect mobile node's attachment, but also the retransmission of
the retransmission of FBU when an FBack has not been received yet. FBU when an FBack has not been received yet. When sent in this
When sent in this ``reactive'' mode, the following fields in FBU "reactive" mode, the following fields in FBU are set differently
are set differently compared to the predictive mode: compared to the predictive mode:
- Destination IP address must be NAR's IP address Destination IP address must be NAR's IP address
- Source IP address must be PCoA (either the Home Address or the Source IP address must be PCoA (either the Home Address or the co-
co-located CoA) located CoA)
When NAR receives FBU, it may already have processed the HI message 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 and created a host route entry for the PCoA. In that case, NAR
should immediately forward arriving and buffered packets including should immediately forward arriving and buffered packets including
the FBAck message. In any case, NAR MUST forward the contents of the FBAck message. In any case, NAR MUST forward the contents of
this message, starting from the Type field, to PAR, which means the this message, starting from the Type field, to PAR, which means the
Source and Destination IP addresses now contain the IP addresses of Source and Destination IP addresses in the new packet now contain the
NAR and PAR respectively. IP addresses of NAR and PAR respectively.
The reactive mode of operation (adapted from [1]) is illustrated in
Figure 2.
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.
Even though the mobile node can obtain this NCoA from the NAR, it The reactive mode of operation (adapted from [rfc4068]) is
is unaware of the address at the time it sends an FBU. Hence, it illustrated in Figure Figure 2.
binds PCoA to NAR's IP address as before.
MN PAR NAR MN PAR NAR
| | | | | |
|------RtSolPr------->| | |------RtSolPr------->| |
|<-----PrRtAdv--------| | |<-----PrRtAdv--------| |
| | | | | |
disconnect | | disconnect | |
| | | | | |
| | | | | |
connect | | connect | |
skipping to change at page 8, line 25 skipping to change at page 8, line 28
| |<-----FBU-----------| | |<-----FBU-----------|
| |------FBack-------->| | |------FBack-------->|
| forward | | forward |
| packets===============>| | packets===============>|
| | | | | |
|<=================================== deliver packets |<=================================== deliver packets
| | | |
Figure 2: Reactive Fast Handover Figure 2: Reactive Fast Handover
4. Use of Previous FA Notification Extension 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.
5. Using Previous FA Notification Extension
Sending FBU from the new link (i.e., reactive mode) is similar to Sending FBU from the new link (i.e., reactive mode) is similar to
using the extension defined in [2]. However, with the neighborhood using the extension defined in [draft-mip4-ro]. However, with the
information gathered using the proxy router messages (see neighborhood information gathered using the proxy router messages
Section 5.3, Section 5.4), movement detection and router discovery (see Section Section 6.3, Section Section 6.4), movement detection
delays are avoided even in the reactive case. The FBU and FBAck and router discovery delays are avoided even in the reactive case.
messages defined in this document can be naturally used even when The FBU and FBAck messages defined in this document can be naturally
no neighborhood information is available. used even when no neighborhood information is available.
5. Message Formats 6. Message Formats
5.1. Fast Binding Update (FBU) 6.1. Fast Binding Update (FBU)
The FBU format is bitwise identical to the Registration Request The FBU format is bitwise identical to the Registration Request
format in RFC 3344. The same destination port number, 434, is format in [rfc3344]. The same destination port number, 434, is used,
used, but the FBU and FBAck messages in this specification have new but the FBU and FBAck messages in this specification have new message
message type numbers. type numbers.
0 1 2 3 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 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 | | Type |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Figure 3: Fast Binding Update (FBU) Message 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).
Source address Destination Address: The IP address of the Previous Access Router
The interface address from which the or the New Access Router.
message is sent. Either PCoA (co-located
or Home Address), or NAR's IP address
(when forwarded from NAR to PAR).
Destination Address Source Port: variable
The IP address of the Previous Access
Router or the New Access Router.
Source Port variable Destination port: 434
Destination port 434 Type: To be assigned by IANA
Type To be assigned by IANA Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are
sent as zero, and ignored on reception.
Flags See RFC 3344 reserved: Sent as zero, ignored on input
reserved Sent as zero, ignored on input Lifetime: The number of seconds remaining before binding
expires. MUST NOT exceed 10 seconds.
Lifetime The number of seconds remaining before Home Address: MUST be PCoA, which can either be the co-located
binding expires. MUST NOT exceed 10 CoA or the Home Address
seconds.
Home Address MUST be PCoA (i.e., either co-located CoA or Home Agent: The Previous Access Router's global IP address
Home Address)
Home Agent The Previous Access Router's global IP Care-of Address: The New Access Router's global IP address
address
Care-of Address The New Access Router's global IP address Identification: a 64-bit number used for matching an FBU with
FBack. Identical to usage in [rfc3344]
Identification See RFC 3344 Extensions: MUST contain the MN - PAR Authentication Extension
Extensions MUST contain the MN - PAR Authentication 6.2. Fast Binding Acknowledgment (FBAck)
Extension
5.2. Fast Binding Acknowledgment (FBAck)
The FBAck format is bitwise identical to the Registration Reply The FBAck format is bitwise identical to the Registration Reply
format in [2]. format in [rfc3344].
0 1 2 3 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 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 | | Type | Code | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Figure 4: Fast Binding Acknowledgment (FBAck) Message Figure 4: Fast Binding Acknowledgement (FBAck) Message
IP fields:
Source address Source address: Typically copied from the destination address of
Typically copied from the destination the FBU message
address of the FBU message
Destination Address Destination Address: Copied from the Source IP address in FBU
Copied from the Source IP address in FBU
message message
Source Port variable Source Port: variable
Destination port copied from the source port in FBU message Destination port: copied from the source port in FBU message
Type To be assigned by IANA Type: To be assigned by IANA
Code Indicates the result of processing FBU Code: Indicates the result of processing FBU message. Code = 0
message. Code = 0 means Fast Binding Update means Fast Binding Update accepted. Code = 1 means Fast
accepted. Code = 1 means Fast Binding Binding Update accepted but NCoA is supplied as an extension.
Update accepted but NCoA is supplied as an
extension.
reserved Sent as zero, ignored on input reserved: Sent as zero, ignored on input
Lifetime The number of seconds remaining before Lifetime: The granted number of seconds remaining before
binding expires. MUST NOT exceed 10 binding expires.
seconds.
Home Address PCoA (i.e., either co-located CoA or Home Home Address: PCoA (i.e., either co-located CoA or Home
Address) Address)
Home Agent The Previous Access Router's global IP Home Agent: The Previous Access Router's global IP address
address Identification: a 64-bit number used for matching FBU. Copied
from the field in FBU for which this FBack is a reply.
Identification a 64-bit number used for matching FBU. See
RFC 3344.
Extensions The PAR - MN Authentication extension MUST Extensions: The PAR - MN Authentication extension MUST be
be present. In addition, an NCoA option present. In addition, an NCoA option MUST be present when NAR
MUST be present when NAR supplies the NCoA. supplies the NCoA.
If the FBAck message indicates that the new care-of address is a If the FBAck message indicates that the new care-of address is a
Foreign Agent care-of address [2], then the mobile node MUST set Foreign Agent care-of address [rfc3344], then the mobile node MUST
the 'D' bit in its Registration Request message that it uses to set the 'D' bit in its Registration Request message that it uses to
register the NCoA with its home agent. register the NCoA with its home agent.
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) 6.3. Router Solicitation for Proxy Advertisement (RtSolPr)
Mobile Nodes send Router Solicitation for Proxy Advertisement in Mobile Nodes send Router Solicitation for Proxy Advertisement in
order to prompt routers for Proxy Router Advertisements. All the order to prompt routers for Proxy Router Advertisements. All the
link-layer address options have the format defined in 6.1. The link-layer address options have the format defined in Section 7.1.
message format and processing rules are identical to those defined The message format and processing rules are identical to those
in [1]. We only provide the format here for convenience. defined in [rfc4068].
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier | | Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Router Solicitation for Proxy (RtSolPr) Message Figure 5: Router Solicitation for Proxy Advertisement (RtSolPr)
Message
IP Fields: IP Fields:
Source Address Source Address: An IP address assigned to the sending interface
An IP address assigned to the sending interface
Destination Address Destination Address: The address of the Access Router or the
The address of the Access Router or the all routers all routers multicast address.
multicast address.
Time-to-Live At least 1. See RFC 1256. Time-to-Live: At least 1. See [rfc1256].
ICMP Fields: ICMP Fields:
Type To be assigned by IANA Type: To be assigned by IANA
Code 0 Code: 0
Checksum The 16-bit one's complement of the one's Checksum: The 16-bit one's complement of the one's complement
complement sum of the ICMP message, start- sum of the ICMP message, start ing with the ICMP Type. For
ing with the ICMP Type. For computing the computing the checksum, the Checksum and the Reserved fields
checksum, the Checksum and the Reserved fields are are set to 0. See [rfc1256].
set to 0. See RFC 1256.
Subtype To be assigned by IANA Subtype: To be assigned by IANA
Reserved MUST be set to zero by the sender and ignored by Reserved: MUST be set to zero by the sender and ignored by the
the receiver. receiver.
Identifier MUST be set by the sender so that replies can be Identifier: MUST be set by the sender so that replies can be
matched to this Solicitation. matched to this Solicitation.
Valid Options: Valid Options:
New Access Point Link-layer Address New Access Point Link-layer Address: The link-layer address or
The link-layer address or identification of the identification of the access point for which the MN requests
access point for which the MN requests routing routing advertisement information. It MUST be included in all
advertisement information. It MUST be included RtSolPr messages. More than one such address or identifier can
in all RtSolPr messages. More than one such address be present. This field can also be a wildcard address (see
or identifier can be present. This field can also Section 7.1).
be a wildcard address with all bits set to zero.
5.4. Proxy Router Advertisement (PrRtAdv) 6.4. Proxy Router Advertisement (PrRtAdv)
Access routers send out Proxy Router Advertisement message Access routers send out Proxy Router Advertisement message
gratuitously if the handover is network-initiated or as a response gratuitously if the handover is network-initiated or as a response to
to RtSolPr message from a mobile node, providing the link-layer RtSolPr message from a mobile node, providing the link-layer address,
address, IP address and subnet prefixes of neighboring routers. IP address and subnet prefixes of neighboring routers. All the link-
All the link-layer address options have the format defined in 6.1. layer address options have the format defined in Section 7.1.
The message format and processing rules are identical to those The message format and processing rules are identical to those
defined in [1]. We only provide the format here for convenience. defined in [rfc4068].
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier | | Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Proxy Router Advertisement (PrRtAdv) Message Figure 6: Proxy Router Advertisement (PrRtAdv) Message
IP Fields: IP Fields:
Source Address Source Address: An IP address assigned to the sending interface
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 RFC 1256. 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: ICMP Fields:
Type To be assigned by IANA Type: To be assigned by IANA
Code 0, 1, 2, 3 or 4. See below. Code 0, 1, 2, 3 or 4. See below.
Checksum The 16-bit one's complement of the one's Checksum: The 16-bit one's complement of the one's complement
complement sum of the ICMP message, start- sum of the ICMP message, start- ing with the ICMP Type. For
ing with the ICMP Type. For computing the computing the checksum, the Checksum and the Reserved fields
checksum, the Checksum and the Reserved fields are are set to 0. See [rfc1256].
set to 0. See RFC 1256.
Subtype To be assigned by IANA. Subtype: To be assigned by IANA.
Reserved MUST be set to zero by the sender and ignored by Reserved: MUST be set to zero by the sender and ignored by the
the receiver. receiver.
Identifier Copied from Router Solicitation for Proxy Identifier: Copied from Router Solicitation for Proxy
Advertisement or set to Zero if unsolicited. Advertisement or set to Zero if unsolicited.
Valid Options in the following order: Valid Options in the following order:
New Access Point Link-layer Address New Access Point Link-layer Address: The link-layer address or
The link-layer address or identification of the identification of the access point is copied from RtSolPr
access point is copied from RtSolPr
message. This option MUST be present. message. This option MUST be present.
New Router's Link-layer Address New Router's Link-layer Address: The link-layer address of the
The link-layer address of the Access Router for Access Router for which this message is proxied for. This
which this message is proxied for. This option MUST be option MUST be included when Code is 0 or 1.
included when Code is 0 or 1.
New Router's IP Address New Router's IP Address: The IP address of NAR. This option
The IP address of NAR. This option MUST be MUST be included when Code is 0 or 1.
included when Code is 0 or 1.
New Router Prefix Information Option New Router Prefix Information Option: The number of leading
The number of leading bits that define the network bits that define the network number of the corresponding
number of the corresponding Router's IP Address Router's IP Address option (see above).
option (see above).
New CoA 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 New CoA 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. In
any case, the MN should be prepared to use this address instead
of performing DHCP or similar operations to obtain an IPv4
address.
5.5.1. Handover Initiate (HI) 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 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 Option-Code field (see Section 7.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 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 The Handover Initiate (HI) is an ICMP message sent by an Access
Router (typically PAR) to another Access Router (typically NAR) to Router (typically PAR) to another Access Router (typically NAR) to
initiate the process of a mobile node's handover. initiate the process of a mobile node's handover.
The message format and processing rules are identical to those The message format and processing rules are identical to those
defined in [1]. We only provide the format here for convenience. defined in [rfc4068].
IP Fields:
Source Address
The IP address of the PAR
Destination Address
The IP address of the NAR
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier | | Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Handover Initiate (HI) Message Figure 7: Handover Initiate (HI) Message
Time-to-Live At least 1. See RFC 1256. IP Fields:
ICMP Fields: Source Address: The IP address of the PAR
Type To be assigned by IANA Destination Address: The IP address of the NAR
Code 0 or 1. See below Time-to-Live: At least 1. See [rfc1256].
Checksum The 16-bit one's complement of the one's ICMP Fields:
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 To be assigned by IANA Type: To be assigned by IANA
S Assigned address configuration flag. When set, this Code: 0 or 1. See below
message requests a new CoA to be returned by the Checksum: The 16-bit one's complement of the one's complement
destination. May be set when Code = 0. MUST be 0 sum of the ICMP message, start- ing with the ICMP Type. For
when Code = 1. computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256].
U Buffer flag. When set, the destination SHOULD buffer Subtype: To be assigned by IANA
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 S: Assigned address configuration flag. When set, this message
the receiver. requests a new CoA to be returned by the destination. May be
set when Code = 0. MUST be 0 when Code = 1.
Identifier MUST be set by the sender so replies can be matched 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. to this message.
Valid Options: Valid Options:
Link-layer address of MN Link-layer address of MN: The link-layer address of the MN that
The link-layer address of the MN that is is undergoing handover to the destination (i.e., NAR). This
undergoing handover to the destination (i.e., NAR). option MUST be included so that the destination can recognize
This option MUST be included so that the destination the MN.
can recognize the MN.
Previous Care of Address Previous Care of Address: The IP address used by the MN while
The IP address used by the MN while attached to the originating router. This option MUST be
attached to the originating router. This option included so that a host route can be established on the NAR.
SHOULD be included so that host route can be
established in case necessary.
New Care of Address New Care of Address: This option MAY be present when the MN
The IP address the MN wishes to use when wishes to use a new IP address when connected to the
connected to the destination. When the `S' bit is destination. When the 'S' bit is set, NAR MAY provide this
set, NAR MAY assign this address. 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. Handover Acknowledge (HAck) 6.5.2. Handover Acknowledge (HAck)
The Handover Acknowledgment message is a new ICMP message that The Handover Acknowledgment message is a new ICMP message that MUST
MUST be sent (typically by NAR to PAR) as a reply to the Handover be sent (typically by NAR to PAR) as a reply to the Handover Initiate
Initiate (HI) (see section 5.5.1) message. (HI) (see Section Section 6.5.1) message.
The message format and processing rules are identical to those The message format and processing rules are identical to those
defined in [1]. We only provide the format here for convenience. defined in [rfc4068].
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier | | Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Handover Acknowledge (HAck) Message Figure 8: Handover Acknowledge (HAck) Message
IP Fields: IP Fields:
Source Address Source Address: Copied from the destination address of the
Copied from the destination address of the Handover Handover Initiate Message to which this message is a response.
Initiate Message to which this message is a
response.
Destination Address Destination Address: Copied from the source address of the
Copied from the source address of the Handover Handover Initiate Message to which this message is a response.
Initiate Message to which this message is a
response.
Time-to-Live At least 1. See RFC 1256. Time-to-Live: At least 1. See [rfc1256].
ICMP Fields: ICMP Fields:
Type To be assigned by IANA Type: To be assigned by IANA
Code Code:
0: Handover Accepted, NCoA valid
0: Handover Accepted
1: Handover Accepted, NCoA not valid 1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use 2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned 3: Handover Accepted, NCoA assigned (used in Assigned
(used in Assigned addressing) addressing)
4: Handover Accepted, NCoA not assigned 4: Handover Accepted, NCoA not assigned
(used in Assigned addressing)
128: Handover Not Accepted, reason unspecified 128: Handover Not Accepted, reason unspecified
129: Administratively prohibited 129: Administratively prohibited
130: Insufficient resources 130: Insufficient resources
Checksum The 16-bit one's complement of the one's Checksum: The 16-bit one's complement of the one's complement
complement sum of the ICMP message, start- sum of the ICMP message, start- ing with the ICMP Type. For
ing with the ICMP Type. For computing the computing the checksum, the Checksum and the Reserved fields
checksum, the Checksum and the Reserved fields are are set to 0. See [rfc1256].
set to 0. See RFC 1256.
Subtype To be assigned by IANA. Subtype: To be assigned by IANA.
Reserved MUST be set to zero by the sender and ignored by Reserved: MUST be set to zero by the sender and ignored by the
the receiver. receiver.
Identifier Copied from the corresponding field in the Handover Identifier: Copied from the corresponding field in the Handover
Initiate message this message is in response to. Initiate message this message is in response to.
Valid Options: Valid Options:
New Care of Address New Care of Address: If the 'S' flag in the HI message is set,
If the S flag in the Handover Initiate message is set, this option MUST be used to provide NCoA the MN should use when
this option MUST be used to provide NCoA the MN should connected to this router. This option MAY be included even
use when connected to this router. This option MAY be when 'S' bit is not set, e.g., Code 2 above. The MN should be
included even when `S' bit is not set, e.g., Code 2 prepared to use this address instead of performing DHCP or
above. similar operations to obtain an IPv4 address.
6. Option formats 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.
The options in this section are specified as optional extensions 7. Option Formats
for the HI and HAck messages, as well as for the Router Proxy
Solicitation and Router Proxy Advertisement messages..
6.1. Link-Layer Address Option Format The options in this section are specified as extensions for the HI
and HAck messages, as well as for the PrRtSol and PrRtAdv messages.
7.1. Link-Layer Address Option Format
0 1 2 3 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 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 ... | Type | Length | Option-Code | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Link-Layer Address Option Format Figure 9: Link Layer Address Option Format
Fields: Fields:
Type Type: To be assigned by IANA
1 Mobile Node Link-layer Address Option-Code:
2 New Access Point Link-layer Address
3 NAR Link-layer Address
Length The length of the option (including the type and 0: wildcard requesting resolution for all nearby access
length fields) in units of octets. For example, points
the length for IEEE 802 addresses is 1 [IPv6- 1: Link-Layer Address of the New Access Point
ETHER]. 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
Link-Layer Address Length: The length of the option (including the Type, Length
The variable length link-layer address. and Option-Code fields) in units of 8 octets.
The content and format of this field (including Link-Layer Address: The variable length link-layer address.
byte and bit ordering) depends on the specific The content and format of this field (including byte and bit
link-layer in use. ordering) depends on the specific link-layer in use.
6.2. New IPv4 Address Option Format 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.
This option is used to provide the new router's IPv4 address in 7.2. New IPv4 Address Option Format
PrRtAdv. When it is also used to provide NCoA, it MUST appear
after the new router's IPv4 address to distinguish the two This option is used to provide the new router's IPv4 address or the
addresses. NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck messages.
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 Address | | New IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: New IPv4 Address Option Format Figure 10: New IPv4 Address Option Format
Fields: Fields:
Type Type: To be assigned by IANA
To be assigned by IANA
Length The length of the option (including the type and Length: The length of the option (including the Type, Length
length fields) in units of octets. and Option-Code fields) in units of 8 octets.
Reserved Set to zero. Option-Code:
New IPv4 Address 1: Previous CoA
NAR's IPv4 address or the NCoA assigned by NAR. 2: New CoA
3: NAR's IP Address
6.3. New Router Prefix Information Option Reserved: Set to zero.
This option is the same as the ``Prefix-Lengths Extension'' in RFC New IPv4 Address: NAR's IPv4 address or the NCoA assigned by
3344 (Section 2.1.2). NAR.
7.3. New Router Prefix Information Option
This option is used in the PrRtAdv message.
0 1 2 3 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 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 | Prefix-Length | Reserved | | Type | Length | Option-Code | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: New Router Prefix Information Option Format Figure 11: New Router Prefix Information Option Format
Fields: Fields:
Type Type: To be assigned by IANA
To be assigned by IANA
Length 1 Length: The length of the option (including the Type, Length
and Option-Code fields) in units of 8 octets.
Prefix-Length Option-Code: 0
The number of leading bits that define the network
number of the corresponding Router's IP Address
option.
Reserved Set to zero. Prefix-Length The number of leading bits that define the
network number of the corresponding Router's IP Address option.
7. Security Considerations Reserved: Set to zero.
The FBU and FBack messages MUST be protected using a security 8. 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 association shared between a mobile node and its access router. In
particular, the MN - PAR Authentication Extension MUST be present particular, the MN - PAR Authentication Extension MUST be present in
in each of these messages. Failure to include this extension can each of these messages. This document does not specify how the
lead to a bogus node claiming a genuine mobile node's address security association is established between a MN and the AR/FA.
and binding it to an arbitrary address. When the NCoA is NAR's
address, there is no risk of a genuine mobile node misdirecting
traffic, either inadvertently or intentionally, to an unsuspecting
node on NAR's subnet. When NCoA is other than NAR's address, NAR
MUST ensure that the proposed NCoA in HI is conflict-free, and
MUST indicate the disposition in the HAck message. If there is a
conflict, PAR MUST NOT tunnel packets to the address in question.
Instead, PAR SHOULD tunnel packets to the address specified in
HAck, if any is provided.
8. IANA Considerations Secure FBU, malicious or inadvertent redirection:
Even if the MN - PAR authentication extension is present in an FBU, a
MN may indevertently 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.
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 pre-existing
security association between the access routers to 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 All the messages and the option formats specified in this document
require Type assignment from IANA. require Type assignment from IANA. Specifically, the Types, Sub-
types and the Codes need assignment from ICMP, Mobile IP and
Experimental Mobility Type [rfc4065] registries.
9. Acknowledgement 10. Acknowledgement
Thanks to all those who expressed interest in having a Fast Thanks to all those who expressed interest in having a Fast Handovers
Handovers for Mobile IPv4 protocol along the lines of [1]. Thanks for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to
to Vijay Devarapalli, Keng Leung, Alex Petrescu for their review Vijay Devarapalli, Keng Leung for their review and input. Kumar
and input. Viswanath and Uday Mohan implemented an early version of this
protocol. Many thanks to Alex Petrescu for his thorough review that
improved this document.
Normative References 11. References
[1] R. (Editor) Koodli. Fast Handovers for Mobile IPv6. Request 11.1. Normative References
for Comments 4068, Internet Engineering Task Force, July 2005.
[2] C. Perkins (Editor). IP Mobility Support for IPv4. Request [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
for Comments (Proposed Standard) 3344, Internet Engineering Requirement Levels", BCP 14, RFC 2119, March 1997.
Task Force, August 2002.
Informative References [rfc1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[3] The IEEE 802.21 group. http://www.ieee802.org/21. Technical [rfc3344] Perkins (Editor), C., "IP Mobility Support for IPv4",
report, IEEE. RFC 3344, August 2002.
[4] IEEE Standard for Local and Metropolitan Area Networks: [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental
Port-Based Network Access Control. Technical report, IEEE. Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[5] IEEE Standard forLocal and Metropolitan Area Networks: [rfc4068] Koodli (Editor), R., "Fast Handovers for Mobile IPv6",
RFC 4068, July 2005.
11.2. Informative References
[draft-mip4-ro]
Perkins, C. and 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. Fast Roaming/Fast BSS Transition, the IEEE Task Group TGr.
Technical report, IEEE. Technical report, IEEE.".
[6] R. Droms. Dynamic Host Configuration Protocol. Request for [ieee-802.1x]
Comments (Draft Standard) 2131, Internet Engineering Task "IEEE Standard for Local and Metropolitan Area Networks:
Force, March 1997. Port-Based Network Access Control. Technical report,
IEEE.".
[7] C. Perkins and D. Johnson. Route Optimization in Mobile IP [ieee-802.21]
(work in progress). Internet Draft, Internet Engineering Task "The IEEE 802.21 group. http://www.ieee802.org/21.".
Force.
draft-ietf-mobileip-optim-09.txt, February 2000.
Questions about this memo can be directed to the authors: [rfc2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
Rajeev Koodli Charles E. Perkins Appendix A. Change Log
Nokia Research Center Nokia Research Center
975 Page Mill Road, 200 975 Page Mill Road, 200
Palo Alto, California 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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of Addressed the following Last Call and subsequent reviews:
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 Provided all the Code values in PrRtAdv message to cover various
assurances of licenses to be made available, or the result of an cases involving neighborhood discovery. Harmonized the option
attempt made to obtain a general license or permission for the formats with [rfc4068].
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 Added the Terminology Section
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 Added text regarding FBU message flags 'S' and 'B'
This document and the information contained herein are provided Revised text in Security Considerations
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 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 move from LaTex to xml turned out to be
quite a task, sigh..)
Authors' Addresses
Rajeev Koodli
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, CA 94304
USA
Email: charles.perkins@nokia.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 193 change blocks. 
541 lines changed or deleted 677 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/