One document matched: draft-ietf-mip4-fmipv4-03.txt
Differences from draft-ietf-mip4-fmipv4-02.txt
Mobile IPv4 Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins
Experimental Nokia Research Center
6 February 2007
Mobile IPv4 Fast Handovers
draft-ietf-mip4-fmipv4-03.txt
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a submission of the IETF MIP4 WG. Comments should
be directed to the MIP4 WG mailing list, mip4@ietf.org.
Abstract
This document adapts the Mobile IPv6 Fast Handovers [1] to
improve delay and packet loss resulting from Mobile IPv4 handover
operations. Specifically, this document addresses movement
detection, IP address configuration and location update latencies
during a handover. For reducing the IP address configuration
latency, the document proposes that the new Care-of Address is
always made to be the new access router's IP address. Additional
mechanisms may be defined in the future versions of this document.
Koodli, Perkins Expires 6 August 2007 [Page i]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Contents
Abstract i
1. Introduction 2
2. Factors Affecting Handover 3
3. Protocol 4
3.1. Overview . . . . . . . . . . . . . . . . . 4
3.2. Operation . . . . . . . . . . . . . . . . . 5
4. Use of Previous FA Notification Extension 8
5. Message Formats 9
5.1. Fast Binding Update (FBU) . . . . . . . . . . . . 9
5.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . 11
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) . 13
5.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . 15
5.5. Inter-Access Router Messages . . . . . . . . . . 17
5.5.1. Handover Initiate (HI) . . . . . . . . . 17
5.5.2. Handover Acknowledge (HAck) . . . . . . . . 19
6. Option formats 22
6.1. Link-Layer Address Option Format . . . . . . . . . 22
6.2. New IPv4 Address Option Format . . . . . . . . . . 23
6.3. New Router Prefix Information Option . . . . . . . . 24
7. Security Considerations 25
8. IANA Considerations 25
9. Acknowledgement 25
Intellectual Property Statement 27
Koodli, Perkins Expires 6 August 2007 [Page ii]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Disclaimer of Validity 27
Copyright Statement 28
Acknowledgment 28
Koodli, Perkins Expires 6 August 2007 [Page 1]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
1. Introduction
This document adapts the fast handover specification [1] to
IPv4 networks. The fast handover protocol specified in this
document is particularly interesting for operation over wireless
links such as IEEE 802 wireless links. Fast handovers are not
typically needed for wired media due to the relatively large delays
attributable to establishing new connections in today's wired
networks. Mobile IPv4 [2] registration messages are re-used (with
new type numbers) to enable faster implementation using existing
Mobile IPv4 software. This draft does not rely on link-layer
triggers for protocol operation, but performance will typically be
enhanced by using the appropriate triggers when they are available.
This document assumes that the reader is familiar with the basic
operation and terminology of Mobile IPv4 [1] and Fast Handovers for
Mobile IPv6 [1].
The active agents that enable continued packet delivery to a mobile
node (MN) are the access routers on the networks that the mobile
node connects to. Handover means that the mobile node changes its
network connection, and we consider the scenario in which this
change means change in access routers. The mobile node utilizes
the access routers as default routers in the normal sense, but also
as partners in mobility management. Thus, when the mobile node
moves to a new network, it processes handover-related signaling
in order to identify and develop a relationship with a new access
router. In this document, we call the previous access router PAR
and the new access router NAR, consistent with the terminology
in [1]. Unless otherwise mentioned, a PAR is also a Previous
Foreign Agent (PFA) and a NAR is also a New Foreign Agent (NFA).
On a particular network, a mobile node may obtain its IP address
via DHCP [6] (i.e., Co-located Care-of Address) or use the Foreign
Agent CoA. During a handover, the new CoA (NCoA) is always made
to be that of NAR. This allows a mobile node to receive and send
packets using its previous CoA (PCoA), so that delays resulting
from IP configuration (such as DHCP address acquisition delay)
Koodli, Perkins Expires 6 August 2007 [Page 2]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
subsequent to attaching to the new link are disengaged from
affecting the existing sessions.
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.11, the
handover operation typically involves 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 [4]. These
delays contribute to the handover performance. Optimizations are
being proposed for standardization in IEEE, for instance see [5]
and [3]. Together with appropriate implementation techniques,
Koodli, Perkins Expires 6 August 2007 [Page 3]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
these optimizations can provide the required level of delay support
at the link-layer for real-time applications.
3. Protocol
3.1. Overview
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.
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 exchanged
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 mobile node obtains its IPv4 care-of address, it builds
a neighborhood access point and subnet map using the Router
Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
Advertisement (PrRtAdv) messages. The mobile node may scan for
access points (APs) based on the configuration policy in operation
for its wireless network interface. If a scan results in a new AP
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.
Koodli, Perkins Expires 6 August 2007 [Page 4]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
The coordination between the access routers is done by way of the
Handover Initiate (HI) and Handover Acknowledge (HAck) messages
defined in [1]. After these signals have been exchanged between
the previous and new access routers (PAR and NAR), data arriving
at PAR will be tunneled to NAR for delivery to the newly arrived
mobile node. The purpose of HI is to securely deliver the routing
parameters for establishing this tunnel. The tunnel is created by
the access routers in response to the delivery of the FBU from the
mobile node.
3.2. Operation
In response to a handover trigger or indication, the mobile node
sends a Fast Binding Update message to Previous Access Router (PAR)
(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:
- ``Home Address'' field must be the PCoA (which can be either
the Home Address or the co-located CoA)
- Home Agent field, even though redundant, must be set to PAR's
IP address
- Care-of Address field must be the NAR's IP address discovered
via PrRtAdv message
- Destination IP address must be PAR's IP address
- Source IP address must be the PCoA (which can be either the
Home Address or the co-located CoA)
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.
Koodli, Perkins Expires 6 August 2007 [Page 5]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
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:
Koodli, Perkins Expires 6 August 2007 [Page 6]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
- Destination IP address must be NAR's IP address
- Source IP address must be PCoA (either the Home Address or the
co-located CoA)
When NAR receives FBU, it may already have processed the HI message
and created a host route entry for the PCoA. In that case, NAR
should immediately forward arriving and buffered packets including
the FBAck message. In any case, NAR MUST forward the contents of
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
serve to establish a bidirectional tunnel between the routers
to support packet forwarding for PCoA. The tunnel itself is
established as a response to the FBU message. The PAR sends HI
message with Code = 0 when it receives FBU with source IP address
set to PCoA. The PAR sends HI with Code = 1 when it receives FBU
with source IP address not set to PCoA (i.e., when received from
NAR). This allows NAR to disambiguate HI message processing sent as
a response to predictive and reactive modes of operation. If NAR
receives a HI message with Code = 1, and it has already set up a
host route entry and a reverse tunnel for PCoA, it should silently
discard the HI message.
The protocol provides an option for NAR to return NCoA for use by
the mobile node. When NAR can provide an NCoA for exclusive use of
the mobile node, the address is supplied in the HAck message. The
PAR includes this NCoA in FBack.
Even though the mobile node can obtain this NCoA from the NAR, it
is unaware of the address at the time it sends an FBU. Hence, it
binds PCoA to NAR's IP address as before.
Koodli, Perkins Expires 6 August 2007 [Page 7]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-----------FBU-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 2: Reactive Fast Handover
4. Use of Previous FA Notification Extension
Sending FBU from the new link (i.e., reactive mode) is similar to
using the extension defined in [2]. However, with the neighborhood
information gathered using the proxy router messages (see
Section 5.3, Section 5.4), movement detection and router discovery
delays are avoided even in the reactive case. The FBU and FBAck
messages defined in this document can be naturally used even when
no neighborhood information is available.
Koodli, Perkins Expires 6 August 2007 [Page 8]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
5. Message Formats
5.1. Fast Binding Update (FBU)
The FBU format is bitwise identical to the Registration Request
format in RFC 3344. The same destination port number, 434, is
used, but the FBU and FBAck messages in this specification have new
message type numbers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 3: Fast Binding Update (FBU) Message
Koodli, Perkins Expires 6 August 2007 [Page 9]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
IP fields:
Source address
The interface address from which the
message is sent. Either PCoA (co-located
or Home Address), or NAR's IP address
(when forwarded from NAR to PAR).
Destination Address
The IP address of the Previous Access
Router or the New Access Router.
Source Port variable
Destination port 434
Type To be assigned by IANA
Flags See RFC 3344
reserved Sent as zero, ignored on input
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
Identification See RFC 3344
Extensions MUST contain the MN - PAR Authentication
Extension
Koodli, Perkins Expires 6 August 2007 [Page 10]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
5.2. Fast Binding Acknowledgment (FBAck)
The FBAck format is bitwise identical to the Registration Reply
format in [2].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 4: Fast Binding Acknowledgment (FBAck) Message
Koodli, Perkins Expires 6 August 2007 [Page 11]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
IP fields:
Source address
Typically copied from the destination
address of the FBU message
Destination Address
Copied from the Source IP address in FBU
message
Source Port variable
Destination port copied from the source port in FBU message
Type To be assigned by IANA
Code Indicates the result of processing FBU
message. Code = 0 means Fast Binding Update
accepted. Code = 1 means Fast Binding
Update accepted but NCoA is supplied as an
extension.
reserved Sent as zero, ignored on input
Lifetime The number of seconds remaining before
binding expires. MUST NOT exceed 10
seconds.
Home Address PCoA (i.e., either co-located CoA or Home
Address)
Home Agent The Previous Access Router's global IP
address
Identification a 64-bit number used for matching FBU. See
RFC 3344.
Koodli, Perkins Expires 6 August 2007 [Page 12]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
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
Foreign Agent care-of address [2], then the mobile node MUST set
the 'D' bit in its Registration Request message that it uses to
register the NCoA with its home agent.
5.3. Router Solicitation for Proxy Advertisement (RtSolPr)
Mobile Nodes send Router Solicitation for Proxy Advertisement in
order to prompt routers for Proxy Router Advertisements. All the
link-layer address options have the format defined in 6.1. 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Router Solicitation for Proxy (RtSolPr) Message
IP Fields:
Koodli, Perkins Expires 6 August 2007 [Page 13]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Source Address
An IP address assigned to the sending interface
Destination Address
The address of the Access Router or the all routers
multicast address.
Time-to-Live At least 1. See RFC 1256.
ICMP Fields:
Type To be assigned by IANA
Code 0
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
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Identifier MUST be set by the sender so that replies can be
matched to this Solicitation.
Valid Options:
New Access Point Link-layer Address
The link-layer address or identification of the
access point for which the MN requests routing
advertisement information. It MUST be included
in all RtSolPr messages. More than one such address
or identifier can be present. This field can also
Koodli, Perkins Expires 6 August 2007 [Page 14]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
be a wildcard address with all bits set to zero.
5.4. Proxy Router Advertisement (PrRtAdv)
Access routers send out Proxy Router Advertisement message
gratuitously if the handover is network-initiated or as a response
to RtSolPr message from a mobile node, providing the link-layer
address, IP address and subnet prefixes of neighboring routers.
All the link-layer address options have the format defined in 6.1.
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Proxy Router Advertisement (PrRtAdv) Message
IP Fields:
Source Address
An IP address assigned to the sending interface
Koodli, Perkins Expires 6 August 2007 [Page 15]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Destination Address
The Source Address of an invoking Router
Solicitation for Proxy Advertisement or the address
of the node the Access Router is instructing to
handover.
Time-to-Live At least 1. See RFC 1256.
ICMP Fields:
Type To be assigned by IANA
Code 0, 1, 2, 3 or 4. See below.
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.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Identifier Copied from Router Solicitation for Proxy
Advertisement or set to Zero if unsolicited.
Valid Options in the following order:
New Access Point Link-layer Address
The link-layer address or identification of the
access point is copied from RtSolPr
message. This option MUST be present.
New Router's Link-layer Address
The link-layer address of the Access Router for
which this message is proxied for. This option MUST be
Koodli, Perkins Expires 6 August 2007 [Page 16]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
included when Code is 0 or 1.
New Router's IP Address
The IP address of NAR. This option MUST be
included when Code is 0 or 1.
New Router Prefix Information Option
The number of leading bits that define the network
number of the corresponding Router's IP Address
option (see above).
New CoA Option
MAY be present when PrRtAdv is sent
unsolicited. PAR MAY compute new CoA using NAR's
prefix information and the MN's L2 address, or by
any other means.
5.5. Inter-Access Router Messages
5.5.1. Handover Initiate (HI)
The Handover Initiate (HI) is an ICMP message sent by an Access
Router (typically PAR) to another Access Router (typically NAR) to
initiate the process of a mobile node's handover.
The message format and processing rules are identical to those
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
Koodli, Perkins Expires 6 August 2007 [Page 17]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Handover Initiate (HI) Message
Time-to-Live At least 1. See RFC 1256.
ICMP Fields:
Type To be assigned by IANA
Code 0 or 1. See below
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
S Assigned address configuration flag. When set, this
message requests a new CoA to be returned by the
destination. May be set when Code = 0. MUST be 0
when Code = 1.
Koodli, Perkins Expires 6 August 2007 [Page 18]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
U Buffer flag. When set, the destination SHOULD buffer
any packets towards the node indicated in the options
of this message. Used when Code = 0, SHOULD be set
to 0 when Code = 1.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Identifier MUST be set by the sender so replies can be matched
to this message.
Valid Options:
Link-layer address of MN
The link-layer address of the MN that is
undergoing handover to the destination (i.e., NAR).
This option MUST be included so that the destination
can recognize the MN.
Previous Care of Address
The IP address used by the MN while
attached to the originating router. This option
SHOULD be included so that host route can be
established in case necessary.
New Care of Address
The IP address the MN wishes to use when
connected to the destination. When the `S' bit is
set, NAR MAY assign this address.
5.5.2. Handover Acknowledge (HAck)
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 (HI) (see section 5.5.1) message.
Koodli, Perkins Expires 6 August 2007 [Page 19]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Handover Acknowledge (HAck) Message
IP Fields:
Source Address
Copied from the destination address of the Handover
Initiate Message to which this message is a
response.
Destination Address
Copied from the source address of the Handover
Initiate Message to which this message is a
response.
Time-to-Live At least 1. See RFC 1256.
ICMP Fields:
Koodli, Perkins Expires 6 August 2007 [Page 20]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Type To be assigned by IANA
Code
0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned
(used in Assigned addressing)
4: Handover Accepted, NCoA not assigned
(used in Assigned addressing)
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
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.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Identifier Copied from the corresponding field in the Handover
Initiate message this message is in response to.
Valid Options:
New Care of Address
If the S flag in the Handover Initiate message is set,
this option MUST be used to provide NCoA the MN should
use when connected to this router. This option MAY be
included even when `S' bit is not set, e.g., Code 2
above.
Koodli, Perkins Expires 6 August 2007 [Page 21]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
6. Option formats
The options in this section are specified as optional extensions
for the HI and HAck messages, as well as for the Router Proxy
Solicitation and Router Proxy Advertisement messages..
6.1. Link-Layer Address Option Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Link-Layer Address Option Format
Fields:
Type
1 Mobile Node Link-layer Address
2 New Access Point Link-layer Address
3 NAR Link-layer Address
Length The length of the option (including the type and
length fields) in units of octets. For example,
the length for IEEE 802 addresses is 1 [IPv6-
ETHER].
Link-Layer Address
The variable length link-layer address.
Koodli, Perkins Expires 6 August 2007 [Page 22]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
The content and format of this field (including
byte and bit ordering) depends on the specific
link-layer in use.
6.2. New IPv4 Address Option Format
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 the new router's IPv4 address to distinguish the two
addresses.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: New IPv4 Address Option Format
Fields:
Type
To be assigned by IANA
Length The length of the option (including the type and
length fields) in units of octets.
Reserved Set to zero.
Koodli, Perkins Expires 6 August 2007 [Page 23]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
New IPv4 Address
NAR's IPv4 address or the NCoA assigned by NAR.
6.3. New Router Prefix Information Option
This option is the same as the ``Prefix-Lengths Extension'' in RFC
3344 (Section 2.1.2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: New Router Prefix Information Option Format
Fields:
Type
To be assigned by IANA
Length 1
Prefix-Length
The number of leading bits that define the network
number of the corresponding Router's IP Address
option.
Koodli, Perkins Expires 6 August 2007 [Page 24]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Reserved Set to zero.
7. Security Considerations
The FBU and FBack messages MUST be protected using a security
association shared between a mobile node and its access router. In
particular, the MN - PAR Authentication Extension MUST be present
in each of these messages. Failure to include this extension can
lead to a bogus node claiming a genuine mobile node's address
and binding it to an arbitrary address. When the NCoA is NAR's
address, there is no risk of a genuine mobile node misdirecting
traffic, either inadvertently or intentionally, to an unsuspecting
node on NAR's subnet. When NCoA is other than NAR's address, NAR
MUST ensure that the proposed NCoA in HI is conflict-free, and
MUST indicate the disposition in the HAck message. If there is a
conflict, PAR MUST NOT tunnel packets to the address in question.
Instead, PAR SHOULD tunnel packets to the address specified in
HAck, if any is provided.
8. IANA Considerations
All the messages and the option formats specified in this document
require Type assignment from IANA.
9. Acknowledgement
Thanks to all those who expressed interest in having a Fast
Handovers for Mobile IPv4 protocol along the lines of [1]. Thanks
to Vijay Devarapalli, Keng Leung, Alex Petrescu for their review
and input.
Koodli, Perkins Expires 6 August 2007 [Page 25]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Normative References
[1] R. (Editor) Koodli. Fast Handovers for Mobile IPv6. Request
for Comments 4068, Internet Engineering Task Force, July 2005.
[2] C. Perkins (Editor). IP Mobility Support for IPv4. Request
for Comments (Proposed Standard) 3344, Internet Engineering
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:
Rajeev Koodli Charles E. Perkins
Nokia Research Center Nokia Research Center
975 Page Mill Road, 200 975 Page Mill Road, 200
Palo Alto, California 94304 Palo Alto, California 94304
USA USA
Phone: +1-650 625-2359 Phone: +1-650 625-2986
EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Koodli, Perkins Expires 6 August 2007 [Page 26]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Koodli, Perkins Expires 6 August 2007 [Page 27]
Internet Draft Fast Handovers for Mobile IPv4 6 February 2007
Copyright Statement
Copyright (C) The IETF Trust (2007).
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Koodli, Perkins Expires 6 August 2007 [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-24 09:19:55 |