One document matched: draft-koodli-fmipv4-00.txt
Mobile IP Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins
15 October 2004 Nokia Research Center
Adapting Mobile IPv6 Fast Handovers for IPv4
draft-koodli-fmipv4-00.txt
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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.
Abstract
The Mobile IPv6 fast handover document [2] specifies a protocol to
improve latency and packet loss resulting from Mobile IPv6 handover
operations. This document adapts the protocol for IPv4 networks
to improve performance over Mobile IPv4 operations, including
processing of Agent Advertisements, new Care of Address acquisition
and Registration Request and Reply. However, Foreign Agent operation
at a router is not necessary. Also, the protocol may be used
transparently on hosts which do not support Mobile IP, but with
limited movement across subnets.
Using the concepts outlined in [2], this document also addresses
movement detection, IP address configuration and location update
latencies. For reducing the IP address configuration, the draft
provides two alternatives. First, the new CoA is always made to be
the new access router's IP address. Second, a hash algorithm is used
to produce a new CoA, and any conflicts are resolved so as not to
cause traffic misdirection.
Koodli, Perkins Expires 15 April 2005 [Page i]
Internet Draft Fast Handovers for IPv4 15 October 2004
Contents
Abstract i
1. Introduction 2
2. Protocol Operation 2
2.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 3
2.2. MN Formulating NCoA . . . . . . . . . . . . . . . . . . . 4
2.3. Assigned Addressing Support . . . . . . . . . . . . . . . 4
3. Message Formats 5
3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 5
3.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 6
3.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 7
3.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 9
3.5. Inter-Access Router Messages . . . . . . . . . . . . . . 11
3.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 11
3.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 12
4. Option formats 14
4.1. Link-Layer Address Option Format . . . . . . . . . . . . 14
4.2. New IPv4 Address Option Format . . . . . . . . . . . . . 15
4.3. New Router Prefix Information Option . . . . . . . . . . 15
5. Security Considerations 16
6. IANA Considerations 17
Intellectual Property Statement 17
Disclaimer of Validity 18
Copyright Statement 18
Acknowledgment 18
A. Random choice of care-of address 18
Koodli, Perkins Expires 15 April 2005 [Page 1]
Internet Draft Fast Handovers for IPv4 15 October 2004
1. Introduction
In this document, we adapt the fast handover specification [2] to
IPv4 networks. The fast handover protocol specified in this document
is particularly interesting for operation on commonly available
wireless links such as IEEE 802.11 WLAN 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. This draft does not require a Foreign Agent (FA)
functionality. Mobile IPv4 registration messages are re-used (with
new type numbers) to enable quick implementation using existing
foreign agent code when present. 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.
The active agents that enable continued packet delivery to a mobile
node 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.
Address allocation and configuration may be supported using DHCP or
any other method. The mobile node's new care-of address (NCoA) can
be provided by NAR, as is conventionally done when NAR is functioning
as a foreign agent. Regardless of whether the NCoA is owned by the
foreign agent, or allocated for exclusive use of the mobile node, the
NCoA is a piece of configuration information that can be returned by
the NAR in the HAck message.
An access router can configure a NCoA for the mobile node, following
the ``assigned addressing'' model specified in [2]. That is, the
MN MUST obtain its NCoA from the NAR. After obtaining either such a
foreign-agent NCoA, or alternatively obtaining a co-located NCoA by
any means available, the mobile node subsequently performs Mobile
IP [3] operations.
2. Protocol Operation
After a MN obtains its IPv4 care-of address, it builds a neighborhood
access point and subnet map using the Router Solicitation for Proxy
Advertisement and Proxy Router Advertisement messages. The MN may
Koodli, Perkins Expires 15 April 2005 [Page 2]
Internet Draft Fast Handovers for IPv4 15 October 2004
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 MN resolves the AP-ID to subnet information
using the messages defined below.
The coordination between the access routers is done by way of the
Handover Initiate (HI) and Handover Acknowledge (HAck) messages.
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.
We consider three scenarios. First, the access routers are not
involved in IP address management for the MN. The mobile nodes
acquire a new care-of address upon attaching to a new subnet link as
they normally do. 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
packet formats presented in RFC 3344 are re-used to achieve maximum
compatibility with Mobile IP.
2.1. Basic NCoA Support
In response to a handover trigger or indication, the MN sends a
Fast Binding Update message to Previous Access Router (PAR) (see
Section 3.1). This message should be sent when the MN is still
connected to PAR. When sent in this ``predictive'' mode, the ``Home
Address'' field must be the PCoA. The Home Agent field, even though
redundant, must be set to PAR's IP address, and the Care-of Address
must be the NAR's IP address discovered via PrRtAdv message. The
destination IP address of the FBU message must be PAR's IP address.
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 PCoA 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
and created a host route entry for the PCoA. In that case, NAR can
immediately forward arriving and buffered packets including the FBAck
Koodli, Perkins Expires 15 April 2005 [Page 3]
Internet Draft Fast Handovers for IPv4 15 October 2004
message. In any case, NAR MUST forward the contents of this message,
starting from the Type field, to PAR.
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
serve to establish a tunnel between the routers to support packet
forwarding for PCoA. The tunnel itself is established as a response
to the FBU message. Furthermore, when the MN obtains a NCoA from
NAR, the reverse tunnel to the PAR is not necessary; the MN would
reverse tunnel to the Home Agent directly using its NCoA.
The PAR sends HI message with Code = 0 when it receives FBU with
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 processing when
HI needs to be sent as a response to predictive and reactive modes of
operation.
2.2. MN Formulating NCoA
A MN may formulate its own NCoA and use it in the Care-of-Address
field. See Appendix A for one such formulation.
2.3. Assigned Addressing Support
In this mode, the NAR provides NCoA, which is delivered to the MN 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, it
always binds its PCoA to NAR's address. This results in a tunnel
from PAR to NAR. However, with Mobile IP, a reverse tunnel to PAR is
not necessary since the MN can directly reverse tunnel to the Home
Agent.
The source IP address in FBU is PCoA regardless of the link it is
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.
The result of faster NCoA formulation is that a reverse tunnel from
NAR to PAR is not necessary, thus alleviating the need for a special
ingress filtering rule (corresponding to PCoA) for all outbound
packets from the NAR's link.
Koodli, Perkins Expires 15 April 2005 [Page 4]
Internet Draft Fast Handovers for IPv4 15 October 2004
3. Message Formats
3.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 1: Fast Binding Update (FBU) Message
IP fields:
Source address
The interface address from which the
message is sent. Either PCoA or NAR's IP
address.
Destination Address
The IP address of the Previous Access
Router or the New Access Router.
Source Port variable
Destination port 434 (TBA)
Type To be assigned by IANA
Koodli, Perkins Expires 15 April 2005 [Page 5]
Internet Draft Fast Handovers for IPv4 15 October 2004
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 or the MN's 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
3.2. Fast Binding Acknowledgment (FBAck)
The FBAck format is bitwise identical to the Registration Reply
format in [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 2: Fast Binding Acknowledgment (FBAck) Message
Koodli, Perkins Expires 15 April 2005 [Page 6]
Internet Draft Fast Handovers for IPv4 15 October 2004
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 thr 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 or MN's Home Address
Home Agent The Previous Access Router's global IP address
Identification a 64-bit number used for matching FBU. See RFC
3344.
Extensions The PAR - MN Authentication extension MUST be
present. In addition, a 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 [3], 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.
3.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 4.1. The
Koodli, Perkins Expires 15 April 2005 [Page 7]
Internet Draft Fast Handovers for IPv4 15 October 2004
message format and processing rules are identical to that defined
in [2]. 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 3: Router Solicitation for Proxy (RtSolPr) Message
IP Fields:
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 ICMP checksum. 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:
Koodli, Perkins Expires 15 April 2005 [Page 8]
Internet Draft Fast Handovers for IPv4 15 October 2004
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
be a wildcard address with all bits set to zero.
3.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 MN, providing the link-layer address,
IP address and subnet prefixes of neighboring routers. All the
link-layer address options have the format defined in 4.1.
The message format and processing rules are identical to that defined
in [2]. We only provide the format here for convenience. The ICMP
checksum is defined in [1].
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 4: Proxy Router Advertisement (PrRtAdv) Message
IP Fields:
Source Address
An IP address assigned to the sending interface
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
Koodli, Perkins Expires 15 April 2005 [Page 9]
Internet Draft Fast Handovers for IPv4 15 October 2004
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 ICMP checksum. 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
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.
Koodli, Perkins Expires 15 April 2005 [Page 10]
Internet Draft Fast Handovers for IPv4 15 October 2004
3.5. Inter-Access Router Messages
3.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 MN's handover.
The message format and processing rules are identical to that defined
in [2]. 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 |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: 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.
ICMP Fields:
Type To be assigned by IANA
Code 0 or 1. See below
Checksum The ICMP checksum. See RFC 1256
Subtype To be assigned by IANA
Koodli, Perkins Expires 15 April 2005 [Page 11]
Internet Draft Fast Handovers for IPv4 15 October 2004
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.
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.
3.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 3.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:
Koodli, Perkins Expires 15 April 2005 [Page 12]
Internet Draft Fast Handovers for IPv4 15 October 2004
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: Handover Acknowledge (HAck) Message
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:
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 ICMP checksum. See RFC 1256.
Subtype To be assigned by IANA.
Koodli, Perkins Expires 15 April 2005 [Page 13]
Internet Draft Fast Handovers for IPv4 15 October 2004
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.
4. 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..
4.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 7: 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-
Koodli, Perkins Expires 15 April 2005 [Page 14]
Internet Draft Fast Handovers for IPv4 15 October 2004
ETHER].
Link-Layer Address
The variable length link-layer address.
The content and format of this field (including
byte and bit ordering) depends on the specific
link-layer in use.
4.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 8: 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.
NCoA The New CoA assigned by NAR.
4.3. New Router Prefix Information Option
This option is the same as the ``Prefix-Lengths Extension'' in RFC
3344 (Section 2.1.2).
Koodli, Perkins Expires 15 April 2005 [Page 15]
Internet Draft Fast Handovers for IPv4 15 October 2004
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 9: 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.
Reserved Set to zero.
5. Security Considerations
The FBU and FBack messages MUST be protected using a security
association shared between a MN 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 MN's address and binding it to
an arbitrary address. When the NCoA is NAR's address, there is no
risk of a genuine MN misdirecting traffic, either inadvertantly 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.
Koodli, Perkins Expires 15 April 2005 [Page 16]
Internet Draft Fast Handovers for IPv4 15 October 2004
6. IANA Considerations
All the messages and the option formats specified in this document
require Type assignment from IANA.
References
[1] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991.
[2] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force.
draft-ietf-mipshop-fast-mipv6-02.txt, October 2003.
[3] C. Perkins (Editor). IP Mobility Support for IPv4. Request for
Comments (Proposed Standard) 3344, Internet Engineering Task
Force, August 2002.
Questions about this memo can be directed to the authors:
Rajeev Koodli Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
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
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
Koodli, Perkins Expires 15 April 2005 [Page 17]
Internet Draft Fast Handovers for IPv4 15 October 2004
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
A. Random choice of care-of address
To the knowledge of the authors, the material in this section of the
appendix is the only part of this specification which may be covered
by patent protection.
When a mobile node moves to a new subnet, it needs a prospective new
care-of address. In order to minimize the chances for collision, the
choice should be made at random within a restricted range defined by
the subnet prefix. Certain addresses are considered off limits --
specifically the following:
- <subnet_prefix> followed by all zeros
- <subnet_prefix> followed by all ones
Koodli, Perkins Expires 15 April 2005 [Page 18]
Internet Draft Fast Handovers for IPv4 15 October 2004
- The first 16 addresses within the subnet range,
- The last 16 addresses within the subnet range.
Within the range defined by the subnet prefix, define the following
values:
FirstAvailableAddr
LastAvailableAddr
AvailableRange :=
LastAvailableAddr + 1 - FirstAvailableAddr
Retry, initially zero
First get a random number:
Random := HMAC_MD5 (NewSubnetPrefix || HomeAddress || Retry)
To get a random offset into the available range, calculate:
Offset := Random mod AvailableRange
Finally, calculate the prospective care-of address as:
CoA := FirstAvailableAddr + Offset
This calculation has the following characteristics:
- Two mobile nodes with different home addresses will obtain
different care-of addresses with maximum likelihood
- The calculation is computationally easy to carry out
- The HMAC_MD5 is already mandated by the base Mobile IPv4
specification
- The mobile node will get the same answer every time it renews its
attachment to the same subnet.
When the calculation yields a result that is not usable on the new
subnet, then in the future the mobile node SHOULD increment its
Retry variable for that subnet. This is only possible whenever the
mobile node has enough memory available to keep track of the recent
subnets it has visited. In that case, the Retry variable would be
incremented until a suitable care-of address could be calculated.
Due to the tight time requirements surrounding handovers, and the
nature of the fast handover signaling, it may well be that setting
Koodli, Perkins Expires 15 April 2005 [Page 19]
Internet Draft Fast Handovers for IPv4 15 October 2004
the value for the Retry varialble make take several iterations which
span multiple handovers separated in time. Eventually, however, this
method makes it more likely that the mobile node will succeed to find
better prospective care-of addresses.
If the mobile node is unlikely to visit the same subnet multiple
times, or if no memory is available for storing current values of
the Retry variable, then the Retry variable should just be set to
a random value on every attempt to calculate a prospective care-of
address.
Koodli, Perkins Expires 15 April 2005 [Page 20] | PAFTECH AB 2003-2026 | 2026-04-24 02:52:43 |