< draft-ietf-mip4-rfc3344bis-09.txt   draft-ietf-mip4-rfc3344bis-10.txt >
MIP4 Working Group C. Perkins, Ed. MIP4 Working Group C. Perkins, Ed.
Internet-Draft WiChorus Inc. Internet-Draft WiChorus Inc.
Obsoletes: 3344 (if approved) January 26, 2010 Obsoletes: 3344 (if approved) April 8, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: July 30, 2010 Expires: October 10, 2010
IP Mobility Support for IPv4, revised IP Mobility Support for IPv4, revised
draft-ietf-mip4-rfc3344bis-09 draft-ietf-mip4-rfc3344bis-10
Abstract Abstract
This document specifies protocol enhancements that allow transparent This document specifies protocol enhancements that allow transparent
routing of IP datagrams to mobile nodes in the Internet. Each mobile routing of IP datagrams to mobile nodes in the Internet. Each mobile
node is always identified by its home address, regardless of its node is always identified by its home address, regardless of its
current point of attachment to the Internet. While situated away current point of attachment to the Internet. While situated away
from its home, a mobile node is also associated with a care-of from its home, a mobile node is also associated with a care-of
address, which provides information about its current point of address, which provides information about its current point of
attachment to the Internet. The protocol provides for registering attachment to the Internet. The protocol provides for registering
the care-of address with a home agent. The home agent sends the care-of address with a home agent. The home agent sends
datagrams destined for the mobile node through a tunnel to the datagrams destined for the mobile node through a tunnel to the
care-of address. After arriving at the end of the tunnel, each care-of address. After arriving at the end of the tunnel, each
datagram is then delivered to the mobile node. datagram is then delivered to the mobile node.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 10, 2010.
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 Internet-Draft will expire on July 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 5 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 5
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
1.5. New Architectural Entities . . . . . . . . . . . . . . . 7 1.5. New Architectural Entities . . . . . . . . . . . . . . . 7
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10
1.8. Message Format and Protocol Extensibility . . . . . . . . 14 1.8. Message Format and Protocol Extensibility . . . . . . . . 14
1.9. Type-Length-Value Extension Format for Mobile IP 1.9. Type-Length-Value Extension Format for Mobile IP
Extensions . . . . . . . . . . . . . . . . . . . . . . . 16 Extensions . . . . . . . . . . . . . . . . . . . . . . . 16
1.10. Long Extension Format . . . . . . . . . . . . . . . . . . 17 1.10. Long Extension Format . . . . . . . . . . . . . . . . . . 17
1.11. Short Extension Format . . . . . . . . . . . . . . . . . 18 1.11. Short Extension Format . . . . . . . . . . . . . . . . . 18
2. Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . 19 2. Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . 19
2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 19 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 19
2.1.1. Mobility Agent Advertisement Extension . . . . . . . 21 2.1.1. Mobility Agent Advertisement Extension . . . . . . . 21
2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . . . 23 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . . . 24
2.1.3. One-byte Padding Extension . . . . . . . . . . . . . 24 2.1.3. One-byte Padding Extension . . . . . . . . . . . . . 25
2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 25 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 25
2.3. Foreign Agent and Home Agent Considerations . . . . . . . 25 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 25
2.3.1. Advertised Router Addresses . . . . . . . . . . . . . 26 2.3.1. Advertised Router Addresses . . . . . . . . . . . . . 26
2.3.2. Sequence Numbers and Rollover Handling . . . . . . . 26 2.3.2. Sequence Numbers and Rollover Handling . . . . . . . 27
2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 27 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 27
2.4.1. Registration Required . . . . . . . . . . . . . . . . 28 2.4.1. Registration Required . . . . . . . . . . . . . . . . 28
2.4.2. Move Detection . . . . . . . . . . . . . . . . . . . 28 2.4.2. Move Detection . . . . . . . . . . . . . . . . . . . 28
2.4.3. Returning Home . . . . . . . . . . . . . . . . . . . 29 2.4.3. Returning Home . . . . . . . . . . . . . . . . . . . 30
2.4.4. Sequence Numbers and Rollover Handling . . . . . . . 30 2.4.4. Sequence Numbers and Rollover Handling . . . . . . . 30
3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 31 3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1. Registration Overview . . . . . . . . . . . . . . . . . . 31 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 31
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 33 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 33
3.3. Registration Request . . . . . . . . . . . . . . . . . . 33 3.3. Registration Request . . . . . . . . . . . . . . . . . . 33
3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 36 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 36
3.5. Registration Extensions . . . . . . . . . . . . . . . . . 39 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 39
3.5.1. Computing Authentication Extension Values . . . . . . 39 3.5.1. Computing Authentication Extension Values . . . . . . 39
3.5.2. Mobile-Home Authentication Extension . . . . . . . . 40 3.5.2. Mobile-Home Authentication Extension . . . . . . . . 40
3.5.3. Mobile-Foreign Authentication Extension . . . . . . . 41 3.5.3. Mobile-Foreign Authentication Extension . . . . . . . 41
skipping to change at page 4, line 13 skipping to change at page 4, line 8
Appendix B. Link-Layer Considerations . . . . . . . . . . . . . 94 Appendix B. Link-Layer Considerations . . . . . . . . . . . . . 94
Appendix C. TCP Considerations . . . . . . . . . . . . . . . . . 95 Appendix C. TCP Considerations . . . . . . . . . . . . . . . . . 95
C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 95 C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 95
C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 95 C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 95
Appendix D. Example Scenarios . . . . . . . . . . . . . . . . . 96 Appendix D. Example Scenarios . . . . . . . . . . . . . . . . . 96
D.1. Registering with a Foreign Agent Care-of Address . . . . 96 D.1. Registering with a Foreign Agent Care-of Address . . . . 96
D.2. Registering with a Co-Located Care-of Address . . . . . . 96 D.2. Registering with a Co-Located Care-of Address . . . . . . 96
D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 97 D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 97
Appendix E. Applicability of Prefix-Lengths Extension . . . . . 98 Appendix E. Applicability of Prefix-Lengths Extension . . . . . 98
Appendix F. Interoperability Considerations . . . . . . . . . . 99 Appendix F. Interoperability Considerations . . . . . . . . . . 99
Appendix G. Changes since RFC 2002 . . . . . . . . . . . . . . . 100 Appendix G. Changes since RFC 3344 . . . . . . . . . . . . . . . 100
G.1. Recent Changes . . . . . . . . . . . . . . . . . . . . . 100 Appendix H. Example Messages . . . . . . . . . . . . . . . . . . 102
G.2. Major Changes . . . . . . . . . . . . . . . . . . . . . . 101 H.1. Example ICMP Agent Advertisement Message Format . . . . . 102
G.3. Minor Changes . . . . . . . . . . . . . . . . . . . . . . 103 H.2. Example Registration Request Message Format . . . . . . . 102
G.4. Changes since RFC3344 . . . . . . . . . . . . . . . . . . 104 H.3. Example Registration Reply Message Format . . . . . . . . 103
Appendix H. Example Messages . . . . . . . . . . . . . . . . . . 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 105
H.1. Example ICMP Agent Advertisement Message Format . . . . . 106
H.2. Example Registration Request Message Format . . . . . . . 106
H.3. Example Registration Reply Message Format . . . . . . . . 107
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 109
1. Introduction 1. Introduction
IP version 4 assumes that a node's IP address uniquely identifies the IP version 4 assumes that a node's IP address uniquely identifies the
node's point of attachment to the Internet. Therefore, a node must node's point of attachment to the Internet. Therefore, a node must
be located on the network indicated by its IP address in order to be located on the network indicated by its IP address in order to
receive datagrams destined to it; otherwise, datagrams destined to receive datagrams destined to it; otherwise, datagrams destined to
the node would be undeliverable. For a node to change its point of the node would be undeliverable. For a node to change its point of
attachment without losing its ability to communicate, currently one attachment without losing its ability to communicate, currently one
of the two following mechanisms must typically be employed: of the two following mechanisms must typically be employed:
skipping to change at page 5, line 33 skipping to change at page 5, line 33
connections when the node changes location. The second has obvious connections when the node changes location. The second has obvious
and severe scaling problems, especially relevant considering the and severe scaling problems, especially relevant considering the
explosive growth in sales of notebook (mobile) computers. explosive growth in sales of notebook (mobile) computers.
A new, scalable, mechanism is required for accommodating node A new, scalable, mechanism is required for accommodating node
mobility within the Internet. This document defines such a mobility within the Internet. This document defines such a
mechanism, which enables nodes to change their point of attachment to mechanism, which enables nodes to change their point of attachment to
the Internet without changing their IP address. the Internet without changing their IP address.
Changes between this revised specification for Mobile IP and the Changes between this revised specification for Mobile IP and the
original specifications (see [40],[14],[15],[20],[4]) are detailed in original specifications (see [44],[14],[15],[20],[4]) are detailed in
Appendix G. Appendix G.
1.1. Protocol Requirements 1.1. Protocol Requirements
A mobile node must be able to communicate with other nodes after A mobile node must be able to communicate with other nodes after
changing its link-layer point of attachment to the Internet, yet changing its link-layer point of attachment to the Internet, yet
without changing its IP address. without changing its IP address.
A mobile node must be able to communicate with other nodes that do A mobile node must be able to communicate with other nodes that do
not implement these mobility functions. No protocol enhancements are not implement these mobility functions. No protocol enhancements are
skipping to change at page 9, line 8 skipping to change at page 9, line 8
A peer with which a mobile node is communicating. A correspondent A peer with which a mobile node is communicating. A correspondent
node may be either mobile or stationary. node may be either mobile or stationary.
Foreign Network Foreign Network
Any network other than the mobile node's Home Network. Any network other than the mobile node's Home Network.
Gratuitous ARP Gratuitous ARP
An ARP packet sent by a node in order to spontaneously cause other An ARP packet sent by a node in order to spontaneously cause other
nodes to update an entry in their ARP cache [42]. See nodes to update an entry in their ARP cache [45]. See
Section 4.6. Section 4.6.
Home Address Home Address
An IP address that is assigned for an extended period of time to a An IP address that is assigned for an extended period of time to a
mobile node. It remains unchanged regardless of where the node is mobile node. It remains unchanged regardless of where the node is
attached to the Internet. attached to the Internet.
Home Network Home Network
skipping to change at page 11, line 44 skipping to change at page 11, line 44
o When the mobile node detects that it is located on its home o When the mobile node detects that it is located on its home
network, it operates without mobility services. If returning to network, it operates without mobility services. If returning to
its home network from being registered elsewhere, the mobile node its home network from being registered elsewhere, the mobile node
deregisters with its home agent, through exchange of a deregisters with its home agent, through exchange of a
Registration Request and Registration Reply message with it. Registration Request and Registration Reply message with it.
o When a mobile node detects that it has moved to a foreign network, o When a mobile node detects that it has moved to a foreign network,
it obtains a care-of address on the foreign network. The care-of it obtains a care-of address on the foreign network. The care-of
address can either be determined from a foreign agent's address can either be determined from a foreign agent's
advertisements (a foreign agent care-of address), or by some advertisements (a foreign agent care-of address), or by some
external assignment mechanism such as DHCP [30] (a co-located external assignment mechanism such as DHCP [34] (a co-located
care-of address). care-of address).
o The mobile node operating away from home then registers its new o The mobile node operating away from home then registers its new
care-of address with its home agent through exchange of a care-of address with its home agent through exchange of a
Registration Request and Registration Reply message with it, Registration Request and Registration Reply message with it,
possibly via a foreign agent (Section 3). possibly via a foreign agent (Section 3).
o Datagrams sent to the mobile node's home address are intercepted o Datagrams sent to the mobile node's home address are intercepted
by its home agent, tunneled by the home agent to the mobile node's by its home agent, tunneled by the home agent to the mobile node's
care-of address, received at the tunnel endpoint (either at a care-of address, received at the tunnel endpoint (either at a
skipping to change at page 12, line 40 skipping to change at page 12, line 40
tunnel and, upon receiving tunneled datagrams, decapsulates them tunnel and, upon receiving tunneled datagrams, decapsulates them
and delivers the inner datagram to the mobile node. This mode of and delivers the inner datagram to the mobile node. This mode of
acquisition is preferred because it allows many mobile nodes to acquisition is preferred because it allows many mobile nodes to
share the same care-of address and therefore does not place share the same care-of address and therefore does not place
unnecessary demands on the already limited IPv4 address space. unnecessary demands on the already limited IPv4 address space.
b. A "co-located care-of address" is a care-of address acquired by b. A "co-located care-of address" is a care-of address acquired by
the mobile node as a local IP address through some external the mobile node as a local IP address through some external
means, which the mobile node then associates with one of its own means, which the mobile node then associates with one of its own
network interfaces. The address may be dynamically acquired as a network interfaces. The address may be dynamically acquired as a
temporary address by the mobile node such as through DHCP [30], temporary address by the mobile node such as through DHCP [34],
or may be owned by the mobile node as a long-term address for its or may be owned by the mobile node as a long-term address for its
use only while visiting some foreign network. Specific external use only while visiting some foreign network. Specific external
methods of acquiring a local IP address for use as a co-located methods of acquiring a local IP address for use as a co-located
care-of address are beyond the scope of this document. When care-of address are beyond the scope of this document. When
using a co-located care-of address, the mobile node serves as the using a co-located care-of address, the mobile node serves as the
endpoint of the tunnel and itself performs decapsulation of the endpoint of the tunnel and itself performs decapsulation of the
datagrams tunneled to it. datagrams tunneled to it.
The mode of using a co-located care-of address has the advantage that The mode of using a co-located care-of address has the advantage that
it allows a mobile node to function without a foreign agent, for it allows a mobile node to function without a foreign agent, for
skipping to change at page 14, line 47 skipping to change at page 14, line 47
Mobile IP defines a set of new control messages, sent with UDP [17] Mobile IP defines a set of new control messages, sent with UDP [17]
using well-known port number 434. The following two message types using well-known port number 434. The following two message types
are defined in this document: are defined in this document:
1 Registration Request 1 Registration Request
3 Registration Reply 3 Registration Reply
Up-to-date values for the message types for Mobile IP control Up-to-date values for the message types for Mobile IP control
messages are specified in the IANA online database [45]. messages are specified in the IANA online database [48].
In addition, for Agent Discovery, Mobile IP makes use of the existing In addition, for Agent Discovery, Mobile IP makes use of the existing
Router Advertisement and Router Solicitation messages defined for Router Advertisement and Router Solicitation messages defined for
ICMP Router Discovery [5]. ICMP Router Discovery [5].
Mobile IP defines a general Extension mechanism to allow optional Mobile IP defines a general Extension mechanism to allow optional
information to be carried by Mobile IP control messages or by ICMP information to be carried by Mobile IP control messages or by ICMP
Router Discovery messages. Some extensions have been specified to be Router Discovery messages. Some extensions have been specified to be
encoded in the simple Type-Length-Value format described in encoded in the simple Type-Length-Value format described in
Section 1.9. Section 1.9.
Extensions allow variable amounts of information to be carried within Extensions allow variable amounts of information to be carried within
each datagram. The end of the list of Extensions is indicated by the each datagram. The end of the list of Extensions is indicated by the
total length of the IP datagram. total length of the IP datagram.
Two separately maintained sets of numbering spaces, from which Two separately maintained sets of numbering spaces, from which
Extension Type values are allocated, are used in Mobile IP: Extension Type values are allocated, are used in Mobile IP:
o The first set consists of those Extensions which may appear only o The first set consists of those Extensions which may appear in
in Mobile IP control messages (those sent to and from UDP port Mobile IP control messages (those sent to and from UDP port number
number 434). In this document, the following Types are defined 434). In this document, the following Types are defined for
for Extensions appearing in Mobile IP control messages: Extensions appearing in Mobile IP control messages:
0 One-byte Padding (encoded with no Length nor Data field)
32 Mobile-Home Authentication 32 Mobile-Home Authentication
33 Mobile-Foreign Authentication 33 Mobile-Foreign Authentication
34 Foreign-Home Authentication 34 Foreign-Home Authentication
o The second set consists of those extensions which may appear only o The second set consists of those extensions which may appear in
in ICMP Router Discovery messages [5]. In this document, the ICMP Router Discovery messages [5]. In this document, the
following Types are defined for Extensions appearing in ICMP following Types are defined for Extensions appearing in ICMP
Router Discovery messages: Router Discovery messages:
0 One-byte Padding (encoded with no Length nor Data field) 0 One-byte Padding (encoded with no Length nor Data field)
16 Mobility Agent Advertisement 16 Mobility Agent Advertisement
19 Prefix-Lengths 19 Prefix-Lengths
Each individual Extension is described in detail in a separate Each individual Extension is described in detail in a separate
section later in this document. Up-to-date values for these section later in this document. Up-to-date values for these
Extension Type numbers are specified in the IANA online database Extension Type numbers are specified in the IANA online database
[45]. [48].
Due to the separation (orthogonality) of these sets, it is Due to the separation (orthogonality) of these sets, it is
conceivable that two Extensions that are defined at a later date conceivable that two Extensions that are defined at a later date
could have identical Type values, so long as one of the Extensions could have identical Type values, so long as one of the Extensions
may be used only in Mobile IP control messages and the other may be may be used only in Mobile IP control messages and the other may be
used only in ICMP Router Discovery messages. used only in ICMP Router Discovery messages.
The type field in the Mobile IP extension structure can support up to The type field in the Mobile IP extension structure can support up to
255 (skippable and not skippable) uniquely identifiable extensions. 255 (skippable and not skippable) uniquely identifiable extensions.
When an Extension numbered in either of these sets within the range 0 When an Extension numbered in either of these sets within the range 0
skipping to change at page 16, line 15 skipping to change at page 16, line 16
Extensions and message data MUST still be processed. The Length Extensions and message data MUST still be processed. The Length
field of the Extension is used to skip the Data field in searching field of the Extension is used to skip the Data field in searching
for the next Extension. for the next Extension.
Unless additional structure is utilized for the extension types, new Unless additional structure is utilized for the extension types, new
developments or additions to Mobile IP might require so many new developments or additions to Mobile IP might require so many new
extensions that the available space for extension types might run extensions that the available space for extension types might run
out. Two new extension structures are proposed to solve this out. Two new extension structures are proposed to solve this
problem. Certain types of extensions can be aggregated, using problem. Certain types of extensions can be aggregated, using
subtypes to identify the precise extension, for example as has been subtypes to identify the precise extension, for example as has been
done with the Generic Authentication Keys extensions [43]. In many done with the Generic Authentication Keys extensions [46]. In many
cases, this may reduce the rate of allocation for new values of the cases, this may reduce the rate of allocation for new values of the
type field. type field.
Since the new extension structures will cause an efficient usage of Since the new extension structures will cause an efficient usage of
the extension type space, it is recommended that new Mobile IP the extension type space, it is recommended that new Mobile IP
extensions follow one of the two new extension formats whenever there extensions follow one of the two new extension formats whenever there
may be the possibility to group related extensions together. may be the possibility to group related extensions together.
The following subsections provide details about three distinct The following subsections provide details about three distinct
structures for Mobile IP extensions: structures for Mobile IP extensions:
skipping to change at page 17, line 23 skipping to change at page 17, line 23
Data Data
The particular data associated with this Extension. This field The particular data associated with this Extension. This field
may be zero or more bytes in length. The format and length of the may be zero or more bytes in length. The format and length of the
data field is determined by the type and length fields. data field is determined by the type and length fields.
1.10. Long Extension Format 1.10. Long Extension Format
This format is applicable for non-skippable extensions which carry This format is applicable for non-skippable extensions which carry
information more than 256 bytes. information more than 256 bytes. Skippable extensions can never use
the long format, because the receiver is not required to include
parsing code and is likely to treat the 8 bits immediately following
the Type as the Length field.
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 | Sub-Type | Length | | Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ..... | Data .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Long Extension format requires that the following fields be The Long Extension format requires that the following fields be
skipping to change at page 21, line 44 skipping to change at page 21, line 44
Advertisement fields. It is used to indicate that an ICMP Router Advertisement fields. It is used to indicate that an ICMP Router
Advertisement message is also an Agent Advertisement being sent by a Advertisement message is also an Agent Advertisement being sent by a
mobility agent. The Mobility Agent Advertisement Extension is mobility agent. The Mobility Agent Advertisement Extension is
defined as follows: defined as follows:
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 | Sequence Number | | Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T| reserved | | Registration Lifetime |R|B|H|F|M|G|r|T|U|X|I|reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses | | zero or more Care-of Addresses |
| ... | | ... |
Type Type
16 16
Length Length
skipping to change at page 23, line 17 skipping to change at page 23, line 17
GRE encapsulation. This agent implements receiving tunneled GRE encapsulation. This agent implements receiving tunneled
datagrams that use GRE encapsulation [13]. datagrams that use GRE encapsulation [13].
r r
Sent as zero; ignored on reception. SHOULD NOT be allocated for Sent as zero; ignored on reception. SHOULD NOT be allocated for
any other uses. any other uses.
T T
Foreign agent supports reverse tunneling [12]. Foreign agent supports reverse tunneling as specified in [12].
U
Mobility agent supports UDP Tunnelling as specified in [27].
X
Mobility agent supports Registration Revocation as specified in
[28].
I
Foreign agent supports Regional Registration as specified in [29].
reserved reserved
Sent as zero; ignored on reception. Sent as zero; ignored on reception.
Care-of Address(es) Care-of Address(es)
The advertised foreign agent care-of address(es) provided by this The advertised foreign agent care-of address(es) provided by this
foreign agent. An Agent Advertisement MUST include at least one foreign agent. An Agent Advertisement MUST include at least one
care-of address if the 'F' bit is set. The number of care-of care-of address if the 'F' bit is set. The number of care-of
skipping to change at page 39, line 27 skipping to change at page 39, line 27
129 administratively prohibited 129 administratively prohibited
130 insufficient resources 130 insufficient resources
131 mobile node failed authentication 131 mobile node failed authentication
132 foreign agent failed authentication 132 foreign agent failed authentication
133 registration Identification mismatch 133 registration Identification mismatch
134 poorly formed Request 134 poorly formed Request
135 too many simultaneous mobility bindings 135 too many simultaneous mobility bindings
136 unknown home agent address 136 unknown home agent address
Up-to-date values of the Code field are specified in the IANA online Up-to-date values of the Code field are specified in the IANA online
database [45]. database [48].
3.5. Registration Extensions 3.5. Registration Extensions
3.5.1. Computing Authentication Extension Values 3.5.1. Computing Authentication Extension Values
The Authenticator value computed for each authentication Extension The Authenticator value computed for each authentication Extension
MUST protect the following fields from the registration message: MUST protect the following fields from the registration message:
o the UDP payload (that is, the Registration Request or Registration o the UDP payload (that is, the Registration Request or Registration
Reply data), Reply data),
skipping to change at page 40, line 32 skipping to change at page 40, line 32
IP MUST implement the default authentication algorithm (HMAC-MD5) IP MUST implement the default authentication algorithm (HMAC-MD5)
specified above. specified above.
3.5.2. Mobile-Home Authentication Extension 3.5.2. Mobile-Home Authentication Extension
At least one authorization-enabling extension MUST be present in all At least one authorization-enabling extension MUST be present in all
Registration Requests, and also in all Registration Replies generated Registration Requests, and also in all Registration Replies generated
by the Home Agent. The Mobile-Home Authentication Extension is by the Home Agent. The Mobile-Home Authentication Extension is
always an authorization-enabling for registration messages specified always an authorization-enabling for registration messages specified
in this document. This requirement is intended to eliminate problems in this document. This requirement is intended to eliminate problems
[26] which result from the uncontrolled propagation of remote [30] which result from the uncontrolled propagation of remote
redirects in the Internet. The location of the authorization- redirects in the Internet. The location of the authorization-
enabling extension marks the end of the data to be authenticated by enabling extension marks the end of the data to be authenticated by
the authorizatizing agent interpreting that authorization-enabling the authorizing agent interpreting that authorization-enabling
extension. extension.
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 | SPI .... | Type | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ... ... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 64, line 38 skipping to change at page 64, line 38
with a Code of 129. with a Code of 129.
Requests with non-zero bits in reserved fields MUST be rejected with Requests with non-zero bits in reserved fields MUST be rejected with
code 134 (poorly formed request). code 134 (poorly formed request).
3.8.3. Sending Registration Replies 3.8.3. Sending Registration Replies
If the home agent accepts a Registration Request, it then MUST update If the home agent accepts a Registration Request, it then MUST update
its record of the mobile node's mobility binding(s) and SHOULD send a its record of the mobile node's mobility binding(s) and SHOULD send a
Registration Reply with a suitable Code. Otherwise (the home agent Registration Reply with a suitable Code. Otherwise (the home agent
has denied the Request), it it SHOULD in most cases send a has denied the Request), it SHOULD in most cases send a Registration
Registration Reply with an appropriate Code specifying the reason the Reply with an appropriate Code specifying the reason the Request was
Request was denied. The following sections provide additional detail denied. The following sections provide additional detail for the
for the values the home agent MUST supply in the fields of values the home agent MUST supply in the fields of Registration Reply
Registration Reply messages. messages.
3.8.3.1. IP/UDP Fields 3.8.3.1. IP/UDP Fields
This section provides the specific rules by which home agents pick This section provides the specific rules by which home agents pick
values for the IP and UDP header fields of a Registration Reply. values for the IP and UDP header fields of a Registration Reply.
IP Source Address IP Source Address
Copied from the IP Destination Address of Registration Request, Copied from the IP Destination Address of Registration Request,
unless a multicast or broadcast address was used. If the IP unless a multicast or broadcast address was used. If the IP
skipping to change at page 75, line 17 skipping to change at page 75, line 17
The use of ARP [16] requires special rules for correct operation when The use of ARP [16] requires special rules for correct operation when
wireless or mobile nodes are involved. The requirements specified in wireless or mobile nodes are involved. The requirements specified in
this section apply to all home networks in which ARP is used for this section apply to all home networks in which ARP is used for
address resolution. address resolution.
In addition to the normal use of ARP for resolving a target node's In addition to the normal use of ARP for resolving a target node's
link-layer address from its IP address, this document distinguishes link-layer address from its IP address, this document distinguishes
two special uses of ARP: two special uses of ARP:
o A Proxy ARP [46] is an ARP Reply sent by one node on behalf of o A Proxy ARP [49] is an ARP Reply sent by one node on behalf of
another node which is either unable or unwilling to answer its own another node which is either unable or unwilling to answer its own
ARP Requests. The sender of a Proxy ARP reverses the Sender and ARP Requests. The sender of a Proxy ARP reverses the Sender and
Target Protocol Address fields as described in [16], but supplies Target Protocol Address fields as described in [16], but supplies
some configured link-layer address (generally, its own) in the some configured link-layer address (generally, its own) in the
Sender Hardware Address field. The node receiving the Reply will Sender Hardware Address field. The node receiving the Reply will
then associate this link-layer address with the IP address of the then associate this link-layer address with the IP address of the
original target node, causing it to transmit future datagrams for original target node, causing it to transmit future datagrams for
this target node to the node with that link-layer address. this target node to the node with that link-layer address.
o A Gratuitous ARP [42] is an ARP packet sent by a node in order to o A Gratuitous ARP [45] is an ARP packet sent by a node in order to
spontaneously cause other nodes to update an entry in their ARP spontaneously cause other nodes to update an entry in their ARP
cache. A gratuitous ARP MAY use either an ARP Request or an ARP cache. A gratuitous ARP MAY use either an ARP Request or an ARP
Reply packet. In either case, the ARP Sender Protocol Address and Reply packet. In either case, the ARP Sender Protocol Address and
ARP Target Protocol Address are both set to the IP address of the ARP Target Protocol Address are both set to the IP address of the
cache entry to be updated, and the ARP Sender Hardware Address is cache entry to be updated, and the ARP Sender Hardware Address is
set to the link-layer address to which this cache entry should be set to the link-layer address to which this cache entry should be
updated. When using an ARP Reply packet, the Target Hardware updated. When using an ARP Reply packet, the Target Hardware
Address is also set to the link-layer address to which this cache Address is also set to the link-layer address to which this cache
entry should be updated (this field is not used in an ARP Request entry should be updated (this field is not used in an ARP Request
packet). packet).
skipping to change at page 75, line 50 skipping to change at page 75, line 50
transmitted as a local broadcast packet on the local link. As transmitted as a local broadcast packet on the local link. As
specified in [16], any node receiving any ARP packet (Request or specified in [16], any node receiving any ARP packet (Request or
Reply) MUST update its local ARP cache with the Sender Protocol Reply) MUST update its local ARP cache with the Sender Protocol
and Hardware Addresses in the ARP packet, if the receiving node and Hardware Addresses in the ARP packet, if the receiving node
has an entry for that IP address already in its ARP cache. This has an entry for that IP address already in its ARP cache. This
requirement in the ARP protocol applies even for ARP Request requirement in the ARP protocol applies even for ARP Request
packets, and for ARP Reply packets that do not match any ARP packets, and for ARP Reply packets that do not match any ARP
Request transmitted by the receiving node [16]. Request transmitted by the receiving node [16].
While a mobile node is registered on a foreign network, its home While a mobile node is registered on a foreign network, its home
agent uses proxy ARP [46] to reply to ARP Requests it receives that agent uses proxy ARP [49] to reply to ARP Requests it receives that
seek the mobile node's link-layer address. When receiving an ARP seek the mobile node's link-layer address. When receiving an ARP
Request, the home agent MUST examine the target IP address of the Request, the home agent MUST examine the target IP address of the
Request, and if this IP address matches the home address of any Request, and if this IP address matches the home address of any
mobile node for which it has a registered mobility binding, the home mobile node for which it has a registered mobility binding, the home
agent MUST transmit an ARP Reply on behalf of the mobile node. After agent MUST transmit an ARP Reply on behalf of the mobile node. After
exchanging the sender and target addresses in the packet [46], the exchanging the sender and target addresses in the packet [49], the
home agent MUST set the sender link-layer address in the packet to home agent MUST set the sender link-layer address in the packet to
the link-layer address of its own interface over which the Reply will the link-layer address of its own interface over which the Reply will
be sent. be sent.
When a mobile node leaves its home network and registers a binding on When a mobile node leaves its home network and registers a binding on
a foreign network, its home agent uses gratuitous ARP to update the a foreign network, its home agent uses gratuitous ARP to update the
ARP caches of nodes on the home network. This causes such nodes to ARP caches of nodes on the home network. This causes such nodes to
associate the link-layer address of the home agent with the mobile associate the link-layer address of the home agent with the mobile
node's home (IP) address. When registering a binding for a mobile node's home (IP) address. When registering a binding for a mobile
node for which the home agent previously had no binding (the mobile node for which the home agent previously had no binding (the mobile
skipping to change at page 79, line 43 skipping to change at page 79, line 43
extensions. extensions.
5.2. Areas of Security Concern in this Protocol 5.2. Areas of Security Concern in this Protocol
The registration protocol described in this document will result in a The registration protocol described in this document will result in a
mobile node's traffic being tunneled to its care-of address. This mobile node's traffic being tunneled to its care-of address. This
tunneling feature could be a significant vulnerability if the tunneling feature could be a significant vulnerability if the
registration were not authenticated. Such remote redirection, for registration were not authenticated. Such remote redirection, for
instance as performed by the mobile registration protocol, is widely instance as performed by the mobile registration protocol, is widely
understood to be a security problem in the current Internet if not understood to be a security problem in the current Internet if not
authenticated [26]. Moreover, the Address Resolution Protocol (ARP) authenticated [30]. Moreover, the Address Resolution Protocol (ARP)
is not authenticated, and can potentially be used to steal another is not authenticated, and can potentially be used to steal another
host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings
with it all of the risks associated with the use of ARP. with it all of the risks associated with the use of ARP.
5.3. Key Management 5.3. Key Management
This specification requires a strong authentication mechanism (keyed This specification requires a strong authentication mechanism (keyed
MD5) which precludes many potential attacks based on the Mobile IP MD5) which precludes many potential attacks based on the Mobile IP
registration protocol. However, because key distribution is registration protocol. However, because key distribution is
difficult in the absence of a network key management protocol, difficult in the absence of a network key management protocol,
skipping to change at page 80, line 41 skipping to change at page 80, line 41
traffic analysis should consider appropriate use of link encryption. traffic analysis should consider appropriate use of link encryption.
If absolute location privacy is desired, the mobile node can create a If absolute location privacy is desired, the mobile node can create a
tunnel to its home agent. Then, datagrams destined for correspondent tunnel to its home agent. Then, datagrams destined for correspondent
nodes will appear to emanate from the home network, and it may be nodes will appear to emanate from the home network, and it may be
more difficult to pinpoint the location of the mobile node. Such more difficult to pinpoint the location of the mobile node. Such
mechanisms are all beyond the scope of this document. mechanisms are all beyond the scope of this document.
5.6. Ingress Filtering 5.6. Ingress Filtering
Many routers implement security policies such as "ingress filtering" Many routers implement security policies such as "ingress filtering"
[31] that do not allow forwarding of packets that have a Source [35] that do not allow forwarding of packets that have a Source
Address which appears topologically incorrect. In environments where Address which appears topologically incorrect. In environments where
this is a problem, mobile nodes may use reverse tunneling [12] with this is a problem, mobile nodes may use reverse tunneling [12] with
the foreign agent supplied care-of address as the Source Address. the foreign agent supplied care-of address as the Source Address.
Reverse tunneled packets will be able to pass normally through such Reverse tunneled packets will be able to pass normally through such
routers, while ingress filtering rules will still be able to locate routers, while ingress filtering rules will still be able to locate
the true topological source of the packet in the same way as packets the true topological source of the packet in the same way as packets
from non-mobile nodes. from non-mobile nodes.
5.7. Replay Protection for Registration Requests 5.7. Replay Protection for Registration Requests
skipping to change at page 84, line 16 skipping to change at page 84, line 16
Mobile IP specifies several new number spaces for values to be used Mobile IP specifies several new number spaces for values to be used
in various message fields. These number spaces include the in various message fields. These number spaces include the
following: following:
o Mobile IP message types sent to UDP port 434, as defined in o Mobile IP message types sent to UDP port 434, as defined in
Section 1.8. Section 1.8.
o types of extensions to Registration Request and Registration Reply o types of extensions to Registration Request and Registration Reply
messages (see Section 3.3 and Section 3.4, and also consult messages (see Section 3.3 and Section 3.4, and also consult
([12],[39],[2],[3],[7]). ([12],[43],[2],[3],[7]).
o values for the Code in the Registration Reply message (see o values for the Code in the Registration Reply message (see
Section 3.4, and also consult ([12],[39],[2],[3],[7]). Section 3.4, and also consult ([12],[43],[2],[3],[7]).
o Mobile IP defines so-called Agent Solicitation and Agent o Mobile IP defines so-called Agent Solicitation and Agent
Advertisement messages. These messages are in fact Router Advertisement messages. These messages are in fact Router
Discovery messages [5] augmented with mobile-IP specific Discovery messages [5] augmented with mobile-IP specific
extensions. Thus, they do not define a new name space, but do extensions. Thus, they do not define a new name space, but do
define additional Router Discovery extensions as described below define additional Router Discovery extensions as described below
in Section 6.2. Also see Section 2.1 and consult ([3], [7]). in Section 6.2. Also see Section 2.1 and consult ([3], [7]).
There are additional Mobile IP numbering spaces specified in [3]. There are additional Mobile IP numbering spaces specified in [3].
skipping to change at page 84, line 48 skipping to change at page 84, line 48
for Foreign Agent messages. This error code is needed to indicate for Foreign Agent messages. This error code is needed to indicate
the status "Invalid Home Agent Address". See Section 3.7.2 for the status "Invalid Home Agent Address". See Section 3.7.2 for
details. details.
6.1. Mobile IP Message Types 6.1. Mobile IP Message Types
Mobile IP messages are defined to be those that are sent to a message Mobile IP messages are defined to be those that are sent to a message
recipient at port 434 (UDP or TCP). The number space for Mobile IP recipient at port 434 (UDP or TCP). The number space for Mobile IP
messages is specified in Section 1.8. Approval of new extension messages is specified in Section 1.8. Approval of new extension
numbers is subject to Expert Review, and a specification is required numbers is subject to Expert Review, and a specification is required
[21]. The currently standardized message types have the following [22]. The currently standardized message types have the following
numbers, and are specified in the indicated sections. numbers, and are specified in the indicated sections.
Type Name Section Type Name Section
---- -------------------------------------------- --------- ---- -------------------------------------------- ---------
1 Registration Request 3.3 1 Registration Request 3.3
3 Registration Reply 3.4 3 Registration Reply 3.4
6.2. Extensions to RFC 1256 Router Advertisement 6.2. Extensions to RFC 1256 Router Advertisement
RFC 1256 defines two ICMP message types, Router Advertisement and RFC 1256 defines two ICMP message types, Router Advertisement and
skipping to change at page 85, line 25 skipping to change at page 85, line 25
Mobile IP. The extension types currently standardized for use with Mobile IP. The extension types currently standardized for use with
Mobile IP have the following numbers. Mobile IP have the following numbers.
Type Name Reference Type Name Reference
---- -------------------------------------------- --------- ---- -------------------------------------------- ---------
0 One-byte Padding 2.1.3 0 One-byte Padding 2.1.3
16 Mobility Agent Advertisement 2.1.1 16 Mobility Agent Advertisement 2.1.1
19 Prefix-Lengths 2.1.2 19 Prefix-Lengths 2.1.2
Approval of new extension numbers for use with Mobile IP is subject Approval of new extension numbers for use with Mobile IP is subject
to Expert Review, and a specification is required [21]. to Expert Review, and a specification is required [22].
6.3. Extensions to Mobile IP Registration Messages 6.3. Extensions to Mobile IP Registration Messages
The Mobile IP messages, specified within this document, and listed in The Mobile IP messages, specified within this document, and listed in
Section 1.8 and Section 6.1, may have extensions. Mobile IP message Section 1.8 and Section 6.1, may have extensions. Mobile IP message
extensions all share the same number space, even if they are to be extensions all share the same number space, even if they are to be
applied to different Mobile IP messages. The number space for Mobile applied to different Mobile IP messages. The number space for Mobile
IP message extensions is specified within this document. Approval of IP message extensions is specified within this document. Approval of
new extension numbers is subject to Expert Review, and a new extension numbers is subject to Expert Review, and a
specification is required [21]. specification is required [22].
Type Name Reference Type Name Reference
---- -------------------------------------------- --------- ---- -------------------------------------------- ---------
0 One-byte Padding 0 One-byte Padding
32 Mobile-Home Authentication 3.5.2 32 Mobile-Home Authentication 3.5.2
33 Mobile-Foreign Authentication 3.5.3 33 Mobile-Foreign Authentication 3.5.3
34 Foreign-Home Authentication 3.5.4 34 Foreign-Home Authentication 3.5.4
6.4. Code Values for Mobile IP Registration Reply Messages 6.4. Code Values for Mobile IP Registration Reply Messages
The Mobile IP Registration Reply message, specified in Section 3.4, The Mobile IP Registration Reply message, specified in Section 3.4,
has a Code field. The number space for the Code field values is also has a Code field. The number space for the Code field values is also
specified in Section 3.4. The Code number space is structured specified in Section 3.4. The Code number space is structured
according to whether the registration was successful, or whether the according to whether the registration was successful, or whether the
foreign agent denied the registration request, or lastly whether the foreign agent denied the registration request, or lastly whether the
home agent denied the registration request, as follows: home agent denied the registration request, as follows:
0-8 Success Codes +---------+------------------------------------------------------+
9-63 No allocation guidelines currently exist | Code #s | Guideline |
64-127 Error Codes from the Foreign Agent +---------+------------------------------------------------------+
128-192 Error Codes from the Home Agent | 0-8 | Success Codes |
193-255 No allocation guidelines currently exist | | |
| 9-63 | Allocation guidelines not specified in this document |
| | |
| 64-127 | Error Codes from the Foreign Agent |
| | |
| 128-192 | Error Codes from the Home Agent |
| | |
| 193-200 | Error Codes from the Gateway Foreign Agent [29] |
| | |
| 201-255 | Allocation guidelines not specified in this document |
+---------+------------------------------------------------------+
Approval of new Code values requires Expert Review [21]. Approval of new Code values requires Expert Review [22].
Table 1: Guidelines for Allocation of Code Values
7. Acknowledgments 7. Acknowledgments
Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp
and John Ioannidis (JI) (Columbia University), for forming the and John Ioannidis (JI) (Columbia University), for forming the
working group, chairing it, and putting so much effort into its early working group, chairing it, and putting so much effort into its early
development. Columbia's early Mobile IP work can be found in development. Columbia's early Mobile IP work can be found in
[33],[34],[35]. [37],[38],[39].
Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon,
Erik Nordmark, Basavaraj Patil, and Phil Roberts for their Erik Nordmark, Basavaraj Patil, and Phil Roberts for their
contributions to the group while performing the duties of contributions to the group while performing the duties of
chairperson, as well as for their many useful comments. chairperson, as well as for their many useful comments.
Thanks to the active members of the Mobile IP Working Group, Thanks to the active members of the Mobile IP Working Group,
particularly those who contributed text, including (in alphabetical particularly those who contributed text, including (in alphabetical
order) order)
skipping to change at page 90, line 23 skipping to change at page 90, line 23
[18] Postel, J., "Internet Protocol", STD 5, RFC 791, [18] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[20] Solomon, J., "Applicability Statement for IP Mobility Support", [20] Solomon, J., "Applicability Statement for IP Mobility Support",
RFC 2005, October 1996. RFC 2005, October 1996.
[21] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [21] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
8.2. Informative References 8.2. Informative References
[22] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for [23] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
PPP IPCP", RFC 2290, February 1998. PPP IPCP", RFC 2290, February 1998.
[23] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. [24] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
Vaidya, "Long Thin Networks", RFC 2757, January 2000. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[24] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over [25] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, Satellite Channels using Standard Mechanisms", BCP 28,
RFC 2488, January 1999. RFC 2488, January 1999.
[25] Paxson, V. and M. Allman, "Computing TCP's Retransmission [26] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[26] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", [27] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
Address Translation (NAT) Devices", RFC 3519, April 2003.
[28] Glass, S. and M. Chandra, "Registration Revocation in Mobile
IPv4", RFC 3543, August 2003.
[29] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
Regional Registration", RFC 4857, June 2007.
[30] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, 19(2), March 1989. ACM Computer Communications Review, 19(2), March 1989.
[27] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [31] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Mitigate Shelby, "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations", RFC 3135, June 2001. Link-Related Degradations", RFC 3135, June 2001.
[28] Caceres, R. and L. Iftode, "Improving the Performance of [32] Caceres, R. and L. Iftode, "Improving the Performance of
Reliable Transport Protocols in Mobile Computing Environments", Reliable Transport Protocols in Mobile Computing Environments",
IEEE Journal on Selected Areas in Communication, 13(5):850-- IEEE Journal on Selected Areas in Communication, 13(5):850--
857, June 1995. 857, June 1995.
[29] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. [33] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
Vaidya, "End-to-end Performance Implications of Links with Vaidya, "End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3155, August 2001. Errors", BCP 50, RFC 3155, August 2001.
[30] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [34] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[31] Ferguson, P. and D. Senie, "Network Ingress Filtering: [35] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[32] Jacobson, V., "Compressing TCP/IP headers for low-speed serial [36] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990. links", RFC 1144, February 1990.
[33] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols [37] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols
for Mobile Interworking", In Proceedings of the SIGCOMM '01 for Mobile Interworking", In Proceedings of the SIGCOMM '01
Conference: Communications Architectures and Protocols, Pages Conference: Communications Architectures and Protocols, Pages
235--245, September 1991. 235--245, September 1991.
[34] Ioannidis, J. and G. Maguire, "The Design and Implementation of [38] Ioannidis, J. and G. Maguire, "The Design and Implementation of
a Mobile Internetworking Architecture", In Proceedings of the a Mobile Internetworking Architecture", In Proceedings of the
Winter USENIX Technical Conference, Pages 489--500, Winter USENIX Technical Conference, Pages 489--500,
January 1993. January 1993.
[35] Ioannidis, J., "Protocols for Mobile Interworking", PhD [39] Ioannidis, J., "Protocols for Mobile Interworking", PhD
Dissertation - Columbia University in the City of New York , Dissertation - Columbia University in the City of New York ,
July 1993. July 1993.
[36] Jacobson, V., "Congestion Avoidance and Control", In [40] Jacobson, V., "Congestion Avoidance and Control", In
Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM
Press, Pages 314--329, August 1998. Press, Pages 314--329, August 1998.
[37] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", [41] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000. RFC 2863, June 2000.
[38] McGregor, G., "The PPP Internet Protocol Control Protocol [42] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[39] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for [43] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998. Mobile IP", RFC 2356, June 1998.
[40] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [44] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[41] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[42] Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols", [45] Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols",
Addison-Wesley, Reading, Massachussets, 1994. Addison-Wesley, Reading, Massachussets, 1994.
[43] Perkins, C. and P. Calhoun, "Authentication, Authorization, and [46] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
March 2005. March 2005.
[44] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [47] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[45] IANA Assigned Numbers Online Database, "Mobile IPv4 Numbers", [48] IANA Assigned Numbers Online Database, "Mobile IPv4 Numbers",
http://www.iana.org/assignments/mobileip-numbers . http://www.iana.org/assignments/mobileip-numbers .
[46] Postel, J., "Multi-LAN address resolution", RFC 925, [49] Postel, J., "Multi-LAN address resolution", RFC 925,
October 1984. October 1984.
Appendix A. Pre-RFC5378 Disclaimer Appendix A. Pre-RFC5378 Disclaimer
"This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English." than English.
Appendix B. Link-Layer Considerations Appendix B. Link-Layer Considerations
The mobile node MAY use link-layer mechanisms to decide that its The mobile node MAY use link-layer mechanisms to decide that its
point of attachment has changed. Such indications include the Down/ point of attachment has changed. Such indications include the Down/
Testing/Up interface status [37], and changes in cell or Testing/Up interface status [41], and changes in cell or
administration. The mechanisms will be specific to the particular administration. The mechanisms will be specific to the particular
link-layer technology, and are outside the scope of this document. link-layer technology, and are outside the scope of this document.
The Point-to-Point-Protocol (PPP) [44] and its Internet Protocol The Point-to-Point-Protocol (PPP) [47] and its Internet Protocol
Control Protocol (IPCP) [38], negotiates the use of IP addresses. Control Protocol (IPCP) [42], negotiates the use of IP addresses.
The mobile node SHOULD first attempt to specify its home address, so The mobile node SHOULD first attempt to specify its home address, so
that if the mobile node is attaching to its home network, the that if the mobile node is attaching to its home network, the
unrouted link will function correctly. When the home address is not unrouted link will function correctly. When the home address is not
accepted by the peer, but a transient IP address is dynamically accepted by the peer, but a transient IP address is dynamically
assigned to the mobile node, and the mobile node is capable of assigned to the mobile node, and the mobile node is capable of
supporting a co-located care-of address, the mobile node MAY register supporting a co-located care-of address, the mobile node MAY register
that address as a co-located care-of address. When the peer that address as a co-located care-of address. When the peer
specifies its own IP address, that address MUST NOT be assumed to be specifies its own IP address, that address MUST NOT be assumed to be
a foreign agent care-of address or the IP address of a home agent. a foreign agent care-of address or the IP address of a home agent.
PPP extensions for Mobile IP have been specified in RFC 2290 [22]. PPP extensions for Mobile IP have been specified in RFC 2290 [23].
Please consult that document for additional details for how to handle Please consult that document for additional details for how to handle
care-of address assignment from PPP in a more efficient manner. care-of address assignment from PPP in a more efficient manner.
Appendix C. TCP Considerations Appendix C. TCP Considerations
C.1. TCP Timers C.1. TCP Timers
When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency
Radio) links are in use, some TCP stacks may have insufficiently Radio) links are in use, some TCP stacks may have insufficiently
adaptive (non-standard) retransmission timeouts. There may be adaptive (non-standard) retransmission timeouts. There may be
spurious retransmission timeouts, even when the link and network are spurious retransmission timeouts, even when the link and network are
actually operating properly, but just with a high delay because of actually operating properly, but just with a high delay because of
the medium in use. This can cause an inability to create or maintain the medium in use. This can cause an inability to create or maintain
TCP connections over such links, and can also cause unneeded TCP connections over such links, and can also cause unneeded
retransmissions which consume already scarce bandwidth. Vendors are retransmissions which consume already scarce bandwidth. Vendors are
encouraged to follow the algorithms in RFC 2988 [25] when encouraged to follow the algorithms in RFC 2988 [26] when
implementing TCP retransmission timers. Vendors of systems designed implementing TCP retransmission timers. Vendors of systems designed
for low-bandwidth, high-delay links should consult RFCs 2757 and 2488 for low-bandwidth, high-delay links should consult RFCs 2757 and 2488
[23], [24]. Designers of applications targeted to operate on mobile [24], [25]. Designers of applications targeted to operate on mobile
nodes should be sensitive to the possibility of timer-related nodes should be sensitive to the possibility of timer-related
difficulties. difficulties.
C.2. TCP Congestion Management C.2. TCP Congestion Management
Mobile nodes often use media which are more likely to introduce Mobile nodes often use media which are more likely to introduce
errors, effectively causing more packets to be dropped. This errors, effectively causing more packets to be dropped. This
introduces a conflict with the mechanisms for congestion management introduces a conflict with the mechanisms for congestion management
found in modern versions of TCP [36]. Now, when a packet is dropped, found in modern versions of TCP [40]. Now, when a packet is dropped,
the correspondent node's TCP implementation is likely to react as if the correspondent node's TCP implementation is likely to react as if
there were a source of network congestion, and initiate the slow- there were a source of network congestion, and initiate the slow-
start mechanisms [36] designed for controlling that problem. start mechanisms [40] designed for controlling that problem.
However, those mechanisms are inappropriate for overcoming errors However, those mechanisms are inappropriate for overcoming errors
introduced by the links themselves, and have the effect of magnifying introduced by the links themselves, and have the effect of magnifying
the discontinuity introduced by the dropped packet. This problem has the discontinuity introduced by the dropped packet. This problem has
been analyzed by Caceres, et al. [28]. TCP approaches to the problem been analyzed by Caceres, et al. [32]. TCP approaches to the problem
of handling errors that might interfere with congestion management of handling errors that might interfere with congestion management
are discussed in documents from the [pilc] working group [27] [29]. are discussed in documents from the [pilc] working group [31] [33].
While such approaches are beyond the scope of this document, they While such approaches are beyond the scope of this document, they
illustrate that providing performance transparency to mobile nodes illustrate that providing performance transparency to mobile nodes
involves understanding mechanisms outside the network layer. involves understanding mechanisms outside the network layer.
Problems introduced by higher media error rates also indicate the Problems introduced by higher media error rates also indicate the
need to avoid designs which systematically drop packets; such designs need to avoid designs which systematically drop packets; such designs
might otherwise be considered favorably when making engineering might otherwise be considered favorably when making engineering
tradeoffs. tradeoffs.
Appendix D. Example Scenarios Appendix D. Example Scenarios
skipping to change at page 96, line 45 skipping to change at page 96, line 45
Mobility Agent Advertisement Extension of the Mobility Agent Advertisement Extension of the
Router Advertisement message Router Advertisement message
Identification = Network Time Protocol timestamp or Nonce Identification = Network Time Protocol timestamp or Nonce
Extensions: Extensions:
An authorization-enabling extension (e.g., the Mobile-Home An authorization-enabling extension (e.g., the Mobile-Home
Authentication Extension) Authentication Extension)
D.2. Registering with a Co-Located Care-of Address D.2. Registering with a Co-Located Care-of Address
The mobile node enters a foreign network that contains no foreign The mobile node enters a foreign network that contains no foreign
agents. The mobile node obtains an address from a DHCP server [30] agents. The mobile node obtains an address from a DHCP server [34]
for use as a co-located care-of address. The mobile node supports for use as a co-located care-of address. The mobile node supports
all forms of encapsulation (IP-in-IP, minimal encapsulation, and all forms of encapsulation (IP-in-IP, minimal encapsulation, and
GRE), desires a copy of broadcast datagrams on the home network, and GRE), desires a copy of broadcast datagrams on the home network, and
does not want simultaneous mobility bindings: does not want simultaneous mobility bindings:
IP fields: IP fields:
Source Address = care-of address obtained from DHCP server Source Address = care-of address obtained from DHCP server
Destination Address = IP address of home agent Destination Address = IP address of home agent
Time to Live = 64 Time to Live = 64
UDP fields: UDP fields:
skipping to change at page 99, line 18 skipping to change at page 99, line 18
improve interoperability by resolving ambiguities contained in the improve interoperability by resolving ambiguities contained in the
earlier text. Implementations that perform authentication according earlier text. Implementations that perform authentication according
to the new more precisely specified algorithm would be interoperable to the new more precisely specified algorithm would be interoperable
with earlier implementations that did what was originally expected with earlier implementations that did what was originally expected
for producing authentication data. That was a major source of non- for producing authentication data. That was a major source of non-
interoperability before. interoperability before.
However, this specification does have new features that, if used, However, this specification does have new features that, if used,
would cause interoperability problems with older implementations. would cause interoperability problems with older implementations.
All features specified in RFC 2002 will work with the new All features specified in RFC 2002 will work with the new
implementations, except for V-J compression [32]. The following list implementations, except for V-J compression [36]. The following list
details some of the possible areas of compatibility problems that may details some of the possible areas of compatibility problems that may
be experienced by nodes conforming to this revised specification, be experienced by nodes conforming to this revised specification,
when attempting to interoperate with nodes obeying RFC 2002. when attempting to interoperate with nodes obeying RFC 2002.
o A client that expects some of the newly mandatory features (like o A client that expects some of the newly mandatory features (like
reverse tunneling) from a foreign agent would still be reverse tunneling) from a foreign agent would still be
interoperable as long as it pays attention to the `T' bit. interoperable as long as it pays attention to the `T' bit.
o Mobile nodes that use the NAI extension to identify themselves o Mobile nodes that use the NAI extension to identify themselves
would not work with old mobility agents. would not work with old mobility agents.
skipping to change at page 100, line 5 skipping to change at page 100, line 5
In all of these cases, a robust and well-configured mobile node is In all of these cases, a robust and well-configured mobile node is
very likely to be able to recover if it takes reasonable actions upon very likely to be able to recover if it takes reasonable actions upon
receipt of a Registration Reply with an error code indicating the receipt of a Registration Reply with an error code indicating the
cause for rejection. For instance, if a mobile node sends a cause for rejection. For instance, if a mobile node sends a
registration request that is rejected because it contains the wrong registration request that is rejected because it contains the wrong
kind of authentication extension, then the mobile node could retry kind of authentication extension, then the mobile node could retry
the registration with a mobile-home authentication extension, since the registration with a mobile-home authentication extension, since
the foreign agent and/or home agent in this case will not be the foreign agent and/or home agent in this case will not be
configured to demand the alternative authentication data. configured to demand the alternative authentication data.
Appendix G. Changes since RFC 2002 Appendix G. Changes since RFC 3344
G.1. Recent Changes The following revisions to details of the specification in this
document were made after RFC 3344 was published. A list of changes
from RFC 2002 made during the development of RFC 3344 [21] may be
found in the latter document. For items marked with issue numbers,
more information is available by consulting the MIP4 mailing list
archives.
The following changes have been made since RFC 3344 was published. o Showed more bit definitions in the Agent Advertisement message
For items marked with issue numbers, more information is available by structure (see Section 2.1.1). New advertisement bits have been
consulting the MIP4 issues web page, defined by other specification documents, but not reflected in
http://www.mip4.org/issues/tracker/mip4/ previous publications of this specification; this has led to
confusion. Citations for the other specification documents have
also been included.
o (Issue 6) The behavior of the home agent was changed to avoid o (Issue 6) The behavior of the home agent was changed to avoid
mandating error replies to Registration Requests that were mandating error replies to Registration Requests that were
invalidated because the foreign agent failed authentication. The invalidated because the foreign agent failed authentication. The
intention is to make the home agent more robust against Denial of intention is to make the home agent more robust against Denial of
Service attacks in which the malicious device has no intention of Service attacks in which the malicious device has no intention of
providing a valid registration request but only wants to congest providing a valid registration request but only wants to congest
traffic on the home network. See section Section 3.8.2.1. traffic on the home network. See section Section 3.8.2.1.
o Due to non-unique assignment of IPv4 addresses in many domains, it o Due to non-unique assignment of IPv4 addresses in many domains, it
skipping to change at page 101, line 23 skipping to change at page 101, line 32
the Mobile-Home Authentication extension (section 3.7.3.2). the Mobile-Home Authentication extension (section 3.7.3.2).
o (Issue 44) Specified that the address advertised by the foreign o (Issue 44) Specified that the address advertised by the foreign
agent in Agent Advertisements is the care-of address offered on agent in Agent Advertisements is the care-of address offered on
that network interface, not necessarily the address of the network that network interface, not necessarily the address of the network
interface (section 3.7.2.2). interface (section 3.7.2.2).
o (Issue 45) Clarification in section 3.7.2.1 that code 77 can only o (Issue 45) Clarification in section 3.7.2.1 that code 77 can only
apply to a Registration Request with nonzero lifetime. apply to a Registration Request with nonzero lifetime.
G.2. Major Changes
o Specification for Destination IP address of Registration Reply
transmitted from Foreign Agent, to avoid any possible transmission
to IP address 0.0.0.0.
o Specification of two new formats for Mobile IP extensions,
according to the ideas contained in MIER.
o Specification that the SPI of the MN-HA authentication extension
is to be used as part of the data over which the authentication
algorithm must be computed.
o Eliminated Van-Jacobson Compression feature
o Specification that foreign agents MAY send advertisements at a
rate faster than once per second, but chosen so that the
advertisements do not burden the capacity of the local link. For
simplicity, the foreign agent now MAY send advertisements at an
interval less than 1/3 the advertised ICMP Lifetime.
o Specification that foreign agents SHOULD support reverse
tunneling, and home agents MUST support decapsulation of reverse
tunnels.
o Changed the preconfiguration requirements in section 3.6 for the
mobile node to reflect the capability, specified in RFC 2794 [2],
for the mobile node to identify itself by using its NAI, and then
getting a home address from the Registration Reply.
o Changed section 3.7.3.1 so that a foreign agent is not required to
discard Registration Replies that have a Home Address field that
does not match any pending Registration Request.
o Allowed registrations to be authenticated by use of a security
association between the mobile node and a suitable authentication
entity acceptable to the home agent. Defined "Authorization-
enabling Extension" to be an authentication extension that makes a
registration message acceptable to the recipient. This is needed
according to specification in [2].
o Mandated that HMAC-MD5 be used instead of the "prefix+suffix" mode
of MD5 as originally mandated in RFC 2002.
o Specified that the mobile node SHOULD take the first care-of
address in a list offered by a foreign agent, and MAY try each
subsequent advertised address in turn if the attempted
registrations are rejected by the foreign agent
o Clarification that a mobility agent SHOULD only put its own
addresses into the initial (i.e., not mobility-related) list of
routers in the mobility advertisement. RFC 2002 suggests that a
mobility agent might advertise other default routers.
o Specification that a mobile node MUST ignore reserved bits in
Agent Advertisements, as opposed to discarding such
advertisements. In this way, new bits can be defined later,
without affecting the ability for mobile nodes to use the
advertisements even when the newly defined bits are not
understood. Furthermore, foreign agents can set the `R' bit to
make sure that new bits are handled by themselves instead of some
legacy mobility agent.
o Specification that the foreign agent checks to make sure that the
indicated home agent address does not belong to any of its network
interfaces before relaying a Registration Request. If the check
fails, and the foreign agent is not the mobile node's home agent,
then the foreign agent rejects the request with code 136 (unknown
home agent address).
o Specification that, while they are away from the home network,
mobile nodes MUST NOT broadcast ARP packets to find the MAC
address of another Internet node. Thus, the (possibly empty) list
of Router Addresses from the ICMP Router Advertisement portion of
the message is not useful for selecting a default router, unless
the mobile node has some means not involving broadcast ARP and not
specified within this document for obtaining the MAC address of
one of the routers in the list. Similarly, in the absence of
unspecified mechanisms for obtaining MAC addresses on foreign
networks, the mobile node MUST ignore redirects to other routers
on foreign networks.
o Specification that a foreign agent MUST NOT use broadcast ARP for
a mobile node's MAC address on a foreign network. It may obtain
the MAC address by copying the information from an Agent
Solicitation or a Registration Request transmitted from a mobile
node.
o Specification that a foreign agent's ARP cache for the mobile
node's IP address MUST NOT be allowed to expire before the mobile
node's visitor list entry expires, unless the foreign agent has
some way other than broadcast ARP to refresh its MAC address
associated to the mobile node's IP address.
o At the end of section 4.6, clarified that a home agent MUST NOT
make any changes to the way it performs proxy ARP after it rejects
an invalid deregistration request.
o In section 4.2.3, specification that multihomed home agents MUST
use the the address sent to the mobile node in the home agent
field of the registration reply as the source address in the outer
IP header of the encapsulated datagram.
o Inserted 'T' bit into its proper place in the Registration Request
message format (section 3.3).
G.3. Minor Changes
o Allowed registration replies to be processed by the mobile node,
even in the absence of any Mobile-Home Authentication extension,
when containing rejection code by the foreign agent.
o Specification that the foreign agent MAY configure a maximum
number of pending registrations that it is willing to maintain
(typically 5). Additional registrations SHOULD then be rejected
by the foreign agent with code 66. The foreign agent MAY delete
any pending Registration Request after the request has been
pending for more than 7 seconds; in this case, the foreign agent
SHOULD reject the Request with code 78 (registration timeout).
o Relaxation of the requirement that, when a mobile node has joined
a multicast group at the router on the foreign network, the mobile
node MUST use its home address as the source IP address for
multicast packets.
o Clarification that a mobility agent MAY use different settings for
each of the 'R', 'H', and 'F' bits on different network
interfaces.
o Replacement of the terminology "recursive tunneling" by the
terminology "nested tunneling".
o Specification that the mobile node MAY use the IP source address
of an agent advertisement as its default router address.
o Clarification that keys with arbitrary binary values MUST be
supported as part of mobility security associations.
o Specification that the default value may be chosen as 7 seconds,
for allowable time skews between a home agent and mobile node
using timestamps for replay protection. Further specification
that this value SHOULD be greater than 3 seconds.
o Specification that Registration Requests with the 'D' bit set to
0, and specifying a care-of address not offered by the foreign
agent, MUST be rejected with code 77 (invalid care-of address).
o Clarification that the foreign agent SHOULD consider its own
maximum value when handling the Lifetime field of the Registration
Reply.
o Clarification that the home agent MUST ignore the 'B' bit (as
opposed to rejecting the Registration Request) if it does not
support broadcasts.
o Advice about the impossibility of using dynamic home agent
discovery in the case when routers change the IP destination
address of a datagram from a subnet-directed broadcast address to
255.255.255.255 before injecting it into the destination subnet.
o Clarified that when an Agent Advertisement is unicast to a mobile
node, the specific IP home address of a mobile node MAY be used as
the destination IP address.
o Included a reference to RFC 2290 within appendix B, which deals
with PPP operation.
o Created IANA Considerations section
o In section 3.8.3, clarified that a home agent SHOULD arrange the
selection of a home address for a mobile node when the
Registration Reply contains a zero Home Address.
G.4. Changes since RFC3344
This section lists the changes between this document and the previous
version of the Mobile IPv4 Proposed Standard, RFC 3344 [41].
o Created a new error code for use when a Foreign Agent can detect o Created a new error code for use when a Foreign Agent can detect
that the Home Agent address field is incorrect. that the Home Agent address field is incorrect.
o Prohibited the use of the Foreign-Home Authorization Extension on o Prohibited the use of the Foreign-Home Authorization Extension on
deregistration messages. deregistration messages.
o Cleaned up some more wording having to do with authorization- o Cleaned up some more wording having to do with authorization-
enabling extensions. enabling extensions.
o For consistency, changed some wording about copying UDP ports. o For consistency, changed some wording about copying UDP ports.
o Added wording to clearly not disallow dynamically configuring o Added wording to clearly not disallow dynamically configuring
netmask and security information at the mobile node. netmask and security information at the mobile node.
o Revamped Changes section o Revamped Changes section.
o Updated citations. o Updated citations.
Appendix H. Example Messages Appendix H. Example Messages
H.1. Example ICMP Agent Advertisement Message Format H.1. Example ICMP Agent Advertisement Message 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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs |Addr Entry Size| Lifetime | | Num Addrs |Addr Entry Size| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address[1] | | Router Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[1] | | Preference Level[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address[2] | | Router Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[2] | | Preference Level[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Length | Sequence Number | | Type = 16 | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T| reserved | | Registration Lifetime |R|B|H|F|M|G|r|T|U|X|I|reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address[1] | | Care-of Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address[2] | | Care-of Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Extensions : : Optional Extensions :
: .... ...... ...... : : .... ...... ...... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H.2. Example Registration Request Message Format H.2. Example Registration Request Message Format
The UDP header is followed by the Mobile IP fields shown below: The UDP header is followed by the Mobile IP fields shown below:
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 = 1 |S|B|D|M|G|r|T|x| Lifetime | | Type = 1 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Non-Auth Extensions for HA ... | | Optional Non-Auth Extensions for HA ... |
| ( variable length ) | | ( variable length ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =32 | Length | SPI | | Type =32 | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont..) | | | SPI (cont..) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: MN-HA Authenticator ( variable length ) : : MN-HA Authenticator ( variable length ) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Non-Auth Extensions for FA ......... : Optional Non-Auth Extensions for FA .........
: Optional MN-FA Authentication Extension... : Optional MN-FA Authentication Extension...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H.3. Example Registration Reply Message Format H.3. Example Registration Reply Message Format
The UDP header is followed by the Mobile IP fields shown below: The UDP header is followed by the Mobile IP fields shown below:
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 = 3 | Code | Lifetime | | Type = 3 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent | | Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional HA Non-Auth Extensions ... | | Optional HA Non-Auth Extensions ... |
| ( variable length ) | | ( variable length ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =32 | Length | SPI | | Type =32 | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont...) | | | SPI (cont...) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: MN-HA Authenticator ( variable length ) : : MN-HA Authenticator ( variable length ) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Extensions used by FA......... : Optional Extensions used by FA.........
: Optional MN-FA Authentication Extension... : Optional MN-FA Authentication Extension...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Author's Address Author's Address
Charles E. Perkins Charles E. Perkins
WiChorus Inc. WiChorus Inc.
3590 N. 1st Street, Suite 300 3590 N. 1st Street, Suite 300
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 93 change blocks. 
365 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/