draft-ietf-mip4-fmipv4-06.txt   draft-ietf-mip4-fmipv4-07.txt 
MIP4 Working Group Rajeev. Koodli MIP4 Working Group Rajeev. Koodli
Internet-Draft Charles. Perkins Internet-Draft Charles. Perkins
Intended status: Experimental Nokia Research Center Intended status: Experimental Nokia Research Center
Expires: November 5, 2007 May 4, 2007 Expires: November 18, 2007 May 17, 2007
Mobile IPv4 Fast Handovers Mobile IPv4 Fast Handovers
draft-ietf-mip4-fmipv4-06.txt draft-ietf-mip4-fmipv4-07.txt
Status of this Memo 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 that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in 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 Internet-Draft will expire on November 5, 2007. This Internet-Draft will expire on November 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document adapts the Mobile IPv6 Fast Handovers to improve delay This document adapts the Mobile IPv6 Fast Handovers to improve delay
and packet loss resulting from Mobile IPv4 handover operations. and packet loss resulting from Mobile IPv4 handover operations.
Specifically, this document addresses movement detection, IP address Specifically, this document addresses movement detection, IP address
skipping to change at page 2, line 24 skipping to change at page 2, line 24
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 9 6.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 9
6.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 11 6.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 11
6.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 12 6.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 12
6.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . . 14 6.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . . 14
6.5. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 16 6.5. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 16
6.6. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 18 6.6. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 18
7. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Link-Layer Address Option Format . . . . . . . . . . . . . 20 7.1. Link-Layer Address Option Format . . . . . . . . . . . . . 20
7.2. New IPv4 Address Option Format . . . . . . . . . . . . . . 21 7.2. New IPv4 Address Option Format . . . . . . . . . . . . . . 21
7.3. New Router Prefix Information Option . . . . . . . . . . . 21 7.3. New Router Prefix Information Option . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
This document adapts the fast handover specification [rfc4068] to This document adapts the fast handover specification [rfc4068] to
IPv4 networks. The fast handover protocol specified in this document IPv4 networks. The fast handover protocol specified in this document
is particularly interesting for operation over links such as IEEE 802 is particularly interesting for operation over links such as IEEE 802
wireless links. Fast handovers are not typically needed for wired wireless links. Fast handovers are not typically needed for wired
media due to the relatively large delays attributable to establishing media due to the relatively large delays attributable to establishing
new connections in today's wired networks. Mobile IPv4 [rfc3344] new connections in today's wired networks. Mobile IPv4 [rfc3344]
skipping to change at page 9, line 34 skipping to change at page 9, line 34
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 [draft-mip4-ro]. However, with the using the extension defined in [draft-mip4-ro]. However, with the
neighborhood information gathered using the proxy router messages neighborhood information gathered using the proxy router messages
(see Section 6.3, Section 6.4), movement detection and router (see Section 6.3, Section 6.4), movement detection and router
discovery delays are avoided even in the reactive case. The FBU and discovery delays are avoided even in the reactive case. The FBU and
FBAck messages defined in this document can be naturally used even FBAck messages defined in this document can be naturally used even
when no neighborhood information is available. when no neighborhood information is available.
6. Message Formats 6. 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.
6.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 [rfc3344]. The same destination port number, 434, is used, format in [rfc3344]. The same destination port number, 434, is used,
but the FBU and FBAck messages in this specification have new message but the FBU and FBAck messages in this specification have new 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 6 skipping to change at page 11, line 6
reserved: Sent as zero, ignored on input reserved: Sent as zero, ignored on input
Lifetime: The number of seconds remaining before binding Lifetime: The number of seconds remaining before binding
expires. MUST NOT exceed 10 seconds. expires. MUST NOT exceed 10 seconds.
Home Address: MUST be PCoA, which can either be the co-located Home Address: MUST be PCoA, which can either be the co-located
CoA or the Home Address CoA or the Home Address
Home Agent: The Previous Access Router's global IP address Home Agent: The Previous Access Router's global IP address
Care-of Address: The New 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 6.4),
NAR's IP address MUST be used for this field.
Identification: a 64-bit number used for matching an FBU with Identification: a 64-bit number used for matching an FBU with
FBack. Identical to usage in [rfc3344] FBack. Identical to usage in [rfc3344]
Extensions: MUST contain the MN - PAR Authentication Extension Extensions: MUST contain the MN - PAR Authentication Extension
The MN - PAR Authentication Extension is the Generalized Mobile IP The MN - PAR Authentication Extension is the Generalized Mobile IP
Authentication Extension in [rfc4721] with a new Subtype for MN - PAR Authentication Extension in [rfc4721] with a new Subtype for MN - PAR
Authentication. The Authenticator field in the Generalized Mobile IP Authentication. The Authenticator field in the Generalized Mobile IP
Authentication Extension is calculated using a shared key between the Authentication Extension is calculated using a shared key between the
MN and the PAR. However, the key distribution itself is beyond 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 scope of this document, and is assumed to be performed by other means
(using [rfc3957] for example). (for example, using [rfc3957]).
6.2. Fast Binding Acknowledgment (FBAck) 6.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 [rfc3344]. 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 |
skipping to change at page 13, line 29 skipping to change at page 13, line 29
Source Address: An IP address assigned to the sending interface Source Address: An IP address assigned to the sending interface
Destination Address: The address of the Access Router or the Destination Address: The address of the Access Router or the
all routers multicast address. all routers multicast address.
Time-to-Live: At least 1. See [rfc1256]. Time-to-Live: At least 1. See [rfc1256].
ICMP Fields: ICMP Fields:
Type: To be assigned by IANA Type: 41. See Section 3 in [rfc4065].
Code: 0 Code: 0
Checksum: The 16-bit one's complement of the one's complement Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256]. are set to 0. See [rfc1256].
Subtype: To be assigned by IANA Subtype: To be assigned by IANA
skipping to change at page 14, line 42 skipping to change at page 14, line 42
Source Address: An IP address assigned to the sending interface Source Address: An IP address assigned to the sending interface
Destination Address: The Source Address of an invoking Router Destination Address: The Source Address of an invoking Router
Solicitation for Proxy Advertisement or the address of the node Solicitation for Proxy Advertisement or the address of the node
the Access Router is instructing to handover. the Access Router is instructing to handover.
Time-to-Live: At least 1. See [rfc1256]. Time-to-Live: At least 1. See [rfc1256].
ICMP Fields: ICMP Fields:
Type: To be assigned by IANA Type: 41. See Section 3 in [rfc4065].
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 complement Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256]. are set to 0. See [rfc1256].
Subtype: To be assigned by IANA. Subtype: To be assigned by IANA.
Reserved: MUST be set to zero by the sender and ignored by the Reserved: MUST be set to zero by the sender and ignored by 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: The link-layer address or New Access Point Link-layer Address: The link-layer address or
identification of the access point is copied from RtSolPr identification of the access point. When there is no wildcard
message. This option MUST be present. in RtSolPr, this is copied from the LLA (for which the router
is supplying the [AP-ID, AR-Info] tuple) present in 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 New Router's Link-layer Address: The link-layer address of the
Access Router for which this message is proxied for. This Access Router for which this message is proxied for. This
option MUST be included when Code is 0 or 1. option MUST be included when Code is 0 or 1.
New Router's IP Address: The IP address of NAR. This option New Router's IP Address: The IP address of NAR. This option
MUST be included when Code is 0 or 1. MUST be included when Code is 0 or 1.
New Router Prefix Information Option: The number of leading New Router Prefix Information Option: The number of leading
bits that define the network number of the corresponding bits that define the network number of the corresponding
Router's IP Address option (see above). Router's IP Address option (see above).
New CoA Option: MAY be present when PrRtAdv is sent New CoA Option: MAY be present, typically when PrRtAdv is sent
unsolicited. PAR MAY compute new CoA using NAR's prefix unsolicited. PAR MAY compute new CoA by communicating with the
information and the MN's L2 address, or by any other means. In NAR or by means not specified in this document. In any case,
any case, the MN should be prepared to use this address instead the MN should be prepared to use this address instead of
of performing DHCP or similar operations to obtain an IPv4 performing DHCP or similar operations to obtain an IPv4
address. 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- 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- 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, 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 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 options are related, and the Option-Code for the New Router's LLA
option is 3. Multiple tuples may be present. option is 3. Multiple tuples may be present.
A PrRtAdv with Code 1 means that the message is sent unsolicited. If 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 a New IPv4 option (see Figure 10) is present following the New Router
skipping to change at page 16, line 29 skipping to change at page 16, line 35
A Proxy Router Advertisement with Code 4 means that the subnet A Proxy Router Advertisement with Code 4 means that the subnet
information regarding neighboring access points is sent unsolicited, information regarding neighboring access points is sent unsolicited,
but the message is not a handover trigger, unlike when the message is but the message is not a handover trigger, unlike when the message is
sent with Code 1. Multiple tuples may be present. sent with Code 1. Multiple tuples may be present.
When a wildcard AP identifier is supplied in the RtSolPr message, the When a wildcard AP identifier is supplied in the RtSolPr message, the
PrRtAdv message should include any 'n' [Access Point Identifier, PrRtAdv message should include any 'n' [Access Point Identifier,
Link-Layer Address option, Prefix Information Option] tuples Link-Layer Address option, Prefix Information Option] tuples
corresponding to the PAR's neighborhood. 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. For this reason, the use
of New CoA option in solicited PrRtAdv is not specified in this
document.
6.5. Handover Initiate (HI) 6.5. 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 [rfc4068]. defined in [rfc4068].
0 1 2 3 0 1 2 3
skipping to change at page 17, line 14 skipping to change at page 17, line 28
IP Fields: IP Fields:
Source Address: The IP address of the PAR Source Address: The IP address of the PAR
Destination Address: The IP address of the NAR Destination Address: The IP address of the NAR
Time-to-Live: At least 1. See [rfc1256]. Time-to-Live: At least 1. See [rfc1256].
ICMP Fields: ICMP Fields:
Type: To be assigned by IANA Type: 41. See Section 3 in [rfc4065].
Code: 0 or 1. See below Code: 0 or 1. See below
Checksum: The 16-bit one's complement of the one's complement Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256]. are set to 0. See [rfc1256].
Subtype: To be assigned by IANA Subtype: To be assigned by IANA
skipping to change at page 19, line 5 skipping to change at page 19, line 18
Source Address: Copied from the destination address of the Source Address: Copied from the destination address of the
Handover Initiate Message to which this message is a response. Handover Initiate Message to which this message is a response.
Destination Address: Copied from the source address of the Destination Address: Copied from the source address of the
Handover Initiate Message to which this message is a response. Handover Initiate Message to which this message is a response.
Time-to-Live: At least 1. See [rfc1256]. Time-to-Live: At least 1. See [rfc1256].
ICMP Fields: ICMP Fields:
Type: To be assigned by IANA Type: 41. See Section 3 in [rfc4065].
Code: Code:
0: Handover Accepted 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 (used in Assigned 3: Handover Accepted, NCoA assigned (used in Assigned
addressing) addressing)
4: Handover Accepted, NCoA not assigned 4: Handover Accepted, NCoA not assigned
128: Handover Not Accepted, reason unspecified 128: Handover Not Accepted, reason unspecified
skipping to change at page 20, line 9 skipping to change at page 20, line 19
[rfc4068]). Code values 1 and 2 are for cases when the MN proposes [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 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). 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 Code 4 is when the NAR does not provide NCoA, but instead provides
routing support for PCoA. routing support for PCoA.
7. Option Formats 7. Option Formats
The options in this section are specified as extensions for the HI The options in this section are specified as extensions for the HI
and HAck messages, as well as for the PrRtSol and PrRtAdv messages. 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.
7.1. Link-Layer Address Option Format 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 | Option-Code | LLA ... | Type | Length | Option-Code | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Link Layer Address Option Format Figure 9: Link Layer Address Option Format
skipping to change at page 24, line 46 skipping to change at page 25, line 19
+---------+-----------------------+--------------------------+ +---------+-----------------------+--------------------------+
10. Acknowledgement 10. Acknowledgement
Thanks to all those who expressed interest in having a Fast Handovers Thanks to all those who expressed interest in having a Fast Handovers
for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to
Vijay Devarapalli, Kent Leung and Domagoj Premec for their review and Vijay Devarapalli, Kent Leung and Domagoj Premec for their review and
input. Kumar Viswanath and Uday Mohan implemented an early version input. Kumar Viswanath and Uday Mohan implemented an early version
of this protocol. Many thanks to Alex Petrescu for his thorough of this protocol. Many thanks to Alex Petrescu for his thorough
review that improved this document. Thanks to Pete McCann for the review that improved this document. Thanks to Pete McCann for the
final proofreading which has helped improve this document. proofreading, and to Jari Arkko for the review which have helped
improve this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [rfc1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
skipping to change at page 26, line 11 skipping to change at page 26, line 36
RFC 2131, March 1997. RFC 2131, March 1997.
[rfc3957] Perkins, C. and P. Calhoun, "Authentication, [rfc3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005. Mobile IPv4", RFC 3957, March 2005.
Appendix A. Change Log Appendix A. Change Log
Addressed the following Last Call and subsequent reviews: Addressed the following Last Call and subsequent reviews:
Addressed AD review
Addressed Shepherd review input Addressed Shepherd review input
Provided all the Code values in PrRtAdv message to cover various Provided all the Code values in PrRtAdv message to cover various
cases involving neighborhood discovery. Harmonized the option cases involving neighborhood discovery. Harmonized the option
formats with [rfc4068]. formats with [rfc4068].
Added the Terminology Section Added the Terminology Section
Added text regarding FBU message flags 'S' and 'B' Added text regarding FBU message flags 'S' and 'B'
Revised text in Security Considerations Revised text in Security Considerations
Clarified text in different places based on ML comments (including Clarified text in different places based on ML comments (including
"forwarding", MN's use of assigned addresses in lieu of DHCP, and "forwarding", MN's use of assigned addresses in lieu of DHCP, and
so on.) so on.)
Clarified using ICMPv4 checksum for RtSolPr, PrRtAdv, HI and HAck Clarified using ICMPv4 checksum for RtSolPr, PrRtAdv, HI and HAck
Added Figures illustrating predictive and reactive handovers Added Figures illustrating predictive and reactive handovers
Added references to IEEE 802.21 and IEEE 802.11r Added references to IEEE 802.21 and IEEE 802.11r
 End of changes. 21 change blocks. 
25 lines changed or deleted 52 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/