draft-ietf-mobileip-ipv6-10.txt   draft-ietf-mobileip-ipv6-11.txt 
IETF Mobile IP Working Group David B. Johnson IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Carnegie Mellon University INTERNET-DRAFT Carnegie Mellon University
Charles Perkins Charles Perkins
Nokia Nokia
10 February 2000 10 March 2000
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-10.txt> <draft-ietf-mobileip-ipv6-11.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 72 skipping to change at page 1, line 72
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7
3.3. Specification Language . . . . . . . . . . . . . . . . . 8 3.3. Specification Language . . . . . . . . . . . . . . . . . 8
4. Overview of Mobile IPv6 9 4. Overview of Mobile IPv6 9
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9
4.2. New IPv6 Destination Options and ICMP Messages . . . . . 11 4.2. New IPv6 Destination Options and ICMP Messages . . . . . 11
4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 14 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 14
4.4. Binding Management . . . . . . . . . . . . . . . . . . . 18 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 18
5. New IPv6 Destination Options and Message Types 20 5. New IPv6 Destination Options and Message Types 20
5.1. Binding Update Option Format . . . . . . . . . . . . . . 20 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 20
5.2. Binding Acknowledgement Option Format . . . . . . . . . . 24 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 25
5.3. Binding Request Option Format . . . . . . . . . . . . . . 28 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 29
5.4. Home Address Option Format . . . . . . . . . . . . . . . 30 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 31
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 32 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 33
5.6. ICMP Home Agent Address Discovery Request Message . . . . 35 5.6. ICMP Home Agent Address Discovery Request Message . . . . 36
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 37 5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 38
6. Modifications to IPv6 Neighbor Discovery 39 6. Modifications to IPv6 Neighbor Discovery 40
6.1. Modified Router Advertisement Message Format . . . . . . 39 6.1. Modified Router Advertisement Message Format . . . . . . 40
6.2. Modified Prefix Information Option Format . . . . . . . . 40 6.2. Modified Prefix Information Option Format . . . . . . . . 41
6.3. New Advertisement Interval Option Format . . . . . . . . 42 6.3. New Advertisement Interval Option Format . . . . . . . . 43
6.4. New Home Agent Information Option Format . . . . . . . . 43 6.4. New Home Agent Information Option Format . . . . . . . . 44
6.5. Changes to Sending Router Advertisements . . . . . . . . 45 6.5. Changes to Sending Router Advertisements . . . . . . . . 46
6.6. Changes to Sending Router Solicitations . . . . . . . . . 46 6.6. Changes to Sending Router Solicitations . . . . . . . . . 47
7. Requirements for IPv6 Nodes 48 7. Requirements for IPv6 Nodes 49
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 48 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 49
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 48 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 49
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 48 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 49
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 49 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 50
8. Correspondent Node Operation 51 8. Correspondent Node Operation 52
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 51 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 52
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 51 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 52
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 52 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 53
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 53 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 54
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 53 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 54
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 53 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 54
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 54 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 55
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 55 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 56
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 56 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 57
9. Home Agent Operation 58 9. Home Agent Operation 59
9.1. Receiving Router Advertisement Messages . . . . . . . . . 58 9.1. Receiving Router Advertisement Messages . . . . . . . . . 59
9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 59 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 60
9.3. Primary Care-of Address Registration . . . . . . . . . . 61 9.3. Primary Care-of Address Registration . . . . . . . . . . 62
9.4. Primary Care-of Address De-registration . . . . . . . . . 63 9.4. Primary Care-of Address De-registration . . . . . . . . . 64
9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 64 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 65
9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 66 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 67
9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 67 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 68
10. Mobile Node Operation 70 10. Mobile Node Operation 71
10.1. Sending Packets While Away from Home . . . . . . . . . . 70 10.1. Sending Packets While Away from Home . . . . . . . . . . 71
10.2. Interaction with Outbound IPsec Processing . . . . . . . 71 10.2. Interaction with Outbound IPsec Processing . . . . . . . 72
10.3. Receiving Packets While Away from Home . . . . . . . . . 73 10.3. Receiving Packets While Away from Home . . . . . . . . . 74
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 74 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 75
10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 77 10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 78
10.6. Sending Binding Updates to the Home Agent . . . . . . . . 78 10.6. Sending Binding Updates to the Home Agent . . . . . . . . 79
10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 79 10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 80
10.8. Sending Binding Updates to Correspondent Nodes . . . . . 80 10.8. Sending Binding Updates to Correspondent Nodes . . . . . 81
10.9. Establishing Forwarding from a Previous Care-of Address . 83 10.9. Establishing Forwarding from a Previous Care-of Address . 84
10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 84 10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 85
10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 84 10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 85
10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 85 10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 86
10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 85 10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 86
10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 86 10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 87
10.15. Receiving Local Router Advertisement Messages . . . . . . 86 10.15. Receiving Local Router Advertisement Messages . . . . . . 87
10.16. Receiving Tunneled Router Advertisements . . . . . . . . 88 10.16. Receiving Tunneled Router Advertisements . . . . . . . . 89
10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 89 10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 90
10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 89 10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 91
10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 90 10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 91
11. Protocol Constants 92 11. Protocol Constants 94
12. IANA Considerations 93 12. IANA Considerations 95
13. Security Considerations 94 13. Security Considerations 96
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 94 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 96
13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 94 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 96
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 95 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 97
Changes from Previous Version of the Draft 97 Changes from Previous Version of the Draft 99
Acknowledgements 99 Acknowledgements 100
References 100 References 101
Chair's Address 102 Chair's Address 103
Authors' Addresses 103 Authors' Addresses 104
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
router) would not be able to reach it while the mobile node is away router) would not be able to reach it while the mobile node is away
from its home link (the link on which its home IPv6 subnet prefix is from its home link (the link on which its home IPv6 subnet prefix is
in use), since routing is based on the subnet prefix in a packet's in use), since routing is based on the subnet prefix in a packet's
destination IP address. In order to continue communication in spite destination IP address. In order to continue communication in spite
skipping to change at page 11, line 49 skipping to change at page 11, line 49
a packet. a packet.
4.2. New IPv6 Destination Options and ICMP Messages 4.2. New IPv6 Destination Options and ICMP Messages
As discussed in general in Section 4.1, the following four new IPv6 As discussed in general in Section 4.1, the following four new IPv6
destination options are defined for Mobile IPv6: destination options are defined for Mobile IPv6:
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 a correspondent node or the mobile node's home agent of its
its current binding. The Binding Update sent to the mobile current binding. The Binding Update sent to the mobile node's
node's home agent to register its primary care-of address is home agent to register its primary care-of address is marked
marked as a "home registration". Any packet that includes a as a "home registration". Any packet that includes a Binding
Binding Update option MUST also include either an AH [11] or Update option MUST be protected by IPsec [13] to guard against
ESP [12] header providing sender authentication, data integrity malicious Binding Updates. The Binding Update option and
protection, and replay protection. The Binding Update option its specific IPsec requirements are described in detail in
is 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 also include either an AH [11] or Acknowledgement option MUST be protected by IPsec [13] to
ESP [12] header providing sender authentication, data integrity guard against malicious Binding Acknowledgements. The Binding
protection, and replay protection. The Binding Acknowledgement Acknowledgement option and its specific IPsec requirements are
option is described in detail in Section 5.2. 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 15, line 42 skipping to change at page 15, line 42
entries MAY be replaced at any time by any reasonable local entries MAY be replaced at any time by any reasonable local
cache replacement policy but SHOULD NOT be unnecessarily cache replacement policy but SHOULD NOT be unnecessarily
deleted. Any node's Binding Cache may contain at most one deleted. Any node's Binding Cache may contain at most one
entry for each mobile node home address. The contents of a entry for each mobile node home address. The contents of a
node's Binding Cache MUST NOT be changed in response to a Home node's Binding Cache MUST NOT be changed in response to a Home
Address option in a received packet. Address option in a received packet.
Binding Update List Binding Update List
A list, maintained by each mobile node, recording information A list, maintained by each mobile node, recording information
for each Binding Update sent by this mobile node, for which for each Binding Update sent by this mobile node, for which the
the Lifetime sent in that Binding Update has not yet expired. Lifetime sent in that Binding Update has not yet expired. The
The Binding Update List includes all bindings sent by the Binding Update List includes all bindings sent by the mobile
mobile node: those to correspondent nodes, to the mobile node: those to correspondent nodes, those to the mobile node's
node's home agent, and to a previous default router of the home agent, and those to a home agent on the link on which the
mobile node. The Binding Update List MAY be implemented in any mobile node's previous care-of address is located. The Binding
manner consistent with the external behavior described in this Update List MAY be implemented in any manner consistent with
document. Each Binding Update List entry conceptually contains the external behavior described in this document. Each Binding
the following fields: Update List entry conceptually contains the following fields:
- The IP address of the node to which a Binding Update was - The IP address of the node to which a Binding Update was
sent. This node might still have a Binding Cache entry sent. This node might still have a Binding Cache entry
created or updated from this Binding Update, if the Binding created or updated from this Binding Update, if the Binding
Update was successfully received by that node (e.g., not Update was successfully received by that node (e.g., not
lost by the network) and if that node has not deleted the lost by the network) and if that node has not deleted the
entry before its expiration (e.g., to reclaim space in its entry before its expiration (e.g., to reclaim space in its
Binding Cache for other entries). Binding Cache for other entries).
- The home address for which that Binding Update was sent. - The home address for which that Binding Update was sent.
This will be one of the mobile node's home addresses for This will be one of the mobile node's home addresses for
most Binding Updates (Sections 10.6 and 10.8), but will most Binding Updates (Sections 10.6 and 10.8), but will
be the mobile node's previous care-of address for Binding be the mobile node's previous care-of address for Binding
Updates sent to the mobile node's previous default router Updates sent to to establish forwarding from by a home
(Section 10.9). agent from this previous care-of address (Section 10.9).
- The care-of address sent in that Binding Update. This - The care-of address sent in that Binding Update. This
value is necessary for the mobile node to determine if it value is necessary for the mobile node to determine if it
has sent a Binding Update giving its new care-of address to has sent a Binding Update giving its new care-of address to
this destination after changing its care-of address. this destination after changing its care-of address.
- The remaining lifetime of that binding. This lifetime is - The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding initialized from the Lifetime value sent in the Binding
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
skipping to change at page 20, line 7 skipping to change at page 20, line 7
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.
5. New IPv6 Destination Options and Message Types 5. New IPv6 Destination Options and Message Types
5.1. Binding Update Option Format 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:
skipping to change at page 23, line 12 skipping to change at page 23, line 12
binding given in the Binding Update option is indicated by the Home binding given in the Binding Update option is indicated by the Home
Address field in the Home Address option in the packet. Address field in the Home Address option in the packet.
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 specified by the Source Address field in the IPv6 option is normally specified by the Source Address field in the IPv6
header of the packet carrying the Binding Update option. However, a header of the packet carrying the Binding Update option. However, a
care-of address different from the Source Address MAY be specified care-of address different from the Source Address MAY be specified
by including an Alternate Care-of Address sub-option in the Binding by including an Alternate Care-of Address sub-option in the Binding
Update option. Update option.
Any packet that includes a Binding Update option MUST also include Any packet that includes a Binding Update option MUST be protected by
either an AH [11] or ESP [12] header providing sender authentication, IPsec [13] to guard against malicious Binding Updates. Specifically,
data integrity protection, and replay protection. any packet that includes a Binding Update option MUST utilize
IPsec sender authentication, data integrity protection, and replay
protection. Currently, Mobile IPv6 requires that this protection
covering a Binding Update MUST be provided by use of AH [11]; if
another Security Association applied to the packet for other reasons
requires use of ESP [12], the packet MUST use both AH and ESP. Use
of ESP for protecting the Binding Update is not currently defined in
this document, since ESP does not protect the portion of the packet
above the ESP header itself.
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 24, line 5 skipping to change at page 25, line 5
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.
5.2. Binding Acknowledgement Option Format 5.2. Binding Acknowledgement Option
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
skipping to change at page 26, line 34 skipping to change at page 27, line 34
future extensions to the format of the Binding Acknowledgement future extensions to the format of the Binding Acknowledgement
option to be defined. The encoding and format of defined option to be defined. The encoding and format of defined
sub-options are described in Section 5.5. Currently, no valid sub-options are described in Section 5.5. Currently, no valid
sub-options are defined for in a Binding Acknowledgement sub-options are defined for in a Binding Acknowledgement
option. option.
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
also include either an AH [11] or ESP [12] header providing sender be protected by IPsec [13] to guard against malicious Binding
authentication, data integrity protection, and replay protection. Acknowledgements. Specifically, any packet that includes a Binding
Acknowledgement option MUST utilize IPsec sender authentication, data
integrity protection, and replay protection. Currently, Mobile IPv6
requires that this protection covering a Binding Acknowledgement
MUST be provided by use of AH [11]; if another Security Association
applied to the packet for other reasons requires use of ESP [12],
the packet MUST use both AH and ESP. Use of ESP for protecting the
Binding Acknowledgement is not currently defined in this document,
since ESP does not protect the portion of the packet above the ESP
header itself.
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 Cache 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 received and MUST use this entry (which includes the care-of address received
in the Binding Update) in sending the packet containing the Binding in the Binding Update) in sending the packet containing the Binding
Acknowledgement to the mobile node. The details of sending this Acknowledgement to the mobile node. The details of sending this
packet to the mobile node are the same as for sending any packet to a packet to the mobile node are the same as for sending any packet to a
mobile node using a binding, and are described in Section 8.9. The mobile node using a binding, and are described in Section 8.9. The
skipping to change at page 28, line 5 skipping to change at page 29, line 5
extension header in the packet set to indicate "No Next Header" [6]). extension header in the packet set to indicate "No Next Header" [6]).
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
Acknowledgement option, these three bits are set to 000, indicating Acknowledgement option, these three bits are set to 000, indicating
that any IPv6 node processing this option that does not recognize the that any IPv6 node processing this option that does not recognize the
Option Type must skip over this option and continue processing the Option Type must skip over this option and continue processing the
header, and that the data within the option cannot change en-route to header, and that the data within the option cannot change en-route to
the packet's final destination. the packet's final destination.
5.3. Binding Request Option Format 5.3. Binding Request Option
The Binding Request destination option is used to request a mobile The Binding Request destination option is used to request a mobile
node's binding from the mobile node. As a destination option, it node's binding from the mobile node. As a destination option, it
MAY be included in any existing packet being sent to the mobile MAY be included in any existing packet being sent to the mobile
node or MAY be sent in a packet by itself; a packet containing a node or MAY be sent in a packet by itself; a packet containing a
Binding Request option is sent in the same way as any packet to a Binding Request option is sent in the same way as any packet to a
mobile node (Section 8.9). When a mobile node receives a packet mobile node (Section 8.9). When a mobile node receives a packet
containing a Binding Request option, it SHOULD return a Binding containing a Binding Request option, it SHOULD return a Binding
Update (Section 5.1) to the source of the Binding Request. Update (Section 5.1) to the source of the Binding Request.
skipping to change at page 30, line 5 skipping to change at page 31, line 5
option. option.
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
Request option, these three bits are set to 000, indicating that any Request option, these three bits are set to 000, 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 skip over this option and continue processing the header, Type must skip over this option and continue processing the header,
and that the data within the option cannot change en-route to the and that the data within the option cannot change en-route to the
packet's final destination. packet's final destination.
5.4. Home Address Option Format 5.4. Home Address Option
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
skipping to change at page 38, line 17 skipping to change at page 40, 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.
The Source Address of the Home Agent Address Discovery Request
message packet MUST be one of the mobile node's current care-of
addresses, and the mobile node MUST NOT include a Home Address
option in this packet; the home agent then MUST return the Home
Agent Address Discovery Reply message directly to this care-of
address. These restrictions are necessary, since at the time of
performing this dynamic home agent address discovery, the mobile node
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.
6. Modifications to IPv6 Neighbor Discovery 6. Modifications to IPv6 Neighbor Discovery
6.1. Modified Router Advertisement Message Format 6.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the format of the Router Advertisement Mobile IPv6 modifies the format of the Router Advertisement
message [17] by the addition of a single flag bit to indicate that message [17] by the addition of a single flag bit to indicate that
the router sending the Advertisement message is serving as a home the router sending the Advertisement message is serving as a home
agent on this link. The format of the Router Advertisement message agent on this link. The format of the Router Advertisement message
is as follows: is as follows:
skipping to change at page 40, line 16 skipping to change at page 41, line 16
Mobile IPv6 requires knowledge of a router's global address for two Mobile IPv6 requires knowledge of a router's global address for two
reasons: reasons:
- To allow a home agent (a router) to learn the address of all - To allow a home agent (a router) to learn the address of all
other home agents on the link for which it is providing home other home agents on the link for which it is providing home
agent service, for use in building its Home Agents List as agent service, for use in building its Home Agents List as
part of the dynamic home agent address discovery mechanism part of the dynamic home agent address discovery mechanism
(Sections 9.2 and 10.7). (Sections 9.2 and 10.7).
- To allow a mobile node to send a Binding Update to its previous - To allow a mobile node to send a Binding Update to a router on
default router, after moving to a new subnet and acquiring a new the link on which its previous care-of address is located, for
care-of address (Section 10.9). purposes of establishing forwarding from this previous care-of
address to its new care-of address (Section 10.9).
However, Neighbor Discovery [17] only advertises a router's However, Neighbor Discovery [17] only advertises a router's
link-local address, by requiring this address to be used as the IP link-local address, by requiring this address to be used as the IP
Source Address of each Router Advertisement. Source Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to easily Mobile IPv6 extends Neighbor Discovery to allow a router to easily
and efficiently advertise its global address, by the addition of a and efficiently advertise its global address, by the addition of a
single flag bit in the format of a Prefix Information option for single flag bit in the format of a Prefix Information option for
use in Router Advertisement messages. The format of the Prefix use in Router Advertisement messages. The format of the Prefix
Information option is as follows: Information option is as follows:
skipping to change at page 51, line 39 skipping to change at page 52, line 39
the care-of address and Home Address option is transparent to both the care-of address and Home Address option is transparent to both
the mobile node and the correspondent node above the level of the the mobile node and the correspondent node above the level of the
Home Address option generation and processing. 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 Upon receiving a Binding Update option in some packet, the receiving
node MUST validate the Binding Update according to the following node MUST validate the Binding Update according to the following
tests: tests:
- The packet contains a valid AH [11] or ESP [12] header that - The packet meets the specific IPsec requirements for Binding
provides sender authentication, integrity protection, and replay Updates, defined in Section 5.1.
protection.
- The packet MUST contain a valid Home Address option. The home - The packet MUST contain a valid Home Address option. The home
address for the binding is specified by the Home Address field of address for the binding is specified by the Home Address field of
the Home Address option. the 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
skipping to change at page 53, line 33 skipping to change at page 54, line 33
Acknowledgement option acknowledging receipt of the Binding Update. Acknowledgement option acknowledging receipt of the Binding Update.
If the node accepts the Binding Update and creates or updates an If the node accepts the Binding Update and creates or updates an
entry in its Binding Cache for this binding, the Status field in entry in its Binding Cache for this binding, the Status field in
the Binding Acknowledgement MUST be set to a value less than 128; the Binding Acknowledgement MUST be set to a value less than 128;
if the node rejects the Binding Update and does not create or if the node rejects the Binding Update and does not create or
update an entry for this binding, the Status field in the Binding update an entry for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value greater than or equal to 128. Acknowledgement 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 Specific values for the Status field are described in Section 5.2 and
in the most recent "Assigned Numbers" [26]. in the most recent "Assigned Numbers" [26].
As described in Section 5.2, the packet in which the Binding The packet in which the Binding Acknowledgement is returned MUST meet
Acknowledgement is returned MUST include either an AH [11] or the specific IPsec requirements for Binding Acknowledgements, defined
ESP [12] header providing sender authentication, data integrity in Section 5.2; and the packet MUST be sent using a Routing header
protection, and replay protection; and the packet MUST be sent using in the same way as any other packet sent to a mobile node using a
a Routing header in the same way as any other packet sent to a mobile care-of address (even if the binding was rejected), as described
node using a care-of address (even if the binding was rejected), as in Section 8.9. The packet is routed first to the care-of address
described in Section 8.9. The packet is routed first to the care-of contained in the Binding Update being acknowledged, and then to the
address contained in the Binding Update being acknowledged, and mobile node's home address. This use of the Routing header ensures
then to the mobile node's home address. This use of the Routing that the Binding Acknowledgement will be routed to the current
header ensures that the Binding Acknowledgement will be routed to the location of the node sending the Binding Update, whether the Binding
current location of the node sending the Binding Update, whether the Update was accepted or rejected.
Binding Update was accepted or rejected.
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
expires. If such an entry is still in active use in sending packets expires. If such an entry is still in active use in sending packets
to a mobile node, the next packet sent to the mobile node will be to a mobile node, the next packet sent to the mobile node will be
routed normally to the mobile node's home link, where it will be routed normally to the mobile node's home link, where it will be
intercepted and tunneled to the mobile node. The mobile node will intercepted and tunneled to the mobile node. The mobile node will
then return a Binding Update to the sender, allowing it to create then return a Binding Update to the sender, allowing it to create
a new Binding Cache entry for sending future packets to the mobile a new Binding Cache entry for sending future packets to the mobile
skipping to change at page 55, line 38 skipping to change at page 56, line 37
node's home link. There, it will be intercepted by the mobile node's node's home link. There, it will be intercepted by the mobile node's
home agent, encapsulated, and tunneled to the mobile node's primary home agent, encapsulated, and tunneled to the mobile node's primary
care-of address. Any ICMP error message caused by the packet on care-of address. Any ICMP error message caused by the packet on
its way to the mobile node while in the tunnel, will be returned to its way to the mobile node while in the tunnel, will be returned to
the mobile node's home agent (the source of the tunnel). By the the mobile node's home agent (the source of the tunnel). By the
definition of IPv6 encapsulation [4], this encapsulating node MUST definition of IPv6 encapsulation [4], this encapsulating node MUST
relay certain ICMP error messages back to the original sender of the relay certain ICMP error messages back to the original sender of the
packet, which in this case is the correspondent node. packet, which in this case is the correspondent node.
Likewise, if a packet for a mobile node arrives at the mobile node's Likewise, if a packet for a mobile node arrives at the mobile node's
previous default router (e.g., the mobile node moved after the packet previous link and is intercepted there by a home agent for the mobile
was sent), the router will encapsulate and tunnel the packet to the node's previous care-of address as described in Section 10.9 (e.g.,
mobile node's new care-of address (if it has a Binding Cache entry the mobile node moved after the packet was sent), that home agent
for the mobile node). As above, any ICMP error message caused by the will encapsulate and tunnel the packet to the mobile node's new
packet while in this tunnel will be returned to the previous default care-of address. As above, any ICMP error message caused by the
router (the source of the tunnel), which MUST relay certain ICMP packet while in this tunnel will be returned to that home agent (the
error messages back to the correspondent node [4]. source of the tunnel), which MUST relay certain ICMP error messages
back to the correspondent node [4].
Thus, in all cases, any meaningful ICMP error messages caused Thus, in all cases, any meaningful ICMP error messages caused
by packets from a correspondent node to a mobile node will be by packets from a correspondent node to a mobile node will be
returned to the correspondent node. If the correspondent node returned to the correspondent node. If the correspondent node
receives persistent ICMP Destination Unreachable messages after receives persistent ICMP Destination Unreachable messages after
sending packets to a mobile node based on an entry in its Binding sending packets to a mobile node based on an entry in its Binding
Cache, the correspondent node SHOULD delete this Binding Cache Cache, the correspondent node SHOULD delete this Binding Cache
entry. If the correspondent node subsequently transmits another entry. If the correspondent node subsequently transmits another
packet to the mobile node, the packet will be routed to the mobile packet to the mobile node, the packet will be routed to the mobile
node's home link, intercepted by the mobile node's home agent, and node's home link, intercepted by the mobile node's home agent, and
skipping to change at page 59, line 37 skipping to change at page 60, line 37
A mobile node, while away from home, MAY use the dynamic home agent A mobile node, while away from home, MAY use the dynamic home agent
address discovery mechanism to attempt to discover the address of address discovery mechanism to attempt to discover the address of
one or more routers serving as home agents on its home link. This one or more routers serving as home agents on its home link. This
discovery may be necessary, for example, if some nodes on its home discovery may be necessary, for example, if some nodes on its home
link have been reconfigured while the mobile node has been away from link have been reconfigured while the mobile node has been away from
home, such that the router that was operating as the mobile node's home, such that the router that was operating as the mobile node's
home agent has been replaced by a different router serving this role. home agent has been replaced by a different router serving this role.
As described in Section 10.7, a mobile node attempts dynamic home As described in Section 10.7, a mobile node attempts dynamic home
agent address discovery by sending an ICMP Home Agent Address agent address discovery by sending an ICMP Home Agent Address
Discovery message to the "Mobile IPv6 Home-Agents" anycast Discovery Request message to the "Mobile IPv6 Home-Agents" anycast
address [10] for its home IP subnet prefix; the packet MUST also address [10] for its home IP subnet prefix, using its care-of address
include a Home Address option. A home agent receiving such a Home as the Source Address of the packet. A home agent receiving such a
Agent Address Discovery Request message that is serving this subnet Home Agent Address Discovery Request message that is serving this
(the home agent is configured with this anycast address on one of subnet (the home agent is configured with this anycast address on one
its network interfaces) SHOULD return an ICMP Home Agent Address of its network interfaces) SHOULD return an ICMP Home Agent Address
Discovery Reply message to the mobile node, with the Source Address Discovery Reply message to the mobile node (at its care-of address
of the packet set to one of the global unicast addresses of the that was used as the Source Address of the Request message), with the
home agent. The Home Agent Addresses field in the Reply message is Source Address of the Reply packet set to one of the global unicast
constructed as follows: addresses of the home agent. The Home Agent Addresses field in the
Reply message is constructed as follows:
- The Home Agent Addresses field SHOULD contain one global IP - The Home Agent Addresses field SHOULD contain one global IP
address for each home agent currently listed in this home address for each home agent currently listed in this home
agent's own Home Agents List (Section 4.3). However, if this agent's own Home Agents List (Section 4.3). However, if this
home agent's own global IP address would be placed in the list home agent's own global IP address would be placed in the list
(as described below) as the first entry in the list, then this (as described below) as the first entry in the list, then this
home agent SHOULD NOT include its own address in the Home Agent home agent SHOULD NOT include its own address in the Home Agent
Addresses field in the Reply message. Not placing this home Addresses field in the Reply message. Not placing this home
agent's own IP address in the list will cause the receiving agent's own IP address in the list will cause the receiving
mobile node to consider this home agent as the most preferred mobile node to consider this home agent as the most preferred
skipping to change at page 67, line 40 skipping to change at page 68, line 40
Autoconfiguration [27] to aid in renumbering a subnet, such as when a Autoconfiguration [27] to aid in renumbering a subnet, such as when a
site switches to a new network service provider. In renumbering, new site switches to a new network service provider. In renumbering, new
prefixes and addresses can be introduced for the subnet and old ones prefixes and addresses can be introduced for the subnet and old ones
can be deprecated and removed. These mechanisms are defined to work can be deprecated and removed. These mechanisms are defined to work
while all nodes using the old prefixes are at home, connected to the while all nodes using the old prefixes are at home, connected to the
link using these prefixes. Mobile IPv6 extends these mechanisms for link using these prefixes. Mobile IPv6 extends these mechanisms for
the case in which one or more mobile nodes using the old prefixes are the case in which one or more mobile nodes using the old prefixes are
away from home while the renumbering takes place. away from home while the renumbering takes place.
The IPv6 renumbering mechanisms are based on nodes on the link The IPv6 renumbering mechanisms are based on nodes on the link
receiving Prefix Information options in Router Advertisement messages receiving Prefix Information options in Router Advertisement
giving the valid lifetime and preferred lifetime for different messages giving the valid lifetime and preferred lifetime for
prefixes on the link [17]. Mobile IPv6 arranges to tunnel certain different prefixes on the link [17]. Mobile IPv6 arranges to
Router Advertisements giving "important" Prefix Information options tunnel certain Router Advertisements giving "important" Prefix
to mobile nodes while away from home. To avoid the need to tunnel Information options to mobile nodes while away from home. To avoid
all Router Advertisements from the home link to a mobile node away the need to tunnel all Router Advertisements from the home link to
from home, those Router Advertisements that are tunneled to the a mobile node away from home, those Router Advertisements that are
mobile node are retransmitted until acknowledged. To avoid possible tunneled to the mobile node are retransmitted until acknowledged. To
security attacks from forged Router Advertisements tunneled to avoid possible security attacks from forged Router Advertisements
the mobile node, all such tunneled Router Advertisements must be tunneled to the mobile node, all such tunneled Router Advertisements
authenticated to the mobile node by its home agent using AH [11] or must be authenticated to the mobile node by its home agent using
ESP [12]. IPsec [13, 11, 12].
Specifically, a home agent serving some mobile node SHOULD construct Specifically, a home agent serving some mobile node SHOULD construct
and tunnel to the mobile node a new Router Advertisement when any of and tunnel to the mobile node a new Router Advertisement when any of
the following conditions occur: the following conditions occur:
- The preferred or valid lifetime for an existing prefix on the - The preferred or valid lifetime for an existing prefix on the
home link is reduced. home link is reduced.
- A new prefix is introduced on the home link. - A new prefix is introduced on the home link.
skipping to change at page 68, line 35 skipping to change at page 69, line 35
attempt to combine them into a single Router Advertisement message to attempt to combine them into a single Router Advertisement message to
the mobile node. the mobile node.
In tunneling each such Router Advertisement to the mobile node, the In tunneling each such Router Advertisement to the mobile node, the
home agent MUST construct the packet as follows: home agent MUST construct the packet as follows:
- The Source Address in the packet's IPv6 header MUST be set to the - The Source Address in the packet's IPv6 header MUST be set to the
home agent's IP address to which the mobile node addressed its home agent's IP address to which the mobile node addressed its
current home registration. current home registration.
- The packet MUST include either an AH [11] or ESP [12] header - The packet MUST be protected by IPsec [13, 11, 12] to guard
providing sender authentication, data integrity protection, and against malicious Router Advertisements. The IPsec protection
replay protection. MUST provide sender authentication, data integrity protection,
and replay protection, covering the Router Advertisement.
- The packet MUST include a Binding Request destination option. - The packet MUST include a Binding Request destination option.
- The Binding Request destination option MUST include a Unique - The Binding Request destination option MUST include a Unique
Identifier Sub-Option (Section 5.5), with the unique identifier Identifier Sub-Option (Section 5.5), with the unique identifier
in the sub-option data set to a value different than that in in the sub-option data set to a value different than that in
any other Binding Request sent recently by this node. The word any other Binding Request sent recently by this node. The word
"recently" here means within the maximum likely lifetime of a "recently" here means within the maximum likely lifetime of a
packet, including transit time from source to destination and packet, including transit time from source to destination and
time spent awaiting reassembly with other fragments of the same time spent awaiting reassembly with other fragments of the same
skipping to change at page 72, line 16 skipping to change at page 73, line 16
(e.g., by TCP) as if the mobile node were at home and Mobile IP (e.g., by TCP) as if the mobile node were at home and Mobile IP
were not being used. Mobile IP is transparent to such higher were not being used. Mobile IP is transparent to such higher
layers. layers.
- As part of outbound packet processing in IP, the packet is - As part of outbound packet processing in IP, the packet is
compared against the IPsec Security Policy Database (SPD) to compared against the IPsec Security Policy Database (SPD) to
determine what processing is required for the packet [13]. determine what processing is required for the packet [13].
- As a special case for Mobile IP, if a Binding Update or - As a special case for Mobile IP, if a Binding Update or
Binding Acknowledgement is being included in the packet, IPsec Binding Acknowledgement is being included in the packet, IPsec
authentication and replay protection using AH [11] or ESP [12] authentication, integrity protection, and replay protection MUST
MUST be applied to the packet. If the SPD check above has be applied to the packet [13, 11, 12], as defined in Sections 5.1
already indicated that authentication and replay protection and 5.2. If the SPD check above has already indicated that
are required, this processing is sufficient for the Mobile IP authentication and replay protection are required, this
requirement that all packets containing Binding Updates or processing is sufficient for the Mobile IP requirement that all
Binding Acknowledgements be authenticated and covered by replay packets containing Binding Updates or Binding Acknowledgements be
protection. Otherwise, an implementation can force the required authenticated and covered by replay protection. Otherwise, an
IPsec processing on this individual packet by, for example, implementation can force the required IPsec processing on this
creating a temporary SPD entry for the handling of this packet. individual packet by, for example, creating a temporary SPD entry
for the handling of this packet.
- If IPsec processing is required, the packet is either mapped to - If IPsec processing is required, the packet is either mapped to
an existing Security Association (or SA bundle), or a new SA (or an existing Security Association (or SA bundle), or a new SA (or
SA bundle) is created for the packet, according to the procedures SA bundle) is created for the packet, according to the procedures
defined for IPsec. defined for IPsec.
- Since the mobile node is away from home, the mobile node inserts - Since the mobile node is away from home, the mobile node inserts
a Home Address option into the packet, replacing the Source a Home Address option into the packet, replacing the Source
Address in the packet's IP header with a care-of address suitable Address in the packet's IP header with a care-of address suitable
for the link on which the packet is being sent, as described in for the link on which the packet is being sent, as described in
Section 10.1. The Destination Options header in which the Home Section 10.1. The Destination Options header in which the Home
Address option is inserted MUST appear in the packet before the Address option is inserted MUST appear in the packet before the
AH or ESP header, so that the Home Address option is processed by AH [11] (or ESP [12]) header, so that the Home Address option is
the destination node before the AH or ESP header is processed. processed by the destination node before the AH or ESP header is
processed.
- If a Binding Update is being included in the packet, it is - If a Binding Update is being included in the packet, it is
also added to a Destination Options header in the packet. The also added to a Destination Options header in the packet. The
Destination Options header in which the Binding Update option is Destination Options header in which the Binding Update option is
inserted MAY appear either before or after the AH or ESP header. inserted MAY appear either before or after the AH or ESP header.
If it is inserted before the AH or ESP header, it SHOULD be If it is inserted before the AH or ESP header, it SHOULD be
placed in the same Destination Options header in which the Home placed in the same Destination Options header in which the Home
Address option was inserted. Address option was inserted.
- Finally, once the packet is fully assembled, the necessary IPsec - Finally, once the packet is fully assembled, the necessary IPsec
skipping to change at page 73, line 52 skipping to change at page 75, line 5
node's care-of address, with the final hop in the Routing header node's care-of address, with the final hop in the Routing header
directing the packet to the mobile node's home address; the directing the packet to the mobile node's home address; the
processing of this last hop of the Routing header is entirely processing of this last hop of the Routing header is entirely
internal to the mobile node, since the care-of address and home internal to the mobile node, since the care-of address and home
address are both addresses within the mobile node. address are both addresses within the mobile node.
- Packets sent by a correspondent node that has a Binding Cache - Packets sent by a correspondent node that has a Binding Cache
entry for the mobile node that contains an out-of-date care-of entry for the mobile node that contains an out-of-date care-of
address for the mobile node, will be sent by the correspondent address for the mobile node, will be sent by the correspondent
node using a Routing header, as described above. If the mobile node using a Routing header, as described above. If the mobile
node sent a Binding Update to its previous default router when node sent a Binding Update to a home agent on the link on which
moving from this care-of address to another, and if the Binding its previous care-of address is located (Section 10.9), and
Cache entry that was created from this Binding Update is still if this home agent is still serving as a home agent for the
present in this router's Binding Cache, then such a packet mobile node's previous care-of address, then such a packet will
will be intercepted by this router, encapsulated using IPv6 be intercepted by this home agent, encapsulated using IPv6
encapsulation [4], and tunneled to the mobile node's primary encapsulation [4], and tunneled to the mobile node's new care-of
care-of address (registered with this router, acting as a home address (registered with this home agent).
agent for this out-of-date care-of address).
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.8, subject to the sender of the packet, as described in Section 10.8, subject to the
rate limiting defined in Section 10.11. The mobile node SHOULD rate limiting defined in Section 10.11. The mobile node SHOULD
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.
skipping to change at page 79, line 37 skipping to change at page 80, line 37
considers itself the home agent for each such home address of the considers itself the home agent for each such home address of the
mobile node. As the set of on-link subnet prefixes on the home link mobile node. As the set of on-link subnet prefixes on the home link
changes over time, the home agent changes the set of home addresses changes over time, the home agent changes the set of home addresses
for this mobile node for which it is serving as the home agent. for this mobile node for which it is serving as the home agent.
If the mobile node has additional home addresses using a different If the mobile node has additional home addresses using a different
interface identifier, then the mobile node SHOULD send an additional interface identifier, then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the packet containing a Binding Update to its home agent to register the
care-of address for each such other home address (or set of home care-of address for each such other home address (or set of home
addresses sharing an interface identifier). These additional Binding addresses sharing an interface identifier). These additional Binding
Updates MUST each be sent as a separate packet, since each MUST Updates MUST each be sent as a separate packet, since each MUST be
contain an AH [11] or ESP [12] header to authenticate the Binding protected by IPsec [13, 11, 12] to authenticate the Binding Update as
Update as coming from the home address being bound. coming from the home address being bound, as defined in Section 5.1.
10.7. Dynamic Home Agent Address Discovery 10.7. Dynamic Home Agent Address Discovery
It is possible that when the mobile node needs to send a Binding It is possible that when the mobile node needs to send a Binding
Update to its home agent to register its new primary care-of address, Update to its home agent to register its new primary care-of address,
as described in Section 10.6, the mobile node may not know the as described in Section 10.6, the mobile node may not know the
address of any router on its home link that can serve as a home agent address of any 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 for it. For example, some nodes on its home link may have been
reconfigured while the mobile node has been away from home, such that reconfigured while the mobile node has been away from home, such that
the router that was operating as the mobile node's home agent has the router that was operating as the mobile node's home agent has
been replaced by a different router serving this role. been replaced by a different router serving this role.
In this case, the mobile node MAY use the dynamic home agent address In this case, the mobile node MAY use the dynamic home agent address
discovery mechanism to find the address of a suitable home agent on discovery mechanism to find the address of a suitable home agent on
its home link. To do so, the mobile node sends an ICMP Home Agent its home link. To do so, the mobile node sends an ICMP Home Agent
Address Discovery Request message to the "Mobile IPv6 Home-Agents" Address Discovery Request message to the "Mobile IPv6 Home-Agents"
anycast address [10] for its home subnet prefix. This packet MUST anycast address [10] for its home subnet prefix. This packet MUST
also include a Home Address option giving the mobile node's home NOT a Home Address option and must be sent using the mobile node's
address. As described in Section 9.2, the home agent on its home care-of address as the Source Address in the packet's IP header
link that receives this Request message will return an ICMP Home (the packet is sent from the care-of address, not using Mobile IP).
Agent Address Discovery Reply message, giving this home agent's own As described in Section 9.2, the home agent on its home link that
global unicast IP address along with a list of the global unicast IP receives this Request message will return an ICMP Home Agent Address
address of each other home agent operating on the home link. Discovery Reply message, giving this home agent's own global unicast
IP address along with a list of the global unicast IP address of each
other home agent operating on the home link.
The mobile node, upon receiving this Home Agent Address Discovery The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to Reply message, MAY then send its home registration Binding Update to
the home agent address given as the IP Source Address of the packet the home agent address given as the IP Source Address of the packet
carrying the Reply message or to any of the unicast IP addresses carrying the Reply message or to any of the unicast IP addresses
listed in the Home Agent Addresses field in the Reply. For example, listed in the Home Agent Addresses field in the Reply. For example,
if necessary, the mobile node MAY attempt its home registration if necessary, the mobile node MAY attempt its home registration
with each of these home agents, in turn, by sending each a Binding with each of these home agents, in turn, by sending each a Binding
Update and waiting for the matching Binding Acknowledgement, until Update and waiting for the matching Binding Acknowledgement, until
its registration is accepted by one of these home agents. In trying its registration is accepted by one of these home agents. In trying
skipping to change at page 82, line 32 skipping to change at page 83, line 35
- The packet was tunneled using IPv6 encapsulation. - The packet was tunneled using IPv6 encapsulation.
- The Destination Address in the tunnel (outer) IPv6 header is - The Destination Address in the tunnel (outer) IPv6 header is
equal to any of the mobile node's care-of addresses. equal to any of the mobile node's care-of addresses.
- The Destination Address in the original (inner) IPv6 header - The Destination Address in the original (inner) IPv6 header
is equal to one of the mobile node's home addresses; or this is equal to one of the mobile node's home addresses; or this
Destination Address is equal to one of the mobile node's previous Destination Address is equal to one of the mobile node's previous
care-of addresses, if the mobile node has an entry in its Binding care-of addresses, if the mobile node has an entry in its Binding
Update List representing an unexpired Binding Update sent to Update List representing an unexpired Binding Update sent to a
a previous default router for this previous care-of address home agent on the link on which its previous care-of address is
(Section 10.9). located (Section 10.9).
- The Source Address in the tunnel (outer) IPv6 header differs from - The Source Address in the tunnel (outer) IPv6 header differs from
the Source Address in the original (inner) IPv6 header. the Source Address in the original (inner) IPv6 header.
The destination address to which the Binding Update should be sent The destination address to which the Binding Update should be sent
in response to receiving a packet meeting all of the above tests is in response to receiving a packet meeting all of the above tests is
the Source Address in the original (inner) IPv6 header of the packet. the Source Address in the original (inner) IPv6 header of the packet.
The home address for which this Binding Update is sent should be the The home address for which this Binding Update is sent should be the
Destination Address of the original (inner) packet. Destination Address of the original (inner) packet.
skipping to change at page 84, line 19 skipping to change at page 85, line 23
attached to the link on which this previous care-of address and this attached to the link on which this previous care-of address and this
home agent are located; the mobile node obtains this home agent home agent are located; the mobile node obtains this home agent
address from its Home Agents List (Section 4.3). Alternatively, address from its Home Agents List (Section 4.3). Alternatively,
the mobile node MAY use dynamic home agent address discovery the mobile node MAY use dynamic home agent address discovery
(Section 10.7) to discover the global unicast address of a home agent (Section 10.7) to discover the global unicast address of a home agent
on this previous link, but it SHOULD use an address from its Home on this previous link, but it SHOULD use an address from its Home
Agents List if available for the prefix it used in this previous Agents List if available for the prefix it used in this previous
care-of address. care-of address.
As with any packet containing a Binding Update 5.1, the Binding As with any packet containing a Binding Update 5.1, the Binding
Update packet to this home agent MUST include either an AH [11] or Update packet to this home agent MUST meet the IPsec requirements for
ESP [12] header providing sender authentication, data integrity Binding Updates, defined in Section 5.1.
protection, and replay protection.
10.10. Retransmitting Binding Updates 10.10. Retransmitting Binding Updates
If, after sending a Binding Update in which the Acknowledge (A) If, after sending a Binding Update in which the Acknowledge (A)
bit is set, a mobile node fails to receive a valid, matching bit is set, a mobile node fails to receive a valid, matching
Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the
mobile node SHOULD retransmit the Binding Update, until a Binding mobile node SHOULD retransmit the Binding Update, until a Binding
Acknowledgement is received. Such a retransmitted Binding Update Acknowledgement is received. Such a retransmitted Binding Update
MUST use a Sequence Number value greater than that used for the MUST use a Sequence Number value greater than that used for the
previous transmission of this Binding Update. The retransmissions by previous transmission of this Binding Update. The retransmissions by
skipping to change at page 85, line 10 skipping to change at page 86, line 10
Binding Updates at this slower rate indefinitely, in hopes that the Binding Updates at this slower rate indefinitely, in hopes that the
node will eventually be able to process a Binding Update and begin node will eventually be able to process a Binding Update and begin
to route its packets directly to the mobile node at its new care-of to route its packets directly to the mobile node at its new care-of
address. address.
10.12. Receiving Binding Acknowledgements 10.12. Receiving Binding Acknowledgements
Upon receiving a packet carrying a Binding Acknowledgement, a mobile Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests: node MUST validate the packet according to the following tests:
- The packet contains a valid AH [11] or ESP [12] header providing - The packet meets the specific IPsec requirements for Binding
sender authentication, data integrity protection, and replay Acknowledgements, defined in Section 5.2.
protection.
- The Option Length field in the option is greater than or equal to - The Option Length field in the option is greater than or equal to
11 octets. 11 octets.
- The Sequence Number field matches the Sequence Number sent by the - The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding mobile node to this destination address in an outstanding Binding
Update. Update.
Any Binding Acknowledgement not satisfying all of these tests MUST be Any Binding Acknowledgement not satisfying all of these tests MUST be
silently ignored, although the remainder of the packet (i.e., other silently ignored, although the remainder of the packet (i.e., other
skipping to change at page 88, line 35 skipping to change at page 89, line 35
use on the mobile node's home link. use on the mobile node's home link.
When a mobile node receives a tunneled Router Advertisement, it MUST When a mobile node receives a tunneled Router Advertisement, it MUST
validate it according to the following tests: validate it according to the following tests:
- The Source Address of the IP packet carrying the Router - The Source Address of the IP packet carrying the Router
Advertisement is the same as the home agent address to which the Advertisement is the same as the home agent address to which the
mobile node last sent an accepted "home registration" Binding mobile node last sent an accepted "home registration" Binding
Update to register its primary care-of address. Update to register its primary care-of address.
- The packet contains either an AH [11] or ESP [12] header - The packet MUST be protected by IPsec [13, 11, 12] to guard
providing sender authentication, data integrity protection, and against malicious Router Advertisements. The IPsec protection
replay protection. MUST provide sender authentication, data integrity protection,
and replay protection, covering the Router Advertisement.
- The packet contains a Binding Request destination option. - The packet contains a Binding Request destination option.
- The Binding Request option contains a Unique Identifier - The Binding Request option contains a Unique Identifier
Sub-Option. Sub-Option.
Any received tunneled Router Advertisement not meeting all of these Any received tunneled Router Advertisement not meeting all of these
tests MUST be silently discarded. tests MUST be silently discarded.
If a received tunneled Router Advertisement is not discarded If a received tunneled Router Advertisement is not discarded
skipping to change at page 90, line 44 skipping to change at page 91, line 50
The mobile node SHOULD then send a Binding Update to its home agent, The mobile node SHOULD then send a Binding Update to its home agent,
to instruct its home agent to no longer intercept or tunnel packets to instruct its home agent to no longer intercept or tunnel packets
for it. In this Binding Update, the mobile node MUST set the care-of for it. In this Binding Update, the mobile node MUST set the care-of
address for the binding (the Source Address field in the packet's address for the binding (the Source Address field in the packet's
IPv6 header) to the mobile node's own home address. As with other IPv6 header) to the mobile node's own home address. As with other
Binding Updates sent to register with its home agent, the mobile Binding Updates sent to register with its home agent, the mobile
node MUST set the Acknowledge (A) and Home Registration (H) bits, node MUST set the Acknowledge (A) and Home Registration (H) bits,
and SHOULD retransmit the Binding Update until a matching Binding and SHOULD retransmit the Binding Update until a matching Binding
Acknowledgement is received. Acknowledgement is received.
In addition, the mobile node MUST multicast onto the home link When sending this Binding Update to its home agent, the mobile
(to the all-nodes multicast address) a Neighbor Advertisement node must be careful in how it uses Neighbor Soliciation [17] (if
needed) to learn the home agent's link-layer address, since the home
agent will be currently configured to defend the mobile node's home
address for Duplicate Address Detection. In particular, a Neighbor
Solicitation from the mobile node using its home address as the
Source Address would be detected by the home agent as a duplicate
address. In many cases, Neighbor Solicitation by the mobile node
for the home agent's address will not be necessary, since the mobile
node may have already learned the home agent's link-layer address,
for example from a Source Link-Layer Address option in the Router
Advertisement from which it learned that its home address was on-link
and that the mobile node had thus returned home. If the mobile node
does Neighbor Solicitation to learn the home agent's link-layer
address, in this special case of the mobile node returning home, the
mobile node MUST set the Source Address of this Neighbor Solicitation
to the unspecified address.
The mobile node then sends its Binding Update using the home agent's
link-layer address, instructing its home agent to no longer serve
as a home agent for it. By processing this Binding Update, the
home agent will cease defending the mobile node's home address for
Duplicate Address Detection and will no longer respond to Neighbor
Solicitations for the mobile node's home address. The mobile node is
then the only node on the link using the mobile node's home address.
In addition, when returning home and configuring its home address
on its network interface on its home link, the mobile node MUST NOT
perform Duplicate Address Detection on its own home address, in order
to avoid confusion or conflict with its home agent's use of the same
address.
After receiving the Binding Acknowledgement for its Binding Update
to its home agent, the mobile node MUST multicast onto the home
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
home addresses, as defined by the current on-link prefixes, including home addresses, as defined by the current on-link prefixes, including
its link-local address and site-local address. The Solicited its link-local address and site-local address. The Solicited
Flag (S) in these Advertisements MUST NOT be set, since they were Flag (S) in these Advertisements MUST NOT be set, since they were
not solicited by any Neighbor Solicitation message. The Override not solicited by any Neighbor Solicitation message. The Override
skipping to change at page 97, line 9 skipping to change at page 99, line 9
privacy is desired, the mobile node can create a tunnel to its home privacy is desired, the mobile node can create a tunnel to its home
agent. Then, packets destined for correspondent nodes will appear agent. Then, packets destined for correspondent nodes will appear
to emanate from the home subnet, and it may be more difficult to to emanate from the home subnet, and it may be more difficult to
pinpoint the location of the mobile node. Such mechanisms are all pinpoint the location of the mobile node. Such mechanisms are all
beyond the scope of this document. beyond the scope of this document.
Changes from Previous Version of the Draft 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-09.txt: draft-ietf-mobileip-ipv6-10.txt:
- Added additional material in Section 10.2, discussing use any
automated key management protocol [13] (such as IKE [8]) to
create any new SA (or SA bundle) while away from home.
- Also added additional material in Section 10.2 to define the
order in which the Home Address option and Binding Update option
appear in the packet relative to the AH or ESP header that is
required when a Binding Update is inserted. In addition, this
change corrects the placement of the Home Address option in the
packet to be before (not after) the AH or ESP header, so that the
Home Address option is processed by the destination node before
the AH or ESP header is processed.
- Changed the dynamic home agent address discovery mechanism
to use dedicated ICMP message types (defined in Sections 5.6
and 5.7) rather than (re)using the Binding Update and Binding
Acknowledgement options. This change was primarily motivated
by the fact that IP packets sent to an anycast address cannot
(currently) use AH or ESP authentication since the packet is not
directed to any single node with which a Security Association
could be established. In addition, this change simplifies the
processing of Binding Updates and Binding Acknowledgements, since
it removes the special cases there for dynamic home agent address
discovery.
- Removed the Binding Acknowledgement option Status value of 135
(dynamic home agent address discovery response) since it is
no longer needed with the revised dynamic home agent address
discovery mechanism.
- Removed the Home Agents List Sub-Option since it is no longer
needed with the revised dynamic home agent address discovery
mechanism.
- Added a Duplicate Address Detection (D) bit in the Binding
Update option format, to request the mobile node's home agent to
perform Duplicate Address Detection on the mobile node's home
link for the home address in this binding. Also defined a new
Status value of 138 (Duplicate Address Detection failed) for
the Binding Acknowledgement, to indicate any failure of this
Duplicate Address Detection on the home link. The addition of
the Duplicate Address Detection (D) bit in the Binding Update
option also reduced the Reserved field from a 5-bit field to a
4-bit field (and caused it to be renamed Reservd so that the
label fits in the packet format drawing).
- Added text in Section 9.3 and 10.16 to describe the use of the - Added material in Section 10.19 dealing with the problem of
new Duplicate Address Detection (D) bit in the Binding Update Duplicate Address Detection on the home link when the mobile node
option format. returns home.
- Changed the description of the Home Agents List conceptual data - Moved all specific requirements for use of IPsec with Binding
structure to require maintenance of a Home Agents List by each Updates and Binding Acknowledgements to Sections 5.1 and 5.2,
mobile node, as well as by each home agent. A mobile node uses respectively. This avoids repeating the same requirements in
this list to enable notifying a home agent on its previous link, possibly different ways in many places throughout the document.
when the mobile node moves to a new link. Instead, all such places now refer to Sections 5.1 or 5.2.
- In Section 10.10, changed the procedure for retransmitting - Defined in Sections 5.1 and 5.2 that all packets including a
Binding Updates to require that the Sequence Number field in Binding Update or Binding Acknowledgement, respectively, MUST use
each successive retransmission MUST be greater than that used AH to provide the required sender authentication, data integrity
in the previous transmission. The draft previously incorrectly protection, and replay protection. Use of ESP for protecting the
specified here that the same sequence number must be used for Binding Updates and Binding Acknowledgements is not currently
each retransmission. The change is needed since such reuse defined in this document, since ESP does not protect the portion
of sequence numbers will fail if the original transmission of the packet above the ESP header itself.
of the Binding Update was in fact received, but the Binding
Acknowledgement (instead of the Binding Update) was lost in
transmission on the network. Changing the Sequence Number on
each retransmission also avoids the any acknowledgement ambiguity
problem, making the start time for the binding lifetime more
clear.
- Corrected yet a few more minor typographical errors in places. - Corrected yet a few more minor typographical errors in places.
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), Rich Draves (Cisco), Josh Broch (Carnegie Mellon University), Rich Draves
(Microsoft Research), Francis Dupont (INRIA), Jun-Ichiro Hagino (Microsoft Research), Francis Dupont (INRIA), Jun-Ichiro Hagino (IIJ
(IIJ Research Laboratory), Aime Lerouzic (Bull S.A.), Thomas Narten Research Laboratory), Aime Lerouzic (Bull S.A.), Thomas Narten (IBM),
(IBM), Erik Nordmark (Sun Microsystems), Simon Nybroe (Telebit Erik Nordmark (Sun Microsystems), Simon Nybroe (Ericsson Telebit),
Communications), David Oran (Cisco), Basavaraj Patil (Nokia), Phil David Oran (Cisco), Basavaraj Patil (Nokia), Phil Roberts (Motorola),
Roberts (Motorola), Patrice Romand (Bull S.A.), Tom Soderlund (Nokia Patrice Romand (Bull S.A.), Tom Soderlund (Nokia Research), Hesham
Research), Hesham Soliman (Ericsson), Jim Solomon (RedBack Networks), Soliman (Ericsson), Jim Solomon (RedBack Networks), Benny Van Houdt
Benny Van Houdt (University of Antwerp), and Xinhua Zhao (Stanford (University of Antwerp), and Xinhua Zhao (Stanford University) for
University) for their detailed reviews of earlier versions of this their detailed reviews of earlier versions of this document. Their
document. Their suggestions have helped to improve both the design suggestions have helped to improve both the design and presentation
and presentation of the protocol. We would also like to thank the of the protocol.
participants in the Mobile IPv6 testing event held at Nancy, France,
September 15-17, 1999, for their valuable feedback as a result of We would also like to thank the participants in the Mobile IPv6
interoperability testing of four Mobile IPv6 implementations coming testing event held at Nancy, France, September 15-17, 1999, for
from four different organizations: Bull (AIX), Ericsson-Telebit their valuable feedback as a result of interoperability testing
(FreeBSD), NEC (FreeBSD), and INRIA (FreeBSD). of four Mobile IPv6 implementations coming from four different
organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC
(FreeBSD), and INRIA (FreeBSD). Finally, we would like to thank the
feedback from the implementors who participated in the Mobile IPv6
interoperability testing at Connectathon 2000 in San Jose,
California, March 6-9, 2000.
References References
[1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite.
ACM Computer Communications Review, 19(2), March 1989. ACM Computer Communications Review, 19(2), March 1989.
[2] Jim Bound and Charles Perkins. Dynamic Host Configuration [2] Jim Bound and Charles Perkins. Dynamic Host Configuration
Protocol for IPv6 (DHCPv6), February 1999. Work in progress. Protocol for IPv6 (DHCPv6), February 1999. Work in progress.
[3] Scott Bradner. Key words for use in RFCs to indicate [3] Scott Bradner. Key words for use in RFCs to indicate
 End of changes. 

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