📄 rfc3344.txt
字号:
Network Working Group C. Perkins, Ed.
Request for Comments: 3344 Nokia Research Center
Obsoletes: 3220 August 2002
Category: Standards Track
IP Mobility Support for IPv4
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies protocol enhancements that allow transparent
routing of IP datagrams to mobile nodes in the Internet. Each mobile
node is always identified by its home address, regardless of its
current point of attachment to the Internet. While situated away
from its home, a mobile node is also associated with a care-of
address, which provides information about its current point of
attachment to the Internet. The protocol provides for registering
the care-of address with a home agent. The home agent sends
datagrams destined for the mobile node through a tunnel to the care-
of address. After arriving at the end of the tunnel, each datagram
is then delivered to the mobile node.
Contents
1. Introduction 3
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . 4
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . 5
1.5. New Architectural Entities . . . . . . . . . . . . . . 5
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . 9
1.8. Message Format and Protocol Extensibility . . . . . . . 13
1.9. Type-Length-Value Extension Format for Mobile IP
Extensions . . . . . . . . . . . . . . . . . . . . . 15
1.10. Long Extension Format . . . . . . . . . . . . . . . . . 16
Perkins Standards Track [Page 1]
RFC 3344 IP Mobility Support for IPv4 August 2002
1.11. Short Extension Format . . . . . . . . . . . . . . . . 16
2. Agent Discovery 17
2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . 18
2.1.1. Mobility Agent Advertisement Extension . . . . 20
2.1.2. Prefix-Lengths Extension . . . . . . . . . . . 22
2.1.3. One-byte Padding Extension . . . . . . . . . . 22
2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . 23
2.3. Foreign Agent and Home Agent Considerations . . . . . . 23
2.3.1. Advertised Router Addresses . . . . . . . . . . 24
2.3.2. Sequence Numbers and Rollover Handling . . . . 24
2.4. Mobile Node Considerations . . . . . . . . . . . . . . 25
2.4.1. Registration Required . . . . . . . . . . . . . 26
2.4.2. Move Detection . . . . . . . . . . . . . . . . 26
2.4.3. Returning Home . . . . . . . . . . . . . . . . 27
2.4.4. Sequence Numbers and Rollover Handling . . . . 28
3. Registration 28
3.1. Registration Overview . . . . . . . . . . . . . . . . . 29
3.2. Authentication . . . . . . . . . . . . . . . . . . . . 30
3.3. Registration Request . . . . . . . . . . . . . . . . . 30
3.4. Registration Reply . . . . . . . . . . . . . . . . . . 33
3.5. Registration Extensions . . . . . . . . . . . . . . . . 36
3.5.1. Computing Authentication Extension Values . . . 36
3.5.2. Mobile-Home Authentication Extension . . . . . 37
3.5.3. Mobile-Foreign Authentication Extension . . . . 37
3.5.4. Foreign-Home Authentication Extension . . . . . 38
3.6. Mobile Node Considerations . . . . . . . . . . . . . . 38
3.6.1. Sending Registration Requests . . . . . . . . . 40
3.6.2. Receiving Registration Replies . . . . . . . . 44
3.6.3. Registration Retransmission . . . . . . . . . . 47
3.7. Foreign Agent Considerations . . . . . . . . . . . . . 47
3.7.1. Configuration and Registration Tables . . . . . 48
3.7.2. Receiving Registration Requests . . . . . . . . 49
3.7.3. Receiving Registration Replies . . . . . . . . 52
3.8. Home Agent Considerations . . . . . . . . . . . . . . . 54
3.8.1. Configuration and Registration Tables . . . . . 55
3.8.2. Receiving Registration Requests . . . . . . . . 56
3.8.3. Sending Registration Replies . . . . . . . . . 59
4. Routing Considerations 62
4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . 62
4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . 62
4.2.1. Mobile Node Considerations . . . . . . . . . . 62
4.2.2. Foreign Agent Considerations . . . . . . . . . 63
4.2.3. Home Agent Considerations . . . . . . . . . . . 64
4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . 66
4.4. Multicast Datagram Routing . . . . . . . . . . . . . . 66
4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . 67
4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . 69
5. Security Considerations 73
Perkins Standards Track [Page 2]
RFC 3344 IP Mobility Support for IPv4 August 2002
5.1. Message Authentication Codes . . . . . . . . . . . . . 73
5.2. Areas of Security Concern in this Protocol . . . . . . 73
5.3. Key Management . . . . . . . . . . . . . . . . . . . . 74
5.4. Picking Good Random Numbers . . . . . . . . . . . . . . 74
5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6. Ingress Filtering . . . . . . . . . . . . . . . . . . . 75
5.7. Replay Protection for Registration Requests . . . . . . 75
5.7.1. Replay Protection using Timestamps . . . . . . 75
5.7.2. Replay Protection using Nonces . . . . . . . . 77
6. IANA Considerations 77
6.1. Mobile IP Message Types . . . . . . . . . . . . . . . . 78
6.2. Extensions to RFC 1256 Router Advertisement . . . . . . 78
6.3. Extensions to Mobile IP Registration Messages . . . . . 79
6.4. Code Values for Mobile IP Registration Reply
Messages. . . . . . . . . . . . . . . . . . . . . . 79
7. Acknowledgments 80
A. Patent Issues 82
B. Link-Layer Considerations 82
C. TCP Considerations 83
C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . 83
C.2. TCP Congestion Management . . . . . . . . . . . . . . . 83
D. Example Scenarios 84
D.1. Registering with a Foreign Agent Care-of Address . . . 84
D.2. Registering with a Co-Located Care-of Address . . . . . 84
D.3. Deregistration . . . . . . . . . . . . . . . . . . . . 85
E. Applicability of Prefix-Lengths Extension 86
F. Interoperability Considerations 86
G. Changes since RFC 2002 87
G.1. Major Changes . . . . . . . . . . . . . . . . . . . . . 87
G.2. Minor Changes . . . . . . . . . . . . . . . . . . . . . 89
G.3. Changes since revision 04 of RFC2002bis . . . . . . . . 91
H. Example Messages 92
H.1. Example ICMP Agent Advertisement Message Format . . . . 92
H.2. Example Registration Request Message Format . . . . . . 93
H.3. Example Registration Reply Message Format . . . . . . . 94
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 99
1. Introduction
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
be located on the network indicated by its IP address in order to
receive datagrams destined to it; otherwise, datagrams destined to
the node would be undeliverable. For a node to change its point of
attachment without losing its ability to communicate, currently one
of the two following mechanisms must typically be employed:
Perkins Standards Track [Page 3]
RFC 3344 IP Mobility Support for IPv4 August 2002
a) the node must change its IP address whenever it changes its
point of attachment, or
b) host-specific routes must be propagated throughout much of the
Internet routing fabric.
Both of these alternatives are often unacceptable. The first makes
it impossible for a node to maintain transport and higher-layer
connections when the node changes location. The second has obvious
and severe scaling problems, especially relevant considering the
explosive growth in sales of notebook (mobile) computers.
A new, scalable, mechanism is required for accommodating node
mobility within the Internet. This document defines such a
mechanism, which enables nodes to change their point of attachment to
the Internet without changing their IP address.
Changes between this revised specification for Mobile IP and the
original specifications (see [33, 32, 34, 43, 8]) are detailed in the
appendix section G.
1.1. Protocol Requirements
A mobile node must be able to communicate with other nodes after
changing its link-layer point of attachment to the Internet, yet
without changing its IP address.
A mobile node must be able to communicate with other nodes that do
not implement these mobility functions. No protocol enhancements are
required in hosts or routers that are not acting as any of the new
architectural entities introduced in Section 1.5.
All messages used to update another node as to the location of a
mobile node must be authenticated in order to protect against remote
redirection attacks.
1.2. Goals
The link by which a mobile node is directly attached to the Internet
may often be a wireless link. This link may thus have a
substantially lower bandwidth and higher error rate than traditional
wired networks. Moreover, mobile nodes are likely to be battery
powered, and minimizing power consumption is important. Therefore,
the number of administrative messages sent over the link by which a
mobile node is directly attached to the Internet should be minimized,
and the size of these messages should be kept as small as is
reasonably possible.
Perkins Standards Track [Page 4]
RFC 3344 IP Mobility Support for IPv4 August 2002
1.3. Assumptions
The protocols defined in this document place no additional
constraints on the assignment of IP addresses. That is, a mobile
node can be assigned an IP address by the organization that owns the
machine.
This protocol assumes that mobile nodes will generally not change
their point of attachment to the Internet more frequently than once
per second.
This protocol assumes that IP unicast datagrams are routed based on
the destination address in the datagram header (and not, for example,
by source address).
1.4. Applicability
Mobile IP is intended to enable nodes to move from one IP subnet to
another. It is just as suitable for mobility across homogeneous
media as it is for mobility across heterogeneous media. That is,
Mobile IP facilitates node movement from one Ethernet segment to
another as well as it accommodates node movement from an Ethernet
segment to a wireless LAN, as long as the mobile node's IP address
remains the same after such a movement.
One can think of Mobile IP as solving the "macro" mobility management
problem. It is less well suited for more "micro" mobility management
applications -- for example, handoff amongst wireless transceivers,
each of which covers only a very small geographic area. As long as
node movement does not occur between points of attachment on
different IP subnets, link-layer mechanisms for mobility (i.e.,
link-layer handoff) may offer faster convergence and far less
overhead than Mobile IP.
1.5. New Architectural Entities
Mobile IP introduces the following new functional entities:
Mobile Node
A host or router that changes its point of attachment from one
network or subnetwork to another. A mobile node may change its
location without changing its IP address; it may continue to
communicate with other Internet nodes at any location using its
(constant) IP address, assuming link-layer connectivity to a
point of attachment is available.
Perkins Standards Track [Page 5]
RFC 3344 IP Mobility Support for IPv4 August 2002
Home Agent
A router on a mobile node's home network which tunnels
datagrams for delivery to the mobile node when it is away from
home, and maintains current location information for the mobile
node.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -