draft-ietf-mobileip-ipv6-14.txt   draft-ietf-mobileip-ipv6-15.txt 
IETF Mobile IP Working Group David B. Johnson IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Rice University INTERNET-DRAFT Rice University
Charles Perkins Charles Perkins
Nokia Research Center Nokia Research Center
2 July 2000 2 July 2001
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-14.txt> <draft-ietf-mobileip-ipv6-15.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 RFC 2026. all provisions of Section 10 of RFC 2026.
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 Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 67 skipping to change at page 1, line 67
2. Comparison with Mobile IP for IPv4 3 2. Comparison with Mobile IP for IPv4 3
3. Terminology 6 3. Terminology 6
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7
4. Overview of Mobile IPv6 8 4. Overview of Mobile IPv6 8
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11
4.3. Alignment Requirements for New Destination Options . . . 12 4.3. Alignment Requirements for New Destination Options . . . 12
4.4. Authentication Requirements for New Destination Options . 13 4.4. Authentication Requirements for Binding Update and
Acknowledgement . . . . . . . . . . . . . . . . . . . 13
4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14 4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14
4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 15 4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 15
4.7. Binding Management . . . . . . . . . . . . . . . . . . . 19 4.7. Binding Management . . . . . . . . . . . . . . . . . . . 20
4.8. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 21
5. New IPv6 Destination Options and Message Types 22 5. New IPv6 Destination Options and Message Types 22
5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 22 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 22
5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 27 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 26
5.3. Binding Request Option . . . . . . . . . . . . . . . . . 32 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 30
5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 34 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 32
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 37 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 35
5.6. ICMP Home Agent Address Discovery Request Message . . . . 41 5.5.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . 36
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 43 5.5.2. PadN . . . . . . . . . . . . . . . . . . . . . . 36
5.8. ICMP Mobile Prefix Solicitation Message Format . . . . . 45 5.5.3. Unique Identifier . . . . . . . . . . . . . . . . 37
5.9. ICMP Mobile Prefix Advertisement Message Format . . . . . 47 5.5.4. Alternate Care-of Address . . . . . . . . . . . . 37
5.6. Authentication Data . . . . . . . . . . . . . . . . . . . 38
6. Modifications to IPv6 Neighbor Discovery 49 5.7. ICMP Home Agent Address Discovery Request Message . . . . 40
6.1. Modified Router Advertisement Message Format . . . . . . 49 5.8. ICMP Home Agent Address Discovery Reply Message . . . . . 41
6.2. Modified Prefix Information Option Format . . . . . . . . 50 5.9. ICMP Mobile Prefix Solicitation Message Format . . . . . 43
6.3. New Advertisement Interval Option Format . . . . . . . . 52 5.10. ICMP Mobile Prefix Advertisement Message Format . . . . . 45
6.4. New Home Agent Information Option Format . . . . . . . . 53
6.5. Changes to Sending Router Advertisements . . . . . . . . 55
6.6. Changes to Sending Router Solicitations . . . . . . . . . 56
7. Requirements for Types of IPv6 Nodes 58 6. Modifications to IPv6 Neighbor Discovery 47
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 58 6.1. Modified Router Advertisement Message Format . . . . . . 47
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 58 6.2. Modified Prefix Information Option Format . . . . . . . . 48
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 58 6.3. New Advertisement Interval Option Format . . . . . . . . 50
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 59 6.4. New Home Agent Information Option Format . . . . . . . . 51
8. Correspondent Node Operation 61 6.5. Changes to Sending Router Advertisements . . . . . . . . 53
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 61 6.6. Changes to Sending Router Solicitations . . . . . . . . . 54
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 61 7. Requirements for Types of IPv6 Nodes 56
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 62 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 56
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 63 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 56
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 63 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 56
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 63 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 57
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 64 8. Correspondent Node Operation 59
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 65 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 59
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 66 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 59
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 60
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 61
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 61
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 62
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 62
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 63
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 64
9. Home Agent Operation 68 9. Home Agent Operation 67
9.1. Primary Care-of Address Registration . . . . . . . . . . 68 9.1. Primary Care-of Address Registration . . . . . . . . . . 67
9.2. Primary Care-of Address De-registration . . . . . . . . . 71 9.2. Primary Care-of Address De-registration . . . . . . . . . 69
9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 71 9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 70
9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 73 9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 72
9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 75 9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 73
9.6. Home Prefix Propagation . . . . . . . . . . . . . . . . . 75 9.6. Home Prefix Propagation . . . . . . . . . . . . . . . . . 74
9.7. Receiving Router Advertisement Messages . . . . . . . . . 75 9.7. Receiving Router Advertisement Messages . . . . . . . . . 74
9.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 77 9.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 76
9.8.1. Aggregate List of Home Network Prefixes . . . . . 78 9.8.1. Aggregate List of Home Network Prefixes . . . . . 77
9.8.2. Scheduling Prefix Deliveries to the Mobile Node . 80 9.8.2. Scheduling Prefix Deliveries to the Mobile Node . 79
9.8.3. Sending Advertisements to the Mobile Node . . . . 81 9.8.3. Sending Advertisements to the Mobile Node . . . . 80
9.8.4. Lifetimes for Changed Prefixes . . . . . . . . . 83 9.8.4. Lifetimes for Changed Prefixes . . . . . . . . . 82
10. Mobile Node Operation 84 10. Mobile Node Operation 83
10.1. Sending Packets While Away from Home . . . . . . . . . . 84 10.1. Sending Packets While Away from Home . . . . . . . . . . 83
10.2. Interaction with Outbound IPsec Processing . . . . . . . 85 10.2. Interaction with Outbound IPsec Processing . . . . . . . 84
10.3. Receiving Packets While Away from Home . . . . . . . . . 87 10.3. Receiving Packets While Away from Home . . . . . . . . . 86
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 88 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 87
10.5. Receiving Local Router Advertisement Messages . . . . . . 91 10.5. Receiving Local Router Advertisement Messages . . . . . . 90
10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 92 10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 91
10.7. Sending Binding Updates to the Home Agent . . . . . . . . 94 10.7. Sending Binding Updates to the Home Agent . . . . . . . . 93
10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 96 10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 95
10.9. Sending Binding Updates to Correspondent Nodes . . . . . 97 10.9. Sending Binding Updates to Correspondent Nodes . . . . . 96
10.10. Establishing Forwarding from a Previous Care-of Address . 99 10.10. Establishing Forwarding from a Previous Care-of Address . 99
10.11. Retransmitting Binding Updates . . . . . . . . . . . . . 100 10.11. Retransmitting Binding Updates . . . . . . . . . . . . . 100
10.12. Rate Limiting for Sending Binding Updates . . . . . . . . 101 10.12. Rate Limiting for Sending Binding Updates . . . . . . . . 100
10.13. Receiving Binding Acknowledgements . . . . . . . . . . . 101 10.13. Receiving Binding Acknowledgements . . . . . . . . . . . 101
10.14. Receiving Binding Requests . . . . . . . . . . . . . . . 103 10.14. Receiving Binding Requests . . . . . . . . . . . . . . . 102
10.15. Receiving ICMP Error Messages . . . . . . . . . . . . . . 103 10.15. Receiving ICMP Error Messages . . . . . . . . . . . . . . 102
10.16. Sending Mobile Prefix Solicitations . . . . . . . . . . . 104 10.16. Sending Mobile Prefix Solicitations . . . . . . . . . . . 103
10.17. Receiving Mobile Prefix Advertisements . . . . . . . . . 104 10.17. Receiving Mobile Prefix Advertisements . . . . . . . . . 104
10.18. Using Multiple Care-of Addresses . . . . . . . . . . . . 105 10.18. Using Multiple Care-of Addresses . . . . . . . . . . . . 105
10.19. Routing Multicast Packets . . . . . . . . . . . . . . . . 106 10.19. Routing Multicast Packets . . . . . . . . . . . . . . . . 105
10.20. Returning Home . . . . . . . . . . . . . . . . . . . . . 106 10.20. Returning Home . . . . . . . . . . . . . . . . . . . . . 106
11. Protocol Constants 108 11. Protocol Constants 108
12. IANA Considerations 110 12. IANA Considerations 109
13. Security Considerations 112 13. Security Considerations 111
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 112 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 111
13.2. Security for the Home Address Option . . . . . . . . . . 112 13.2. Security for the Home Address Option . . . . . . . . . . 111
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 113 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 112
Acknowledgements 113 Acknowledgements 113
References 115 References 114
A. Changes from Previous Version of the Draft 116 A. Changes from Previous Version of the Draft 115
A.1. Changes from Draft Version ...-14 . . . . . . . . . . . . 115
A.2. Changes from Previous Versions of the Draft . . . . . . . 117
B. Remote Home Address Configuration 117 B. Remote Home Address Configuration 118
Chairs' Addresses 119 Chairs' Addresses 119
Authors' Addresses 120 Authors' Addresses 120
1. Introduction 1. Introduction
This document specifies the operation of mobile computers using This document specifies the operation of mobile computers using
Internet Protocol Version 6 (IPv6) [6]. Without specific support Internet Protocol Version 6 (IPv6) [6]. Without specific support
for mobility in IPv6, packets destined to a mobile node (host or for mobility in IPv6, packets destined to a mobile node (host or
skipping to change at page 11, line 27 skipping to change at page 11, line 27
Binding Update Binding Update
A Binding Update option is used by a mobile node to notify A Binding Update option is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked home agent to register its primary care-of address is marked
as a "home registration". Any packet that includes a Binding as a "home registration". Any packet that includes a Binding
Update option MUST be protected by some authentication data Update option MUST be protected by some authentication data
(see section 5.1), as defined in Section 4.4, to guard against (see section 5.1), as defined in Section 4.4, to guard against
malicious Binding Updates. The Binding Update option and malicious Binding Updates. The Binding Update option and its
its specific IPsec requirements are described in detail in specific authentication requirements are described in detail in
Section 5.1. Section 5.1.
Binding Acknowledgement Binding Acknowledgement
A Binding Acknowledgement option is used to acknowledge receipt A Binding Acknowledgement option is used to acknowledge receipt
of a Binding Update, if an acknowledgement was requested of a Binding Update, if an acknowledgement was requested
in the Binding Update. Any packet that includes a Binding in the Binding Update. Any packet that includes a Binding
Acknowledgement option MUST be protected by some authentication Acknowledgement option MUST be protected by some authentication
data (see section 5.2), as defined in Section 4.4, to guard data (see section 5.2), as defined in Section 4.4, to guard
against malicious Binding Acknowledgements. The Binding against malicious Binding Acknowledgements. The Binding
Acknowledgement option and its specific IPsec requirements are Acknowledgement option and its specific authentication
described in detail in Section 5.2. requirements are described in detail in Section 5.2.
Binding Request Binding Request
A Binding Request option is used to request a mobile node to A Binding Request option is used to request a mobile node to
send to the requesting node a Binding Update containing the send to the requesting node a Binding Update containing the
mobile node's current binding. This option is typically used mobile node's current binding. This option is typically used
by a correspondent node to refresh a cached binding for a by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the mobile node, when the cached binding is in active use but the
binding's lifetime is close to expiration. No authentication binding's lifetime is close to expiration. No authentication
is required for the Binding Request option. The Binding is required for the Binding Request option. The Binding
skipping to change at page 13, line 5 skipping to change at page 13, line 5
alignment requirements [6]. Specifically, the notation xn+y means alignment requirements [6]. Specifically, the notation xn+y means
that the Option Type or Sub-Option Type field must fall at an integer that the Option Type or Sub-Option Type field must fall at an integer
multiple of x octets from the start of the header, plus y octets. multiple of x octets from the start of the header, plus y octets.
For example: For example:
2n means any 2-octet offset from the start of the header. 2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header, 8n+2 means any 8-octet offset from the start of the header,
plus 2 octets. plus 2 octets.
4.4. Authentication Requirements for New Destination Options 4.4. Authentication Requirements for Binding Update and Acknowledgement
Any packet that includes a Binding Update or Binding Acknowledgement Any packet that includes a Binding Update or Binding Acknowledgement
option has to contain some Authentication Data to guard against option has to contain some Authentication Data to guard against
malicious Binding Updates or Acknowledgements. The way that the malicious Binding Updates or Acknowledgements. The way that
Authentication Data is computed has to provide sender authentication, the Authentication Data is computed has to provide sender
data integrity protection, and replay protection. authentication, data integrity protection, and replay protection.
This section specifies requirements for which data is to be protected
when the Authentication Data Sub-Option is used to supply the
necessary authentication data for the Binding Update or Binding
Acknowledgement. Every IPv6 node which supports transmission or
reception of these destination options MUST support the computation
of the Authentication Data Sub-Option according to the rules in
this section. The Authentication Data Sub-Option MUST be the last
Sub-Option contained within any destination option in which the
Authentication Data Sub-Option occurs.
Mobile IPv6 requires that the Authentication Data covering a Binding The Authentication Data covering a Binding Update or MUST be computed
Update or MUST be computed over a bitstring containing the following over a bitstring containing the following fields of the IPv6 header
fields of the IPv6 header and destination options, in order: and destination options, in order:
Destination IP Address of the IPv6 header - The IPv6 address of the destination of the packet, as seen by the
Care-of Address, in the Source IP Address of the IPv6 header recipient
Home Address, from the Home Address destination option - Care-of Address, in the Source IP Address of the IPv6 header
Option Type of the Binding Update destination option - The Home Address of the mobile node, from the Home Address
Option Length of the Binding Update destination option destination option
All flags of the Binding Update destination option - Option Type of the Binding Update destination option
Reserved Field of the Binding Update destination option - Option Length of the Binding Update destination option
7-bit Prefix Length of the Binding Update destination option - All flags of the Binding Update destination option
Authentication Data Length of the Binding Update - Reserved Field of the Binding Update destination option
Lifetime of the Binding Update destination option - Sequence Number Field of the Binding Update
Security Parameters Index (SPI) of the Binding Update - Lifetime of the Binding Update destination option
Sequence Number Field of the Binding Update - The entire data from all Binding Update Sub-Options (except the
The entire data from all Binding Update Sub-Options, if any Authentication Data suboption), if any others exist
- The Type (i.e., the 8-bit value 0x04) and the Length of the
Authentication Data Sub-Option
- Security Parameters Index (SPI) of the Authentication Data
Sub-Option
Mobile IPv6 requires that the Authentication Data covering a Binding When a Routing Header is used to deliver the Binding Update to
Acknowledgement MUST be computed over a bitstring containing the the receiving node, the address to be used for the Destination IP
following data, in order: Address part of the computation will initially be located as the last
component of the Routing Header. Otherwise, the address to be used
will be the Destination IP Address in the IPv6 header of the outgoing
packet.
Destination IP Address of the IPv6 header When the Authentication Data Sub-Option is used with a Binding
Source IP Address of the IPv6 header Acknowledgement, the Authentication Data MUST be computed over a
Option Type of the Binding Acknowledgement destination bitstring containing the following data, in order:
option
Option Length of the Binding Acknowledgement - The IPv6 address of the destination of the packet, as seen by the
Status of the Binding Acknowledgement recipient
Authentication Data Length of the Binding Acknowledgement - The Home Address of the sender
Lifetime of the Binding Acknowledgement destination option - Option Type of the Binding Acknowledgement destination option
Security Parameters Index (SPI) of the Binding - Option Length of the Binding Acknowledgement
Acknowledgement - Status of the Binding Acknowledgement
Sequence Number Field of the Binding Acknowledgement - Sequence Number field of the Binding Acknowledgement
The entire data from all Binding Acknowledgement - Lifetime field of the Binding Acknowledgement destination option
Sub-Options, if any - Refresh field of the Binding Acknowledgement destination option
- The entire data from all Binding Acknowledgement Sub-Options
(except the Authentication Data suboption), if any others exist
- The Type (i.e., the 8-bit value 0x04) and the Length of the
Authentication Data Sub-Option
- Security Parameters Index (SPI) of the Authentication Data
Sub-Option
When a Home Address destination option is used to deliver the Binding
Acknowledgement to the receiving node, the Home Address of the sender
will be located in that destination option. Otherwise, the Home
Address of the sender will be located in the Source IP Address field
of the IPv6 header.
If a Security Association applied to the packet for other reasons If a Security Association applied to the packet for other reasons
requires use of ESP [12], for example to encrypt the transport layer requires use of ESP [12], for example to encrypt the transport layer
data carried in the packet, this use of ESP is not sufficient to data carried in the packet, this use of ESP is not sufficient to
satisfy the authentication requirements of Mobile IPv6. satisfy the authentication requirements of Mobile IPv6.
Authentication Data assuring the integrity of Binding Updates and
Binding Acknowledgement MAY, in some cases, instead be supplied by
other authentication mechanisms outside the scope of this document
(e.g., IPsec [13]). When alternative mechanisms are used, the same
data as indicated above MUST be included as part of the input data
stream for the authentication algorithm; however (according to the
requirements of the alternative authentication algorithm) the order
of the data elements in the input data stream MAY be changed from the
order specified within this section for use with the Authentication
Data Sub-Option (see section 5.5).
4.5. New IPv6 ICMP Messages 4.5. New IPv6 ICMP Messages
Mobile IPv6 also introduces four new ICMP message types, two for use Mobile IPv6 also introduces four new ICMP message types, two for use
in the dynamic home agent address discovery mechanism, and two for in the dynamic home agent address discovery mechanism, and two for
renumbering and mobile configuration mechanisms. As discussed in renumbering and mobile configuration mechanisms. As discussed in
general in Section 4.1, the following two new ICMP message types are general in Section 4.1, the following two new ICMP message types are
used for home agent address discovery: used for home agent address discovery:
Home Agent Address Discovery Request Home Agent Address Discovery Request
The ICMP Home Agent Address Discovery Request message is used The ICMP Home Agent Address Discovery Request message is used
by a mobile node to initiate the dynamic home agent address by a mobile node to initiate the dynamic home agent address
discovery mechanism. When attempting a home registration, the discovery mechanism. When attempting a home registration, the
mobile node may use this mechanism to discover the address of mobile node may use this mechanism to discover the address of
one or more routers currently operating as home agents on its one or more routers currently operating as home agents on its
home link, with which it may register while away from home. home link, with which it may register while away from home.
The Home Agent Address Discovery Request message is described The Home Agent Address Discovery Request message is described
in detail in Section 5.6. in detail in Section 5.7.
Home Agent Address Discovery Reply Home Agent Address Discovery Reply
The ICMP Home Agent Address Discovery Reply message is used by The ICMP Home Agent Address Discovery Reply message is used by
a home agent to respond to a mobile node using the dynamic home a home agent to respond to a mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is agents. The Home Agent Address Discovery Reply message is
described in detail in Section 5.7. described in detail in Section 5.8.
The next two message types are used for network renumbering The next two message types are used for network renumbering
and address configuration on the mobile node, as described in and address configuration on the mobile node, as described in
Section 9.6: Section 9.6:
Mobile Prefix Solicitation Mobile Prefix Solicitation
The ICMP Mobile Prefix Solicitation message is used by a mobile The ICMP Mobile Prefix Solicitation message is used by a mobile
node to request prefix information about the home subnet, in node to request prefix information about the home subnet, in
order to retrieve prefixes that are served by home agents and order to retrieve prefixes that are served by home agents and
can be used to configure one or more home addresses, or to can be used to configure one or more home addresses, or to
refresh home addresses before the expiration of their validity. refresh home addresses before the expiration of their validity.
This message is specified in Section 5.8. This message is specified in Section 5.9.
Mobile Prefix Advertisement Mobile Prefix Advertisement
The ICMP Mobile Prefix Advertisement is used by a home agent to The ICMP Mobile Prefix Advertisement is used by a home agent to
distribute information to a mobile node about prefixes on the distribute information to a mobile node about prefixes on the
home link which are available for use by the mobile node while home link which are available for use by the mobile node while
away from home. This message may be sent as a response to a away from home. This message may be sent as a response to a
Mobile Prefix Solicitation, or due to network renumbering or Mobile Prefix Solicitation, or due to network renumbering or
other prefix changes as specified in Section 5.9 other prefix changes as specified in Section 5.10
4.6. Conceptual Data Structures 4.6. Conceptual Data Structures
This document describes the Mobile IPv6 protocol in terms of the This document describes the Mobile IPv6 protocol in terms of the
following three conceptual data structures: following three conceptual data structures:
Binding Cache Binding Cache
A cache, maintained by each IPv6 node, of bindings for other A cache, maintained by each IPv6 node, of bindings for other
nodes. A separate Binding Cache SHOULD be maintained by each nodes. A separate Binding Cache SHOULD be maintained by each
skipping to change at page 16, line 7 skipping to change at page 16, line 47
- A flag indicating whether or not this Binding Cache entry - A flag indicating whether or not this Binding Cache entry
is a "home registration" entry. is a "home registration" entry.
- A flag indicating whether or not this Binding Cache entry - A flag indicating whether or not this Binding Cache entry
represents a mobile node that should be advertised as a represents a mobile node that should be advertised as a
router in proxy Neighbor Advertisements sent by this node router in proxy Neighbor Advertisements sent by this node
on its behalf. This flag is only valid if the Binding on its behalf. This flag is only valid if the Binding
Cache entry indicates that this is a "home registration" Cache entry indicates that this is a "home registration"
entry. entry.
- The value of the Prefix Length field received in the - The length of the routing prefix for the home address.
Binding Update that created or last modified this Binding This field is only valid if the "home registration" flag is
Cache entry. This field is only valid if the "home set on this Binding Cache entry.
registration" flag is set on this Binding Cache entry.
- The maximum value of the Sequence Number field received - The maximum value of the Sequence Number field received
in previous Binding Updates for this mobile node home in previous Binding Updates for this mobile node home
address. The Sequence Number field is 8 bits long, address. The Sequence Number field is 8 bits long,
and all comparisons between Sequence Number values and all comparisons between Sequence Number values
MUST be performed modulo 2**8. For example, using an MUST be performed modulo 2**8. For example, using an
implementation in the C programming language, a Sequence implementation in the C programming language, a Sequence
Number value A is greater than another Sequence Number Number value A is greater than another Sequence Number
value B if ((int)((a) - (b)) > 0), if the "int" data type value B if ((char)((a) - (b)) > 0), if the "int" data type
is a 8-bit signed integer. is a 8-bit signed integer.
- Recent usage information for this Binding Cache entry, as - Recent usage information for this Binding Cache entry, as
needed to implement the cache replacement policy in use in needed to implement the cache replacement policy in use in
the Binding Cache and to assist in determining whether a the Binding Cache and to assist in determining whether a
Binding Request should be sent when the lifetime on this Binding Request should be sent when the lifetime on this
entry nears expiration. entry nears expiration.
- The Binding Security Association (BSA) to be be used when - The Binding Security Association (BSA) to be be used when
authenticating Binding Updates that are received for this authenticating Binding Updates that are received for this
skipping to change at page 18, line 5 skipping to change at page 18, line 44
Update and is decremented until it reaches zero, at which Update and is decremented until it reaches zero, at which
time this entry MUST be deleted from the Binding Update time this entry MUST be deleted from the Binding Update
List. List.
- The maximum value of the Sequence Number field sent in - The maximum value of the Sequence Number field sent in
previous Binding Updates to this destination. The Sequence previous Binding Updates to this destination. The Sequence
Number field is 8 bits long, and all comparisons between Number field is 8 bits long, and all comparisons between
Sequence Number values MUST be performed modulo 2**8. For Sequence Number values MUST be performed modulo 2**8. For
example, using an implementation in the C programming example, using an implementation in the C programming
language, a Sequence Number value A is greater than another language, a Sequence Number value A is greater than another
Sequence Number value B if ((int)((a) - (b)) > 0), if the Sequence Number value B if ((char)((a) - (b)) > 0), if the
"int" data type is a 8-bit signed integer. "char" data type is a 8-bit signed integer.
- The time at which a Binding Update was last sent to this - The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting destination, as needed to implement the rate limiting
restriction for sending Binding Updates. restriction for sending Binding Updates.
- The state of any retransmissions needed for this Binding - The state of any retransmissions needed for this Binding
Update, if the Acknowledge (A) bit was set in this Binding Update, if the Acknowledge (A) bit was set in this Binding
Update. This state includes the time remaining until the Update. This state includes the time remaining until the
next retransmission attempt for the Binding Update, and the next retransmission attempt for the Binding Update, and the
current state of the exponential back-off mechanism for current state of the exponential back-off mechanism for
skipping to change at page 21, line 21 skipping to change at page 22, line 8
scalability and reliability, and for minimizing overall network load. scalability and reliability, and for minimizing overall network load.
By caching the care-of address of a mobile node, optimal routing of By caching the care-of address of a mobile node, optimal routing of
packets can be achieved from the correspondent node to the mobile packets can be achieved from the correspondent node to the mobile
node. Routing packets directly to the mobile node's care-of address node. Routing packets directly to the mobile node's care-of address
also eliminates congestion at the mobile node's home agent and home also eliminates congestion at the mobile node's home agent and home
link. In addition, the impact of any possible failure of the home link. In addition, the impact of any possible failure of the home
agent, the home link, or intervening networks leading to or from the agent, the home link, or intervening networks leading to or from the
home link is reduced, since these nodes and links are not involved in home link is reduced, since these nodes and links are not involved in
the delivery of most packets to the mobile node. the delivery of most packets to the mobile node.
4.8. Mobile Routers
If a router is itself mobile, and it has acquired a new care-of
address, then that new care-of address should be used by the home
agent for the mobile router, and also to tunnel packets for any home
address that matches the routing prefixes advertised by the mobile
router. The simplest way to do this is for the mobile router to
tell the home agent about the prefix length of the network (and,
consequently, subnets with longer prefixes) being served by the
mobile router. For this purpose, the Mobile Router Prefix Length
Sub-option has been specified (see section 5.5).
This information may be supplied by the mobile router to any
correspondent node; there is no restriction that it be sent only
to Home Agents. However, unless the recipient is itself a router,
it may not have the necessary processing capabilities to make the
entries into its Binding Cache to cover all the matching necessary
for the implied range of Home Addresses. Thus, the sender MUST
be prepared to cease supplying the Mobile Router Prefix Length
Sub-Option to nodes that send back a negative status as part of a
Binding Acknowledgement.
5. New IPv6 Destination Options and Message Types 5. New IPv6 Destination Options and Message Types
5.1. Binding Update Option 5.1. Binding Update Option
The Binding Update destination option is used by a mobile node The Binding Update destination option is used by a mobile node
to notify other nodes of a new care-of address for itself. As a to notify other nodes of a new care-of address for itself. As a
destination option, it MAY be included in any existing packet being destination option, it MAY be included in any existing packet being
sent to this same destination or MAY be sent in a packet by itself; sent to this same destination or MAY be sent in a packet by itself;
a packet containing a Binding Update is sent in the same way as any a packet containing a Binding Update is sent in the same way as any
packet sent by a mobile node (Section 10.1). packet sent by a mobile node (Section 10.1).
The Binding Update option is encoded in type-length-value (TLV) The Binding Update option is encoded in type-length-value (TLV)
format as follows: format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R|D| Reservd |Prefix Length|AuthData Length| Sequence # | |A|H|S|D| Reserved | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =
= Authentication Data (variable length) =
= =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options... | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
198 = 0xC6 198 = 0xC6
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
skipping to change at page 23, line 14 skipping to change at page 23, line 14
Home Registration (H) Home Registration (H)
The Home Registration (H) bit is set by the sending mobile node The Home Registration (H) bit is set by the sending mobile node
to request the receiving node to act as this node's home agent. to request the receiving node to act as this node's home agent.
The destination of the packet carrying this option MUST be that The destination of the packet carrying this option MUST be that
of a router sharing the same subnet prefix as the home address of a router sharing the same subnet prefix as the home address
of the mobile node in the binding (given by the Home Address of the mobile node in the binding (given by the Home Address
field in the Home Address option in the packet). field in the Home Address option in the packet).
Router (R) Single Address Only (S)
The Router (R) bit, when set, indicates that the sending If the `S' bit is set, the mobile node requests that the home
mobile node is a router. This bit is only valid when the agent make no changes to any other Binding Cache entry except
Home Registration (H) bit is also set, and MUST NOT be set for the particular one containing the home address specified in
otherwise. This bit is saved in the home agent's "home the Home Address option. This disables home agent processing
registration" Binding Cache entry for the mobile node, and for other related addresses, as is described in section 9.1.
is copied into the corresponding bit in all proxy Neighbor
Advertisement messages sent on behalf of this mobile node by
the home agent using this Binding Cache entry.
Duplicate Address Detection (D) Duplicate Address Detection (D)
The Duplicate Address Detection (D) bit is set by the sending The Duplicate Address Detection (D) bit is set by the sending
mobile node to request the receiving node (the mobile node's mobile node to request the receiving node (the mobile node's
home agent) to perform Duplicate Address Detection [27] on home agent) to perform Duplicate Address Detection [27] on
the mobile node's home link for the home address in this the mobile node's home link for the home address in this
binding. This bit is only valid when the Home Registration (H) binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. If the Duplicate Address Detection performed by otherwise. If the Duplicate Address Detection performed by
the home agent fails, the Status field in the returned Binding the home agent fails, the Status field in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection Acknowledgement will be set to 138 (Duplicate Address Detection
failed). failed).
Reservd 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.
Prefix Length
The 7-bit Prefix Length field is valid only for a "home
registration" Binding Update; this field MUST be zero if the
Home Registration (H) bit is not set in the Binding Update.
The Prefix Length field is set by the sending mobile node to
the (nonzero) length of its subnet prefix in its home address
(given in the Home Address option in the packet) to request
its home agent to use the interface identifier in the mobile
node's home address (the remaining low-order bits after the
indicated subnet prefix) to form all other home addresses for
the mobile node on the home link. The home agent becomes the
home agent not only for the individual home address given in
this binding, but also for all other home addresses for this
mobile node formed from this interface identifier. That is,
for each on-link prefix on the home link, the home agent uses
the interface identifier to form other valid addresses for
the mobile node on the home link, and acts as a home agent
also for those addresses. In addition, the home agent forms
the link-local address and site-local address corresponding
to this interface identifier, and defends each for purposes
of Duplicate Address Detection. The home agent also performs
Duplicate Address Detection on at least one such address as
part of the home registration processing (before returning
the Binding Acknowledgement), if the Duplicate Address
Detection (D) bit is set in the Binding Update; it is not
necessary to perform Duplicate Address Detection individually
on each of these addresses, since address uniqueness here is
determined solely by the interface identifier [27]. Details of
this operation are described in Section 9.1.
AuthDataLength
The length of the Authentication Data field in octets.
Sequence # Sequence #
An 8-bit number sed by the receiving node to sequence Binding An 8-bit number used by the receiving node to sequence Binding
Updates and by the sending node to match a returned Binding Updates and by the sending node to match a returned Binding
Acknowledgement with this Binding Update. Each Binding Update Acknowledgement with this Binding Update. Each Binding Update
sent by a mobile node MUST use a Sequence Number greater than sent by a mobile node MUST use a Sequence Number greater than
the Sequence Number value sent in the previous Binding Update the Sequence Number value sent in the previous Binding Update
(if any) to the same destination address (modulo 2**8, as (if any) to the same destination address (modulo 2**8, as
defined in Section 4.6). There is no requirement, however, defined in Section 4.6). There is no requirement, however,
that the Sequence Number value strictly increase by 1 with each that the Sequence Number value strictly increase by 1 with each
new Binding Update sent or received. new Binding Update sent or received.
Lifetime Lifetime
32-bit unsigned integer. The number of seconds remaining 32-bit unsigned integer. The number of seconds remaining
before the binding MUST be considered expired. A value of all before the binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value of zero one bits (0xffffffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node MUST indicates that the Binding Cache entry for the mobile node MUST
be deleted. be deleted.
Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that, in combination with
the destination IP address, uniquely identifies the Binding
Security Association (BSA) for this datagram. The set of
SPI values in the range 1 through 255 are reserved by the
Internet Assigned Numbers Authority (IANA) for future use;
a reserved SPI value will not normally be assigned by IANA
unless the use of the assigned SPI value is specified in an
RFC. It is ordinarily selected by the destination system upon
establishment of an BSA.
The SPI value of zero (0) is reserved for local,
implementation-specific use and MUST NOT be sent on the
wire. For example, a key management implementation MAY use the
zero SPI value to mean "No Binding Security Association Exists"
during the period when the implementation has requested that
its key management entity establish a new SA, but the SA has
not yet been established.
Authentication Data
This is a variable-length field that contains the
Authentication Data necessary to secure this Binding Update.
The field must be an integral multiple of 32 bits in length.
The details of the authentication calculation are given
in Section 4.4. This field may include explicit padding,
depending upon the requirements of the algorithm selected by
the SPI.
Sub-Options Sub-Options
Additional information, associated with this Binding Update Additional information, associated with this Binding Update
option, that need not be present in all Binding Updates sent. option. This use of sub-options also allows for future
This use of sub-options also allows for future extensions to extensions to the format of the Binding Update option to be
the format of the Binding Update option to be defined. The defined. The encoding and format of defined sub-options are
encoding and format of defined sub-options are described in described in Section 5.5. The following sub-options are valid
Section 5.5. The following sub-options are valid in a Binding in a Binding Update option:
Update option:
- Unique Identifier Sub-Option - Unique Identifier Sub-Option
- Mobile Router Prefix Length Sub-Option
- Alternate Care-of Address Sub-Option - Alternate Care-of Address Sub-Option
- Authentication Data Sub-Option (see section 4.4 for
authentication requirements).
The alignment requirement [6] for the Binding Update option is 4n+2. The alignment requirement [6] for the Binding Update option is 4n+2.
Any packet that includes a Binding Update option MUST also include Any packet that includes a Binding Update option MUST also include
a Home Address option. The home address of the mobile node in the a Home Address option. The home address of the mobile node in the
binding given in the Binding Update option is that which was received binding given in the Binding Update option is that which was received
as the value of the Home Address field in the Home Address option in as the value of the Home Address field in the Home Address option in
the packet. the packet.
Any packet that includes a Binding Update option MUST contain
authentication data to guard against malicious Binding Updates. The
computation for this authentication data MUST follow the rules in
Section 4.4.
The care-of address for the binding given in the Binding Update The care-of address for the binding given in the Binding Update
option is normally that which was received as the value in the Source option is normally that which was received as the value in the Source
Address field in the IPv6 header of the packet carrying the Binding Address field in the IPv6 header of the packet carrying the Binding
Update option. However, a care-of address different from the Source Update option. However, a care-of address different from the Source
Address MAY be specified by including an Alternate Care-of Address Address MAY be specified by including an Alternate Care-of Address
sub-option in the Binding Update option. sub-option in the Binding Update option. In any case, the care-of
address MUST NOT be any IPv6 address which is prohibited for use
within a Routing Header; thus multicast addresses, the unspecified
address, loop-back address, and link-local addresses are excluded.
Binding Updates indicating any such excluded care-of address MUST be
silently discarded.
If the care-of address for the binding (specified either in an If the care-of address for the binding (specified either in an
Alternate Care-of Address sub-option in the Binding Update option, if Alternate Care-of Address sub-option in the Binding Update option, if
present, or in the Source Address field in the packet's IPv6 header) present, or in the Source Address field in the packet's IPv6 header)
is equal to the home address of the mobile node, the Binding Update is equal to the home address of the mobile node, the Binding Update
option indicates that any existing binding for the mobile node MUST option indicates that any existing binding for the mobile node MUST
be deleted. Likewise, if the Lifetime field in the Binding Update be deleted. Likewise, if the Lifetime field in the Binding Update
option is equal to 0, the Binding Update option indicates that any option is equal to 0, the Binding Update option indicates that any
existing binding for the mobile node MUST be deleted. In each of existing binding for the mobile node MUST be deleted. In each of
these cases, a Binding Cache entry for the mobile node MUST NOT be these cases, a Binding Cache entry for the mobile node MUST NOT be
skipping to change at page 26, line 29 skipping to change at page 25, line 22
The last Sequence Number value sent to a destination in a Binding The last Sequence Number value sent to a destination in a Binding
Update is stored by the mobile node in its Binding Update List entry Update is stored by the mobile node in its Binding Update List entry
for that destination; the last Sequence Number value received from for that destination; the last Sequence Number value received from
a mobile node in a Binding Update is stored by a correspondent node a mobile node in a Binding Update is stored by a correspondent node
in its Binding Cache entry for that mobile node. Thus, the mobile in its Binding Cache entry for that mobile node. Thus, the mobile
node's and the correspondent node's knowledge of the last sequence node's and the correspondent node's knowledge of the last sequence
number expire at the same time. If the sending mobile node has no number expire at the same time. If the sending mobile node has no
Binding Update List entry, the Sequence Number may start at any Binding Update List entry, the Sequence Number may start at any
value; if the receiving correspondent node has no Binding Cache entry value; if the receiving correspondent node has no Binding Cache entry
for the sending mobile node, it MUST accept any Sequence Number value for the sending mobile node, it MUST accept any Sequence Number value
in a received Binding Update from this mobile node. in a received Binding Update from this mobile node. The mobile
node MUST NOT use the same Sequence Number in two different Binding
Updates to the same correspondent node, even if the Binding Updates
provide care-of addresses for two different home addresses of the
mobile node.
The three highest-order bits of the Option Type are encoded to The three highest-order bits of the Option Type are encoded to
indicate specific processing of the option [6]. For the Binding indicate specific processing of the option [6]. For the Binding
Update option, these three bits are set to 110, indicating that any Update option, these three bits are set to 110, indicating that any
IPv6 node processing this option that does not recognize the Option IPv6 node processing this option that does not recognize the Option
Type must discard the packet and, only if the packet's Destination Type must discard the packet and, only if the packet's Destination
Address was not a multicast address, return an ICMP Parameter Address was not a multicast address, return an ICMP Parameter
Problem, Code 2, message to the packet's Source Address; and that the Problem, Code 2, message to the packet's Source Address; and that the
data within the option cannot change en-route to the packet's final data within the option cannot change en-route to the packet's final
destination. destination.
skipping to change at page 27, line 17 skipping to change at page 26, line 17
The Binding Acknowledgement destination option is used to acknowledge The Binding Acknowledgement destination option is used to acknowledge
receipt of a Binding Update option (Section 5.1). When a node receipt of a Binding Update option (Section 5.1). When a node
receives a packet containing a Binding Update option, with this receives a packet containing a Binding Update option, with this
node being the destination of the packet (only the destination node node being the destination of the packet (only the destination node
processes the option since it is a destination option), this node processes the option since it is a destination option), this node
MUST return a Binding Acknowledgement to the source of the packet, MUST return a Binding Acknowledgement to the source of the packet,
if the Acknowledge (A) bit is set in the Binding Update. As a if the Acknowledge (A) bit is set in the Binding Update. As a
destination option, this node MAY include the Binding Acknowledgement destination option, this node MAY include the Binding Acknowledgement
in any existing packet being sent to the mobile node or MAY send it in any existing packet being sent to the mobile node or MAY send it
in a packet by itself. A packet containing a Binding Acknowledgement in a packet by itself. A packet containing a Binding Acknowledgement
is sent in the same way as any packet to a mobile node, using a is sent according to the rules in section 8.5.
Routing header to route the packet to the mobile node by way of the
care-of address in the binding (Section 8.9).
The Binding Acknowledgement option is encoded in type-length-value The Binding Acknowledgement option is encoded in type-length-value
(TLV) format as follows: (TLV) format 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Option Type | | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status |AuthData Length| Sequence # | | Option Length | Status | Reserved | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh | | Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Authentication Data (variable length) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options... | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
7 7
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
skipping to change at page 28, line 13 skipping to change at page 27, line 4
fields. fields.
Status Status
8-bit unsigned integer indicating the disposition of the 8-bit unsigned integer indicating the disposition of the
Binding Update. Values of the Status field less than 128 Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving indicate that the Binding Update was accepted by the receiving
node. The following such Status values are currently defined: node. The following such Status values are currently defined:
0 Binding Update accepted 0 Binding Update accepted
Values of the Status field greater than or equal to 128 Values of the Status field greater than or equal to 128
indicate that the Binding Update was rejected by the receiving indicate that the Binding Update was rejected by the receiving
node. The following such Status values are currently defined: node. The following such Status values are currently defined:
128 Reason unspecified 128 Reason unspecified
130 Administratively prohibited 130 Administratively prohibited
131 Insufficient resources 131 Insufficient resources
132 Home registration not supported 132 Home registration not supported
133 Not home subnet 133 Not home subnet
136 Incorrect interface identifier length
137 Not home agent for this mobile node 137 Not home agent for this mobile node
138 Duplicate Address Detection failed 138 Duplicate Address Detection failed
139 No security association 139 No security association
140 Mobile Router Prefix Length Sub-Option Rejected
141 Sequence number too small 141 Sequence number too small
Up-to-date values of the Status field are to be specified in Up-to-date values of the Status field are to be specified in
the most recent "Assigned Numbers" [26]. the most recent "Assigned Numbers" [26].
AuthDataLength
The length of the Authentication Data field in octets.
Sequence # Sequence #
The Sequence Number in the Binding Acknowledgement is copied The Sequence Number in the Binding Acknowledgement is copied
from the Sequence Number field in the Binding Update being from the Sequence Number field in the Binding Update being
acknowledged, for use by the mobile node in matching this acknowledged, for use by the mobile node in matching this
Acknowledgement with an outstanding Binding Update. Acknowledgement with an outstanding Binding Update.
Lifetime Lifetime
The granted lifetime, in seconds, for which this node will The granted lifetime, in seconds, for which this node will
skipping to change at page 29, line 7 skipping to change at page 27, line 43
serving as the mobile node's home agent, the Lifetime period serving as the mobile node's home agent, the Lifetime period
also indicates the period for which this node will continue also indicates the period for which this node will continue
this service; if the mobile node requires home agent service this service; if the mobile node requires home agent service
from this node beyond this period, the mobile node MUST send a from this node beyond this period, the mobile node MUST send a
new Binding Update to it before the expiration of this period new Binding Update to it before the expiration of this period
(even if it is not changing its primary care-of address), in (even if it is not changing its primary care-of address), in
order to extend the lifetime. The value of this field is order to extend the lifetime. The value of this field is
undefined if the Status field indicates that the Binding Update undefined if the Status field indicates that the Binding Update
was rejected. was rejected.
Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that, in combination
with the destination IP address, uniquely identifies the
BSA for this datagram. The set of SPI values in the range
1 through 255 are reserved by the Internet Assigned Numbers
Authority (IANA) for future use; a reserved SPI value will not
normally be assigned by IANA unless the use of the assigned
SPI value is specified in an RFC. It is ordinarily selected by
the destination system upon establishment of an SA (see the
Security Architecture document for more details).
The SPI value of zero (0) is reserved for local,
implementation- specific use and MUST NOT be sent on
the wire.
Refresh Refresh
The recommended interval, in seconds, at which the mobile The recommended interval, in seconds, at which the mobile
node SHOULD send a new Binding Update to this node in order node SHOULD send a new Binding Update to this node in order
to "refresh" the mobile node's binding in this node's Binding to "refresh" the mobile node's binding in this node's Binding
Cache. This refreshing of the binding is useful in case the Cache. This refreshing of the binding is useful in case the
node fails and loses its cache state. The Refresh period is node fails and loses its cache state. The Refresh period is
determined by the node sending the Binding Acknowledgement determined by the node sending the Binding Acknowledgement
(the node caching the binding). If this node is serving as (the node caching the binding). If this node is serving as
the mobile node's home agent, the Refresh value may be set, the mobile node's home agent, the Refresh value may be set,
skipping to change at page 29, line 45 skipping to change at page 28, line 14
node sending the Binding Acknowledgement is not serving as the node sending the Binding Acknowledgement is not serving as the
mobile node's home agent, the Refresh period SHOULD be set mobile node's home agent, the Refresh period SHOULD be set
equal to the Lifetime period in the Binding Acknowledgement; equal to the Lifetime period in the Binding Acknowledgement;
even if this node loses this cache entry due to a failure of even if this node loses this cache entry due to a failure of
the node, packets from it can still reach the mobile node the node, packets from it can still reach the mobile node
through the mobile node's home agent, causing a new Binding through the mobile node's home agent, causing a new Binding
Update to this node to allow it to recreate this cache entry. Update to this node to allow it to recreate this cache entry.
The value of this field is undefined if the Status field The value of this field is undefined if the Status field
indicates that the Binding Update was rejected. indicates that the Binding Update was rejected.
Authentication Data
This is a variable-length field that contains the
Authentication Data necessary to secure this Binding Update.
The field must be an integral multiple of 32 bits in length.
The details of the authentication data computation are
described in Section 4.4. This field may include explicit
padding, depending upon the requirements of the algorithm
selected by the SPI.
Sub-Options Sub-Options
Additional information, associated with this Binding Additional information, associated with this Binding
Acknowledgement option, that need not be present in all Binding Acknowledgement option. The Authentication Data sub-option MAY
Acknowledgements sent. This use of sub-options also allows for be present, and other sub-options (not currently defined) MAY
future extensions to the format of the Binding Acknowledgement be optionally included. See section 4.4 for authentication
option to be defined. Currently, no valid sub-options are requirements. This use of sub-options also allows for future
defined for a Binding Acknowledgement option. extensions to the format of the Binding Acknowledgement option
to be defined.
The alignment requirement [6] for the Binding Acknowledgement option The alignment requirement [6] for the Binding Acknowledgement option
is 4n+3. is 4n+3.
Any packet that includes a Binding Acknowledgement option MUST Any packet that includes a Binding Acknowledgement option MUST
contain authentication data to guard against malicious Binding contain authentication data to guard against malicious Binding
Updates. The computation for this authentication data must follow Acknowledgements. The computation for this authentication data MUST
the rules in Section 4.4. follow the rules in Section 4.4.
If the node returning the Binding Acknowledgement accepted the If the node returning the Binding Acknowledgement accepted the
Binding Update for which the Acknowledgement is being returned (the Binding Update for which the Acknowledgement is being returned (the
value of the Status field in the Acknowledgement is less than 128), value of the Status field in the Acknowledgement is less than 128),
this node will have an entry for the mobile node in its Binding this node will have an entry for the mobile node in its Binding
Cache and MUST use this entry (which includes the care-of address Cache and MUST use this entry (which includes the care-of address
received in the Binding Update) in sending the packet containing the received in the Binding Update) in sending the packet containing the
Binding Acknowledgement to the mobile node. The details of sending Binding Acknowledgement to the mobile node. The details of sending
this packet (using a Routing header) to the mobile node are the same this packet (using a Routing header) to the mobile node are the same
as for sending any packet to a mobile node using a binding, as are as for sending any packet to a mobile node using a binding, as are
skipping to change at page 34, line 16 skipping to change at page 32, line 16
The Home Address destination option is used in a packet sent by a The Home Address destination option is used in a packet sent by a
mobile node while away from home, to inform the recipient of that mobile node while away from home, to inform the recipient of that
packet of the mobile node's home address. For packets sent by a packet of the mobile node's home address. For packets sent by a
mobile node while away from home, the mobile node generally uses mobile node while away from home, the mobile node generally uses
one of its care-of addresses as the Source Address in the packet's one of its care-of addresses as the Source Address in the packet's
IPv6 header. By including a Home Address option in the packet, the IPv6 header. By including a Home Address option in the packet, the
correspondent node receiving the packet is able to substitute the correspondent node receiving the packet is able to substitute the
mobile node's home address for this care-of address when processing mobile node's home address for this care-of address when processing
the packet, thus making the use of the care-of address transparent to the packet, thus making the use of the care-of address transparent to
the correspondent node. the correspondent node. Note that multicast addresses, link-local
addresses, loopback addresses, IPv4 mapped addresses, and the
unspecified address, MUST NOT be used within a Home Address option.
The Home Address option is encoded in type-length-value (TLV) format The Home Address option is encoded in type-length-value (TLV) format
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 38, line 20 skipping to change at page 36, line 20
Pad1 and PadN (defined below), which are used when necessary to align Pad1 and PadN (defined below), which are used when necessary to align
subsequent sub-options. The Pad1 and PadN sub-options are valid for subsequent sub-options. The Pad1 and PadN sub-options are valid for
all Mobile IPv6 destination options. Unlike the padding options all Mobile IPv6 destination options. Unlike the padding options
used in Hop-by-Hop Options header or Destination Options header [6], used in Hop-by-Hop Options header or Destination Options header [6],
there is no requirement for padding the total size of any Mobile IPv6 there is no requirement for padding the total size of any Mobile IPv6
destination option to a multiple of 8 octets in length, and the destination option to a multiple of 8 octets in length, and the
Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All
Mobile IPv6 sub-options defined in this document MUST be recognized Mobile IPv6 sub-options defined in this document MUST be recognized
by all Mobile IPv6 implementations. by all Mobile IPv6 implementations.
Currently, the following sub-option types are defined for use in The following subsections specify the sub-option types which are
Mobile IPv6 destination options: currently defined for use in Mobile IPv6 destination options.
5.5.1. Pad1
Pad1 Sub-Option (alignment requirement: none) Pad1 Sub-Option (alignment requirement: none)
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 0 | | 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 sub-option is a special NOTE! the format of the Pad1 sub-option is a special
case -- it has neither Sub-Option Len nor Sub-Option Data case -- it has neither Sub-Option Len nor Sub-Option Data
fields. fields.
The Pad1 sub-option is used to insert one octet of padding The Pad1 sub-option is used to insert one octet of padding
into the Sub-Options area of a Mobile IPv6 option. If more into the Sub-Options area of a Mobile IPv6 option. If more
than one octet of padding is required, the PadN sub-option, than one octet of padding is required, the PadN sub-option,
described next, should be used, rather than multiple Pad1 described next, should be used, rather than multiple Pad1
sub-options. sub-options.
PadN Sub-Option (alignment requirement: none) 5.5.2. PadN
PadN Sub-Option (alignment requirement: none)
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Sub-Option Len| Sub-Option Data | 1 | Sub-Option Len| Sub-Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN sub-option is used to insert two or more octets of The PadN sub-option is used to insert two or more octets of
padding into the Sub-Options area of a Mobile IPv6 option. padding into the Sub-Options area of a Mobile IPv6 option.
For N octets of padding, the Sub-Option Len field contains For N octets of padding, the Sub-Option Len field contains
the value N-2, and the Sub-Option Data consists of N-2 the value N-2, and the Sub-Option Data consists of N-2
zero-valued octets. zero-valued octets.
5.5.3. Unique Identifier
Unique Identifier Sub-Option (alignment requirement: 2n) Unique Identifier Sub-Option (alignment requirement: 2n)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 | Unique Identifier | | 2 | 2 | Unique Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unique Identifier sub-option is valid only in Binding The Unique Identifier sub-option is valid only in Binding
Request and Binding Update destination options. The Unique Request and Binding Update destination options. The Unique
Identifier field contains a 16-bit value that serves to Identifier field contains a 16-bit value that serves to
uniquely identify a Binding Request among those sent by this uniquely identify a Binding Request among those sent by this
Source Address, and to allow the Binding Update to identify Source Address, and to allow the Binding Update to identify
the specific Binding Request to which it responds. This the specific Binding Request to which it responds. This
matching of Binding Updates to Binding Requests is required matching of Binding Updates to Binding Requests is required
in the procedure for renumbering the home subnet while a in the procedure for renumbering the home subnet while a
mobile node is away from home (Section 9.6). mobile node is away from home (Section 9.6).
Mobile Router Prefix Length Sub-Option (alignment requirement: 5.5.4. Alternate Care-of Address
2n+1)
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 |x|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Mobile Router Prefix Length Sub-Option is valid only
in the Binding Update destination option. The Prefix
Length field contains a 7-bit value that serves to notify
the recipient that the care-of address may be used for
delivery of packets to any home address whose initial
Prefix-Length address bits match the corresponding bits of
the home address reported in the Home Address destination
option, which MUST also be present in the same message.
See section 4.8 for a discussion about the use of this
Sub-Option.
If a node receives the Mobile Router Prefix Length
Sub-Option, and it cannot carry out the necessary matching
operations with relevant Binding Cache entries, the node
MUST return a Binding Acknowledgement message including
status code 140.
Alternate Care-of Address Sub-Option (alignment requirement: 8n+6) Alternate Care-of Address Sub-Option (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 16 | | 3 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Alternate Care-of Address + + Alternate Care-of Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address sub-option is valid only in The Alternate Care-of Address sub-option is valid only in
Binding Update destination options. The Alternate Care-of Binding Update destination options. The Alternate Care-of
Address field contains an address to use as the care-of Address field contains an address to use as the care-of
address for the binding, rather than using the Source address for the binding, rather than using the Source
Address of the packet as the care-of address. Address of the packet as the care-of address.
5.6. ICMP Home Agent Address Discovery Request Message 5.6. Authentication Data
Authentication Data Sub-Option (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Authentication Data (variable length) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authentication Data sub-option is valid in Binding
Update and Binding Acknowledgement destination options.
The Length of the sub-option is 4 plus the number of bytes
contained in the Authentication Data field.
The SPI is an arbitrary 32-bit value that, in combination
with the destination IP address, uniquely identifies the
BSA for this datagram. The set of SPI values in the range
1 through 255 are reserved by the Internet Assigned Numbers
Authority (IANA) for future use; a reserved SPI value will
not normally be assigned by IANA unless the use of the
assigned SPI value is specified in an RFC. It is ordinarily
selected by the destination system upon establishment of
an SA (see the Security Architecture document for more
details).
The SPI value of zero (0) is reserved for local,
implementation- specific use and MUST NOT be sent on the
wire.
The Authentication Data field is a variable-length
field that contains data necessary to secure a Binding
Update or Binding Acknowledgment. The field must be
an integral multiple of 32 bits in length. The details
of the authentication data computation are described in
Section 4.4. This field may include explicit padding,
depending upon the requirements of the algorithm selected by
the SPI.
5.7. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a The ICMP Home Agent Address Discovery Request message is used by a
mobile node to initiate the dynamic home agent address discovery mobile node to initiate the dynamic home agent address discovery
mechanism, as described in Sections 9.8 and 10.8. The mobile mechanism, as described in Sections 9.8 and 10.8. The mobile
node sends a Home Agent Address Discovery Request message to the node sends a Home Agent Address Discovery Request message to the
"Mobile IPv6 Home-Agents" anycast address for its own home subnet "Mobile IPv6 Home-Agents" anycast address for its own home subnet
prefix [10], and one of the home agents there responds to the mobile prefix [10], and one of the home agents there responds to the mobile
node with a Home Agent Address Discovery Reply message giving a list node with a Home Agent Address Discovery Reply message giving a list
of the routers on the mobile node's home link serving as home agents. of the routers on the mobile node's home link serving as home agents.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<To Be Assigned by IANA> 150 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
Identifier Identifier
An identifier to aid in matching Home Agent Address Discovery An identifier to aid in matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request Reply messages to this Home Agent Address Discovery Request
message. message.
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.
Home Address
The home address of the mobile node sending the Home Agent
Address Discovery Request message.
The Source Address of the Home Agent Address Discovery Request The Source Address of the Home Agent Address Discovery Request
message packet MUST be one of the mobile node's current care-of message packet MUST be one of the mobile node's current care-of
addresses, and the mobile node MUST NOT include a Home Address addresses. The home agent then MUST return the Home Agent Address
option in this packet; the home agent then MUST return the Home Discovery Reply message directly to the Source Address chosen by
Agent Address Discovery Reply message directly to this care-of the mobile node Note that, at the time of performing this dynamic
address. These restrictions are necessary, since at the time of home agent address discovery, it is likely that the mobile node not
performing this dynamic home agent address discovery, the mobile node registered with any home agent within the specified anycast group.
is generally not registered with its home agent; using the mobile
node's care-of address simplifies the return of the Reply message to
the mobile node.
If the mobile node does not have a home address, then the Home
Address field MUST be set to the unspecified address (0::0).
5.7. ICMP Home Agent Address Discovery Reply Message 5.8. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a The ICMP Home Agent Address Discovery Reply message is used by a
home agent to respond to a mobile node using the dynamic home agent home agent to respond to a mobile node using the dynamic home agent
address discovery mechanism, as described in Sections 9.8 and 10.8. address discovery mechanism, as described in Sections 9.8 and 10.8.
The mobile node sends a Home Agent Address Discovery Request message The mobile node sends a Home Agent Address Discovery Request message
to the "Mobile IPv6 Home-Agents" anycast address for its own home to the "Mobile IPv6 Home-Agents" anycast address for its own home
subnet prefix [10], and one of the home agents there responds to the subnet prefix [10], and one of the home agents there responds to the
mobile node with a Home Agent Address Discovery Reply message giving mobile node with a Home Agent Address Discovery Reply message giving
a list of the routers on the mobile node's home link serving as home a list of the routers on the mobile node's home link serving as home
agents. agents.
skipping to change at page 43, line 39 skipping to change at page 41, line 39
+ + + +
. . . .
. Home Agent Addresses . . Home Agent Addresses .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<To Be Assigned by IANA> 151 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
Identifier Identifier
skipping to change at page 45, line 5 skipping to change at page 43, line 5
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.
Home Agent Addresses Home Agent Addresses
A list of addresses of home agents on the home link for the A list of addresses of home agents on the home link for the
mobile node. The number of addresses present in the list is mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message. the Home Agent Address Discovery Reply message.
5.8. ICMP Mobile Prefix Solicitation Message Format 5.9. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node The ICMP Mobile Prefix Solicitation Message is sent by a mobile node
to its home agent while it is away from home. The purpose of the to its home agent while it is away from home. The purpose of the
message is to solicit a Mobile Prefix Advertisement from the home message is to solicit a Mobile Prefix Advertisement from the home
agent, which will allow the mobile node to gather prefix information agent, which will allow the mobile node to gather prefix information
about its home network. This information can be used to configure about its home network. This information can be used to configure
home address(es) by stateless address autoconfiguration [27], home address(es) by stateless address autoconfiguration [27],
or update address(es) according to changes in prefix information or update address(es) according to changes in prefix information
supplied by the home agent. supplied by the home agent.
skipping to change at page 46, line 7 skipping to change at page 44, line 7
Authentication Header Authentication Header
If a Security Association for the IP Authentication Header If a Security Association for the IP Authentication Header
exists between the sender and the destination address, then the exists between the sender and the destination address, then the
sender SHOULD include this header. [subject to change] sender SHOULD include this header. [subject to change]
ICMP Fields: ICMP Fields:
Type Type
<To Be Assigned by IANA> 152 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
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.
5.9. ICMP Mobile Prefix Advertisement Message Format 5.10. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement message to a A home agent will send a Mobile Prefix Advertisement message to a
mobile node to distribute prefix information about the home link mobile node to distribute prefix information about the home link
while the mobile node is traveling away from the home network. This while the mobile node is traveling away from the home network. This
will occur in response to a Mobile Prefix Solicitation with an will occur in response to a Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited Advertisement sent according to Advertisement, or by an unsolicited Advertisement sent according to
the rules in Section 5.9. the rules in Section 5.10.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
skipping to change at page 47, line 45 skipping to change at page 45, line 45
Authentication Header Authentication Header
This header MUST be sent, unless the mobile node This header MUST be sent, unless the mobile node
has not yet configured, and is using its care-of has not yet configured, and is using its care-of
address. [subject to change] address. [subject to change]
ICMP Fields: ICMP Fields:
Type Type
<To Be Assigned by IANA> 153 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
Options: Options:
skipping to change at page 54, line 12 skipping to change at page 52, line 12
this document. Any such dynamic setting of the Home Agent this document. Any such dynamic setting of the Home Agent
Preference, however, MUST set the preference appropriately, Preference, however, MUST set the preference appropriately,
relative to the default Home Agent Preference value of 0 that relative to the default Home Agent Preference value of 0 that
may be in use by some home agents on this link (i.e., a home may be in use by some home agents on this link (i.e., a home
agent not including a Home Agent Information option in its agent not including a Home Agent Information option in its
Router Advertisements will be considered to have a Home Agent Router Advertisements will be considered to have a Home Agent
Preference value of 0). Preference value of 0).
Home Agent Lifetime Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the home 16-bit unsigned integer. The lifetime associated with the
agent in units of seconds. The maximum value corresponds to home agent in units of seconds. The default value is the same
18.2 hours. A value of 0 MUST NOT be used. The Home Agent as the Router Lifetime, as specified in the main body of the
Router Advertisement message. The maximum value corresponds
to 18.2 hours. A value of 0 MUST NOT be used. The Home Agent
Lifetime applies only to this router's usefulness as a home Lifetime applies only to this router's usefulness as a home
agent; it does not apply to information contained in other agent; it does not apply to information contained in other
message fields or options. If this option is not included in message fields or options.
a Router Advertisement in which the Home Agent (H) bit is set,
the lifetime for this home agent MUST be considered to be the
same as the Router Lifetime specified in the main body of the
Router Advertisement message.
Home agents MAY include this option in their Router Advertisements. Home agents MAY include this option in their Router Advertisements.
This option MUST NOT be included in a Router Advertisement in which This option MUST NOT be included in a Router Advertisement in which
the Home Agent (H) bit (see Section 6.1) is not set. the Home Agent (H) bit (see Section 6.1) is not set. If this option
is not included in a Router Advertisement in which the Home Agent (H)
bit is set, the lifetime for this home agent MUST be considered to be
the same as the Router Lifetime in the Router Advertisement.
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
If both the Home Agent Preference and Home Agent Lifetime are set If both the Home Agent Preference and Home Agent Lifetime are set
to their default values specified above, this option SHOULD NOT be to their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home included in the Router Advertisement messages sent by this home
agent. agent.
6.5. Changes to Sending Router Advertisements 6.5. Changes to Sending Router Advertisements
skipping to change at page 61, line 19 skipping to change at page 59, line 19
possibly also be functioning as a home agent for Mobile IPv6. The possibly also be functioning as a home agent for Mobile IPv6. The
procedures in this section thus apply to all IPv6 nodes. procedures in this section thus apply to all IPv6 nodes.
8.1. Receiving Packets from a Mobile Node 8.1. Receiving Packets from a Mobile Node
Packets sent by a mobile node while away from home generally include Packets sent by a mobile node while away from home generally include
a Home Address option. When any node receives a packet containing a Home Address option. When any node receives a packet containing
a Home Address option, it MUST process the option in a manner a Home Address option, it MUST process the option in a manner
consistent with exchanging the Home Address field from the Home consistent with exchanging the Home Address field from the Home
Address option into the IPv6 header, replacing the original value of Address option into the IPv6 header, replacing the original value of
the Source Address field there. However, any actual modifications the Source Address field there. However, any actual modifications to
to the Source Address field in the packet's IPv6 header MUST not the Source Address field in the packet's IPv6 header MUST be carried
be performed until after all processing of other options contained out in such a fashion that further processing of such a packet after
in the same Destination Options extension header is completed. all IPv6 options processing (e.g., at the transport layer) does not
Currently, no other such options are defined. need to know that the original Source Address was a care-of address,
or that the Home Address option was used in the packet.
Further processing of such a packet after all IPv6 options processing Since the sending mobile node uses its home address at the transport
(e.g., at the transport layer) thus does not need to know that the layer when sending such a packet, the use of the care-of address
original Source Address was a care-of address, or that the Home and Home Address option is transparent to both the mobile node and
Address option was used in the packet. Since the sending mobile the correspondent node above the level of the Home Address option
node uses its home address at the transport layer when sending such generation and processing.
a packet, the use of the care-of address and Home Address option is
transparent to both the mobile node and the correspondent node above
the level of the Home Address option generation and processing.
8.2. Receiving Binding Updates 8.2. Receiving Binding Updates
Upon receiving a Binding Update option in some packet, the receiving Before accepting a Binding Update option received in any packet, the
node MUST validate the Binding Update according to the following receiving node MUST validate the Binding Update according to the
tests: following tests:
- The packet meets the specific authentication requirements for - The packet meets the specific authentication requirements for
Binding Updates, defined in Section 4.4. Binding Updates, defined in Section 4.4.
- The packet MUST contain a Home Address option. - The packet MUST contain a Home Address option.
- The Option Length field in the Binding Update option is greater - The Option Length field in the Binding Update option is greater
than or equal to the length specified in Section 5.1. than or equal to the length specified in Section 5.1.
- The Sequence Number field in the Binding Update option is greater - The Sequence Number field in the Binding Update option is greater
than the Sequence Number received in the previous Binding Update than the Sequence Number received in the previous Binding Update
for this home address, if any. As noted in Section 4.6, this for this home address, if any. As noted in Section 4.6, this
Sequence Number comparison MUST be performed modulo 2**8. Sequence Number comparison MUST be performed modulo 2**8.
Any Binding Update not satisfying all of these tests MUST be If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the
receiving node MUST send back a Binding Acknowledgement with status
code 141, and the last accepted sequence number in the Sequence
Number field of the Binding Acknowledgement.
Any Binding Update which fails to satisfy all of these tests for any
other reason (than insufficiency of the Sequence Number) MUST be
silently ignored, and the packet carrying the Binding Update MUST be silently ignored, and the packet carrying the Binding Update MUST be
discarded. discarded.
In this section, the care-of address refers to the IPv6 address, In this section, the care-of address refers to the IPv6 address,
which was originally located in the IPv6 header when the packet was which was originally located in the IPv6 header when the packet was
transmitted by the mobile node. transmitted by the mobile node.
If the Binding Update is valid according to the tests above, then the If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows: Binding Update is processed further as follows:
skipping to change at page 63, line 33 skipping to change at page 61, line 35
Acknowledgement MUST be set to a value less than 128; if, on the Acknowledgement MUST be set to a value less than 128; if, on the
other hand the Binding Update is accepted and the `A' bit is not set, other hand the Binding Update is accepted and the `A' bit is not set,
the node SHOULD NOT send a Binding Acknowledgement. If the node the node SHOULD NOT send a Binding Acknowledgement. If the node
rejects the Binding Update and does not create or update an entry for rejects the Binding Update and does not create or update an entry for
this binding, a Binding Acknowledgement MUST be sent even if the `A' this binding, a Binding Acknowledgement MUST be sent even if the `A'
bit was not sent, and the Status field in the Binding Acknowledgement bit was not sent, and the Status field in the Binding Acknowledgement
MUST be set to a value greater than or equal to 128. Specific values MUST be set to a value greater than or equal to 128. Specific values
for the Status field are described in Section 5.2 and in the most for the Status field are described in Section 5.2 and in the most
recent "Assigned Numbers" [26]. recent "Assigned Numbers" [26].
The packet in which the Binding Acknowledgement is returned MUST meet The packet in which the Binding Acknowledgement is returned
the specific IPsec requirements for Binding Acknowledgements, defined MUST meet the specific authentication requirements for Binding
in Section 4.4; and the packet MUST be sent using a Routing header Acknowledgements, defined in Section 4.4. Furthermore, if the packet
in the same way as any other packet sent to a mobile node using a is to be sent to the mobile node at any address other than the mobile
care-of address (even if the binding was rejected), as described in node's home address, it MUST be sent using a Routing header (even if
Section 8.9. the binding was rejected). The intermediate IP address, to which
the packet will be delivered immediately before the home address, is
determined as follows:
- Whenever the Binding Update is accepted with a nonzero lifetime,
the routing header will be constructed using the care-of address
as described in Section 8.9.
- Otherwise, if the Source IP Address of the packet containing
the Binding Update, is legal for inclusion in a Routing Header,
the routing header will be constructed using that IP address.
Note that multicast addresses, link-local addresses, loopback
addresses, IPv4 mapped addresses, and the unspecified address,
MUST NOT be used within a Routing Header for the Binding
Acknowledgement.
- Otherwise, if the Binding Update has a zero lifetime but the
Source IP address is not allowable for use within the Routing
Header, the Binding Acknowledgment MUST be sent to the mobile
node's home address.
In response to a Binding Update, a node MAY send a Binding In response to a Binding Update, a node MAY send a Binding
Acknowledgement even when the 'A' bit is not set in the Binding Acknowledgement even when the 'A' bit is not set in the Binding
Update. This would happen, for instance, if a mobile node attempted Update. This would happen, for instance, if a mobile node attempted
to send a Binding Update with the 'H' bit set to a correspondent to send a Binding Update with the 'H' bit set to a correspondent
node. node.
8.6. Sending Binding Requests 8.6. Sending Binding Requests
Entries in a node's Binding Cache MUST be deleted when their lifetime Entries in a node's Binding Cache MUST be deleted when their lifetime
skipping to change at page 64, line 26 skipping to change at page 62, line 48
recreating the Binding Cache entry. Since a Binding Request is a recreating the Binding Cache entry. Since a Binding Request is a
destination option, it may, for example, be included in any packet destination option, it may, for example, be included in any packet
already being sent to the mobile node, such as a packet that is part already being sent to the mobile node, such as a packet that is part
of ongoing TCP communication with the mobile node. When the mobile of ongoing TCP communication with the mobile node. When the mobile
node receives a packet from some sender containing a Binding Request node receives a packet from some sender containing a Binding Request
option, it returns a Binding Update option to that sender, giving its option, it returns a Binding Update option to that sender, giving its
current binding and a new lifetime. current binding and a new lifetime.
8.7. Cache Replacement Policy 8.7. Cache Replacement Policy
Any entry in a node's Binding Cache MUST be deleted after the Conceptually, a node maintains a separate timer for each entry in its
expiration of the Lifetime specified in the Binding Update from Binding Cache. When creating or updating a Binding Cache entry in
which the entry was created or last updated. Conceptually, a node response to a received and accepted Binding Update, the node sets the
maintains a separate timer for each entry in its Binding Cache. When timer for this entry to the specified Lifetime period. Any entry in
creating or updating a Binding Cache entry in response to a received a node's Binding Cache MUST be deleted after the expiration of the
and accepted Binding Update, the node sets the timer for this entry Lifetime specified in the Binding Update from which the entry was
to the specified Lifetime period. When a Binding Cache entry's timer created or last updated.
expires, the node deletes the entry.
Each node's Binding Cache will, by necessity, have a finite size. Each node's Binding Cache will, by necessity, have a finite size.
A node MAY use any reasonable local policy for managing the space A node MAY use any reasonable local policy for managing the space
within its Binding Cache, except that any entry marked as a "home within its Binding Cache, except that any entry marked as a "home
registration" (Section 9.1) MUST NOT be deleted from the cache until registration" (Section 9.1) MUST NOT be deleted from the cache
the expiration of its lifetime period. When attempting to add a until the expiration of its lifetime period. When such a "home
new "home registration" entry in response to a Binding Update with registration" entry is deleted, in addition the home agent MUST also
the Home Registration (H) bit set, if insufficient space exists cease intercepting packets on the mobile node's home link addressed
(and sufficient space cannot be reclaimed) in the node's Binding to the mobile node (Section 9.3), just as if the mobile node had
Cache, the node MUST reject the Binding Update and SHOULD return a deregistered its primary care-of address (see Section 9.2).
Binding Acknowledgement to the sending mobile node, in which the
Status field is set to 131 (insufficient resources). When otherwise When attempting to add a new "home registration" entry in response
attempting to add a new entry to its Binding Cache, a node MAY, if to a Binding Update with the Home Registration (H) bit set, if
needed, choose to drop any entry already in its Binding Cache, other insufficient space exists (and sufficient space cannot be reclaimed)
than a "home registration" entry, in order to make space for the new in the node's Binding Cache, the node MUST reject the Binding
entry. For example, a "least-recently used" (LRU) strategy for cache Update and SHOULD return a Binding Acknowledgement to the sending
entry replacement among entries not marked as a "home registration" mobile node, in which the Status field is set to 131 (insufficient
is likely to work well unless the size of the Binding Cache is resources). When otherwise attempting to add a new entry to its
substantially insufficient. Binding Cache, a node MAY, if needed, choose to drop any entry
already in its Binding Cache, other than a "home registration"
entry, in order to make space for the new entry. For example, a
"least-recently used" (LRU) strategy for cache entry replacement
among entries not marked as a "home registration" is likely to
work well unless the size of the Binding Cache is substantially
insufficient.
Any binding dropped from a node's Binding Cache due to lack of cache Any binding dropped from a node's Binding Cache due to lack of cache
space will be rediscovered and a new cache entry created, if the space will be rediscovered and a new cache entry created, if the
binding is still in active use by the node for sending packets. If binding is still in active use by the node for sending packets. If
the node sends a packet to a destination for which it has dropped the the node sends a packet to a destination for which it has dropped the
entry from its Binding Cache, the packet will be routed normally, entry from its Binding Cache, the packet will be routed normally,
leading to the mobile node's home link. There, the packet will be leading to the mobile node's home link. There, the packet will be
intercepted by the mobile node's home agent and tunneled to the intercepted by the mobile node's home agent and tunneled to the
mobile node's current primary care-of address. As when a Binding mobile node's current primary care-of address. As when a Binding
Cache entry is initially created, this indirect routing to the mobile Cache entry is initially created, this indirect routing to the mobile
skipping to change at page 68, line 5 skipping to change at page 65, line 48
is currently at home), the packet will be delivered directly to this is currently at home), the packet will be delivered directly to this
node and processed normally by it. If, however, the destination node node and processed normally by it. If, however, the destination node
is a mobile node that is currently away from home, the packet will is a mobile node that is currently away from home, the packet will
be intercepted by the mobile node's home agent and tunneled (using be intercepted by the mobile node's home agent and tunneled (using
IPv6 encapsulation [4]) to the mobile node's current primary care-of IPv6 encapsulation [4]) to the mobile node's current primary care-of
address, as described in Section 9.4. The mobile node will then send address, as described in Section 9.4. The mobile node will then send
a Binding Update to the sending node, as described in Section 10.9, a Binding Update to the sending node, as described in Section 10.9,
allowing the sending node to create a Binding Cache entry for its use allowing the sending node to create a Binding Cache entry for its use
in sending subsequent packets to this mobile node. in sending subsequent packets to this mobile node.
It is possible that a correspondent node, having no knowledge
of the mobile node's care-of address, would still (for reasons
unspecified here but not necessarily related to mobility) attempt
to deliver a packet, either to or by way of the mobile node's home
address, by using a routing header. If the correspondent node
subsequently accepts a Binding Update and creates a Binding Cache
entry for the mobile node, then afterwards, the routing header used
by the corresponding node which includes the mobile node's home
address SHOULD also include the mobile node's care-of address. The
correspondent node SHOULD put the mobile node's care-of address as
the intermediate node address immediately preceding the mobile node's
home address. When the care-of address is the first intermediate
node address, this implies that the care-of address is to be placed
in the Destination Address of the IPv6 header, and the mobile
node's home address is the first entry in the type 0 routing header.
Otherwise, the correspondent node MUST insert the mobile node's
care-of address immediately before the home address entry in the
routing header.
9. Home Agent Operation 9. Home Agent Operation
9.1. Primary Care-of Address Registration 9.1. Primary Care-of Address Registration
When a node receives a Binding Update, it MUST validate it and When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described determine the type of Binding Update according to the steps described
in Section 8.2. This section describes the processing of a valid in Section 8.2. This section describes the processing of a valid
Binding Update that requests the receiving node to serve as its home Binding Update that requests the receiving node to serve as its home
agent, registering its primary care-of address. agent, registering its primary care-of address.
skipping to change at page 68, line 31 skipping to change at page 67, line 31
which the Status field is set to 132 (home registration not which the Status field is set to 132 (home registration not
supported). supported).
- Else, if the home address for the binding (the Home Address field - 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, address with respect to the home agent's current Prefix List,
then the home agent MUST reject the Binding Update and SHOULD then the home agent MUST reject the Binding Update and SHOULD
return a Binding Acknowledgement to the mobile node, in which the return a Binding Acknowledgement to the mobile node, in which the
Status field is set to 133 (not home subnet). Status field is set to 133 (not home subnet).
- Else, if the Prefix Length field is nonzero in the Binding Update
and this length differs from the length of the home agent's own
knowledge of the corresponding subnet prefix on the home link,
then the home agent MUST reject the Binding Update and SHOULD
return a Binding Acknowledgement to the mobile node, in which the
Status field is set to 136 (incorrect subnet prefix length).
- Else, if the home agent chooses to reject the Binding Update for - 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.
- Finally, if the Duplicate Address Detection (D) bit is set in - Finally, if the Duplicate Address Detection (D) bit is set in
the Binding Update, this home agent MUST perform Duplicate the Binding Update, this home agent MUST perform Duplicate
Address Detection [27] on the mobile node's home link for the Address Detection [27] on the mobile node's home link for the
home address in this binding (before returning the Binding home address in this binding (before returning the Binding
Acknowledgement); if the 7-bit Prefix Length field is nonzero Acknowledgement). The address used for Duplicate Address
in the Binding Update, the home agent SHOULD perform Duplicate Detection SHOULD be the mobile node's link-local address. Normal
Address Detection for only one of the addresses formed from the processing for Duplicate Address Detection specifies that, in
interface identifier for this binding, and if so, the address certain cases, the node SHOULD delay sending the initial Neighbor
used for Duplicate Address Detection SHOULD be the mobile node's Solicitation message of Duplicate Address Detection by a random
link-local address. Normal processing for Duplicate Address delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27]; however,
Detection specifies that, in certain cases, the node SHOULD in this case, the home agent SHOULD NOT perform such a delay.
delay sending the initial Neighbor Solicitation message of If this Duplicate Address Detection fails, then the home agent
Duplicate Address Detection by a random delay between 0 and MUST reject the Binding Update and SHOULD return a Binding
MAX_RTR_SOLICITATION_DELAY [17, 27]; however, in this case, the Acknowledgement to the mobile node, in which the Status field is
home agent SHOULD NOT perform such a delay. If this Duplicate set to 138 (Duplicate Address Detection failed). When the home
Address Detection fails, then the home agent MUST reject the agent sends a successful Binding Acknowledgement to the mobile
Binding Update and SHOULD return a Binding Acknowledgement to the node, in response to a Binding Update with the `D' bit set, the
mobile node, in which the Status field is set to 138 (Duplicate home agent assures to the mobile node that its home address
Address Detection failed). will continue to be valid at least as long as the mobile node
transmits Binding Updates with new care-of addresses for that
home address.
If the home agent does not reject the Binding Update, then it becomes If the home agent does not reject the Binding Update, then it becomes
or remains the home agent for the mobile node. The home agent MUST or remains the home agent for the mobile node. The home agent MUST
then create a new entry in its Binding Cache for this mobile node (or then create a new entry in its Binding Cache for this mobile node (or
update its existing Binding Cache entry for this mobile node, if such update its existing Binding Cache entry for this mobile node, if such
an entry already exists). The home address of the mobile node is an entry already exists). The home address of the mobile node is
taken to be the value which, when the packet was originally received, taken to be the value which, when the packet was originally received,
was located in the Home Address field in the packet's Home Address was located in the Home Address field in the packet's Home Address
option. The care-of address for this Binding Cache entry is taken option. The care-of address for this Binding Cache entry is taken
to be the value which, when the packet was originally received, was to be the value which, when the packet was originally received, was
skipping to change at page 69, line 34 skipping to change at page 68, line 29
in the packet's IPv6 header, otherwise. in the packet's IPv6 header, otherwise.
The home agent MUST mark this Binding Cache entry as a "home The home agent MUST mark this Binding Cache entry as a "home
registration" to indicate that the node is serving as a home registration" to indicate that the node is serving as a home
agent for this binding. Binding Cache entries marked as a "home agent for this binding. Binding Cache entries marked as a "home
registration" MUST be excluded from the normal cache replacement registration" MUST be excluded from the normal cache replacement
policy used for the Binding Cache (Section 8.7) and MUST NOT be policy used for the Binding Cache (Section 8.7) and MUST NOT be
removed from the Binding Cache until the expiration of the Lifetime removed from the Binding Cache until the expiration of the Lifetime
period. period.
In addition, the home agent MUST copy the Router (R) bit from the
Binding Update into the corresponding bit in this Binding Cache entry
for this mobile node.
The lifetime for the Binding Cache entry MUST NOT be greater than the The lifetime for the Binding Cache entry MUST NOT be greater than the
remaining valid lifetime for the subnet prefix in the mobile node's remaining valid lifetime for the subnet prefix in the mobile node's
home address specified with the Binding Update, and MUST NOT be home address specified with the Binding Update, and MUST NOT be
greater than the Lifetime value specified in the Binding Update. The greater than the Lifetime value specified in the Binding Update. The
remaining valid lifetime for this prefix is determined by the home remaining valid lifetime for this prefix is determined by the home
agent based on its own Prefix List entry for this prefix [17]. agent based on its own Prefix List entry for this prefix [17].
If the 7-bit Prefix Length field in the Binding Update is nonzero, If the `S' bit field in the Binding Update is zero, The Home Agent
the Home Agent creates or updates Binding Cache entries for each of creates or updates Binding Cache entries for each of possible
possible several home addresses. The set of such home addresses several home addresses. The set of such home addresses is formed
is formed by replacing the routing prefix (as determined by the by replacing the routing prefix for the given home address with
Prefix Length field value) with all other routing prefixes that are all other routing prefixes that are supported by the home agent
supported by the home agent processing the Binding Update. The Home processing the Binding Update. The Home Agent creates such a
Agent creates such a separate primary care-of address registration separate primary care-of address registration for each such home
for each such home address. Furthermore, if the 7-bit Prefix address. Note that the same considerations for Duplicate Address
Length field in the Binding Update is nonzero, then the lifetime for Detection apply for each affected home address. The lifetime for
the each Binding Cache entry MUST NOT be greater than the minimum the each Binding Cache entry MUST NOT be greater than the minimum
remaining valid lifetime for all subnet prefixes on the mobile remaining valid lifetime for all subnet prefixes on the mobile
node's home link. If the value of the Lifetime field specified by node's home link. If the value of the Lifetime field specified by
the mobile node in its Binding Update is greater than this prefix the mobile node in its Binding Update is greater than this prefix
lifetime, the home agent MUST decrease the binding lifetime to less lifetime, the home agent MUST decrease the binding lifetime to less
than or equal to the prefix valid lifetime. The home agent MAY than or equal to the prefix valid lifetime. The home agent MAY
further decrease the specified lifetime for the binding, for example further decrease the specified lifetime for the binding, for example
based on a local policy. The resulting lifetime is stored by the based on a local policy. The resulting lifetime is stored by the
home agent in the Binding Cache entry, and this Binding Cache entry home agent in the Binding Cache entry, and this Binding Cache entry
MUST be deleted by the home agent after the expiration of this MUST be deleted by the home agent after the expiration of this
lifetime. lifetime.
The Prefix Length in the Binding Update MUST also be saved in the
Binding Cache entry.
Regardless of the setting of the 'A' bit in the Binding Update, the Regardless of the setting of the 'A' bit in the Binding Update, the
home agent MUST return a Binding Acknowledgement to the mobile node, home agent MUST return a Binding Acknowledgement to the mobile node,
constructed as follows: constructed as follows:
- The Status field MUST be set to a value indicating success; this - The Status field MUST be set to a value indicating success; this
value MUST be less than 128. The only currently defined success value MUST be less than 128. The only currently defined success
Status value is 0, indicating simply that the Binding Update was Status value is 0, indicating simply that the Binding Update was
accepted. accepted.
- The Sequence Number field MUST be copied from the Sequence Number - The Sequence Number field MUST be copied from the Sequence Number
skipping to change at page 71, line 44 skipping to change at page 70, line 30
- The Sequence Number field MUST be copied from the Sequence Number - The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update. given in the Binding Update.
- The Lifetime field MUST be set to zero. - The Lifetime field MUST be set to zero.
- The Refresh field MUST be set to zero. - The Refresh field MUST be set to zero.
In addition, the home agent MUST stop intercepting packets on the In addition, the home agent MUST stop intercepting packets on the
mobile node's home link addressed to the mobile node (Section 9.3). mobile node's home link addressed to the mobile node (Section 9.3).
The rules for selecting the Destination IP address (and possibly
Routing Header construction) for the Binding Acknowledgement to the
mobile node are the same as in section 8.5.
9.3. Intercepting Packets for a Mobile Node 9.3. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for mobile node (while the While a node is serving as the home agent for mobile node (while the
node has an entry in its Binding Cache for this mobile node that is node has an entry in its Binding Cache for this mobile node that is
marked as a "home registration"), this node MUST attempt to intercept marked as a "home registration"), this node MUST attempt to intercept
packets on the mobile node's home link addressed to the mobile node, packets on the mobile node's home link addressed to the mobile node,
and MUST tunnel each intercepted packet to the mobile node using and MUST tunnel each intercepted packet to the mobile node using
using IPv6 encapsulation [4]. using IPv6 encapsulation [4].
In order to intercept such packets on the home link, when a node In order to intercept such packets on the home link, when a node
begins serving as the home agent for some mobile node (it did not begins serving as the home agent for some mobile node (it did not
already have a Binding Cache entry for this mobile node marked as a already have a Binding Cache entry for this mobile node marked as a
"home registration"), then the home agent MUST multicast onto the "home registration"), then the home agent MUST multicast onto the
home link a "gratuitous" Neighbor Advertisement message [17] on home link a "gratuitous" Neighbor Advertisement message [17] on
behalf of the mobile node. Specifically, the home agent performs the behalf of the mobile node. Specifically, the home agent performs the
following steps: following steps:
- The home agent examines the value of the Prefix Length field - The home agent examines the value of the `S' bit in the new "home
in the new "home registration" Binding Cache entry. If this registration" Binding Cache entry. If this bit is nonzero,
value is zero, the following step is carried out only for the the following step is carried out only for the individual home
individual home address specified for this binding. If, instead, address specified for this binding. If, instead, this bit is
this field is nonzero, then the following step is carried out zero, then the following step is carried out for each address
for each address for the mobile node formed from the interface for the mobile node formed from the interface identifier in
identifier in the mobile node's home address in this binding the mobile node's home address in this binding (the remaining
(the remaining low-order bits in the address after the indicated low-order bits in the address after the configured subnet
subnet prefix), together with each one of the subnet prefixes prefix), together with each one of the subnet prefixes currently
currently considered by the home agent to be on-link (including considered by the home agent to be on-link (including both the
both the link-local and site-local prefix). link-local and site-local prefix).
- For each specific IP address for the mobile node determined - For each specific IP address for the mobile node determined
in the first step above, the home agent multicasts onto the in the first step above, the home agent multicasts onto the
home link (to the all-nodes multicast address) a Neighbor home link (to the all-nodes multicast address) a Neighbor
Advertisement message [17] on behalf of the mobile node, to Advertisement message [17] on behalf of the mobile node, to
advertise the home agent's own link-layer address for this IP advertise the home agent's own link-layer address for this IP
address. address.
All fields in each such Neighbor Advertisement message SHOULD be All fields in each such Neighbor Advertisement message SHOULD be
set in the same way they would be set by the mobile node itself set in the same way they would be set by the mobile node itself
skipping to change at page 75, line 9 skipping to change at page 73, line 51
organization-local) [9], to which the mobile node is subscribed, organization-local) [9], to which the mobile node is subscribed,
SHOULD be tunneled to the mobile node by default, but this behavior SHOULD be tunneled to the mobile node by default, but this behavior
MUST be configurable to disable it; this default behavior might MUST be configurable to disable it; this default behavior might
change at some point in the future as the definition of these scopes change at some point in the future as the definition of these scopes
become more completely defined in IPv6. become more completely defined in IPv6.
9.5. Handling Reverse Tunneled Packets from a Mobile Node 9.5. Handling Reverse Tunneled Packets from a Mobile Node
A home agent MUST support decapsulating reverse tunneled packets A home agent MUST support decapsulating reverse tunneled packets
sent to it from a mobile node's home address. Such reverse tunneled sent to it from a mobile node's home address. Such reverse tunneled
packets MAY be discarded unless accompanied by a valid AH. This packets MAY be discarded unless accompanied by a valid AH or ESP
support for reverse tunneling allows mobile nodes to defeat certain header. This support for reverse tunneling allows mobile nodes to
kinds of traffic analysis. Requiring AH on reverse tunneled packets defeat certain kinds of traffic analysis. Requiring IPsec headers
allows the home agent to protect the home network against unwarranted on reverse tunneled packets allows the home agent to protect the
intrusions by malicious nodes masquerading as a mobile node with a home network against unwarranted intrusions by malicious nodes
home address on the network served by the home agent. masquerading as a mobile node with a home address on the network
served by the home agent.
9.6. Home Prefix Propagation 9.6. Home Prefix Propagation
IPv6 provides mechanisms as part of Neighbor Discovery [17] and IPv6 provides mechanisms as part of Neighbor Discovery [17] and
Address Autoconfiguration [27] to aid in mobile node configuration Address Autoconfiguration [27] to aid in mobile node configuration
when a mobile node turns on, and in renumbering a subnet, such as when a mobile node turns on, and in renumbering a subnet, such as
when a site switches to a new network service provider. when a site switches to a new network service provider.
In renumbering, new prefixes and addresses can be introduced for the In renumbering, new prefixes and addresses can be introduced for the
subnet and old ones can be deprecated and removed. These mechanisms subnet and old ones can be deprecated and removed. These mechanisms
skipping to change at page 76, line 13 skipping to change at page 75, line 8
home agent on the link, in which the Home Agent (H) bit is set, in a home agent on the link, in which the Home Agent (H) bit is set, in a
manner similar to the Default Router List conceptual data structure manner similar to the Default Router List conceptual data structure
maintained by each host for Neighbor Discovery [17]. maintained by each host for Neighbor Discovery [17].
On receipt of a valid Router Advertisement, as defined in the On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [17], the home processing algorithm specified for Neighbor Discovery [17], the home
agent performs the following steps, in addition to any steps already agent performs the following steps, in addition to any steps already
required of it by Neighbor Discovery: required of it by Neighbor Discovery:
- If the Home Agent (H) bit in the Router Advertisement is not set, - If the Home Agent (H) bit in the Router Advertisement is not set,
skip all of the following steps. There are no special processing skip all of the following steps.
steps required by Mobile IP for this Router Advertisement, since
the Advertisement was not sent by a home agent. - If the Home Agent (H) bit in the Router Advertisement is not set,
and the sending node has an entry in the current Home Agents
List, delete the corresponding entry. Subsequently, skip all of
the following steps.
- Otherwise, extract the Source Address from the IP header of the - Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [17]. link of the home agent sending this Advertisement [17].
- Determine from the Router Advertisement the preference for this - Determine from the Router Advertisement the preference for this
home agent. If the Router Advertisement contains a Home Agent home agent. If the Router Advertisement contains a Home Agent
Information Option, then the preference is taken from the Home Information Option, then the preference is taken from the Home
Agent Preference field in the option; otherwise, the default Agent Preference field in the option; otherwise, the default
preference of 0 MUST be used. preference of 0 MUST be used.
skipping to change at page 80, line 11 skipping to change at page 79, line 8
- Delete prefixes from the aggregate list when their valid - Delete prefixes from the aggregate list when their valid
lifetimes expire. lifetimes expire.
The home agent uses the information in the aggregate list to The home agent uses the information in the aggregate list to
construct Mobile Prefix Advertisements, possibly including Binding construct Mobile Prefix Advertisements, possibly including Binding
Acknowledgement or Binding Request destination options, for delivery Acknowledgement or Binding Request destination options, for delivery
to a mobile node for which it is maintaining a current binding. to a mobile node for which it is maintaining a current binding.
It may be possible to construct an aggregate list by combining It may be possible to construct an aggregate list by combining
information contained in the home agent's AdvPrefixList and its information contained in the home agent's AdvPrefixList and its
Home Agent List used for Dynamic Home Agent Address Discovery Home Agents List used for Dynamic Home Agent Address Discovery
(Section 10.8). (Section 10.8).
9.8.2. Scheduling Prefix Deliveries to the Mobile Node 9.8.2. Scheduling Prefix Deliveries to the Mobile Node
A home agent serving a mobile node will schedule the delivery of new A home agent serving a mobile node will schedule the delivery of new
prefix information to that mobile node when any of the following prefix information to that mobile node when any of the following
conditions occur: conditions occur:
MUST: MUST:
skipping to change at page 81, line 5 skipping to change at page 79, line 51
- If a mobile node sends a solicitation, answer right away. - If a mobile node sends a solicitation, answer right away.
- If a prefix in the aggregate list that matches the mobile - If a prefix in the aggregate list that matches the mobile
node's home registration is added, or if its information changes node's home registration is added, or if its information changes
in any way that does not cause the mobile node's address to in any way that does not cause the mobile node's address to
go deprecated, ensure that a transmission is scheduled, and go deprecated, ensure that a transmission is scheduled, and
calculate RAND_ADV_DELAY in order to randomize the time at which calculate RAND_ADV_DELAY in order to randomize the time at which
the transmission is scheduled. the transmission is scheduled.
- If there are any uncknowledged changes to prefix information when - If there are any unacknowledged changes to prefix information
a Binding Update arrives for the home registration, send a Mobile when a Binding Update arrives for the home registration, send
Prefix Advertisement to the mobile node immediately. The Mobile a Mobile Prefix Advertisement to the mobile node immediately.
Prefix Advertisement SHOULD have the Binding Acknowledgement as a
Destination Option. If an advertisement was previously scheduled The Mobile Prefix Advertisement SHOULD have the Binding
for the mobile node, cancel that advertisement. Acknowledgement as a Destination Option. If an advertisement
was previously scheduled for the mobile node, cancel that
advertisement.
- If a home registration expires, cancel any scheduled - If a home registration expires, cancel any scheduled
advertisements to the mobile node. advertisements to the mobile node.
If the home agent already has scheduled the transmission of a Router If the home agent already has scheduled the transmission of a Router
Advertisement to the mobile node, and if the freshly calculated Advertisement to the mobile node, and if the freshly calculated
RAND_ADV_DELAY would cause another transmission BEFORE the Preferred RAND_ADV_DELAY would cause another transmission BEFORE the Preferred
Lifetime of the mobile node's home address derived from the prefix Lifetime of the mobile node's home address derived from the prefix
whose advertisement information has changed, then add the new whose advertisement information has changed, then add the new
information to be transmitted to the existing scheduled transmission. information to be transmitted to the existing scheduled transmission.
skipping to change at page 81, line 32 skipping to change at page 80, line 30
to schedule an advertisement to the mobile node. to schedule an advertisement to the mobile node.
Otherwise, the home agent uses the following algorithm to compute Otherwise, the home agent uses the following algorithm to compute
a fresh value for RAND_ADV_DELAY, the offset from the current time a fresh value for RAND_ADV_DELAY, the offset from the current time
for the scheduled transmission. If there is already a scheduled for the scheduled transmission. If there is already a scheduled
transmission, add the data from the existing scheduled transmission transmission, add the data from the existing scheduled transmission
to the newly scheduled transmission, deleting the previously to the newly scheduled transmission, deleting the previously
scheduled transmission event. scheduled transmission event.
If the mobile node's binding expires before the Preferred Lifetime, If the mobile node's binding expires before the Preferred Lifetime,
then return. The mobile node will get the revised information wth then return. The mobile node will get the revised information with
its next Binding Acknowledgement. Otherwise, continue with the its next Binding Acknowledgement. Otherwise, continue with the
following computation. following computation.
MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime) MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
for the newly advertised Preferred Lifetime. for the newly advertised Preferred Lifetime.
Then compute RAND_ADV_DELAY == Then compute RAND_ADV_DELAY ==
MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt)
RAND_ADV_DELAY is the offset from the current time to be used RAND_ADV_DELAY is the offset from the current time to be used
to schedule the necessary advertisement to the mobile node. The to schedule the necessary advertisement to the mobile node. The
skipping to change at page 83, line 24 skipping to change at page 82, line 22
solicitations until one is received; thus, the home agent SHOULD NOT solicitations until one is received; thus, the home agent SHOULD NOT
retransmit the responding advertisement. retransmit the responding advertisement.
If while the home agent is still retransmitting a Mobile Prefix If while the home agent is still retransmitting a Mobile Prefix
Advertisement to the mobile node, another condition as described Advertisement to the mobile node, another condition as described
above occurs on the home link causing another Prefix Advertisement to above occurs on the home link causing another Prefix Advertisement to
be sent to the mobile node, the home agent SHOULD combine any Prefix be sent to the mobile node, the home agent SHOULD combine any Prefix
Information options in the unacknowledged Mobile Prefix Advertisement Information options in the unacknowledged Mobile Prefix Advertisement
into the new Advertisement, discard the old Advertisement, and then into the new Advertisement, discard the old Advertisement, and then
begin retransmitting the new one. according to the algorithm in begin retransmitting the new one. according to the algorithm in
sectino 9.8.2. The home agent MUST generate a new unique identifier section 9.8.2. The home agent MUST generate a new unique identifier
for use in the Unique Identifier Sub-Option in the Binding Request for use in the Unique Identifier Sub-Option in the Binding Request
tunneled with the new Mobile Prefix Advertisement. tunneled with the new Mobile Prefix Advertisement.
9.8.4. Lifetimes for Changed Prefixes 9.8.4. Lifetimes for Changed Prefixes
As described in Section 9.1, the lifetime returned by the home As described in Section 9.1, the lifetime returned by the home
agent in a Binding Acknowledgement MUST be no greater than the agent in a Binding Acknowledgement MUST be no greater than the
remaining valid lifetime for the subnet prefix in the mobile node's remaining valid lifetime for the subnet prefix in the mobile node's
home address. Furthermore, as described in Section 10.9, Binding home address. Furthermore, as described in Section 10.9, Binding
Updates sent by the mobile node to other nodes MUST use a lifetime no Updates sent by the mobile node to other nodes MUST use a lifetime no
greater than the remaining lifetime of its home registration of its greater than the remaining lifetime of its home registration of its
primary care-of address. These limits on the binding lifetime serve primary care-of address. These limits on the binding lifetime serve
to prohibit use of a mobile node's home address after it becomes to prohibit use of a mobile node's home address after it becomes
invalid. The mobile node SHOULD further limit the lifetimes that it invalid. The mobile node SHOULD further limit the lifetimes that it
sends on any Binding Updates to be within the remaining preferred sends on any Binding Updates to be within the remaining preferred
lifetime for the prefix in its home address. lifetime for the prefix in its home address.
When the lifetime for a changed prefix decreases, and the change When the lifetime for a changed prefix decreases, and the change
would cause cached bindings at correspondent nodes in the Binding would cause cached bindings at correspondent nodes in the Binding
Update List to be stored past the newly shortened lifetime, the Update List to be stored past the newly shortened lifetime, the
mobile ndoe MUST issue a Binding Update to all such correspondent mobile node MUST issue a Binding Update to all such correspondent
nodes. nodes.
10. Mobile Node Operation 10. Mobile Node Operation
10.1. Sending Packets While Away from Home 10.1. Sending Packets While Away from Home
While a mobile node is away from home, it continues to use its home While a mobile node is away from home, it continues to use its home
address as well as also using one or more care-of addresses. When address as well as also using one or more care-of addresses. When
sending a packet while away from home, a mobile node MAY choose among sending a packet while away from home, a mobile node MAY choose among
these in selecting the address that it will use as the source of the these in selecting the address that it will use as the source of the
skipping to change at page 88, line 10 skipping to change at page 87, line 10
node sent a Binding Update to a home agent on the link on which node sent a Binding Update to a home agent on the link on which
its previous care-of address is located (Section 10.10), and its previous care-of address is located (Section 10.10), and
if this home agent is still serving as a home agent for the if this home agent is still serving as a home agent for the
mobile node's previous care-of address, then such a packet will mobile node's previous care-of address, then such a packet will
be intercepted by this home agent, encapsulated using IPv6 be intercepted by this home agent, encapsulated using IPv6
encapsulation [4], and tunneled to the mobile node's new care-of encapsulation [4], and tunneled to the mobile node's new care-of
address (registered with this home agent). address (registered with this home agent).
For packets received by either the first or last of these three For packets received by either the first or last of these three
methods, the mobile node SHOULD send a Binding Update to the original methods, the mobile node SHOULD send a Binding Update to the original
sender of the packet, as described in Section 10.9, subject to the sender of the packet, as described in Section 10.9, subject to
rate limiting defined in Section 10.12. The mobile node SHOULD the rate limiting defined in Section 10.12. The mobile node MUST
also process the received packet in the manner defined for IPv6 also process the received packet in the manner defined for IPv6
encapsulation [4], which will result in the encapsulated (inner) encapsulation [4], which will result in the encapsulated (inner)
packet being processed normally by upper-layer protocols within the packet being processed normally by upper-layer protocols within the
mobile node, as if it had been addressed (only) to the mobile node's mobile node, as if it had been addressed (only) to the mobile node's
home address. home address.
For packets received by the second method above (using a Routing For packets received by the second method above (using a Routing
header), the mobile node SHOULD process the received packet in the header), the mobile node MUST process the received packet in the
manner defined for the type of IPv6 Routing header used [6], which manner defined for the type of IPv6 Routing header used [6], which
will result in the packet being processed normally by upper-layer will result in the packet being processed normally by upper-layer
protocols within the mobile node, as if it had been addressed (only) protocols within the mobile node, as if it had been addressed (only)
to the mobile node's home address. to the mobile node's home address.
In addition, the general procedures defined by IPv6 for Routing In addition, the general procedures defined by IPv6 for Routing
headers suggest that a received Routing header MAY be automatically headers suggest that a received Routing header MAY be automatically
"reversed" to construct a Routing header for use in any response "reversed" to construct a Routing header for use in any response
packets sent by upper-layer protocols, if the received packet is packets sent by upper-layer protocols, if the received packet is
authenticated [6]. If this is done for upper-layer protocol response authenticated [6]. If this is done for upper-layer protocol response
skipping to change at page 89, line 13 skipping to change at page 88, line 13
Advertisement messages, as specified for Router Discovery [17]. Advertisement messages, as specified for Router Discovery [17].
Based on received Router Advertisement messages, a mobile node (in Based on received Router Advertisement messages, a mobile node (in
the same way as any other node) maintains an entry in its Default the same way as any other node) maintains an entry in its Default
Router List for each router, and an entry in its Prefix List for each Router List for each router, and an entry in its Prefix List for each
subnet prefix, that it currently considers to be on-link. Each entry subnet prefix, that it currently considers to be on-link. Each entry
in these lists has an associated invalidation timer value (extracted in these lists has an associated invalidation timer value (extracted
from the Router Advertisement and Prefix Information options) used to from the Router Advertisement and Prefix Information options) used to
expire the entry when it becomes invalid. expire the entry when it becomes invalid.
While away from home, a mobile node SHOULD select one router from While away from home, a mobile node typically selects one router
its Default Router List to use as its default router, and one subnet from its Default Router List to use as its default router, and one
prefix advertised by that router from its Prefix List to use as subnet prefix advertised by that router from its Prefix List to use
the subnet prefix in its primary care-of address. A mobile node as the subnet prefix in its primary care-of address. A mobile node
MAY also have associated additional care-of addresses, using other MAY also have associated additional care-of addresses, using other
subnet prefixes from its Prefix List. The method by which a mobile subnet prefixes from its Prefix List. The method by which a mobile
node selects and forms a care-of address from the available subnet node selects and forms a care-of address from the available subnet
prefixes is described in Section 10.6. The mobile node registers prefixes is described in Section 10.6. The mobile node registers
its primary care-of address with its home agent, as described in its primary care-of address with its home agent, as described in
Section 10.7. Section 10.7.
While a mobile node is away from home and using some router as its While a mobile node is away from home and using some router as its
default router, it is important for the mobile node to be able to default router, it is important for the mobile node to be able to
quickly detect when that router becomes unreachable, so that it can quickly detect when that router becomes unreachable, so that it
switch to a new default router and to a new primary care-of address. can switch to a new default router and (if needed, according to
Since some links (notably wireless) do not necessarily work equally prefix advertisement) to a new primary care-of address. Since some
well in both directions, it is likewise important for the mobile links (notably wireless) do not necessarily work equally well in
node to detect when it becomes unreachable for packets sent from its both directions, it is likewise important for the mobile node to
default router, so that the mobile node can take steps to ensure that detect when it becomes unreachable for packets sent from its default
any correspondent nodes attempting to communicate with it can still router, so that the mobile node can take steps to ensure that any
reach it through some other route. correspondent nodes attempting to communicate with it can still reach
it through some other route.
To detect when its default router becomes unreachable, a mobile To detect when its default router becomes unreachable, a mobile
node SHOULD use Neighbor Unreachability Detection. As specified in node SHOULD use Neighbor Unreachability Detection. As specified in
Neighbor Discovery [17], while the mobile node is actively sending Neighbor Discovery [17], while the mobile node is actively sending
packets to (or through) its default router, the mobile node can packets to (or through) its default router, the mobile node can
detect that the router (as its neighbor) is still reachable either detect that the router (as its neighbor) is still reachable either
through indications from upper layer protocols on the mobile node through indications from upper layer protocols on the mobile node
that a connection is making "forward progress" (e.g., receipt of TCP that a connection is making "forward progress" (e.g., receipt of TCP
acknowledgements for new data transmitted), or through receipt of a acknowledgements for new data transmitted), or through receipt of a
Neighbor Advertisement message from its default router in response Neighbor Advertisement message from its default router in response
skipping to change at page 90, line 40 skipping to change at page 89, line 41
supplement this monitoring of Router Advertisements, by setting its supplement this monitoring of Router Advertisements, by setting its
network interface into "promiscuous" receive mode, so that it is able network interface into "promiscuous" receive mode, so that it is able
to receive all packets on the link, including those not link-level to receive all packets on the link, including those not link-level
addressed to it (i.e., disabling link-level address filtering). The addressed to it (i.e., disabling link-level address filtering). The
mobile node will then be able to detect any packets sent by the mobile node will then be able to detect any packets sent by the
router, in order to detect reachability from the router. This use of router, in order to detect reachability from the router. This use of
promiscuous mode may be useful on very low bandwidth (e.g., wireless) promiscuous mode may be useful on very low bandwidth (e.g., wireless)
links, but its use MUST be configurable on the mobile node since it links, but its use MUST be configurable on the mobile node since it
is likely to consume additional energy resources. is likely to consume additional energy resources.
If the above means do not provide indication that the mobile node is If the above means do not provide indication that the mobile node
still reachable from its current default router (i.e., the mobile is still reachable from its current default router (for instance,
node receives no packets from the router for a period of time), then the mobile node receives no packets from the router for a period
the mobile node SHOULD attempt to actively probe the router with of time), then the mobile node SHOULD attempt to actively probe
Neighbor Solicitation messages, even if it is not otherwise actively the router with Neighbor Solicitation messages, even if it is not
sending packets to the router. If it receives a solicited Neighbor otherwise actively sending packets to the router. If it receives a
Advertisement message in response from the router, then the mobile solicited Neighbor Advertisement message in response from the router,
node can deduce that it is still reachable. It is expected that the then the mobile node can deduce that it is still reachable. It is
mobile node will in most cases be able to determine its reachability expected that the mobile node will in most cases be able to determine
from the router by listening for packets from the router as described its reachability from the router by listening for packets from the
above, and thus, such extra Neighbor Solicitation probes should router as described above, and thus, such extra Neighbor Solicitation
rarely be necessary. probes should rarely be necessary.
With some types of networks, indications about link-layer mobility With some types of networks, indications about link-layer mobility
might be obtained from lower-layer protocol or device driver software might be obtained from lower-layer protocol or device driver software
within the mobile node. However, all link-layer mobility indications within the mobile node. However, all link-layer mobility indications
from lower layers do not necessarily indicate a movement of the from lower layers do not necessarily indicate a movement of the
mobile node to a new link, such that the mobile node would need to mobile node to a new link, such that the mobile node would need to
switch to a new default router and primary care-of address. For switch to a new default router and primary care-of address. For
example, movement of a mobile node from one cell to another in many example, movement of a mobile node from one cell to another in many
wireless LANs can be made transparent to the IP level through use of wireless LANs can be made transparent to the IP level through use of
a link-layer "roaming" protocol, as long as the different wireless a link-layer "roaming" protocol, as long as the different wireless
LAN cells all operate as part of the same IP link with the same LAN cells all operate as part of the same IP link with the same
subnet prefix. Upon lower-layer indication of link-layer mobility, subnet prefix. Upon lower-layer indication of link-layer mobility,
the mobile node MAY send Router Solicitation messages to determine if the mobile node MAY send Router Solicitation messages to determine if
new routers (and new on-link subnet prefixes) are present on its new additional on-link subnet prefixes are available on its new link.
link.
Such lower-layer information might also be useful to a mobile node in Such lower-layer information might also be useful to a mobile node in
deciding to switch its primary care-of address to one of the other deciding to switch its primary care-of address to one of the other
care-of addresses it has formed from the on-link subnet prefixes care-of addresses it has formed from the on-link subnet prefixes
currently available through different routers from which the mobile currently available through different routers from which the mobile
node is reachable. For example, a mobile node MAY use signal node is reachable. For example, a mobile node MAY use signal
strength or signal quality information (with suitable hysteresis) for strength or signal quality information (with suitable hysteresis) for
its link with the available routers to decide when to switch to a new its link with the available routers to decide when to switch to a new
primary care-of address using that router rather than its current primary care-of address using that router rather than its current
default router (and current primary care-of address). Even though default router (and current primary care-of address). Even though
skipping to change at page 91, line 46 skipping to change at page 90, line 48
Advertisement has not yet expired. This list is used by the mobile Advertisement has not yet expired. This list is used by the mobile
node to enable it to send a Binding Update to the global unicast node to enable it to send a Binding Update to the global unicast
address of a home agent on its previous link when it moves to a new address of a home agent on its previous link when it moves to a new
link, as described in Section 10.10. On receipt of a valid Router link, as described in Section 10.10. On receipt of a valid Router
Advertisement, as defined in the processing algorithm specified for Advertisement, as defined in the processing algorithm specified for
Neighbor Discovery [17], the mobile node performs the following Neighbor Discovery [17], the mobile node performs the following
steps, in addition to any steps already required of it by Neighbor steps, in addition to any steps already required of it by Neighbor
Discovery. Discovery.
- If the Home Agent (H) bit in the Router Advertisement is not set, - If the Home Agent (H) bit in the Router Advertisement is not set,
skip all of the following steps. Mobile IPv6 requires no special and the sending node currently has an entry in the node's Home
processing steps for this Router Advertisement. Agents List, delete the corresponding entry. Subsequently, skip
all of the following steps.
- Otherwise, extract the Source Address from the IP header of the - Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [17]. link of the home agent sending this Advertisement [17].
- Determine from the Router Advertisement the preference for this - Determine from the Router Advertisement the preference for this
home agent. If the Router Advertisement contains a Home Agent home agent. If the Router Advertisement contains a Home Agent
Information Option, then the preference is taken from the Home Information Option, then the preference is taken from the Home
Agent Preference field in the option; otherwise, the default Agent Preference field in the option; otherwise, the default
preference of 0 MUST be used. preference of 0 MUST be used.
skipping to change at page 94, line 39 skipping to change at page 93, line 39
- The Acknowledge (A) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update.
- The packet MUST contain a Home Address option, giving the mobile - The packet MUST contain a Home Address option, giving the mobile
node's home address for the binding. node's home address for the binding.
- The care-of address for the binding MUST be used as the Source - The care-of address for the binding MUST be used as the Source
Address in the packet's IPv6 header, unless an Alternate Care-of Address in the packet's IPv6 header, unless an Alternate Care-of
Address sub-option is included in the Binding Update option. Address sub-option is included in the Binding Update option.
- The Prefix Length field SHOULD be set to the length of the mobile - The `S' bit is set to the zero to request the mobile node's home
node's subnet prefix in its home address, to request the mobile agent to serve as a home agent for all home addresses for the
node's home agent to serve as a home agent for all home addresses mobile node based on all on-link subnet prefixes on the home
for the mobile node based on all on-link subnet prefixes on the link; this is the default behavior. If the mobile node desires
home link. Otherwise, this field MUST be set to zero. that only a single home address should be affected by this
Binding Update, the `S' bit can be set to 1.
- The value specified in the Lifetime field SHOULD be less than - The value specified in the Lifetime field SHOULD be less than
or equal to the remaining lifetime of the home address and the or equal to the remaining lifetime of the home address and the
care-of address specified for the binding. care-of address specified for the binding.
The Acknowledge (A) bit in the Binding Update requests the home The Acknowledge (A) bit in the Binding Update requests the home
agent to return a Binding Acknowledgement in response to this agent to return a Binding Acknowledgement in response to this
Binding Update. As described in Section 5.2, the mobile node Binding Update. As described in Section 5.2, the mobile node SHOULD
SHOULD retransmit this Binding Update to its home agent until retransmit this Binding Update to its home agent until it receives
it receives a matching Binding Acknowledgement. Once reaching a a matching Binding Acknowledgement. Once reaching a retransmission
retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
node SHOULD continue to periodically retransmit the Binding Update the process of delivering the Binding Update, but trying instead the
next Home Agent from its Home Agent list (see section 10.8). If
there is only one home agent in the Home Agent list, the mobile node
instead SHOULD continue to periodically retransmit the Binding Update
at this rate until acknowledged (or until it begins attempting to at this rate until acknowledged (or until it begins attempting to
register a different primary care-of address). See section 10.11 for register a different primary care-of address). See section 10.11 for
information about retransmitting Binding Updates. information about retransmitting Binding Updates.
The Prefix Length field in the Binding Update allows the mobile node The Prefix Length field in the Binding Update allows the mobile node
to request its home agent to serve all home addresses for the mobile to request its home agent to serve all home addresses for the mobile
node, as indicated by the interface identifier in the mobile node's node, as indicated by the interface identifier in the mobile node's
home address (the remaining low-order bits after the indicated subnet home address (the remaining low-order bits after the indicated subnet
prefix), together with each on-link subnet prefix on the home link. prefix), together with each on-link subnet prefix on the home link.
Until the lifetime of this registration expires, the home agent Until the lifetime of this registration expires, the home agent
skipping to change at page 96, line 8 skipping to change at page 95, line 12
its home address and a care-of address. If some time elapses during its home address and a care-of address. If some time elapses during
which the mobile node has no binding at the home agent, it might be which the mobile node has no binding at the home agent, it might be
possible for another node to autoconfigure the mobile node's home possible for another node to autoconfigure the mobile node's home
address. Therefore, the mobile node MUST treat creation of a new address. Therefore, the mobile node MUST treat creation of a new
binding with the home agent using an existing home address the same binding with the home agent using an existing home address the same
as creation of a new home address. In the unlikely event that the as creation of a new home address. In the unlikely event that the
mobile node's home address is autoconfigured as the IPv6 address mobile node's home address is autoconfigured as the IPv6 address
of another network node on the home network, the home agent will of another network node on the home network, the home agent will
reply to the mobile node's subsequent Binding Update with a Binding reply to the mobile node's subsequent Binding Update with a Binding
Acknowledgement showing Status 138, Duplicate Address Detection Acknowledgement showing Status 138, Duplicate Address Detection
failed. failed. In this case, the mobile node MUST NOT attempt to re-use
the same home address. It SHOULD continue to register care-of
addresses for its other home addresses, if any. The mobile node MAY
also attempt to acquire a new home address to replace the one for
which Status 138 was received, for instance by using the techniques
described in appendix B.
10.8. Dynamic Home Agent Address Discovery 10.8. Dynamic Home Agent Address Discovery
Sometimes, when the mobile node needs to send a Binding Update to its Sometimes, when the mobile node needs to send a Binding Update to its
home agent to register its new primary care-of address, as described home agent to register its new primary care-of address, as described
in Section 10.7, the mobile node may not know the address of any in Section 10.7, the mobile node may not know the address of any
router on its home link that can serve as a home agent for it. For router on its home link that can serve as a home agent for it. For
example, some nodes on its home link may have been reconfigured while example, some nodes on its home link may have been reconfigured while
the mobile node has been away from home, such that the router that the mobile node has been away from home, such that the router that
was operating as the mobile node's home agent has been replaced by a was operating as the mobile node's home agent has been replaced by a
skipping to change at page 97, line 15 skipping to change at page 96, line 22
If the mobile node has a current registration with some home agent If the mobile node has a current registration with some home agent
on its home link (the Lifetime for that registration has not yet on its home link (the Lifetime for that registration has not yet
expired), then the mobile node MUST attempt any new registration expired), then the mobile node MUST attempt any new registration
first with that home agent. If that registration attempt fails first with that home agent. If that registration attempt fails
(e.g., times out or is rejected), the mobile node SHOULD then (e.g., times out or is rejected), the mobile node SHOULD then
reattempt this registration with another home agent on its home link. reattempt this registration with another home agent on its home link.
If the mobile node knows of no other suitable home agent, then it MAY If the mobile node knows of no other suitable home agent, then it MAY
attempt the dynamic home agent address discovery mechanism described attempt the dynamic home agent address discovery mechanism described
above. above.
If, after a mobile node transmits a Home Agent Address Discovery
Request message to the Home Agents Anycast address, it does not
receive a corresponding Home Agent Address Discovery Reply message
within INITIAL_DHAAD_TIMEOUT seconds, the mobile node MAY retransmit
the same Request message to the same anycast address. This
retransmission MAY be repeated up to a maximum of DHAAD_RETRIES
attempts. Each retransmission MUST be delayed by twice the time
interval of the previous retransmission.
10.9. Sending Binding Updates to Correspondent Nodes 10.9. Sending Binding Updates to Correspondent Nodes
A mobile node MAY send a Binding Update to any correspondent node at When the mobile node is assured that its home address is valid,
any time to allow the correspondent node to cache the mobile node's it MAY send a Binding Update to any correspondent node at any
time to allow the correspondent node to cache the mobile node's
current care-of address (subject to the rate limiting defined in current care-of address (subject to the rate limiting defined in
Section 10.12). In any Binding Update sent by a mobile node, the Section 10.12). See for example the home agent's use the 'D' bit
care-of address (either the Source Address in the packet's IPv6 of Binding Updates (in section 9.1) for how the mobile node can be
header or the Care-of Address in the Alternate Care-of Address assured that its home address is still valid. In any Binding Update
Sub-Option of the Binding Update) MUST be set to one of the care-of sent by a mobile node, the care-of address (either the Source Address
addresses currently in use by the mobile node or to the mobile node's in the packet's IPv6 header or the Care-of Address in the Alternate
home address. Care-of Address Sub-Option of the Binding Update) MUST be set to one
of the care-of addresses currently in use by the mobile node or to
the mobile node's home address.
A mobile node MAY choose to keep its location private from certain
correspondent nodes, and thus need not send new Binding Updates to
those correspondents. A mobile node MAY also send a Binding Update
to such a correspondent node to instruct it to delete any existing
binding for the mobile node from its Binding Cache, as described in
Section 5.1. No other IPv6 nodes are authorized to send Binding
Updates on behalf of a mobile node.
If set to one of the mobile node's current care-of addresses (the If set to one of the mobile node's current care-of addresses (the
care-of address given MAY differ from the mobile node's primary care-of address given MAY differ from the mobile node's primary
care-of address), the Binding Update requests the correspondent node care-of address), the Binding Update requests the correspondent node
to create or update an entry for the mobile node in the correspondent to create or update an entry for the mobile node in the correspondent
node's Binding Cache to record this care-of address for use in node's Binding Cache to record this care-of address for use in
sending future packets to the mobile node. In this case, the value sending future packets to the mobile node. In this case, the value
specified in the Lifetime field sent in the Binding Update SHOULD be specified in the Lifetime field sent in the Binding Update SHOULD be
less than or equal to the remaining lifetime of the home address and less than or equal to the remaining lifetime of the home address and
the care-of address specified for the binding. the care-of address specified for the binding.
skipping to change at page 99, line 34 skipping to change at page 99, line 10
Binding Updates sent to correspondent nodes are not generally Binding Updates sent to correspondent nodes are not generally
required to be acknowledged. However, if the mobile node wants required to be acknowledged. However, if the mobile node wants
to be sure that its new care-of address has been entered into a to be sure that its new care-of address has been entered into a
correspondent node's Binding Cache, the mobile node MAY request an correspondent node's Binding Cache, the mobile node MAY request an
acknowledgement by setting the Acknowledge (A) bit in the Binding acknowledgement by setting the Acknowledge (A) bit in the Binding
Update. In this case, however, the mobile node SHOULD NOT continue Update. In this case, however, the mobile node SHOULD NOT continue
to retransmit the Binding Update once the retransmission timeout to retransmit the Binding Update once the retransmission timeout
period has reached MAX_BINDACK_TIMEOUT. period has reached MAX_BINDACK_TIMEOUT.
A mobile node MAY choose to keep its location private from certain
correspondent nodes, and thus need not send new Binding Updates to
those correspondents. A mobile node MAY also send a Binding Update
to such a correspondent node to instruct it to delete any existing
binding for the mobile node from its Binding Cache, as described in
Section 5.1. No other IPv6 nodes are authorized to send Binding
Updates on behalf of a mobile node.
10.10. Establishing Forwarding from a Previous Care-of Address 10.10. Establishing Forwarding from a Previous Care-of Address
When a mobile node connects to a new link and forms a new care-of When a mobile node connects to a new link and forms a new care-of
address, it MAY establish forwarding of packets from a previous address, it MAY establish forwarding of packets from a previous
care-of address to this new care-of address. To do so, the mobile care-of address to this new care-of address. To do so, the mobile
node sends a Binding Update to any home agent on the link on which node sends a Binding Update to any home agent on the link on which
the previous care-of address is located, indicating this previous the previous care-of address is located, indicating this previous
care-of address as the home address for the binding, and giving its care-of address as the home address for the binding, and giving its
new care-of address as the binding's care-of address. Such packet new care-of address as the binding's care-of address. Such packet
forwarding allows packets destined to the mobile node from nodes that forwarding allows packets destined to the mobile node from nodes that
skipping to change at page 103, line 26 skipping to change at page 102, line 44
in the same way as for any other Binding Update sent by the mobile in the same way as for any other Binding Update sent by the mobile
node. node.
Note, however, that the mobile node MAY choose to keep its current Note, however, that the mobile node MAY choose to keep its current
binding private from the sender of the Binding Request. In this binding private from the sender of the Binding Request. In this
case, the mobile node instead SHOULD return a Binding Update to the case, the mobile node instead SHOULD return a Binding Update to the
sender, in which the Lifetime field is set to zero and the care-of sender, in which the Lifetime field is set to zero and the care-of
address is set to the mobile node's home address. address is set to the mobile node's home address.
If the Binding Request for which the Binding Update is being returned If the Binding Request for which the Binding Update is being returned
contains a Unique Identifer Sub-Option, the Binding Update MUST also contains a Unique Identifier Sub-Option, the Binding Update MUST also
include a Unique Identifier Sub-Option. The unique identifier in the include a Unique Identifier Sub-Option. The unique identifier in the
Sub-Option Data field of the Unique Identifier Sub-Option MUST be Sub-Option Data field of the Unique Identifier Sub-Option MUST be
copied from the unique identifier carried in the Binding Request. copied from the unique identifier carried in the Binding Request.
10.15. Receiving ICMP Error Messages 10.15. Receiving ICMP Error Messages
The Option Type value for a Binding Update option specifies that The Option Type value for a Binding Update option specifies that
any node receiving this option that does not recognize the Option any node receiving this option that does not recognize the Option
Type SHOULD return an ICMP Parameter Problem, Code 2, message to Type SHOULD return an ICMP Parameter Problem, Code 2, message to
the sender of the packet containing the Binding Update option. If the sender of the packet containing the Binding Update option. If
skipping to change at page 108, line 8 skipping to change at page 107, line 26
then it SHOULD perform DAD. then it SHOULD perform DAD.
After the Mobile Node sends the Binding Update, the Home Agent MUST After the Mobile Node sends the Binding Update, the Home Agent MUST
remove the Proxy Neighbor Cache entry for the Mobile Node and MAY remove the Proxy Neighbor Cache entry for the Mobile Node and MAY
learn its link-layer address based on the link-layer packet or cached learn its link-layer address based on the link-layer packet or cached
information, or if that is not available, it SHOULD send a Neighbor information, or if that is not available, it SHOULD send a Neighbor
Solicitation with the target address equal to the Binding Update's Solicitation with the target address equal to the Binding Update's
source IP address. The Mobile Node MUST then reply with a unicast source IP address. The Mobile Node MUST then reply with a unicast
Neighbor Advertisement to the Home Agent with its link-layer address. Neighbor Advertisement to the Home Agent with its link-layer address.
While the Mobile Node is waiting for a Binding Acknowledgement, it While the Mobile Node is waiting for a Binding Acknowledgement, it
MUST NOT respond to any Neighbor Solicitations other than those MUST NOT respond to any Neighbor Solicitations for its Home Address
originating from the IP address to which it sent the Binding Update. other than those originating from the IP address to which it sent the
Binding Update.
After receiving the Binding Acknowledgement for its Binding Update After receiving the Binding Acknowledgement for its Binding Update
to its home agent, the mobile node MUST multicast onto the home to its home agent, the mobile node MUST multicast onto the home
link (to the all-nodes multicast address) a Neighbor Advertisement link (to the all-nodes multicast address) a Neighbor Advertisement
message [17], to advertise the mobile node's own link-layer address message [17], to advertise the mobile node's own link-layer address
for its own home address. The Target Address in this Neighbor for its own home address. The Target Address in this Neighbor
Advertisement message MUST be set to the mobile node's home address, Advertisement message MUST be set to the mobile node's home address,
and the Advertisement MUST include a Target Link-layer Address option and the Advertisement MUST include a Target Link-layer Address option
specifying the mobile node's link-layer address. The mobile node specifying the mobile node's link-layer address. The mobile node
MUST multicast such a Neighbor Advertisement message for each of its MUST multicast such a Neighbor Advertisement message for each of its
skipping to change at page 108, line 38 skipping to change at page 108, line 7
Since multicasts on the local link (such as Ethernet) are typically Since multicasts on the local link (such as Ethernet) are typically
not guaranteed to be reliable, the mobile node MAY retransmit these not guaranteed to be reliable, the mobile node MAY retransmit these
Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to
increase their reliability. It is still possible that some nodes on increase their reliability. It is still possible that some nodes on
the home link will not receive any of these Neighbor Advertisements, the home link will not receive any of these Neighbor Advertisements,
but these nodes will eventually be able to recover through use of but these nodes will eventually be able to recover through use of
Neighbor Unreachability Detection [17]. Neighbor Unreachability Detection [17].
11. Protocol Constants 11. Protocol Constants
HomeRtrAdvInterval 3,600 seconds
DHAAD_RETRIES 3 retransmissions
INITIAL_BINDACK_TIMEOUT 1 second INITIAL_BINDACK_TIMEOUT 1 second
INITIAL_DHAAD_TIMEOUT 2 seconds
INITIAL_SOLICIT_TIMER 2 seconds INITIAL_SOLICIT_TIMER 2 seconds
MAX_BINDACK_TIMEOUT 256 seconds MAX_BINDACK_TIMEOUT 256 seconds
PREFIX_ADV_TIMEOUT 5 seconds
PREFIX_ADV_RETRIES 3 retransmissions
MAX_UPDATE_RATE once per second MAX_UPDATE_RATE once per second
SLOW_UPDATE_RATE once per 10 second interval
MAX_FAST_UPDATES 5 transmissions MAX_FAST_UPDATES 5 transmissions
MAX_ADVERT_REXMIT 3 transmissions MAX_ADVERT_REXMIT 3 transmissions
MAX_PFX_ADV_DELAY 1,000 seconds MAX_PFX_ADV_DELAY 1,000 seconds
PREFIX_ADV_RETRIES 3 retransmissions
HomeRtrAdvInterval 3,600 seconds PREFIX_ADV_TIMEOUT 5 seconds
SLOW_UPDATE_RATE once per 10 second interval
12. IANA Considerations 12. IANA Considerations
This document defines four new types of IPv6 destination options, This document defines four new types of IPv6 destination options,
each of which must be assigned an Option Type value: each of which must be assigned an Option Type value:
- The Binding Update option, described in Section 5.1; - The Binding Update option, described in Section 5.1;
- The Binding Acknowledgement option, described in Section 5.2; - The Binding Acknowledgement option, described in Section 5.2;
skipping to change at page 110, line 28 skipping to change at page 109, line 28
These destination options can sometimes take sub-options. The These destination options can sometimes take sub-options. The
current sub-options are specified in section 5.5, "Mobile IPv6 current sub-options are specified in section 5.5, "Mobile IPv6
Destination Option Sub-Options", and include the following: Destination Option Sub-Options", and include the following:
0 Pad1 sub-option 0 Pad1 sub-option
1 PadN sub-option 1 PadN sub-option
2 Unique Identifier sub-option 2 Unique Identifier sub-option
3 Mobile Router Prefix Length sub-option 3 Alternate Care-of Address sub-option
4 Alternate Care-of Address sub-option 4 Authentication Data sub-option
In addition, this document defines four ICMP message types, two used In addition, this document defines four ICMP message types, two used
as part of the dynamic home agent address discovery mechanism and as part of the dynamic home agent address discovery mechanism and
two used in lieu of router solicitations and advertisements when the two used in lieu of router solicitations and advertisements when the
mobile node is away from the home link: mobile node is away from the home link:
- The Home Agent Address Discovery Request message, described in - The Home Agent Address Discovery Request message, described in
Section 5.6; Section 5.7;
- The Home Agent Address Discovery Reply message, described in - The Home Agent Address Discovery Reply message, described in
Section 5.7; Section 5.8;
- The Mobile Prefix Solicitation message, described in Section 5.8; - The Mobile Prefix Solicitation message, described in Section 5.9;
and and
- The Mobile Prefix Advertisement message, described in - The Mobile Prefix Advertisement message, described in
Section 5.9. Section 5.10.
This document also defines two new Neighbor Discovery [17] options, This document also defines two new Neighbor Discovery [17] options,
which must be assigned Option Type values within the option numbering which must be assigned Option Type values within the option numbering
space for Neighbor Discovery messages: space for Neighbor Discovery messages:
- The Advertisement Interval option, described in Section 6.3; and - The Advertisement Interval option, described in Section 6.3; and
- The Home Agent Information option, described in Section 6.4. - The Home Agent Information option, described in Section 6.4.
A new space of predefined SPIs for Binding Security Associations must A new space of predefined SPIs for Binding Security Associations must
skipping to change at page 112, line 35 skipping to change at page 111, line 35
the sender or the receiver. Issues with binding privacy stemming the sender or the receiver. Issues with binding privacy stemming
from use of the Binding Request option can be dealt with either from use of the Binding Request option can be dealt with either
through existing IPsec encryption mechanisms or through use of through existing IPsec encryption mechanisms or through use of
firewalls. firewalls.
After the Sequence Number space of the Binding Update and Binding After the Sequence Number space of the Binding Update and Binding
Acknowledgement options has been exhausted, the mobile node and the Acknowledgement options has been exhausted, the mobile node and the
home agent SHOULD renegotiate their security association in order to home agent SHOULD renegotiate their security association in order to
prevent any possibility of replay attacks. prevent any possibility of replay attacks.
The only way binding cache entries can be deleted is through Binding
Updates and persistent ICMP unreachables messages. The former
are required to be authenticated, but not the latter. Therefore,
unauthenticated ICMP messages can unfortunately be used for DoS
attacks. However, the security exposure is limited, since the effect
would be only to cause packets for the mobile node to be sent by way
of the mobile node's home network.
13.2. Security for the Home Address Option 13.2. Security for the Home Address Option
No special authentication of the Home Address option is required, No special authentication of the Home Address option is required,
except that if the IPv6 header of a packet is covered by except that if the IPv6 header of a packet is covered by
authentication, then that authentication MUST also cover the Home authentication, then that authentication MUST also cover the Home
Address option; this coverage is achieved automatically by the Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option definition of the Option Type code for the Home Address option
(Section 5.4), since it indicates that the option is included in the (Section 5.4), since it indicates that the option is included in the
authentication computation. Thus, even when authentication is used authentication computation. Thus, even when authentication is used
in the IPv6 header, the security of the Source Address field in the in the IPv6 header, the security of the Source Address field in the
skipping to change at page 113, line 12 skipping to change at page 112, line 20
mobile node to pass normally through routers implementing ingress mobile node to pass normally through routers implementing ingress
filtering [7]. Since the care-of address used in the Source Address filtering [7]. Since the care-of address used in the Source Address
field of the packet's IPv6 header is topologically correct for the field of the packet's IPv6 header is topologically correct for the
sending location of the mobile node, ingress filtering can trace the sending location of the mobile node, ingress filtering can trace the
location of the mobile node in the same way as can be done with any location of the mobile node in the same way as can be done with any
sender when ingress filtering is in use. A node receiving a packet sender when ingress filtering is in use. A node receiving a packet
that includes a Home Address option MAY implement the processing of that includes a Home Address option MAY implement the processing of
this option by physically exchanging the Home Address option field this option by physically exchanging the Home Address option field
with the source IPv6 address in the IPv6 header. with the source IPv6 address in the IPv6 header.
Notice that use of the Home Address option is conceptually similar to
a particular use of encapsulation, with both the inner and outer IPv6
header equal to the Correspondent Node's address. This is important
for understanding the security implications surrounding the use of
the Home Address option.
13.3. General Mobile Computing Issues 13.3. General Mobile Computing Issues
The mobile computing environment is potentially very different from The mobile computing environment is potentially very different from
the ordinary computing environment. In many cases, mobile computers the ordinary computing environment. In many cases, mobile computers
will be connected to the network via wireless links. Such links will be connected to the network via wireless links. Such links
are particularly vulnerable to passive eavesdropping, active replay are particularly vulnerable to passive eavesdropping, active replay
attacks, and other active attacks. Furthermore, mobile computers attacks, and other active attacks. Furthermore, mobile computers
are more susceptible to loss or theft than stationary computers. are more susceptible to loss or theft than stationary computers.
Any secrets such as authentication or encryption keys stored on the Any secrets such as authentication or encryption keys stored on the
mobile computer are thus subject to compromise in ways generally not mobile computer are thus subject to compromise in ways generally not
skipping to change at page 113, line 50 skipping to change at page 113, line 14
foreign network and has sent a Binding Update to its home agent, then foreign network and has sent a Binding Update to its home agent, then
the mobile node may need to make use of security features in order to the mobile node may need to make use of security features in order to
communicate with that same correspondent node. communicate with that same correspondent node.
Acknowledgements Acknowledgements
We would like to thank the members of the Mobile IP and IPng Working We would like to thank the members of the Mobile IP and IPng Working
Groups for their comments and suggestions on this work. We would Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) Fred Baker particularly like to thank (in alphabetical order) Fred Baker
(Cisco), Josh Broch (Carnegie Mellon University), Robert Chalmers (Cisco), Josh Broch (Carnegie Mellon University), Robert Chalmers
(University of California at Santa Barbara), Vijay Devarapalli (University of California at Santa Barbara), Noel Chiappa (MIT),
(Nokia Research Center), Rich Draves (Microsoft Research), Francis Vijay Devarapalli (Nokia Research Center), Rich Draves (Microsoft
Dupont (ENST Bretagne), Thomas Eklund (Xelerated), Jun-Ichiro Itojun Research), Francis Dupont (ENST Bretagne), Thomas Eklund (Xelerated),
Hagino (IIJ Research Laboratory), T.J. Kniveton (Nokia Research), Jun-Ichiro Itojun Hagino (IIJ Research Laboratory), Krishna Kumar
Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Erik Nordmark (IBM Research), T.J. Kniveton (Nokia Research), Jiwoong Lee (KTF),
(Sun Microsystems), Simon Nybroe (Ericsson Telebit), David Oran Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Erik Nordmark (Sun
(Cisco), Basavaraj Patil (Nokia), Ken Powell (Compaq), Phil Roberts Microsystems), Simon Nybroe (Ericsson Telebit), David Oran (Cisco),
(Motorola), Patrice Romand (Bull S.A.), Jeff Schiller (MIT) Tom Lars Henrik Petander (HUT), Basavaraj Patil (Nokia), Ken Powell
Soderlund (Nokia Research), Hesham Soliman (Ericsson), Jim Solomon (Compaq), Phil Roberts (Motorola), Patrice Romand (Bull S.A.),
(RedBack Networks), Tapio Suihko (Technical Research Center of Jeff Schiller (MIT) Tom Soderlund (Nokia Research), Hesham Soliman
Finland), Benny Van Houdt (University of Antwerp), Jon-Olov Vatn (Ericsson), Jim Solomon (RedBack Networks), Tapio Suihko (Technical
(KTH), and Xinhua Zhao (Stanford University) for their detailed Research Center of Finland), Benny Van Houdt (University of Antwerp),
reviews of earlier versions of this document. Their suggestions have Jon-Olov Vatn (KTH), Alper Yegin (Sun Microsystems), and Xinhua Zhao
helped to improve both the design and presentation of the protocol. (Stanford University) for their detailed reviews of earlier versions
of this document. Their suggestions have helped to improve both the
design and presentation of the protocol.
We would also like to thank the participants in the Mobile IPv6 We would also like to thank the participants in the Mobile IPv6
testing event held at Nancy, France, September 15-17, 1999, for testing event held at Nancy, France, September 15-17, 1999, for
their valuable feedback as a result of interoperability testing their valuable feedback as a result of interoperability testing
of four Mobile IPv6 implementations coming from four different of four Mobile IPv6 implementations coming from four different
organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC
(FreeBSD), and INRIA (FreeBSD). Further, we would like to thank the (FreeBSD), and INRIA (FreeBSD). Further, we would like to thank the
feedback from the implementors who participated in the Mobile IPv6 feedback from the implementors who participated in the Mobile IPv6
interoperability testing at Connectathon 2000 in San Jose, interoperability testing at Connectathon 2000 in San Jose,
California, March 6-9, 2000. Finally, we would like to thank the California, March 6-9, 2000. Finally, we would like to thank the
skipping to change at page 116, line 47 skipping to change at page 115, line 47
[26] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, [26] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994. See also http://www.iana.org/numbers.html. October 1994. See also http://www.iana.org/numbers.html.
[27] Susan Thomson and Thomas Narten. IPv6 Stateless Address [27] Susan Thomson and Thomas Narten. IPv6 Stateless Address
Autoconfiguration. RFC 2462, December 1998. Autoconfiguration. RFC 2462, December 1998.
A. Changes from Previous Version of the Draft A. Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this This appendix briefly lists some of the major changes in this
draft relative to the previous version of this same draft, draft relative to the previous version of this same draft,
draft-ietf-mobileip-ipv6-13.txt: draft-ietf-mobileip-ipv6-14.txt:
A.1. Changes from Draft Version ...-14
- Strengthened mandates for mobile nodes so that now a mobile node
MUST support decapsulation and processing for routing headers
(section 10.3).
- Enabled ESP to be a valid way to secure reverse tunneled packets
(section 9.5).
- Removed mandate that mobile node select a default router,
and instead described it as typical behavior (section 10.4).
Also made it clear that picking a new default router does not
automatically mean picking a new primary care-of address.
- Added provisional ICMP numbers for the new message types, which
may be reassigned by IANA, but which will be useful for testing
purposes.
- Removed the Mobile Router Prefix Length Sub-Option
- Removed the Prefix Length field from the Binding Update, and
references to error number 136.
- Added the `S' bit so that the home agent can be instructed to
*override* its default behavior. That is, with the `S' bit
set, the home agent will not attempt to be helpful by changing
multiple Binding Cache entries, for multiple routing prefixes,
after receiving only one Binding Update.
- Reworded the specification so that the Home Agent now has to
perform Duplicate Address Detection for the mobile node's address
on all the prefixes for which the router is performing home agent
service.
- Removed the section about Mobile Routers
- Added the Authentication Data Sub-option; reorganized the section
about computing authentication data.
- Specified that the Home Agent lifetime is by default the same as
the Router lifetime, in a Router Advertisement.
- Specified that Binding Updates with zero lifetime and the 'A' bit
set should cause a Binding Acknowledgement to be sent back to the
Source IP address of the Binding Update.
- Qualified the allowable times when a mobile node can send a
Binding Update to a correspondent node
- Added text allowing the correspondent node to extend an existing
Routing Header by also including the care-of address as the entry
of a routing header to be visited immediately before the home
address. In this way, for instance, the mobile node can be an
intermediate node of a path along the way to some other node.
- Removed the Home Address field from the Home Agent Address
Discovery Request Message.
- Noted that ICMP Unreachable forms a potential mechanism by which
a malicious node can cause a correspondent node to delete a valid
entry from its Binding Cache.
- Specified that, when a router stops offering home agent services
by turning off the 'H' flag, the mobile node has to delete the
corresponding entry from its Home Agent list.
A.2. Changes from Previous Versions of the Draft
- Clarified language about how the aggregate list of prefixes is - Clarified language about how the aggregate list of prefixes is
built by the home agent, to include only prefixes with the 'H' built by the home agent, to include only prefixes with the 'H'
bit set. bit set.
- Specified a new error status (141) to handle cases for sequence - Specified a new error status (141) to handle cases for sequence
number mismatches (e.g., when a mobile node reboots). number mismatches (e.g., when a mobile node reboots).
- Moved this section to the appendix, and reorganized other - Moved this section to the appendix, and reorganized other
appendix sections. appendix sections.
skipping to change at page 117, line 35 skipping to change at page 117, line 52
authenticating Binding Acknowledgement authenticating Binding Acknowledgement
- Specified that all correspondent nodes MUST implement a base - Specified that all correspondent nodes MUST implement a base
protocol [?] for establishing a Binding Key. protocol [?] for establishing a Binding Key.
- Added the following protocol constants: - Added the following protocol constants:
INITIAL_SOLICIT_TIMER: INITIAL_SOLICIT_TIMER:
- Created new ICMP messages for Mobile Prefix Solicitations and - Created new ICMP messages for Mobile Prefix Solicitations and
Advertisements (see sections 5.8 and 5.9). Advertisements (see sections 5.9 and 5.10).
- Changed Network Renumbering (Section 9.6) to encompass mobile - Changed Network Renumbering (Section 9.6) to encompass mobile
node configuration issues, remove unspecified address usage, node configuration issues, remove unspecified address usage,
simplify rules for prefix maintenance and sending, and use new simplify rules for prefix maintenance and sending, and use new
ICMP message types noted above. ICMP message types noted above.
- Added a paragraph to Returning Home (section 10.20) to describe - Added a paragraph to Returning Home (section 10.20) to describe
how the Home Agent discovers the mobile node's link-layer address how the Home Agent discovers the mobile node's link-layer address
- Reworded parts of appendix B as needed. - Reworded parts of appendix B as needed.
- Added the Mobile Router Prefix Length Sub-Option (section 5.5), - Added the Mobile Router Prefix Length Sub-Option (section 5.5),
along with text in Section 4.8 describing what a Mobile Router along with text describing what a Mobile Router should do with
should do with it. it.
B. Remote Home Address Configuration B. Remote Home Address Configuration
The method for initializing a mobile node's home addresses on The method for initializing a mobile node's home addresses on
power-up or after an extended period of being disconnected from power-up or after an extended period of being disconnected from
the network is beyond the scope of this specification. Whatever the network is beyond the scope of this specification. Whatever
procedure is used should result in the mobile node having the same procedure is used should result in the mobile node having the same
stateless or stateful (e.g., DHCPv6) home address autoconfiguration stateless or stateful (e.g., DHCPv6) home address autoconfiguration
information it would have if it were attached to the home network. information it would have if it were attached to the home network.
Due to the possibility that the home network could be renumbered Due to the possibility that the home network could be renumbered
skipping to change at page 119, line 9 skipping to change at page 119, line 18
9. Send a binding update(s) to the home agent to register the mobile 9. Send a binding update(s) to the home agent to register the mobile
node's home addresses. node's home addresses.
10. Receive binding acknowledgement(s) then begin normal 10. Receive binding acknowledgement(s) then begin normal
communications. communications.
Chairs' Addresses Chairs' Addresses
The Working Group can be contacted via its current chairs: The Working Group can be contacted via its current chairs:
Phil Roberts Basavaraj Patil Phil Roberts
Motorola Nokia Corporation Megisto Corp.
1501 West Shure Drive 6000 Connection Drive Suite 120
Arlington Heights, IL 60004 M/S M8-540 20251 Century Blvd
Irving, TX 75039 Germantown MD 20874
Phone: +1 847 632-3148 USA USA
E-mail: qa3445@email.mot.com Phone: +1 972-894-6709 Phone: +1 847-202-9314
Fax : +1 972-894-5349 Email: PRoberts@MEGISTO.com
Basavaraj Patil EMail: Raj.Patil@nokia.com
Nokia
6000 Connection Drive
M/S M8-540
Irving, TX 75039
USA
Phone: +1 972 894-6709
Fax: +1 972 894-5349
E-mail: raj.patil@nokia.com
Authors' Addresses Authors' Addresses
Questions about this document can also be directed to the authors: QuestionsDaboutathisvdocumenticandalsoBbe.directedJtoothehauthors:nson
David B. Johnson Rice University Charles Perkins
Rice University Department of Computer Science, Nokia
Department of Computer Science, MS 132 MS 132 313 Fairchild Drive
6100 Main Street 6100 Main Street Mountain View, CA 94043
Houston, TX 77005-1892 Houston, TX 77005-1892 USA
USA USA Phone: +1 650 625-2986
Phone: +1 713 348-3063 Phone: +1 713 348-3063 Fax: +1 650 625-2502
Fax: +1 713 348-5930 Fax: +1 713 348-5930 E-mail: charliep@iprg.nokia.com
E-mail: dbj@cs.rice.edu E-mail: dbj@cs.rice.edu
Charles Perkins
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625-2986
Fax: +1 650 625-2502
E-mail: charliep@iprg.nokia.com
 End of changes. 

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