draft-ietf-mip4-fmipv4-05.txt   draft-ietf-mip4-fmipv4-06.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: September 1, 2007 February 28, 2007 Expires: November 5, 2007 May 4, 2007
Mobile IPv4 Fast Handovers Mobile IPv4 Fast Handovers
draft-ietf-mip4-fmipv4-05.txt draft-ietf-mip4-fmipv4-06.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 September 1, 2007. This Internet-Draft will expire on November 5, 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
configuration and location update latencies during a handover. For configuration and location update latencies during a handover. For
reducing the IP address configuration latency, the document proposes reducing the IP address configuration latency, the document proposes
that the new Care-of Address is always made to be the new access that the new Care-of Address is always made to be the new access
router's IP address. Additional mechanisms may be defined in the router's IP address. Additional mechanisms may be defined in the
future versions of this document. future versions of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Factors Affecting Handover . . . . . . . . . . . . . . . . . . 4 3. Factors Affecting Handover . . . . . . . . . . . . . . . . . . 4
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Using Previous FA Notification Extension . . . . . . . . . . . 9 5. Using Previous FA Notification Extension . . . . . . . . . . . 9
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) . . . . . . . . . . . 10 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) . . . . . . . . . . . 13 6.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . . 14
6.5. Inter-Access Router Messages . . . . . . . . . . . . . . . 16 6.5. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 16
6.5.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 16 6.6. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 18
6.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 17 7. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Link-Layer Address Option Format . . . . . . . . . . . . . 20
7.1. Link-Layer Address Option Format . . . . . . . . . . . . . 19 7.2. New IPv4 Address Option Format . . . . . . . . . . . . . . 21
7.2. New IPv4 Address Option Format . . . . . . . . . . . . . . 20
7.3. New Router Prefix Information Option . . . . . . . . . . . 21 7.3. New Router Prefix Information Option . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 26 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]
registration messages are re-used (with new type numbers) in this registration messages are re-used (with new type numbers) in this
skipping to change at page 3, line 45 skipping to change at page 3, line 45
On a particular network, a mobile node may obtain its IP address via 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 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 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 be that of NAR. This allows a mobile node to receive and send
packets using its previous CoA (PCoA), so that delays resulting from packets using its previous CoA (PCoA), so that delays resulting from
IP configuration (such as DHCP address acquisition delay) subsequent IP configuration (such as DHCP address acquisition delay) subsequent
to attaching to the new link are disengaged from affecting the to attaching to the new link are disengaged from affecting the
existing sessions. existing sessions.
Unlike in Mobile IPv6, a Mobile IPv4 host may rely on its Foreign
Agent to provide a care-of address. In fast handovers, the binding
at the PAR is always established between the on-link address the
mobile node is using and a new CoA which it can use on the NAR's
link. When FA-CoA is used, the on-link address is the MN's home
address, not the FA-CoA itself, which needs to be bound to the NCoA.
So, when we say "a binding is established between PCoA and NCoA," it
is actually the home address of the mobile node which is bound to the
NCoA in the FA-CoA mode.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The terminology used in this document in based on [rfc4068] and The terminology used in this document in based on [rfc4068] and
[rfc3344]. We provide some definitions below for convenience. [rfc3344]. We provide some definitions below for convenience.
Mobile Node (MN): A Mobile IPv6 host. Mobile Node (MN): A Mobile IPv4 host.
Access Point (AP): A Layer 2 device connected to an IP subnet that Access Point (AP): A Layer 2 device connected to an IP subnet that
offers wireless connectivity to an MN. An Access Point Identifier offers wireless connectivity to an MN. An Access Point Identifier
(AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also (AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also
referred to as a Base Station Subsystem ID (BSSID). referred to as a Base Station Subsystem ID (BSSID).
Access Router (AR): The MN's default router. Access Router (AR): The MN's default router.
Previous Access Router (PAR): The MN's default router prior to its Previous Access Router (PAR): The MN's default router prior to its
handover. handover.
skipping to change at page 6, line 27 skipping to change at page 6, line 37
arriving at PAR will be tunneled to NAR for delivery to the newly arriving at PAR will be tunneled to NAR for delivery to the newly
arrived mobile node. The purpose of HI is to securely deliver the arrived mobile node. The purpose of HI is to securely deliver the
routing parameters for establishing this tunnel. The tunnel is routing parameters for establishing this tunnel. The tunnel is
created by the access routers in response to the delivery of the FBU created by the access routers in response to the delivery of the FBU
from the mobile node. from the mobile node.
4.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 Section 6.1). Depending on the Mobile IP mode of (see Section 6.1). Depending on the Mobile IP mode of operation, the
operation, the PCoA is either the Home Address (in FA CoA mode) or PCoA is either the Home Address (in FA CoA mode) or co-located CoA
co-located CoA (in CCoA mode). The FBU message SHOULD be sent when (in CCoA mode). The FBU message SHOULD be sent when the mobile node
the mobile node is still connected to PAR. When sent in this is still connected to PAR. When sent in this "predictive" mode, the
"predictive" mode, the fields in the FBU are used as follows: fields in the FBU are used as follows:
"Home Address" field must be the PCoA (which can be either the "Home Address" field must be the PCoA (which can be either 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 IP Home Agent field must be set to PAR's IP address
address
Care-of Address field must be the NAR's IP address discovered via Care-of Address field must be the NAR's IP address discovered 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 Home Source IP address must be the PCoA (which can be either the 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 PCoA As a result of processing the FBU, PAR creates a binding between PCoA
and NAR's IP address in its routing table. The PAR sends an FBack and NAR's IP address in its routing table. The PAR sends an FBack
message (see Section Section 6.2) as a response to the mobile node. message (see Section 6.2) as a response to the mobile node.
The timeline for the predictive mode of operation (adapted from The timeline for the predictive mode of operation (adapted from
[rfc4068]) is shown in Figure Figure 1. [rfc4068]) is shown in Figure 1.
MN PAR NAR MN PAR NAR
| | | | | |
|------RtSolPr------->| | |------RtSolPr------->| |
|<-----PrRtAdv--------| | |<-----PrRtAdv--------| |
| | | | | |
|------FBU----------->|--------HI--------->| |------FBU----------->|--------HI--------->|
| |<------HAck---------| | |<------HAck---------|
| <--FBack---|--FBack---> | | <--FBack---|--FBack---> |
| | | | | |
disconnect forward | disconnect forward |
| packets===============>| | packets===============>|
| | | | | |
| | | | | |
connect | | connect | |
| | | | | |
|--------- FBU --------------------------->| |--------- FBU --------------------------->|
|<=================================== deliver packets |<=================================== deliver packets
| | (including FBack)
| |<-----FBU-----------| | |<-----FBU-----------|
Figure 1: Predictive Fast Handover Figure 1: Predictive Fast Handover
The mobile node sends the FBU regardless of its previous transmission The mobile node sends the FBU regardless of its previous transmission
when attachment to a new link is detected. This minimally allows NAR when attachment to a new link is detected. This minimally allows NAR
to detect mobile node's attachment, but also the retransmission of to detect mobile node's attachment, but also the retransmission of
FBU when an FBack has not been received yet. When sent in this FBU when an FBack has not been received yet. When sent in this
"reactive" mode, the following fields in FBU are set differently "reactive" mode, the Destination IP address must be NAR's IP address;
compared to the predictive mode: the rest of the fields in the FBU are the same as in the "predictive"
scenario.
Destination IP address must be NAR's IP address
Source IP address must be PCoA (either the Home Address or the co-
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 in the new packet now contain the Source and Destination IP addresses in the new packet now contain the
IP addresses of NAR and PAR respectively. IP addresses of NAR and PAR respectively.
The reactive mode of operation (adapted from [rfc4068]) is The reactive mode of operation (adapted from [rfc4068]) is
illustrated in Figure Figure 2. illustrated in Figure 2. Even though the Figure does not show the HI
and HAck messages illustrated in Figure 1, these messages could
already have been exchanged (in the case when the PAR has already
processed the FBU sent from the previous link); if not, the PAR sends
a HI message to the NAR. The FBack packet is forwarded by the NAR to
the MN along with the data packets.
MN PAR NAR MN PAR NAR
| | | | | |
|------RtSolPr------->| | |------RtSolPr------->| |
|<-----PrRtAdv--------| | |<-----PrRtAdv--------| |
| | | | | |
disconnect | | disconnect | |
| | | | | |
| | | | | |
connect | | connect | |
|-----------FBU-------|------------------->| |-----------FBU-------|------------------->|
| |<-----FBU-----------| | |<-----FBU-----------|
| |------FBack-------->| | |------FBack-------->|
| forward | | forward |
| packets===============>| | packets===============>|
| | | | | |
|<=================================== deliver packets |<=================================== deliver packets
| (including FBack)
| | | |
Figure 2: Reactive Fast Handover Figure 2: Reactive Fast Handover
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
serve to establish a bidirectional tunnel between the routers to serve to establish a bidirectional tunnel between the routers to
support packet forwarding for PCoA. The tunnel itself is established support packet forwarding for PCoA. The tunnel itself is established
as a response to the FBU message. The PAR sends HI message with Code 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 = 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 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 not set to PCoA (i.e., when received from NAR). This allows NAR to
disambiguate HI message processing sent as a response to predictive disambiguate HI message processing sent as a response to predictive
and reactive modes of operation. If NAR receives a HI message with 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 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. tunnel for PCoA, it SHOULD still respond with a HAck message, using
an appropriate Code value defined in Section 6.6.
The protocol provides an option for NAR to return NCoA for use by the 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. When NAR can provide an NCoA for exclusive use of the
mobile node, the address is supplied in the HAck message. The PAR mobile node, the address is supplied in the HAck message. The PAR
includes this NCoA in FBack. Exactly how NAR manages the address includes this NCoA in FBack. Exactly how NAR manages the address
pool from which it supplies NCoA is not specified in this document. pool from which it supplies NCoA is not specified in this document.
Nevertheless, the MN should be prepared to use this address instead Nevertheless, the MN should be prepared to use this address instead
of performing DHCP or similar operations to obtain an IPv4 address. 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 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 unaware of the address at the time it sends an FBU. Hence, it binds
PCoA to NAR's IP address as before. PCoA to NAR's IP address as before.
5. Using Previous FA Notification Extension 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 [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 Section 6.3, Section Section 6.4), movement detection (see Section 6.3, Section 6.4), movement detection and router
and router discovery delays are avoided even in the reactive case. discovery delays are avoided even in the reactive case. The FBU and
The FBU and FBAck messages defined in this document can be naturally FBAck messages defined in this document can be naturally used even
used even when no neighborhood information is available. when no neighborhood information is available.
6. Message Formats 6. Message Formats
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.
skipping to change at page 10, line 27 skipping to change at page 11, line 4
Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are
sent as zero, and ignored on reception. sent as zero, and ignored on reception.
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
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
Authentication Extension in [rfc4721] with a new Subtype for MN - PAR
Authentication. The Authenticator field in the Generalized Mobile IP
Authentication Extension is calculated using a shared key between the
MN and the PAR. However, the key distribution itself is beyond the
scope of this document, and is assumed to be performed by other means
(using [rfc3957] for example).
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 11, line 25 skipping to change at page 12, line 4
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Figure 4: Fast Binding Acknowledgement (FBAck) Message Figure 4: Fast Binding Acknowledgement (FBAck) Message
Source address: Typically copied from the destination address of Source address: Typically copied from the destination address of
the FBU message the FBU message
Destination Address: Copied from the Source IP address in FBU Destination Address: 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 message. Code = 0 Code: Indicates the result of processing FBU message.
means Fast Binding Update accepted. Code = 1 means Fast
Binding Update accepted but NCoA is supplied as an extension. 0: FBU Accepted
1: FBU Accepted, NCoA supplied
128: FBU Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
reserved: Sent as zero, ignored on input reserved: Sent as zero, ignored on input
Lifetime: The granted number of seconds remaining before Lifetime: The granted number of seconds remaining before
binding expires. binding expires.
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 address Home Agent: The Previous Access Router's global IP address
skipping to change at page 12, line 4 skipping to change at page 12, line 30
reserved: Sent as zero, ignored on input reserved: Sent as zero, ignored on input
Lifetime: The granted number of seconds remaining before Lifetime: The granted number of seconds remaining before
binding expires. binding expires.
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 address Home Agent: The Previous Access Router's global IP address
Identification: a 64-bit number used for matching FBU. Copied Identification: a 64-bit number used for matching FBU. Copied
from the field in FBU for which this FBack is a reply. from the field in FBU for which this FBack is a reply.
Extensions: The PAR - MN Authentication extension MUST be Extensions: The MN - PAR Authentication extension MUST be
present. In addition, an NCoA option MUST be present when NAR present. In addition, an NCoA option MUST be present when NAR
supplies the NCoA. supplies the NCoA.
If the FBAck message indicates that the new care-of address is a
Foreign Agent care-of address [rfc3344], then the mobile node MUST
set the 'D' bit in its Registration Request message that it uses to
register the NCoA with its home agent.
6.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 Section 7.1. link-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 [rfc4068]. 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
skipping to change at page 14, line 25 skipping to change at page 14, line 38
Figure 6: Proxy Router Advertisement (PrRtAdv) Message Figure 6: Proxy Router Advertisement (PrRtAdv) Message
IP Fields: IP Fields:
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: 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 complement Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, start- ing 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.
skipping to change at page 16, line 11 skipping to change at page 16, line 29
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.
6.5. Inter-Access Router Messages 6.5. Handover Initiate (HI)
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 [rfc4068]. 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
skipping to change at page 17, line 4 skipping to change at page 17, line 17
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: To be assigned by IANA
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, start- ing 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
S: Assigned address configuration flag. When set, this message S: Assigned address configuration flag. When set, this message
requests a new CoA to be returned by the destination. May be requests a new CoA to be returned by the destination. May be
set when Code = 0. MUST be 0 when Code = 1. set when Code = 0. MUST be 0 when Code = 1.
U: Buffer flag. When set, the destination SHOULD buffer any U: Buffer flag. When set, the destination SHOULD buffer any
skipping to change at page 17, line 39 skipping to change at page 18, line 8
option MUST be included so that the destination can recognize option MUST be included so that the destination can recognize
the MN. the MN.
Previous Care of Address: The IP address used by the MN while Previous Care of Address: The IP address used by the MN while
attached to the originating router. This option MUST be attached to the originating router. This option MUST be
included so that a host route can be established on the NAR. included so that a host route can be established on the NAR.
New Care of Address: This option MAY be present when the MN New Care of Address: This option MAY be present when the MN
wishes to use a new IP address when connected to the wishes to use a new IP address when connected to the
destination. When the 'S' bit is set, NAR MAY provide this destination. When the 'S' bit is set, NAR MAY provide this
address in HAck, in which case t he MN should be prepared to address in HAck, in which case the MN should be prepared to use
use this address instead of performing DHCP or similar this address instead of performing DHCP or similar operations
operations to obtain an IPv4 address. to obtain an IPv4 address.
6.5.2. Handover Acknowledge (HAck) PAR uses Code = 0 when it processes the FBU received with PCoA as
source IP address. PAR uses Code = 1 when the FBU is received with
NAR's IP address as the source IP address.
6.6. Handover Acknowledge (HAck)
The Handover Acknowledgment message is a new ICMP message that MUST The Handover Acknowledgment message is a new ICMP message that MUST
be sent (typically by NAR to PAR) as a reply to the Handover Initiate be sent (typically by NAR to PAR) as a reply to the Handover Initiate
(HI) (see Section Section 6.5.1) message. (HI) (see Section 6.5) message.
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
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 |
skipping to change at page 22, line 30 skipping to change at page 23, line 6
Hence, the FBU and FBack messages MUST be protected using a security 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 in particular, the MN - PAR Authentication Extension MUST be present in
each of these messages. This document does not specify how the each of these messages. This document does not specify how the
security association is established between a MN and the AR/FA. security association is established between a MN and the AR/FA.
Secure FBU, malicious or inadvertent redirection: Secure FBU, malicious or inadvertent redirection:
Even if the MN - PAR authentication extension is present in an FBU, a 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 MN may inadvertently or maliciously attempt to bind its PCoA to an
unintended address on NAR's link, and cause traffic flooding to an unintended address on NAR's link, and cause traffic flooding to an
unsuspecting node. unsuspecting node.
This vulnerability is avoided by always binding the PCoA to the NAR's 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 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. is still possible to jam NAR's buffer with redirected traffic.
However, the handover state corresponding to the MN's PCoA has a 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 finite lifetime, and can be configured to be a few multiples of the
anticipated handover latency. Hence, the extent of this anticipated handover latency. Hence, the extent of this
vulnerability is small. vulnerability is small.
skipping to change at page 23, line 12 skipping to change at page 23, line 32
This message exchange needs to be secured to ensure routing updates This message exchange needs to be secured to ensure routing updates
take place as intended. take place as intended.
The HI and HAck messages need to be secured using a pre-existing The HI and HAck messages need to be secured using a pre-existing
security association between the access routers to ensure at least security association between the access routers to ensure at least
message integrity and authentication, and should also include message integrity and authentication, and should also include
encryption. encryption.
9. IANA Considerations 9. IANA Considerations
All the messages and the option formats specified in this document The IANA assignments necessary for messages, extensions and options
require Type assignment from IANA. Specifically, the Types, Sub- specified in this document are described in the following paragraphs.
types and the Codes need assignment from ICMP, Mobile IP and
Experimental Mobility Type [rfc4065] registries. This document defines two new messages that use the Mobile IPv4
control message format [rfc3344]. These message details are as
follows:
+------+-------------+-------------+
| Type | Description | Reference |
+------+-------------+-------------+
| TBA | FBU | Section 6.1 |
| TBA | FBAck | Section 6.2 |
+------+-------------+-------------+
This document defines four new experimental ICMP messages that use
the ICMP Type 41 for IPv4. See Section 3 in [rfc4065]. The new
messages specified in this document need Subtype assignment from the
registry in [rfc4065]:
+---------+-------------+-------------+
| Subtype | Description | Reference |
+---------+-------------+-------------+
| TBA | RtSolPr | Section 6.3 |
| TBA | PrRtAdv | Section 6.4 |
| TBA | HI | Section 6.5 |
| TBA | HAck | Section 6.6 |
+---------+-------------+-------------+
This document defines three new options that need Type assignment
from the Mobile IP Extensions for ICMP Router Discovery messages
[rfc3344]. These options are as follows:
+------+------------------+-------------+
| Type | Description | Reference |
+------+------------------+-------------+
| TBA | LLA | Section 7.1 |
| TBA | New IPv4 Address | Section 7.2 |
| TBA | NAR Prefix Info | Section 7.3 |
+------+------------------+-------------+
The MN-PAR Authentication Extension described in Section 6.1 and
Section 6.2 is a Generalized Mobile IP Authentication Extension
defined in Section 5 of [rfc4721]. The MN - PAR Authentication needs
a Subtype assignment from the registry specified in [rfc4721]. The
Extension details are as follows:
+---------+-----------------------+--------------------------+
| Subtype | Description | Reference |
+---------+-----------------------+--------------------------+
| TBA | MN-PAR Auth Extension | Section 6.1, Section 6.1 |
+---------+-----------------------+--------------------------+
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, Keng Leung for their review and input. Kumar Vijay Devarapalli, Kent Leung and Domagoj Premec for their review and
Viswanath and Uday Mohan implemented an early version of this input. Kumar Viswanath and Uday Mohan implemented an early version
protocol. Many thanks to Alex Petrescu for his thorough review that of this protocol. Many thanks to Alex Petrescu for his thorough
improved this document. review that improved this document. Thanks to Pete McCann for the
final proofreading which has 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 24, line 5 skipping to change at page 25, line 25
[rfc3344] Perkins (Editor), C., "IP Mobility Support for IPv4", [rfc3344] Perkins (Editor), C., "IP Mobility Support for IPv4",
RFC 3344, August 2002. RFC 3344, August 2002.
[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005. Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[rfc4068] Koodli (Editor), R., "Fast Handovers for Mobile IPv6", [rfc4068] Koodli (Editor), R., "Fast Handovers for Mobile IPv6",
RFC 4068, July 2005. RFC 4068, July 2005.
[rfc4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
Challenge/Response Extensions (Revised)", RFC 4721,
January 2007.
11.2. Informative References 11.2. Informative References
[draft-mip4-ro] [draft-mip4-ro]
Perkins, C. and D. Johnson, "Route Optimization in Mobile Perkins, C. and D. Johnson, "Route Optimization in Mobile
IP (work in progress). Internet Draft, Internet IP (work in progress). Internet Draft, Internet
Engineering Task Force", February 2000. Engineering Task Force", February 2000.
[ieee-802.11r] [ieee-802.11r]
"IEEE Standard forLocal and Metropolitan Area Networks: "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.
skipping to change at page 24, line 28 skipping to change at page 25, line 52
"IEEE Standard for Local and Metropolitan Area Networks: "IEEE Standard for Local and Metropolitan Area Networks:
Port-Based Network Access Control. Technical report, Port-Based Network Access Control. Technical report,
IEEE.". IEEE.".
[ieee-802.21] [ieee-802.21]
"The IEEE 802.21 group. http://www.ieee802.org/21.". "The IEEE 802.21 group. http://www.ieee802.org/21.".
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", [rfc2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[rfc3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for
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 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
 End of changes. 42 change blocks. 
76 lines changed or deleted 153 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/