draft-ietf-mip4-fmipv4-01.txt   draft-ietf-mip4-fmipv4-02.txt 
Mobile IPv4 Working Group Rajeev Koodli Mobile IPv4 Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins INTERNET DRAFT Charles E. Perkins
August 25 2006 Nokia Research Center 23 October 2006 Nokia Research Center
Mobile IPv4 Fast Handovers Mobile IPv4 Fast Handovers
draft-ietf-mip4-fmipv4-01.txt draft-ietf-mip4-fmipv4-02.txt
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 other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
any time. It is inappropriate to use Internet-Drafts as reference any 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 document is a submission of the IETF MIP4 WG. Comments should be This document is a submission of the IETF MIP4 WG. Comments should be
directed to the MIP4 WG mailing list, mip4@ietf.org. directed to the MIP6 WG mailing list, mip4@ietf.org.
Abstract Abstract
The Mobile IPv6 fast handover document [2] specifies a protocol to The Mobile IPv6 fast handover document [2] specifies a protocol to
improve latency and packet loss resulting from Mobile IPv6 handover improve latency and packet loss resulting from Mobile IPv6 handover
operations. This document adapts the protocol for IPv4 networks operations. This document adapts the protocol for IPv4 networks
to improve performance over Mobile IPv4 operations, including to improve performance over Mobile IPv4 operations, including
processing of Agent Advertisements, new Care of Address acquisition processing of Agent Advertisements, new Care of Address acquisition
and Registration Request and Reply. However, operation without and Registration Request and Reply. Using the concepts outlined
Foreign Agent function at a router is also feasible. In addition, in [2], this document also addresses movement detection, IP address
the protocol may be used transparently on hosts which do not support configuration and location update latencies during a handover.
Mobile IP, but with limited movement across subnets. Using the For reducing the IP address configuration, the document currently
concepts outlined in [2], this document also addresses movement proposes that the new CoA is always made to be the new access
detection, IP address configuration and location update latencies router's IP address. Additional mechanisms may be defined in the
during a handover. For reducing the IP address configuration, the future versions of this document.
document currently proposes that the new CoA is always made to be the
new access router's IP address. Additional mechanisms may be defined
in the future versions of this document.
Contents Contents
Abstract i Abstract i
1. Introduction 2 1. Introduction 2
2. Protocol Operation 2 2. Factors Affecting Handover 2
2.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 3
2.2. Assigned Addressing Support . . . . . . . . . . . . . . . 4
3. Use of Previous FA Notification Extension 4 3. Protocol Operation 3
3.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 4
3.2. Assigned Addressing Support . . . . . . . . . . . . . . . 5
4. Message Formats 4 4. Use of Previous FA Notification Extension 5
4.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 4
4.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 6
4.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 7
4.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 9
4.5. Inter-Access Router Messages . . . . . . . . . . . . . . 11
4.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 11
4.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 12
5. Option formats 14 5. Message Formats 5
5.1. Link-Layer Address Option Format . . . . . . . . . . . . 14 5.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 5
5.2. New IPv4 Address Option Format . . . . . . . . . . . . . 15 5.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 7
5.3. New Router Prefix Information Option . . . . . . . . . . 15 5.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 8
5.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 10
5.5. Inter-Access Router Messages . . . . . . . . . . . . . . 12
5.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 12
5.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 13
6. Security Considerations 16 6. Option formats 15
6.1. Link-Layer Address Option Format . . . . . . . . . . . . 15
6.2. New IPv4 Address Option Format . . . . . . . . . . . . . 16
6.3. New Router Prefix Information Option . . . . . . . . . . 16
7. IANA Considerations 17 7. Security Considerations 17
Intellectual Property Statement 17 8. IANA Considerations 18
Disclaimer of Validity 18 Intellectual Property Statement 18
Copyright Statement 18 Disclaimer of Validity 19
Acknowledgment 18 Copyright Statement 19
Acknowledgment 19
1. Introduction 1. Introduction
In this document, we adapt the fast handover specification [2] to This document adapts the fast handover specification [2] to IPv4
IPv4 networks. The fast handover protocol specified in this document networks. The fast handover protocol specified in this document
is particularly interesting for operation on commonly available is particularly interesting for operation on commonly available
wireless links such as IEEE 802.11 WLAN links. Fast handovers are wireless links such as IEEE 802.11 WLAN links. Fast handovers are
not typically needed for wired media due to the relatively large not typically needed for wired media due to the relatively large
delays attributable to establishing new connections in today's wired delays attributable to establishing new connections in today's wired
networks. Mobile IPv4 registration messages are re-used (with new networks. Mobile IPv4 registration messages are re-used (with new
type numbers) to enable quick implementation using existing foreign type numbers) to enable quick implementation using existing foreign
agent software. This draft does not rely on link-layer triggers for agent software. This draft does not rely on link-layer triggers for
protocol operation, but performance will typically be enhanced by protocol operation, but performance will typically be enhanced by
using the appropriate triggers when they are available. using the appropriate triggers when they are available.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
(PFA) and a NAR is also a New FA (NFA). (PFA) and a NAR is also a New FA (NFA).
On a particular network, the MN may obtain its IP address via DHCP On a particular network, the MN may obtain its IP address via DHCP
(i.e., CCoA) or use the Foreign Agent CoA. During a handover, the new (i.e., CCoA) or use the Foreign Agent CoA. During a handover, the new
CoA is always made to be that of NAR. This allows a MN to receive and CoA is always made to be that of NAR. This allows a MN to receive and
send packets using its previous CoA, so that delays resulting from IP send packets using its previous CoA, so that delays resulting from IP
configuration (such as DHCP address acquisition delay) subsequent to configuration (such as DHCP address acquisition delay) subsequent to
attaching to the new link are disengaged from affecting the existing attaching to the new link are disengaged from affecting the existing
sessions. sessions.
2. Protocol Operation 2. Factors Affecting Handover
Both the link-layer operations and IP layer procedures affect the
perceived handover performance. However, the overall performance is
also (always) a function of specific implementation of the technology
as well as the system configuration. This document only specifies IP
layer protocol operations. The purpose of this section is to provide
an illustration of events that affect handover performance, but it is
purely informative.
The IP layer handover delay and packet loss are influenced by
latencies due to movement detection, IP address configuration and
Mobile IP registration procedure. Movement detection latency comes
from the need to reliably detect movement to a new subnet. This is
a function of frequency of router advertisements as well as default
agent reachability. IP address configuration latency depends on the
particular IP CoA being used. If co-located mode with DHCP is used,
the latency is quite likely going to be higher and unacceptable for
real-time applications such as Voice over IP. Finally, the Mobile
IP registration procedure needs a round-trip of delay between the
Mobile Node and its Home Agent over the Internet. This delay is
incurred after the Mobile Node performs movement detection and IP
configuration.
Underlying the IP operations are link-layer procedures. These
are clearly technology-specific. For instance, in IEEE 802.11b
which is also known as WLAN, the handover operation may involve
scanning access points over all available channels, selecting a
suitable access point and associating with it. It may also involve
performing access control operations such as those specified in
IEEE 802.1X. These delays contribute to the handover performance.
Optimizations have been proposed and are being standardized in IEEE
however. Together with appropriate implementation techniques, these
optimizations can provide the required level of delay support for
real-time applications.
3. Protocol Operation
The design of the protocol is the same as for Mobile IPv6 [2].
Readers should consult [2] for details, and here we provide a
summary.
The protocol avoids the delay due to movement detection and IP
configuration and disengage Mobile IP registration delay from the
time-critical path. The protocol provides the surrounding network
network neighborhood information so that a Mobile Node can determine
whether it is moving to a new subnet even before the handover. The
information provided and the signaling exchange between the local
mobility agents allows the Mobile Node to send and receive packets
immediately after handover. In order to disengage the Mobile IP
registration latency, the protocol provides routing support for the
continued use of a Mobile Node's previous CoA.
After a MN obtains its IPv4 care-of address, it builds a neighborhood After a MN obtains its IPv4 care-of address, it builds a neighborhood
access point and subnet map using the Router Solicitation for Proxy access point and subnet map using the Router Solicitation for Proxy
Advertisement and Proxy Router Advertisement messages. The MN may Advertisement and Proxy Router Advertisement messages. The MN may
scan for access points (APs) based on the configuration policy in scan for access points (APs) based on the configuration policy in
operation for its wireless network interface. If a scan results in operation for its wireless network interface. If a scan results in
a new AP discovery, the MN resolves the AP-ID to subnet information a new AP discovery, the MN resolves the AP-ID to subnet information
using the messages defined below. using the messages defined below.
The coordination between the access routers is done by way of the The coordination between the access routers is done by way of the
skipping to change at page 3, line 25 skipping to change at page 4, line 29
provides its own IP address for the MN to use upon connecting to the provides its own IP address for the MN to use upon connecting to the
new link. Third, an access router may allocate an IP address to a new link. Third, an access router may allocate an IP address to a
visiting mobile node by some means not specified in this document. visiting mobile node by some means not specified in this document.
Just as a simple example, an access router may maintain a pool of Just as a simple example, an access router may maintain a pool of
IPv4 addresses for temporary use by visiting mobile nodes. IPv4 addresses for temporary use by visiting mobile nodes.
The protocol semantics are almost identical in all scenarios. The The protocol semantics are almost identical in all scenarios. The
packet formats presented in RFC 3344 are re-used to achieve maximum packet formats presented in RFC 3344 are re-used to achieve maximum
compatibility with Mobile IP. compatibility with Mobile IP.
2.1. Basic NCoA Support 3.1. Basic NCoA Support
In response to a handover trigger or indication, the MN sends a In response to a handover trigger or indication, the MN sends a
Fast Binding Update message to Previous Access Router (PAR) (see Fast Binding Update message to Previous Access Router (PAR) (see
Section 4.1). This message should be sent when the MN is still Section 5.1). This message should be sent when the MN is still
connected to PAR. When sent in this ``predictive'' mode, the ``Home connected to PAR. When sent in this ``predictive'' mode, the ``Home
Address'' field must be the PCoA. The Home Agent field, even though Address'' field must be the PCoA, which can be either the Home
redundant, must be set to PAR's IP address, and the Care-of Address Address (in FA CoA mode) or the co-located CoA. The Home Agent field,
must be the NAR's IP address discovered via PrRtAdv message. The even though redundant, must be set to PAR's IP address, and the
destination IP address of the FBU message must be PAR's IP address. Care-of Address field must be the NAR's IP address discovered via
PrRtAdv message. The destination IP address of the FBU message must
be PAR's IP address. The source IP address of FBU message must
contain the PCoA (in co-located mode) or the Home Address (in FA CoA
mode) or NAR's IP address (when NAR forwards the message to PAR).
When attachment to a new link is detected, FBU should be (re)sent. When attachment to a new link is detected, FBU should be (re)sent.
When sent in this ``reactive'' mode, the destination address must When sent in this ``reactive'' mode, the destination address must
be NAR's IP address, and the source address must be PCoA from the be NAR's IP address, and the source address must be either Home
FBU message. The Home Agent field must be set to PAR's IP address. Address (FA CoA mode) or PCoA (in co-located mode) the from the FBU
message. The Home Agent field must be set to PAR's IP address.
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 can and created a host route entry for the PCoA. In that case, NAR can
immediately forward arriving and buffered packets including the FBAck immediately forward arriving and buffered packets including the FBAck
message. In any case, NAR MUST forward the contents of this message, message. In any case, NAR MUST forward the contents of this message,
starting from the Type field, to PAR. starting from the Type field, to PAR.
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
serve to establish a tunnel between the routers to support packet serve to establish a bidirectional tunnel between the routers to
forwarding for PCoA. The tunnel itself is established as a response support packet forwarding for PCoA. The tunnel itself is established
to the FBU message. Furthermore, when the MN obtains a NCoA from as a response to the FBU message.
NAR, the reverse tunnel to the PAR is not necessary; the MN would
reverse tunnel to the Home Agent directly using its NCoA.
The PAR sends HI message with Code = 0 when it receives FBU with 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 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 it receives FBU with source IP address not set to PCoA (i.e., when
received from NAR). This allows NAR to disambiguate processing when received from NAR). This allows NAR to disambiguate HI message
HI needs to be sent as a response to predictive and reactive modes of processing sent as a response to predictive and reactive modes of
operation. operation.
2.2. Assigned Addressing Support 3.2. Assigned Addressing Support
In this mode, the NAR provides NCoA, which is delivered to the MN in In this mode, the NAR provides NCoA, which is delivered to the MN
the FBAck message either on the previous link or on the new link. in the FBAck message either on the previous link or on the new
Since the MN is unaware of the address that NAR might assign, it link. Since the MN is unaware of the address that NAR might assign,
always binds its PCoA to NAR's address. This results in a tunnel it always binds its PCoA to NAR's address. This results in a
from PAR to NAR. However, with Mobile IP, a reverse tunnel to PAR is bidirectional tunnel between PAR and NAR.
not necessary since the MN can directly reverse tunnel to the Home
Agent.
The source IP address in FBU is PCoA regardless of the link it is The source IP address in FBU is PCoA regardless of the link it is
sent from. The destination address is either PAR's IP address or the sent from. The destination address is either PAR's IP address or the
NAR's IP address depending on the link from which FBU is sent. The NAR's IP address depending on the link from which FBU is sent. The
FBAck message MUST include a NCoA extension. The NAR MUST provide FBAck message MUST include a NCoA extension. The NAR MUST provide
NCoA in the HAck message. The NAR MUST also include the extension NCoA in the HAck message. The NAR MUST also include the extension
when responding to FBU sent from the new link. when responding to FBU sent from the new link.
3. Use of Previous FA Notification Extension 4. Use of 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 [3]. However, with the neighborhood using the extension defined in [3]. However, with the neighborhood
information gathered using the proxy router messages (see information gathered using the proxy router messages (see
Section 4.3, Section 4.4), movement detection and router discovery Section 5.3, Section 5.4), movement detection and router discovery
delays are avoided even in the reactive case. The FBU and FBAck delays are avoided even in the reactive case. The FBU and FBAck
messages defined in this document can be naturally used even when no messages defined in this document can be naturally used even when no
neighborhood information is available. neighborhood information is available.
4. Message Formats 5. Message Formats
4.1. Fast Binding Update (FBU) 5.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 used, format in RFC 3344. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |x|x|D|M|G|r|T|x| reserved | Lifetime | | Type |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Figure 1: Fast Binding Update (FBU) Message Figure 1: Fast Binding Update (FBU) Message
IP fields: IP fields:
Source address Source address
The interface address from which the The interface address from which the
message is sent. Either PCoA or NAR's IP message is sent. Either PCoA (co-located
address. mode), or Home Address (FA CoA mode) or
NAR's IP address (when forwarded from NAR
to PAR).
Destination Address Destination Address
The IP address of the Previous Access The IP address of the Previous Access
Router or the New Access Router. Router or the New Access Router.
Source Port variable Source Port variable
Destination port 434 (TBA) Destination port 434 (TBA)
Type To be assigned by IANA Type To be assigned by IANA
Flags See RFC 3344 Flags See RFC 3344
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 or the MN's Home Address Home Address MUST be PCoA or the MN's 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 See RFC 3344 Identification See RFC 3344
Extensions MUST contain the MN - PAR Authentication Extensions MUST contain the MN - PAR Authentication
Extension Extension
4.2. Fast Binding Acknowledgment (FBAck) 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 [4]. format in [4].
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 | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
skipping to change at page 7, line 25 skipping to change at page 8, line 25
Destination port copied from thr source port in FBU message Destination port copied from thr 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 means Fast Binding Update message. Code = 0 means Fast Binding Update
accepted. Code = 1 means Fast Binding Update accepted. Code = 1 means Fast Binding Update
accepted but NCoA is supplied as an extension. accepted but NCoA is supplied as an extension.
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 PCoA or MN's Home Address Home Address PCoA or MN's Home 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. See RFC Identification a 64-bit number used for matching FBU. See RFC
3344. 3344.
Extensions The PAR - MN Authentication extension MUST be Extensions The PAR - MN Authentication extension MUST be
present. In addition, a NCoA option MUST be present. In addition, a NCoA option MUST be
present when NAR supplies the NCoA. present when NAR 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 [4], then the mobile node MUST set the Foreign Agent care-of address [4], then the mobile node MUST set the
'D' bit in its Registration Request message that it uses to register 'D' bit in its Registration Request message that it uses to register
the NCoA with its home agent. the NCoA with its home agent.
4.3. Router Solicitation for Proxy Advertisement (RtSolPr) 5.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 5.1. The link-layer address options have the format defined in 6.1. The
message format and processing rules are identical to that defined message format and processing rules are identical to that defined
in [2]. We only provide the format here for convenience. in [2]. We only provide the format here for convenience.
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 9, line 13 skipping to change at page 10, line 13
Valid Options: Valid Options:
New Access Point Link-layer Address New Access Point Link-layer Address
The link-layer address or identification of the The link-layer address or identification of the
access point for which the MN requests routing access point for which the MN requests routing
advertisement information. It MUST be included advertisement information. It MUST be included
in all RtSolPr messages. More than one such address in all RtSolPr messages. More than one such address
or identifier can be present. This field can also or identifier can be present. This field can also
be a wildcard address with all bits set to zero. be a wildcard address with all bits set to zero.
4.4. Proxy Router Advertisement (PrRtAdv) 5.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 RtSolPr message from a MN, providing the link-layer address, to RtSolPr message from a MN, providing the link-layer address,
IP address and subnet prefixes of neighboring routers. All the IP address and subnet prefixes of neighboring routers. All the
link-layer address options have the format defined in 5.1. link-layer address options have the format defined in 6.1.
The message format and processing rules are identical to that defined The message format and processing rules are identical to that defined
in [2]. We only provide the format here for convenience. The ICMP in [2]. We only provide the format here for convenience. The ICMP
checksum is defined in [1]. checksum is defined in [1].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 5 skipping to change at page 12, line 5
New Router Prefix Information Option New Router Prefix Information Option
The number of leading bits that define the network The number of leading bits that define the network
number of the corresponding Router's IP Address number of the corresponding Router's IP Address
option (see above). option (see above).
New CoA Option New CoA Option
MAY be present when PrRtAdv is sent MAY be present when PrRtAdv is sent
unsolicited. PAR MAY compute new CoA using NAR's unsolicited. PAR MAY compute new CoA using NAR's
prefix information and the MN's L2 address, or by prefix information and the MN's L2 address, or by
any other means. any other means.
4.5. Inter-Access Router Messages 5.5. Inter-Access Router Messages
4.5.1. Handover Initiate (HI) 5.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 MN's handover. initiate the process of a MN's handover.
The message format and processing rules are identical to that defined The message format and processing rules are identical to that defined
in [2]. We only provide the format here for convenience. in [2]. We only provide the format here for convenience.
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 12, line 39 skipping to change at page 13, line 39
The IP address used by the MN while The IP address used by the MN while
attached to the originating router. This option attached to the originating router. This option
SHOULD be included so that host route can be SHOULD be included so that host route can be
established in case necessary. established in case necessary.
New Care of Address New Care of Address
The IP address the MN wishes to use when The IP address the MN wishes to use when
connected to the destination. When the `S' bit is connected to the destination. When the `S' bit is
set, NAR MAY assign this address. set, NAR MAY assign this address.
4.5.2. Handover Acknowledge (HAck) 5.5.2. 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 4.5.1) message. (HI) (see section 5.5.1) message.
The message format and processing rules are identical to that defined The message format and processing rules are identical to that defined
in [2]. We only provide the format here for convenience. in [2]. We only provide the format here for convenience.
IP Fields: IP Fields:
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 |
skipping to change at page 14, line 20 skipping to change at page 15, line 20
Valid Options: Valid Options:
New Care of Address New Care of Address
If the S flag in the Handover Initiate 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 this option MUST be used to provide NCoA the MN should
use when connected to this router. This option MAY be use when connected to this router. This option MAY be
included even when `S' bit is not set, e.g., Code 2 included even when `S' bit is not set, e.g., Code 2
above. above.
5. Option formats 6. Option formats
The options in this section are specified as optional extensions The options in this section are specified as optional extensions
for the HI and HAck messages, as well as for the Router Proxy for the HI and HAck messages, as well as for the Router Proxy
Solicitation and Router Proxy Advertisement messages.. Solicitation and Router Proxy Advertisement messages..
5.1. Link-Layer Address Option Format 6.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 | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Link-Layer Address Option Format Figure 7: Link-Layer Address Option Format
Fields: Fields:
skipping to change at page 15, line 12 skipping to change at page 16, line 12
length fields) in units of octets. For example, length fields) in units of octets. For example,
the length for IEEE 802 addresses is 1 [IPv6- the length for IEEE 802 addresses is 1 [IPv6-
ETHER]. ETHER].
Link-Layer Address Link-Layer Address
The variable length link-layer address. The variable length link-layer address.
The content and format of this field (including The content and format of this field (including
byte and bit ordering) depends on the specific byte and bit ordering) depends on the specific
link-layer in use. link-layer in use.
5.2. New IPv4 Address Option Format 6.2. New IPv4 Address Option Format
This option is used to provide the new router's IPv4 address in This option is used to provide the new router's IPv4 address in
PrRtAdv. When it is also used to provide NCoA, it MUST appear after PrRtAdv. When it is also used to provide NCoA, it MUST appear after
the new router's IPv4 address to distinguish the two addresses. the new router's IPv4 address to distinguish the two addresses.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 40 skipping to change at page 16, line 40
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 and
length fields) in units of octets. length fields) in units of octets.
Reserved Set to zero. Reserved Set to zero.
NCoA The New CoA assigned by NAR. NCoA The New CoA assigned by NAR.
5.3. New Router Prefix Information Option 6.3. New Router Prefix Information Option
This option is the same as the ``Prefix-Lengths Extension'' in RFC This option is the same as the ``Prefix-Lengths Extension'' in RFC
3344 (Section 2.1.2). 3344 (Section 2.1.2).
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 | Prefix-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 27 skipping to change at page 17, line 27
Length 1 Length 1
Prefix-Length Prefix-Length
The number of leading bits that define the network The number of leading bits that define the network
number of the corresponding Router's IP Address number of the corresponding Router's IP Address
option. option.
Reserved Set to zero. Reserved Set to zero.
6. Security Considerations 7. Security Considerations
The FBU and FBack messages MUST be protected using a security The FBU and FBack messages MUST be protected using a security
association shared between a MN and its access router. In association shared between a MN 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. Failure to include this extension can lead each of these messages. Failure to include this extension can lead
to a bogus node claiming a genuine MN's address and binding it to to a bogus node claiming a genuine MN's address and binding it to
an arbitrary address. When the NCoA is NAR's address, there is no an arbitrary address. When the NCoA is NAR's address, there is no
risk of a genuine MN misdirecting traffic, either inadvertantly or risk of a genuine MN misdirecting traffic, either inadvertantly or
intentionally, to an unsuspecting node on NAR's subnet. When NCoA is 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 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 HI is conflict-free, and MUST indicate the disposition in the HAck
message. If there is a conflict, PAR MUST NOT tunnel packets to message. If there is a conflict, PAR MUST NOT tunnel packets to
the address in question. Instead, PAR SHOULD tunnel packets to the the address in question. Instead, PAR SHOULD tunnel packets to the
address specified in HAck, if any is provided. address specified in HAck, if any is provided.
7. IANA Considerations 8. 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.
References References
[1] S. Deering. ICMP Router Discovery Messages. Request for [1] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991. Force, September 1991.
skipping to change at page 17, line 31 skipping to change at page 18, line 31
in progress). Internet Draft, Internet Engineering Task Force. in progress). Internet Draft, Internet Engineering Task Force.
draft-ietf-mobileip-optim-09.txt, February 2000. draft-ietf-mobileip-optim-09.txt, February 2000.
[4] C. Perkins (Editor). IP Mobility Support for IPv4. Request for [4] C. Perkins (Editor). IP Mobility Support for IPv4. Request for
Comments (Proposed Standard) 3344, Internet Engineering Task Comments (Proposed Standard) 3344, Internet Engineering Task
Force, August 2002. Force, August 2002.
Questions about this memo can be directed to the authors: Questions about this memo can be directed to the authors:
Rajeev Koodli Charles E. Perkins Rajeev Koodli Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center Nokia Research Center Nokia Research Center
975 Page Mill Road 975 Page Mill Road 313 Fairchild Drive 313 Fairchild Drive
Palo Alto, California 94304 Palo Alto, California 94304 Mountain View, California 94043 Mountain View, California 94043
USA USA USA USA
Phone: +1-650 625-2359 Phone: +1-650 625-2986 Phone: +1-650 625-2359 Phone: +1-650 625-2986
EMail: rajeev.koodli@nokia.com EMail: charles.perkins@nokia.com EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 739 0779 Fax: +1 650 739 0779 Fax: +1 650 625-2502 Fax: +1 650 625-2502
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 52 change blocks. 
94 lines changed or deleted 142 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/