draft-ietf-mobileip-ipv6-23.txt   draft-ietf-mobileip-ipv6-24.txt 
IETF Mobile IP Working Group D. Johnson IETF Mobile IP Working Group D. Johnson
Internet-Draft Rice University Internet-Draft Rice University
Expires: October 30, 2003 C. Perkins Expires: December 29, 2003 C. Perkins
Nokia Research Center Nokia Research Center
J. Arkko J. Arkko
Ericsson Ericsson
May 2003 June 30, 2003
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mobileip-ipv6-23.txt draft-ietf-mobileip-ipv6-24.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 30, 2003. This Internet-Draft will expire on December 29, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document specifies a protocol which allows nodes to remain This document specifies a protocol which allows nodes to remain
reachable while moving around in the IPv6 Internet. Each mobile node reachable while moving around in the IPv6 Internet. Each mobile node
is always identified by its home address, regardless of its current is always identified by its home address, regardless of its current
skipping to change at page 4, line 12 skipping to change at page 4, line 12
10.1 Conceptual Data Structures . . . . . . . . . . . . . 89 10.1 Conceptual Data Structures . . . . . . . . . . . . . 89
10.2 Processing Mobility Headers . . . . . . . . . . . . 90 10.2 Processing Mobility Headers . . . . . . . . . . . . 90
10.3 Processing Bindings . . . . . . . . . . . . . . . . 90 10.3 Processing Bindings . . . . . . . . . . . . . . . . 90
10.3.1 Primary Care-of Address Registration . . . . 90 10.3.1 Primary Care-of Address Registration . . . . 90
10.3.2 Primary Care-of Address De-Registration . . 94 10.3.2 Primary Care-of Address De-Registration . . 94
10.4 Packet Processing . . . . . . . . . . . . . . . . . 95 10.4 Packet Processing . . . . . . . . . . . . . . . . . 95
10.4.1 Intercepting Packets for a Mobile Node . . . 95 10.4.1 Intercepting Packets for a Mobile Node . . . 95
10.4.2 Processing Intercepted Packets . . . . . . . 97 10.4.2 Processing Intercepted Packets . . . . . . . 97
10.4.3 Multicast Membership Control . . . . . . . . 98 10.4.3 Multicast Membership Control . . . . . . . . 98
10.4.4 Stateful Address Autoconfiguration . . . . . 99 10.4.4 Stateful Address Autoconfiguration . . . . . 99
10.4.5 Handling Reverse Tunneled Packets . . . . . 100 10.4.5 Handling Reverse Tunneled Packets . . . . . 99
10.4.6 Protecting Return Routability Packets . . . 100 10.4.6 Protecting Return Routability Packets . . . 100
10.5 Dynamic Home Agent Address Discovery . . . . . . . .101 10.5 Dynamic Home Agent Address Discovery . . . . . . . .101
10.5.1 Receiving Router Advertisement Messages . . 101 10.5.1 Receiving Router Advertisement Messages . . 101
10.6 Sending Prefix Information to the Mobile Node . . .103 10.6 Sending Prefix Information to the Mobile Node . . .103
10.6.1 List of Home Network Prefixes . . . . . . . 103 10.6.1 List of Home Network Prefixes . . . . . . . 103
10.6.2 Scheduling Prefix Deliveries . . . . . . . . 104 10.6.2 Scheduling Prefix Deliveries . . . . . . . . 104
10.6.3 Sending Advertisements . . . . . . . . . . . 106 10.6.3 Sending Advertisements . . . . . . . . . . . 106
10.6.4 Lifetimes for Changed Prefixes . . . . . . . 107 10.6.4 Lifetimes for Changed Prefixes . . . . . . . 107
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . 108 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . 108
11.1 Conceptual Data Structures . . . . . . . . . . . . .108 11.1 Conceptual Data Structures . . . . . . . . . . . . .108
skipping to change at page 61, line 50 skipping to change at page 61, line 50
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The Mobile Prefix Advertisement messages may have options. These The Mobile Prefix Advertisement messages may have options. These
options MUST use the option format defined in RFC 2461 [12]. This options MUST use the option format defined in RFC 2461 [12]. This
document defines one option which may be carried in a Mobile Prefix document defines one option which may be carried in a Mobile Prefix
Advertisement message, but future documents may define new options. Advertisement message, but future documents may define new options.
Home agents MUST silently ignore any options they do not recognize Mobile nodes MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message.
Prefix Information Prefix Information
Each message contains one or more Prefix Information options. Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node should use Each option carries the prefix(es) that the mobile node should use
to configure its home address(es). Section 10.6 describes which to configure its home address(es). Section 10.6 describes which
prefixes should be advertised to the mobile node. prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2 of RFC The Prefix Information option is defined in Section 4.6.2 of RFC
skipping to change at page 90, line 46 skipping to change at page 90, line 46
the following sequence of tests: the following sequence of tests:
o If the node implements only correspondent node functionality, or o If the node implements only correspondent node functionality, or
has not been configured to act as a home agent, then the node MUST has not been configured to act as a home agent, then the node MUST
reject the Binding Update. The node MUST then also return a reject the Binding Update. The node MUST then also return a
Binding Acknowledgement to the mobile node, in which the Status Binding Acknowledgement to the mobile node, in which the Status
field is set to 131 (home registration not supported). field is set to 131 (home registration not supported).
o Else, if the home address for the binding (the Home Address field o Else, if the home address for the binding (the Home Address field
in the packet's Home Address option) is not an on-link IPv6 in the packet's Home Address option) is not an on-link IPv6
address with respect to the home agent's current Prefix List or if address with respect to the home agent's current Prefix List, then
the corresponding prefix was not included in an advertisement sent the home agent MUST reject the Binding Update and SHOULD return a
with the Home Agent (H) bit set, then the home agent MUST reject Binding Acknowledgement to the mobile node, in which the Status
the Binding Update and SHOULD return a Binding Acknowledgement to field is set to 132 (not home subnet).
the mobile node, in which the Status field is set to 132 (not home
subnet).
o Else, if the home agent chooses to reject the Binding Update for o Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for field is set to an appropriate value to indicate the reason for
the rejection. the rejection.
o A Home Address destination option MUST be present in the message. o A Home Address destination option MUST be present in the message.
It MUST be validated as described in Section 9.3.1 with the It MUST be validated as described in Section 9.3.1 with the
skipping to change at page 164, line 24 skipping to change at page 164, line 24
[19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an [19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an
On-line Database", RFC 3232, January 2002. On-line Database", RFC 3232, January 2002.
[20] National Institute of Standards and Technology, "Secure Hash [20] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http:// Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>. www.itl.nist.gov/fipspubs/fip180-1.htm>.
[21] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to [21] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling betweenMobile Nodes and Home Protect Mobile IPv6 Signaling betweenMobile Nodes and Home
Agents", draft-ietf-mobileip-mipv6-ha-ipsec-05 (work in Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in
progress), May 2003. progress), June 2003.
Informative References Informative References
[22] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [22] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[23] Perkins, C., "IP Encapsulation within IP", RFC 2003, October [23] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996. 1996.
[24] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [24] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
skipping to change at page 167, line 9 skipping to change at page 167, line 9
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
Appendix A. Changes from Previous Version of the Draft Appendix A. Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this draft This appendix briefly lists some of the major changes in this draft
relative to the previous version of this same draft, relative to the previous version of this same draft,
draft-ietf-mobileip-ipv6-22.txt: draft-ietf-mobileip-ipv6-23.txt:
o A new set of rules regarding the use of automatic or manual key
management has been provided (tracked issue 313).
o Rules regarding the use of the Key Management Capability (K) bit o A typo in Section 6.8 has been corrected; rules regarding
have been corrected for the manual keying case (tracked issue reception of Mobile Prefix Advertisements apply to mobile nodes,
310). not home agents (tracked issue 317).
o The specification now requires that a small MaxRtrAdvertisement o A sentence has been removed from Section 10.3.1, since it dealt
value should not lead to a router lifetime value under one second with the tracking of router advertisements by other home agents,
(tracked issue 308). which is a function that was already removed earlier in an IESG
review (tracked issue 316).
Appendix B. Future Extensions Appendix B. Future Extensions
B.1 Piggybacking B.1 Piggybacking
This document does not specify how to piggyback payload packets on This document does not specify how to piggyback payload packets on
the binding related messages. However, it is envisioned that this the binding related messages. However, it is envisioned that this
can be specified in a separate document when currently discussed can be specified in a separate document when currently discussed
issues such as the interaction between piggybacking and IPsec are issues such as the interaction between piggybacking and IPsec are
fully resolved (see also Appendix B.3). The return routability fully resolved (see also Appendix B.3). The return routability
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/