draft-ietf-mip4-fmipv4-02.txt   draft-ietf-mip4-fmipv4-03.txt 
Mobile IPv4 Working Group Rajeev Koodli Mobile IPv4 Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins INTERNET DRAFT Charles E. Perkins
23 October 2006 Nokia Research Center Experimental Nokia Research Center
6 February 2007
Mobile IPv4 Fast Handovers Mobile IPv4 Fast Handovers
draft-ietf-mip4-fmipv4-02.txt draft-ietf-mip4-fmipv4-03.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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of
and may be updated, replaced, or obsoleted by other documents at six months and may be updated, replaced, or obsoleted by other
any time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference 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
directed to the MIP6 WG mailing list, mip4@ietf.org. be directed to the MIP4 WG mailing list, mip4@ietf.org.
Abstract Abstract
The Mobile IPv6 fast handover document [2] specifies a protocol to This document adapts the Mobile IPv6 Fast Handovers [1] to
improve latency and packet loss resulting from Mobile IPv6 handover improve delay and packet loss resulting from Mobile IPv4 handover
operations. This document adapts the protocol for IPv4 networks operations. Specifically, this document addresses movement
to improve performance over Mobile IPv4 operations, including detection, IP address configuration and location update latencies
processing of Agent Advertisements, new Care of Address acquisition during a handover. For reducing the IP address configuration
and Registration Request and Reply. Using the concepts outlined latency, the document proposes that the new Care-of Address is
in [2], this document also addresses movement detection, IP address always made to be the new access router's IP address. Additional
configuration and location update latencies during a handover. mechanisms may be defined in the future versions of this document.
For reducing the IP address configuration, the 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. Factors Affecting Handover 2 2. Factors Affecting Handover 3
3. Protocol Operation 3 3. Protocol 4
3.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . 4
3.2. Assigned Addressing Support . . . . . . . . . . . . . . . 5 3.2. Operation . . . . . . . . . . . . . . . . . 5
4. Use of Previous FA Notification Extension 5 4. Use of Previous FA Notification Extension 8
5. Message Formats 5 5. Message Formats 9
5.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 5 5.1. Fast Binding Update (FBU) . . . . . . . . . . . . 9
5.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 7 5.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . 11
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 8 5.3. Router Solicitation for Proxy Advertisement (RtSolPr) . 13
5.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 10 5.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . 15
5.5. Inter-Access Router Messages . . . . . . . . . . . . . . 12 5.5. Inter-Access Router Messages . . . . . . . . . . 17
5.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 12 5.5.1. Handover Initiate (HI) . . . . . . . . . 17
5.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 13 5.5.2. Handover Acknowledge (HAck) . . . . . . . . 19
6. Option formats 15 6. Option formats 22
6.1. Link-Layer Address Option Format . . . . . . . . . . . . 15 6.1. Link-Layer Address Option Format . . . . . . . . . 22
6.2. New IPv4 Address Option Format . . . . . . . . . . . . . 16 6.2. New IPv4 Address Option Format . . . . . . . . . . 23
6.3. New Router Prefix Information Option . . . . . . . . . . 16 6.3. New Router Prefix Information Option . . . . . . . . 24
7. Security Considerations 17 7. Security Considerations 25
8. IANA Considerations 18 8. IANA Considerations 25
Intellectual Property Statement 18 9. Acknowledgement 25
Disclaimer of Validity 19 Intellectual Property Statement 27
Copyright Statement 19 Disclaimer of Validity 27
Acknowledgment 19 Copyright Statement 28
Acknowledgment 28
1. Introduction 1. Introduction
This document adapts the fast handover specification [2] to IPv4 This document adapts the fast handover specification [1] to
networks. The fast handover protocol specified in this document IPv4 networks. The fast handover protocol specified in this
is particularly interesting for operation on commonly available document is particularly interesting for operation over wireless
wireless links such as IEEE 802.11 WLAN links. Fast handovers are links such as IEEE 802 wireless links. Fast handovers are not
not typically needed for wired media due to the relatively large typically needed for wired media due to the relatively large delays
delays attributable to establishing new connections in today's wired attributable to establishing new connections in today's wired
networks. Mobile IPv4 registration messages are re-used (with new networks. Mobile IPv4 [2] registration messages are re-used (with
type numbers) to enable quick implementation using existing foreign new type numbers) to enable faster implementation using existing
agent software. This draft does not rely on link-layer triggers for Mobile IPv4 software. This draft does not rely on link-layer
protocol operation, but performance will typically be enhanced by triggers for protocol operation, but performance will typically be
using the appropriate triggers when they are available. enhanced by using the appropriate triggers when they are available.
This document assumes that the reader is familiar with the basic
operation and terminology of Mobile IPv4 [1] and Fast Handovers for
Mobile IPv6 [1].
The active agents that enable continued packet delivery to a mobile The active agents that enable continued packet delivery to a mobile
node are the access routers on the networks that the mobile node node (MN) are the access routers on the networks that the mobile
connects to. Handover means that the mobile node changes its network node connects to. Handover means that the mobile node changes its
connection, and we consider the scenario in which this change means network connection, and we consider the scenario in which this
change in access routers. The mobile node utilizes the access change means change in access routers. The mobile node utilizes
routers as default routers in the normal sense, but also as partners the access routers as default routers in the normal sense, but also
in mobility management. Thus, when the mobile node moves to a new as partners in mobility management. Thus, when the mobile node
network, it processes handover-related signaling in order to identify moves to a new network, it processes handover-related signaling
and develop a relationship with a new access router. In this in order to identify and develop a relationship with a new access
document, we call the previous access router PAR and the new access router. In this document, we call the previous access router PAR
router NAR. Unless otherwise mentioned, a PAR is also a Previous FA and the new access router NAR, consistent with the terminology
(PFA) and a NAR is also a New FA (NFA). in [1]. Unless otherwise mentioned, a PAR is also a Previous
Foreign Agent (PFA) and a NAR is also a New Foreign Agent (NFA).
On a particular network, the MN may obtain its IP address via DHCP On a particular network, a mobile node may obtain its IP address
(i.e., CCoA) or use the Foreign Agent CoA. During a handover, the new via DHCP [6] (i.e., Co-located Care-of Address) or use the Foreign
CoA is always made to be that of NAR. This allows a MN to receive and Agent CoA. During a handover, the new CoA (NCoA) is always made
send packets using its previous CoA, so that delays resulting from IP to be that of NAR. This allows a mobile node to receive and send
configuration (such as DHCP address acquisition delay) subsequent to packets using its previous CoA (PCoA), so that delays resulting
attaching to the new link are disengaged from affecting the existing from IP configuration (such as DHCP address acquisition delay)
sessions. subsequent to attaching to the new link are disengaged from
affecting the existing sessions.
2. Factors Affecting Handover 2. Factors Affecting Handover
Both the link-layer operations and IP layer procedures affect the Both the link-layer operations and IP layer procedures affect the
perceived handover performance. However, the overall performance is perceived handover performance. However, the overall performance
also (always) a function of specific implementation of the technology is also (always) a function of specific implementation of the
as well as the system configuration. This document only specifies IP technology as well as the system configuration. This document
layer protocol operations. The purpose of this section is to provide only specifies IP layer protocol operations. The purpose of
an illustration of events that affect handover performance, but it is this section is to provide an illustration of events that affect
purely informative. handover performance, but it is purely informative.
The IP layer handover delay and packet loss are influenced by The IP layer handover delay and packet loss are influenced by
latencies due to movement detection, IP address configuration and latencies due to movement detection, IP address configuration and
Mobile IP registration procedure. Movement detection latency comes Mobile IP registration procedure. Movement detection latency
from the need to reliably detect movement to a new subnet. This is comes from the need to reliably detect movement to a new subnet.
a function of frequency of router advertisements as well as default This is a function of frequency of router advertisements as well
agent reachability. IP address configuration latency depends on the as default agent reachability. IP address configuration latency
particular IP CoA being used. If co-located mode with DHCP is used, depends on the particular IP CoA being used. If co-located mode
the latency is quite likely going to be higher and unacceptable for with DHCP is used, the latency is quite likely going to be higher
real-time applications such as Voice over IP. Finally, the Mobile and unacceptable for real-time applications such as Voice over IP.
IP registration procedure needs a round-trip of delay between the Finally, the Mobile IP registration procedure needs a round-trip of
Mobile Node and its Home Agent over the Internet. This delay is delay between the Mobile Node and its Home Agent over the Internet.
incurred after the Mobile Node performs movement detection and IP This delay is incurred after the mobile node performs movement
configuration. detection and IP configuration.
Underlying the IP operations are link-layer procedures. These Underlying the IP operations are link-layer procedures. These are
are clearly technology-specific. For instance, in IEEE 802.11b clearly technology-specific. For instance in IEEE 802.11, the
which is also known as WLAN, the handover operation may involve handover operation typically involves scanning access points over
scanning access points over all available channels, selecting a all available channels, selecting a suitable access point, and
suitable access point and associating with it. It may also involve associating with it. It may also involve performing access control
performing access control operations such as those specified in operations such as those specified in IEEE 802.1X [4]. These
IEEE 802.1X. These delays contribute to the handover performance. delays contribute to the handover performance. Optimizations are
Optimizations have been proposed and are being standardized in IEEE being proposed for standardization in IEEE, for instance see [5]
however. Together with appropriate implementation techniques, these and [3]. Together with appropriate implementation techniques,
optimizations can provide the required level of delay support for these optimizations can provide the required level of delay support
real-time applications. at the link-layer for real-time applications.
3. Protocol Operation 3. Protocol
The design of the protocol is the same as for Mobile IPv6 [2]. 3.1. Overview
Readers should consult [2] for details, and here we provide a
The design of the protocol is the same as for Mobile IPv6 [1].
Readers should consult [1] for details, and here we provide a
summary. summary.
The protocol avoids the delay due to movement detection and IP The protocol avoids the delay due to movement detection and IP
configuration and disengage Mobile IP registration delay from the configuration and disengage Mobile IP registration delay from
time-critical path. The protocol provides the surrounding network the time-critical path. The protocol provides the surrounding
network neighborhood information so that a Mobile Node can determine network network neighborhood information so that a mobile node can
whether it is moving to a new subnet even before the handover. The determine whether it is moving to a new subnet even before the
information provided and the signaling exchange between the local handover. The information provided and the signaling exchanged
mobility agents allows the Mobile Node to send and receive packets between the local mobility agents allows the mobile node to send
immediately after handover. In order to disengage the Mobile IP and receive packets immediately after handover. In order to
registration latency, the protocol provides routing support for the disengage the Mobile IP registration latency, the protocol provides
continued use of a Mobile Node's previous CoA. 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 mobile node obtains its IPv4 care-of address, it builds
access point and subnet map using the Router Solicitation for Proxy a neighborhood access point and subnet map using the Router
Advertisement and Proxy Router Advertisement messages. The MN may Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
scan for access points (APs) based on the configuration policy in Advertisement (PrRtAdv) messages. The mobile node may scan for
operation for its wireless network interface. If a scan results in access points (APs) based on the configuration policy in operation
a new AP discovery, the MN resolves the AP-ID to subnet information for its wireless network interface. If a scan results in a new AP
using the messages defined below. discovery, the mobile node resolves the corresponding AP Identifier
to subnet information using the RtSolPr and PrRtAdv messages
mentioned above.
At some point, the mobile node decides to undergo handover. It
sends an FBU message to PAR from the previous link or from the new
link. FBU message enables creation of a binding between the mobile
node's previous CoA and the new CoA.
The coordination between the access routers is done by way of the The coordination between the access routers is done by way of the
Handover Initiate (HI) and Handover Acknowledge (HAck) messages. Handover Initiate (HI) and Handover Acknowledge (HAck) messages
After these signals have been exchanged between the previous and new defined in [1]. After these signals have been exchanged between
access routers (PAR and NAR), data arriving at PAR will be tunneled the previous and new access routers (PAR and NAR), data arriving
to NAR for delivery to the newly arrived mobile node. The purpose at PAR will be tunneled to NAR for delivery to the newly arrived
of HI is to securely deliver the routing parameters for establishing mobile node. The purpose of HI is to securely deliver the routing
this tunnel. The tunnel is created by the access routers in response parameters for establishing this tunnel. The tunnel is created by
to the delivery of the FBU from the mobile node. the access routers in response to the delivery of the FBU from the
mobile node.
We consider three scenarios. First, the access routers are not 3.2. Operation
involved in IP address assignment for the MN not any more than,
e.g., being a DHCP Relay when DHCP is being used. Second, an access
router acts as a foreign agent, using the same IP address for use by
a multiplicity of mobile nodes. In this scenario, an access router
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
visiting mobile node by some means not specified in this document.
Just as a simple example, an access router may maintain a pool of
IPv4 addresses for temporary use by visiting mobile nodes.
The protocol semantics are almost identical in all scenarios. The In response to a handover trigger or indication, the mobile node
packet formats presented in RFC 3344 are re-used to achieve maximum sends a Fast Binding Update message to Previous Access Router (PAR)
compatibility with Mobile IP. (see Section 5.1). Depending on whether the Mobile IP mode of
operation, the PCoA is either the Home Address (in FA CoA mode)
or co-located CoA (in CCoA mode). The FBU message SHOULD be sent
when the mobile node is still connected to PAR. When sent in this
``predictive'' mode, the fields in the FBU are used as follows:
3.1. Basic NCoA Support - ``Home Address'' field must be the PCoA (which can be either
the Home Address or the co-located CoA)
In response to a handover trigger or indication, the MN sends a - Home Agent field, even though redundant, must be set to PAR's
Fast Binding Update message to Previous Access Router (PAR) (see IP address
Section 5.1). This message should be sent when the MN is still
connected to PAR. When sent in this ``predictive'' mode, the ``Home - Care-of Address field must be the NAR's IP address discovered
Address'' field must be the PCoA, which can be either the Home via PrRtAdv message
Address (in FA CoA mode) or the co-located CoA. The Home Agent field,
even though redundant, must be set to PAR's IP address, and the - Destination IP address 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 - Source IP address must be the PCoA (which can be either the
be PAR's IP address. The source IP address of FBU message must Home Address or the co-located CoA)
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). 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 message (see 5.2) as a response to the mobile node.
The timeline for the predictive mode of operation (adapted
from [1]) is shown in Figure 1.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FBU --------------------------->|
|<=================================== deliver packets
| |<-----FBU-----------|
Figure 1: Predictive Fast Handover
The mobile node sends the FBU regardless of its previous
transmission when attachment to a new link is detected. This
minimally allows NAR to detect mobile node's attachment, but also
the retransmission of FBU when an FBack has not been received yet.
When sent in this ``reactive'' mode, the following fields in FBU
are set differently compared to the predictive mode:
- 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 attachment to a new link is detected, FBU should be (re)sent.
When sent in this ``reactive'' mode, the destination address must
be NAR's IP address, and the source address must be either Home
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
immediately forward arriving and buffered packets including the FBAck should immediately forward arriving and buffered packets including
message. In any case, NAR MUST forward the contents of this message, the FBAck message. In any case, NAR MUST forward the contents of
starting from the Type field, to PAR. this message, starting from the Type field, to PAR, which means the
Source and Destination IP addresses now contain the IP addresses of
NAR and PAR respectively.
The reactive mode of operation (adapted from [1]) is illustrated in
Figure 2.
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages 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
support packet forwarding for PCoA. The tunnel itself is established to support packet forwarding for PCoA. The tunnel itself is
as a response to the FBU message. established as a response to the FBU message. The PAR sends HI
message with Code = 0 when it receives FBU with source IP address
set to PCoA. The PAR sends HI with Code = 1 when it receives FBU
with source IP address not set to PCoA (i.e., when received from
NAR). This allows NAR to disambiguate HI message processing sent as
a response to predictive and reactive modes of operation. If NAR
receives a HI message with Code = 1, and it has already set up a
host route entry and a reverse tunnel for PCoA, it should silently
discard the HI message.
The PAR sends HI message with Code = 0 when it receives FBU with The protocol provides an option for NAR to return NCoA for use by
source IP address set to PCoA. The PAR sends HI with Code = 1 when the mobile node. When NAR can provide an NCoA for exclusive use of
it receives FBU with source IP address not set to PCoA (i.e., when the mobile node, the address is supplied in the HAck message. The
received from NAR). This allows NAR to disambiguate HI message PAR includes this NCoA in FBack.
processing sent as a response to predictive and reactive modes of
operation.
3.2. Assigned Addressing Support Even though the mobile node can obtain this NCoA from the NAR, it
is unaware of the address at the time it sends an FBU. Hence, it
binds PCoA to NAR's IP address as before.
In this mode, the NAR provides NCoA, which is delivered to the MN MN PAR NAR
in the FBAck message either on the previous link or on the new | | |
link. Since the MN is unaware of the address that NAR might assign, |------RtSolPr------->| |
it always binds its PCoA to NAR's address. This results in a |<-----PrRtAdv--------| |
bidirectional tunnel between PAR and NAR. | | |
disconnect | |
| | |
| | |
connect | |
|-----------FBU-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
The source IP address in FBU is PCoA regardless of the link it is Figure 2: Reactive Fast Handover
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
FBAck message MUST include a NCoA extension. The NAR MUST provide
NCoA in the HAck message. The NAR MUST also include the extension
when responding to FBU sent from the new link.
4. 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 [2]. However, with the neighborhood
information gathered using the proxy router messages (see information gathered using the proxy router messages (see
Section 5.3, Section 5.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
neighborhood information is available. no neighborhood information is available.
5. Message Formats 5. Message Formats
5.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
but the FBU and FBAck messages in this specification have new message used, but the FBU and FBAck messages in this specification have new
type numbers. message 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 |S|B|D|M|G|r|T|x| Lifetime | | Type |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Figure 1: Fast Binding Update (FBU) Message Figure 3: 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 (co-located message is sent. Either PCoA (co-located
mode), or Home Address (FA CoA mode) or or Home Address), or NAR's IP address
NAR's IP address (when forwarded from NAR (when forwarded from NAR to PAR).
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
Type To be assigned by IANA Type To be assigned by IANA
Flags See RFC 3344 Flags See RFC 3344
Lifetime The number of seconds remaining before binding
expires. MUST NOT exceed 10 seconds.
Home Address MUST be PCoA or the MN's Home Address reserved Sent as zero, ignored on input
Home Agent The Previous Access Router's global IP address Lifetime The number of seconds remaining before
binding expires. MUST NOT exceed 10
seconds.
Home Address MUST be PCoA (i.e., either co-located CoA or
Home 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
5.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 [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 | Code | Lifetime | | Type | Code | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Figure 2: Fast Binding Acknowledgment (FBAck) Message Figure 4: Fast Binding Acknowledgment (FBAck) Message
IP fields: IP fields:
Source address Source address
Typically copied from the destination Typically copied from the destination
address of the FBU message address of the FBU message
Destination Address Destination Address
Copied from the Source IP address in FBU Copied from the Source IP address in FBU
message message
Source Port variable Source Port variable
Destination port copied from thr source port in FBU message Destination port copied from the source port in FBU message
Type To be assigned by IANA Type To be assigned by IANA
Code Indicates the result of processing FBU Code Indicates the result of processing FBU
message. Code = 0 means Fast Binding Update message. Code = 0 means Fast Binding Update
accepted. Code = 1 means Fast Binding Update accepted. Code = 1 means Fast Binding
accepted but NCoA is supplied as an extension. Update accepted but NCoA is supplied as an
extension.
Lifetime The number of seconds remaining before binding reserved Sent as zero, ignored on input
expires. MUST NOT exceed 10 seconds.
Home Address PCoA or MN's Home Address Lifetime The number of seconds remaining before
binding expires. MUST NOT exceed 10
seconds.
Home Agent The Previous Access Router's global IP address Home Address PCoA (i.e., either co-located CoA or Home
Address)
Identification a 64-bit number used for matching FBU. See RFC Home Agent The Previous Access Router's global IP
3344. address
Extensions The PAR - MN Authentication extension MUST be Identification a 64-bit number used for matching FBU. See
present. In addition, a NCoA option MUST be RFC 3344.
present when NAR supplies the NCoA.
Extensions The PAR - MN Authentication extension MUST
be present. In addition, an NCoA option
MUST be 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 [2], then the mobile node MUST set
'D' bit in its Registration Request message that it uses to register the 'D' bit in its Registration Request message that it uses to
the NCoA with its home agent. register the NCoA with its home agent.
5.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 6.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 those defined
in [2]. We only provide the format here for convenience. in [1]. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: Router Solicitation for Proxy (RtSolPr) Message Figure 5: Router Solicitation for Proxy (RtSolPr) Message
IP Fields: IP Fields:
Source Address Source Address
An IP address assigned to the sending interface An IP address assigned to the sending interface
Destination Address Destination Address
The address of the Access Router or the all routers The address of the Access Router or the all routers
multicast address. multicast address.
Time-to-Live At least 1. See RFC 1256. Time-to-Live At least 1. See RFC 1256.
ICMP Fields: ICMP Fields:
Type To be assigned by IANA Type To be assigned by IANA
Code 0 Code 0
Checksum The ICMP checksum. See RFC 1256 Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, start-
ing with the ICMP Type. For computing the
checksum, the Checksum and the Reserved fields are
set to 0. See RFC 1256.
Subtype To be assigned by IANA Subtype To be assigned by IANA
Reserved MUST be set to zero by the sender and ignored by Reserved MUST be set to zero by the sender and ignored by
the receiver. the receiver.
Identifier MUST be set by the sender so that replies can be Identifier MUST be set by the sender so that replies can be
matched to this Solicitation. matched to this Solicitation.
Valid Options: Valid Options:
skipping to change at page 10, line 17 skipping to change at page 15, line 10
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.
5.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 mobile node, providing the link-layer
IP address and subnet prefixes of neighboring routers. All the address, IP address and subnet prefixes of neighboring routers.
link-layer address options have the format defined in 6.1. All the 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 those
in [2]. We only provide the format here for convenience. The ICMP defined in [1]. We only provide the format here for convenience.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier | | Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Proxy Router Advertisement (PrRtAdv) Message Figure 6: Proxy Router Advertisement (PrRtAdv) Message
IP Fields: IP Fields:
Source Address Source Address
An IP address assigned to the sending interface An IP address assigned to the sending interface
Destination Address Destination Address
The Source Address of an invoking Router The Source Address of an invoking Router
Solicitation for Proxy Advertisement or the address Solicitation for Proxy Advertisement or the address
of the node the Access Router is instructing to of the node the Access Router is instructing to
handover. handover.
Time-to-Live At least 1. See RFC 1256. Time-to-Live At least 1. See RFC 1256.
ICMP Fields: ICMP Fields:
skipping to change at page 11, line 14 skipping to change at page 16, line 18
handover. handover.
Time-to-Live At least 1. See RFC 1256. Time-to-Live At least 1. See RFC 1256.
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 ICMP checksum. See RFC 1256. Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, start-
ing with the ICMP Type. For computing the
checksum, the Checksum and the Reserved fields are
set to 0. See RFC 1256.
Subtype To be assigned by IANA. Subtype To be assigned by IANA.
Reserved MUST be set to zero by the sender and ignored by Reserved MUST be set to zero by the sender and ignored by
the receiver. the 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:
skipping to change at page 12, line 11 skipping to change at page 17, line 26
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.
5.5. Inter-Access Router Messages 5.5. Inter-Access Router Messages
5.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 mobile node's handover.
The message format and processing rules are identical to that defined The message format and processing rules are identical to those
in [2]. We only provide the format here for convenience. defined in [1]. We only provide the format here for convenience.
IP Fields:
Source Address
The IP address of the PAR
Destination Address
The IP address of the NAR
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier | | Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Handover Initiate (HI) Message Figure 7: Handover Initiate (HI) Message
IP Fields:
Source Address
The IP address of the PAR
Destination Address
The IP address of the NAR
Time-to-Live At least 1. See RFC 1256. Time-to-Live At least 1. See RFC 1256.
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 ICMP checksum. See RFC 1256 Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, start-
ing with the ICMP Type. For computing the
checksum, the Checksum and the Reserved fields are
set to 0. See RFC 1256.
Subtype To be assigned by IANA Subtype To be assigned by IANA
S Assigned address configuration flag. When set, this S Assigned address configuration flag. When set, this
message requests a new CoA to be returned by the message requests a new CoA to be returned by the
destination. May be set when Code = 0. MUST be 0 destination. May be set when Code = 0. MUST be 0
when Code = 1. when Code = 1.
U Buffer flag. When set, the destination SHOULD buffer U Buffer flag. When set, the destination SHOULD buffer
any packets towards the node indicated in the options any packets towards the node indicated in the options
of this message. Used when Code = 0, SHOULD be set of this message. Used when Code = 0, SHOULD be set
to 0 when Code = 1. to 0 when Code = 1.
skipping to change at page 13, line 41 skipping to change at page 19, line 37
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.
5.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
be sent (typically by NAR to PAR) as a reply to the Handover Initiate MUST be sent (typically by NAR to PAR) as a reply to the Handover
(HI) (see section 5.5.1) message. Initiate (HI) (see section 5.5.1) message.
The message format and processing rules are identical to that defined
in [2]. We only provide the format here for convenience.
IP Fields: The message format and processing rules are identical to those
defined in [1]. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Handover Acknowledge (HAck) Message Figure 8: Handover Acknowledge (HAck) Message
IP Fields:
Source Address Source Address
Copied from the destination address of the Handover Copied from the destination address of the Handover
Initiate Message to which this message is a Initiate Message to which this message is a
response. response.
Destination Address Destination Address
Copied from the source address of the Handover Copied from the source address of the Handover
Initiate Message to which this message is a Initiate Message to which this message is a
response. response.
skipping to change at page 14, line 45 skipping to change at page 21, line 19
1: Handover Accepted, NCoA not valid 1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use 2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned 3: Handover Accepted, NCoA assigned
(used in Assigned addressing) (used in Assigned addressing)
4: Handover Accepted, NCoA not assigned 4: Handover Accepted, NCoA not assigned
(used in Assigned addressing) (used in Assigned addressing)
128: Handover Not Accepted, reason unspecified 128: Handover Not Accepted, reason unspecified
129: Administratively prohibited 129: Administratively prohibited
130: Insufficient resources 130: Insufficient resources
Checksum The ICMP checksum. See RFC 1256. Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, start-
ing with the ICMP Type. For computing the
checksum, the Checksum and the Reserved fields are
set to 0. See RFC 1256.
Subtype To be assigned by IANA. Subtype To be assigned by IANA.
Reserved MUST be set to zero by the sender and ignored by Reserved MUST be set to zero by the sender and ignored by
the receiver. the receiver.
Identifier Copied from the corresponding field in the Handover Identifier Copied from the corresponding field in the Handover
Initiate message this message is in response to. Initiate message this message is in response to.
Valid Options: Valid Options:
skipping to change at page 15, line 34 skipping to change at page 22, line 19
Solicitation and Router Proxy Advertisement messages.. Solicitation and Router Proxy Advertisement messages..
6.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 9: Link-Layer Address Option Format
Fields: Fields:
Type Type
1 Mobile Node Link-layer Address 1 Mobile Node Link-layer Address
2 New Access Point Link-layer Address 2 New Access Point Link-layer Address
3 NAR Link-layer Address 3 NAR Link-layer Address
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. For example, length fields) in units of octets. For example,
skipping to change at page 16, line 8 skipping to change at page 23, line 4
2 New Access Point Link-layer Address 2 New Access Point Link-layer Address
3 NAR Link-layer Address 3 NAR Link-layer Address
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. 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.
6.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
the new router's IPv4 address to distinguish the two addresses. after 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 Address | | New IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: New IPv4 Address Option Format Figure 10: New IPv4 Address Option Format
Fields: Fields:
Type Type
To be assigned by IANA To be assigned by IANA
Length The length of the option (including the type and Length The length of the option (including the type 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. New IPv4 Address
NAR's IPv4 address or the NCoA assigned by NAR.
6.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: New Router Prefix Information Option Format Figure 11: New Router Prefix Information Option Format
Fields: Fields:
Type Type
To be assigned by IANA To be assigned by IANA
Length 1 Length 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.
7. 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 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
each of these messages. Failure to include this extension can lead in each of these messages. Failure to include this extension can
to a bogus node claiming a genuine MN's address and binding it to lead to a bogus node claiming a genuine mobile node's address
an arbitrary address. When the NCoA is NAR's address, there is no and binding it to an arbitrary address. When the NCoA is NAR's
risk of a genuine MN misdirecting traffic, either inadvertantly or address, there is no risk of a genuine mobile node misdirecting
intentionally, to an unsuspecting node on NAR's subnet. When NCoA is traffic, either inadvertently or intentionally, to an unsuspecting
other than NAR's address, NAR MUST ensure that the proposed NCoA in node on NAR's subnet. When NCoA is other than NAR's address, NAR
HI is conflict-free, and MUST indicate the disposition in the HAck MUST ensure that the proposed NCoA in HI is conflict-free, and
message. If there is a conflict, PAR MUST NOT tunnel packets to MUST indicate the disposition in the HAck message. If there is a
the address in question. Instead, PAR SHOULD tunnel packets to the conflict, PAR MUST NOT tunnel packets to the address in question.
address specified in HAck, if any is provided. Instead, PAR SHOULD tunnel packets to the address specified in
HAck, if any is provided.
8. 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 9. Acknowledgement
[1] S. Deering. ICMP Router Discovery Messages. Request for Thanks to all those who expressed interest in having a Fast
Comments (Proposed Standard) 1256, Internet Engineering Task Handovers for Mobile IPv4 protocol along the lines of [1]. Thanks
Force, September 1991. to Vijay Devarapalli, Keng Leung, Alex Petrescu for their review
and input.
[2] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in Normative References
progress). Internet Draft, Internet Engineering Task Force.
draft-ietf-mipshop-fast-mipv6-03.txt, October 2005.
[3] C. Perkins and D. Johnson. Route Optimization in Mobile IP (work [1] R. (Editor) Koodli. Fast Handovers for Mobile IPv6. Request
in progress). Internet Draft, Internet Engineering Task Force. for Comments 4068, Internet Engineering Task Force, July 2005.
draft-ietf-mobileip-optim-09.txt, February 2000.
[4] C. Perkins (Editor). IP Mobility Support for IPv4. Request for [2] C. Perkins (Editor). IP Mobility Support for IPv4. Request
Comments (Proposed Standard) 3344, Internet Engineering Task for Comments (Proposed Standard) 3344, Internet Engineering
Force, August 2002. Task Force, August 2002.
Informative References
[3] The IEEE 802.21 group. http://www.ieee802.org/21. Technical
report, IEEE.
[4] IEEE Standard for Local and Metropolitan Area Networks:
Port-Based Network Access Control. Technical report, IEEE.
[5] IEEE Standard forLocal and Metropolitan Area Networks:
Fast Roaming/Fast BSS Transition, the IEEE Task Group TGr.
Technical report, IEEE.
[6] R. Droms. Dynamic Host Configuration Protocol. Request for
Comments (Draft Standard) 2131, Internet Engineering Task
Force, March 1997.
[7] C. Perkins and D. Johnson. Route Optimization in Mobile IP
(work in progress). Internet Draft, Internet Engineering Task
Force.
draft-ietf-mobileip-optim-09.txt, February 2000.
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
Nokia Research Center Nokia Research Center Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive 975 Page Mill Road, 200 975 Page Mill Road, 200
Mountain View, California 94043 Mountain View, California 94043 Palo Alto, California 94304 Palo Alto, California 94304
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: charliep@iprg.nokia.com EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502 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
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights. Information on the procedures with respect to rights
found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 96 change blocks. 
305 lines changed or deleted 418 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/