18] by the addition of a single flag bit to indicate that the router sending the Advertisement message is serving as a home agent on this link. The format of the Router Advertisement message is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- This format represents the following changes over that originally specified for Neighbor Discovery : Home Agent (H) The Home Agent (H) bit is set in a Router Advertisement to indicate that the router sending this Router Advertisement is also functioning as a Mobile IPv6 home agent on this link. Reserved Reduced from a 6-bit field to a 5-bit field to account for the addition of the above bit.
18] only advertises a router's link- local address, by requiring this address to be used as the IP Source Address of each Router Advertisement. Mobile IPv6 extends Neighbor Discovery to allow a router to advertise its global address, by the addition of a single flag bit in the format of a Prefix Information option for use in Router Advertisement messages. The format of the Prefix Information option is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format represents the following changes over that originally specified for Neighbor Discovery : Router Address (R) 1-bit router address flag. When set, indicates that the Prefix field contains a complete IP address assigned to the sending router. The indicated prefix is given by the first Prefix Length bits of the Prefix field. The router IP address has the same scope and conforms to the same lifetime values as the advertised prefix. This use of the Prefix field is compatible with its use in advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus independent of the processing required for the On-Link (L) and Autonomous Address-Configuration (A) flag bits. Reserved1 Reduced from a 6-bit field to a 5-bit field to account for the addition of the above bit. In a Router Advertisement, a home agent MUST, and all other routers MAY, include at least one Prefix Information option with the Router Address (R) bit set. Neighbor Discovery (RFC 4861 ) specifies that, when including all options in a Router Advertisement causes the size of the Advertisement to exceed the link MTU, multiple Advertisements can be sent, each containing a subset of the Neighbor Discovery options. Also, when sending unsolicited multicast Router Advertisements more frequently than the limit specified in RFC 4861, the sending router need not include all options in each of these Advertisements. However, in both of these cases the router SHOULD include at least one Prefix Information option with the Router Address (R) bit set in each such advertisement, if this bit is set in some advertisement sent by the router. In addition, the following requirement can assist mobile nodes in movement detection. Barring changes in the prefixes for the link, routers that send multiple Router Advertisements with the Router Address (R) bit set in some of the included Prefix Information options SHOULD provide at least one option and router address that stays the same in all of the Advertisements.
Type 7 Length 8-bit unsigned integer. The length of the option (including the type and length fields) is in units of 8 octets. The value of this field MUST be 1. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Advertisement Interval 32-bit unsigned integer. The maximum time, in milliseconds, between successive unsolicited Router Advertisement messages sent by this router on this network interface. Using the conceptual router configuration variables defined by Neighbor Discovery , this field MUST be equal to the value MaxRtrAdvInterval, expressed in milliseconds. Routers MAY include this option in their Router Advertisements. A mobile node receiving a Router Advertisement containing this option SHOULD utilize the specified Advertisement Interval for that router in its movement detection algorithm, as described in Section 11.5.1. This option MUST be silently ignored for other Neighbor Discovery messages.
Type 8 Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value of this field MUST be 1. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Home Agent Preference 16-bit unsigned integer. The preference for the home agent sending this Router Advertisement, for use in ordering the addresses returned to a mobile node in the Home Agent Addresses field of a Home Agent Address Discovery Reply message. Higher values mean more preferable. If this option is not included in a Router Advertisement in which the Home Agent (H) bit is set, the preference value for this home agent MUST be considered to be 0. Greater values indicate a more preferable home agent than lower values. The manual configuration of the Home Agent Preference value is described in Section 8.4. In addition, the sending home agent MAY dynamically set the Home Agent Preference value, for example, basing it on the number of mobile nodes it is currently serving or on its remaining resources for serving additional mobile nodes; such dynamic settings are beyond the scope of this document. Any such dynamic setting of the Home Agent Preference, however, MUST set the preference appropriately, 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 agent not including a Home Agent Information option in its Router Advertisements will be considered to have a Home Agent Preference value of 0). Home Agent Lifetime 16-bit unsigned integer. The lifetime associated with the home agent in units of seconds. The default value is the same as the Router Lifetime, as specified in the main body of the Router Advertisement. 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 agent; it does not apply to information contained in other message fields or options. Home agents MAY include this option in their Router Advertisements. This option MUST NOT be included in a Router Advertisement in which the Home Agent (H) bit (see Section 7.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. If multiple Advertisements are being sent instead of a single larger unsolicited multicast Router Advertisement, all of the multiple Advertisements with the Router Address (R) bit set MUST include this option with the same contents; otherwise, this option MUST be omitted from all Advertisements. This option MUST be silently ignored for other Neighbor Discovery messages. If both the Home Agent Preference and Home Agent Lifetime are set to their default values specified above, this option SHOULD NOT be included in the Router Advertisement messages sent by this home agent. 18] limits routers to a minimum interval of 3 seconds between sending unsolicited multicast Router Advertisement messages from any given network interface (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection. This limitation, however, is not suitable to providing timely movement detection for mobile nodes. Mobile nodes detect their own movement by learning the presence of new routers as the mobile node moves into wireless transmission range of them (or physically connects to a new wired network), and by learning that previous routers are no longer reachable. Mobile nodes MUST be able to quickly detect when they move to a link served by a new router, so that they can acquire a new care-of address and send Binding Updates to register this care-of address with their home agent and to notify correspondent nodes as needed.
One method that can provide for faster movement detection is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. This method can be applied where the router is expecting to provide service to visiting mobile nodes (e.g., wireless network interfaces), or on which it is serving as a home agent to one or more mobile nodes (who may return home and need to hear its Advertisements). Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow sending of unsolicited multicast Router Advertisements more often. The minimum allowed values are: o MinRtrAdvInterval 0.03 seconds o MaxRtrAdvInterval 0.07 seconds In the case where the minimum intervals and delays are used, the mean time between unsolicited multicast Router Advertisements is 50 ms. Use of these modified limits MUST be configurable (see also the configuration variable MinDelayBetweenRas in Section 13 that may also have to be modified accordingly). Systems where these values are available MUST NOT default to them, and SHOULD default to values specified in Neighbor Discovery (RFC 4861 ). Knowledge of the type of network interface and operating environment SHOULD be taken into account in configuring these limits for each network interface. This is important with some wireless links, where increasing the frequency of multicast beacons can cause considerable overhead. Routers SHOULD adhere to the intervals specified in RFC 4861 , if this overhead is likely to cause service degradation. Additionally, the possible low values of MaxRtrAdvInterval may cause some problems with movement detection in some mobile nodes. To ensure that this is not a problem, Routers SHOULD add 20 ms to any Advertisement Intervals sent in RAs that are below 200 ms, in order to account for scheduling granularities on both the MN and the router. Note that multicast Router Advertisements are not always required in certain wireless networks that have limited bandwidth. Mobility detection or link changes in such networks may be done at lower layers. Router advertisements in such networks SHOULD be sent only when solicited. In such networks it SHOULD be possible to disable unsolicited multicast Router Advertisements on specific interfaces. The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set to some high values.
Home agents MUST include the Source Link-Layer Address option in all Router Advertisements they send. This simplifies the process of returning home, as discussed in Section 11.5.5. Note that according to Neighbor Discovery (RFC 4861 ), AdvDefaultLifetime is by default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime field of Router Advertisements. Given that this field is expressed in seconds, a small MaxRtrAdvInterval value can result in a zero value for this field. To prevent this, routers SHOULD keep AdvDefaultLifetime in at least one second, even if the use of MaxRtrAdvInterval would result in a smaller value. Section 11.3.5), and communications will flow through the home agent.
An IPv6 node MUST NOT support the Home Address destination option, type 2 routing header, or the Mobility Header unless it fully supports the requirements listed in the next sections for either route optimization, mobile node, or home agent functionality. Section 11.3.1 discusses how mobile nodes may avoid route optimization for some of the remaining cases, such as very short-term communications. The following requirements apply to all correspondent nodes that support route optimization: o The node MUST be able to validate a Home Address option using an existing Binding Cache entry, as described in Section 9.3.1. o The node MUST be able to insert a type 2 routing header into packets to be sent to a mobile node, as described in Section 9.3.2.
o Unless the correspondent node is also acting as a mobile node, it MUST ignore type 2 routing headers and silently discard all packets that it has received with such headers. o The node SHOULD be able to interpret ICMP messages as described in Section 9.3.4. o The node MUST be able to send Binding Error messages as described in Section 9.3.3. o The node MUST be able to process Mobility Headers as described in Section 9.2. o The node MUST be able to participate in a return routability procedure (Section 9.4). o The node MUST be able to process Binding Update messages (Section 9.5). o The node MUST be able to return a Binding Acknowledgement (Section 9.5.4). o The node MUST be able to maintain a Binding Cache of the bindings received in accepted Binding Updates, as described in Sections 9.1 and 9.6. o The node SHOULD allow route optimization to be administratively enabled or disabled. The default SHOULD be enabled. Section 7.3) in each of its Router Advertisements , to aid movement detection by mobile nodes (as in Section 11.5.1). The use of this option in Router Advertisements SHOULD be configurable. o Every IPv6 router SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 7.5. If the router supports a faster rate, the used rate MUST be configurable. o Each router SHOULD include at least one prefix with the Router Address (R) bit set and with its full IP address in its Router Advertisements (as described in Section 7.2).
o Routers supporting filtering packets with routing headers SHOULD support different rules for type 0 and type 2 routing headers (see Section 6.4) so that filtering of source routed packets (type 0) will not necessarily limit Mobile IPv6 traffic that is delivered via type 2 routing headers. 10.1 and 10.3.1). o Every home agent MUST be able to intercept packets (using proxy Neighbor Discovery ) addressed to a mobile node for which it is currently serving as the home agent, on that mobile node's home link, while the mobile node is away from home (Section 10.4.1). o Every home agent MUST be able to encapsulate  such intercepted packets in order to tunnel them to the primary care-of address for the mobile node indicated in its binding in the home agent's Binding Cache (Section 10.4.2). o Every home agent MUST support decapsulating  reverse-tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node (Section 10.4.5). o The node MUST be able to process Mobility Headers as described in Section 10.2. o Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update (Section 10.3.1). o Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in Sections 10.1 and 10.5.1. o Every home agent MUST be able to accept packets addressed to the Mobile IPv6 Home-Agents anycast address  for the subnet on which it is serving as a home agent, and MUST be able to participate in dynamic home agent address discovery (Section 10.5).
o Every home agent SHOULD support a configuration mechanism to allow a system administrator to manually set the value to be sent by this home agent in the Home Agent Preference field of the Home Agent Information Option in Router Advertisements that it sends (Section 7.4). o Every home agent SHOULD support sending ICMP Mobile Prefix Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix Solicitations (Section 6.7). If supported, this behavior MUST be configurable, so that home agents can be configured to avoid sending such Prefix Advertisements according to the needs of the network administration in the home domain. o Every home agent MUST support IPsec ESP for protection of packets belonging to the return routability procedure (Section 10.4.6). o Every home agent SHOULD support the multicast group membership control protocols as described in Section 10.4.3. If this support is provided, the home agent MUST be capable of using it to determine which multicast data packets to forward via the tunnel to the mobile node. o Home agents MAY support stateful address autoconfiguration for mobile nodes as described in Section 10.4.4. Section 11.1). o The node MUST support sending packets containing a Home Address option (Section 11.3.1), and follow the required IPsec interaction (Section 11.3.2). o The node MUST be able to perform IPv6 encapsulation and decapsulation . o The node MUST be able to process type 2 routing header as defined in Sections 6.4 and 11.3.3. o The node MUST support receiving a Binding Error message (Section 11.3.6). o The node MUST support receiving ICMP errors (Section 11.3.5).
o The node MUST support movement detection, care-of address formation, and returning home (Section 11.5). o The node MUST be able to process Mobility Headers as described in Section 11.2. o The node MUST support the return routability procedure (Section 11.6). o The node MUST be able to send Binding Updates, as specified in Sections 11.7.1 and 11.7.2. o The node MUST be able to receive and process Binding Acknowledgements, as specified in Section 11.7.3. o The node MUST support receiving a Binding Refresh Request (Section 6.1.2), by responding with a Binding Update. o The node MUST support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. o The node SHOULD support use of the dynamic home agent address discovery mechanism, as described in Section 11.4.1. o The node MUST allow route optimization to be administratively enabled or disabled. The default SHOULD be enabled. o The node MAY support the multicast address listener part of a multicast group membership protocol as described in Section 11.3.4. If this support is provided, the mobile node MUST be able to receive tunneled multicast packets from the home agent. o The node MAY support stateful address autoconfiguration mechanisms such as DHCPv6  on the interface represented by the tunnel to the home agent.
maintained by Neighbor Discovery . When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache . Each Binding Cache entry conceptually contains the following fields: o The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent. o The care-of address for the mobile node indicated by the home address field in this Binding Cache entry. o A lifetime value, indicating the remaining lifetime for this Binding Cache entry. The lifetime value is initialized from the Lifetime field in the Binding Update that created or last modified this Binding Cache entry. A correspondent node MAY select a smaller lifetime for the Binding Cache entry, and supply that value to the mobile node in the Binding Acknowledgment message. o A flag indicating whether or not this Binding Cache entry is a home registration entry (applicable only on nodes that support home agent functionality). o The maximum value of the Sequence Number field received in previous Binding Updates for this home address. The Sequence Number field is 16 bits long. Sequence Number values MUST be compared modulo 2**16 as explained in Section 9.5.1. o Usage information for this Binding Cache entry. This is needed to implement the cache replacement policy in use in the Binding Cache. Recent use of a cache entry also serves as an indication that a Binding Refresh Request should be sent when the lifetime of this entry nears expiration. Binding Cache entries not marked as home registrations MAY be replaced at any time by any reasonable local cache replacement policy but SHOULD NOT be unnecessarily deleted. The Binding Cache for any one of a node's IPv6 addresses may contain at most one entry for each mobile node home address. The contents of a node's Binding Cache MUST NOT be changed in response to a Home Address option in a received packet.
Section 6.1. If invalid, the node MUST silently discard the message. o The MH Type field MUST have a known value (Section 6.1.1). Otherwise, the node MUST discard the message and issue a Binding Error message as described in Section 9.3.3, with the Status field set to 2 (unrecognized MH Type value). o The Payload Proto field MUST be IPPROTO_NONE (59 decimal). Otherwise, the node MUST discard the message and SHOULD send ICMP Parameter Problem, Code 0, directly to the Source Address of the packet as specified in RFC 4443 . Thus, no Binding Cache information is used in sending the ICMP message. The Pointer field in the ICMP message SHOULD point at the Payload Proto field. o The Header Len field in the Mobility Header MUST NOT be less than the length specified for this particular type of message in Section 6.1. Otherwise, the node MUST discard the message and SHOULD send ICMP Parameter Problem, Code 0, directly to the Source Address of the packet as specified in RFC 4443 . (The Binding Cache information is again not used.) The Pointer field in the ICMP message SHOULD point at the Header Len field. Subsequent checks depend on the particular Mobility Header.
entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet. If the packet is dropped due to the above tests, the correspondent node MUST send the Binding Error message as described in Section 9.3.3. The Status field in this message should be set to 1 (unknown binding for Home Address destination option). The correspondent node MUST process the option in a manner consistent with exchanging the Home Address field from the Home Address option into the IPv6 header and replacing the original value of the Source Address field there. After all IPv6 options have been processed, it MUST be possible for upper layers to process the packet without the knowledge that it came originally from a care-of address or that a Home Address option was used. The use of IPsec Authentication Header (AH) for the Home Address option is not required, except that if the IPv6 header of a packet is covered by AH, then the authentication MUST also cover the Home Address option; this coverage is achieved automatically by the definition of the Option Type code for the Home Address option, since it indicates that the data within the option cannot change en route to the packet's final destination, and thus the option is included in the AH computation. By requiring that any authentication of the IPv6 header also cover the Home Address option, the security of the Source Address field in the IPv6 header is not compromised by the presence of a Home Address option. When attempting to verify AH authentication data in a packet that contains a Home Address option, the receiving node MUST calculate the AH authentication data as if the following were true: the Home Address option contains the care-of address, and the source IPv6 address field of the IPv6 header contains the home address. This conforms with the calculation specified in Section 11.3.2. 18] packet.
o Where otherwise noted in Section 6.1. When calculating authentication data in a packet that contains a type 2 routing header, the correspondent node MUST calculate the AH authentication data as if the following were true: the routing header contains the care-of address, the destination IPv6 address field of the IPv6 header contains the home address, and the Segments Left field is zero. The IPsec Security Policy Database lookup MUST based on the mobile node's home address. For instance, assuming there are no additional routing headers in this packet beyond those needed by Mobile IPv6, the correspondent node could set the fields in the packet's IPv6 header and routing header as follows: o The Destination Address in the packet's IPv6 header is set to the mobile node's home address (the original destination address to which the packet was being sent). o The routing header is initialized to contain a single route segment, containing the mobile node's care-of address copied from the Binding Cache entry. The Segments Left field is, however, temporarily set to zero. The IP layer will insert the routing header before performing any necessary IPsec processing. Once all IPsec processing has been performed, the node swaps the IPv6 destination field with the Home Address field in the routing header, sets the Segments Left field to one, and sends the packet. This ensures the AH calculation is done on the packet in the form it will have on the receiver after advancing the routing header. Following the definition of a type 2 routing header in Section 6.4, this packet will be routed to the mobile node's care-of address, where it will be delivered to the mobile node (the mobile node has associated the care-of address with its network interface). Note that following the above conceptual model in an implementation creates some additional requirements for path MTU discovery since the layer that determines the packet size (e.g., TCP and applications using UDP) needs to be aware of the size of the headers added by the IP layer on the sending node. If, instead, the sending node has no Binding Cache entry for the destination address to which the packet is being sent, the sending node simply sends the packet normally, with no routing header. If the destination node is not a mobile node (or is a mobile node that is currently at home), the packet will be delivered directly to this
node and processed normally by it. If, however, the destination node is a mobile node that is currently away from home, the packet will be intercepted by the mobile node's home agent and tunneled to the mobile node's current primary care-of address. 9.2 and 9.3.1 describe error conditions that lead to a need to send a Binding Error message. A Binding Error message is sent directly to the address that appeared in the IPv6 Source Address field of the offending packet. If the Source Address field does not contain a unicast address, the Binding Error message MUST NOT be sent. The Home Address field in the Binding Error message MUST be copied from the Home Address field in the Home Address destination option of the offending packet, or set to the unspecified address if no such option appeared in the packet. Note that the IPv6 Source Address and Home Address field values discussed above are the values from the wire, i.e., before any modifications possibly performed as specified in Section 9.3.1. Binding Error messages SHOULD be subject to rate limiting in the same manner as is done for ICMPv6 messages . 7], the home agent MUST relay certain ICMP error messages back to the original sender of the packet, which in this case is the correspondent node. Thus, in all cases, any meaningful ICMP error messages caused by packets from a correspondent node to a mobile node will be returned to the correspondent node. If the correspondent node receives
persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. Note that if the mobile node continues to send packets with the Home Address destination option to this correspondent node, they will be dropped due to the lack of a binding. For this reason it is important that only persistent ICMP messages lead to the deletion of the Binding Cache entry. Section 5.2. The correspondent node MUST have a secret Kcn and a nonce. If it does not have this material yet, it MUST produce it before continuing with the return routability procedure. Section 9.4.3 specifies further processing. Section 9.4.1.
Section 9.4.4 specifies further processing. Section 6.1.5) and sends it to the mobile node at the latter's home address. Section 6.1.6) and sends it to the mobile node at the latter's care-of address.
This Sequence Number comparison MUST be performed modulo 2**16, i.e., the number is a free running counter represented modulo 65536. A Sequence Number in a received Binding Update is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32768 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32783 through 65535, would be considered less than or equal. When the Home Registration (H) bit is not set, the following are also required: o A Nonce Indices mobility option MUST be present, and the Home and Care-of Nonce Index values in this option MUST be recent enough to be recognized by the correspondent node. (Care-of Nonce Index values are not inspected for requests to delete a binding.) o The correspondent node MUST re-generate the home keygen token and the care-of keygen token from the information contained in the packet. It then generates the binding management key Kbm and uses it to verify the authenticator field in the Binding Update as specified in Section 6.1.7. o The Binding Authorization Data mobility option MUST be present, and its contents MUST satisfy rules presented in Section 5.2.6. Note that a care-of address different from the Source Address MAY have been specified by including an Alternate Care-of Address mobility option in the Binding Update. When such a message is received and the return routability procedure is used as an authorization method, the correspondent node MUST verify the authenticator by using the address within the Alternate Care-of Address in the calculations. o The Binding Authorization Data mobility option MUST be the last option and MUST NOT have trailing padding. If the Home Registration (H) bit is set, the Nonce Indices mobility option MUST NOT be present. If the mobile node sends a sequence number that is not greater than the sequence number from the last valid Binding Update for this home address, then the receiving node MUST send back a Binding Acknowledgement with status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement.
If a binding already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 139 (registration type change disallowed). The home registration flag stored in the Binding Cache entry MUST NOT be changed. If the receiving node no longer recognizes the Home Nonce Index value, Care-of Nonce Index value, or both values from the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 136, 137, or 138, respectively. Packets carrying Binding Updates that fail to satisfy all of these tests for any reason other than insufficiency of the Sequence Number, registration type change, or expired nonce index values, MUST be silently discarded. If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows: o The Sequence Number value received from a mobile node in a Binding Update is stored by the receiving node in its Binding Cache entry for the given home address. o If the Lifetime specified in the Binding Update is not zero, then this is a request to cache a binding for the home address. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.1; otherwise, it is processed according to the procedure specified in Section 9.5.2. o If the Lifetime specified in the Binding Update is zero, then this is a request to delete the cached binding for the home address. In this case, the Binding Update MUST include a valid home nonce index, and the care-of nonce index MUST be ignored by the correspondent node. The generation of the binding management key depends then exclusively on the home keygen token (Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.2; otherwise, it is processed according to the procedure specified in Section 9.5.3. The specified care-of address MUST be determined as follows: o If the Alternate Care-of Address option is present, the care-of address is the address in that option.
o Otherwise, the care-of address is the Source Address field in the packet's IPv6 header. The home address for the binding MUST be determined as follows: o If the Home Address destination option is present, the home address is the address in that option. o Otherwise, the home address is the Source Address field in the packet's IPv6 header. Section 9.3.1, such packets will be dropped if there is no binding. This situation is recoverable, but can cause temporary packet loss. The correspondent node MAY refuse to accept a new Binding Cache entry if it does not have sufficient resources. A new entry MAY also be refused if the correspondent node believes its resources are utilized more efficiently in some other purpose, such as serving another mobile node with higher amount of traffic. In both cases the correspondent node SHOULD return a Binding Acknowledgement with status value 130.
Any existing binding for the given home address MUST be deleted. A Binding Cache entry for the home address MUST NOT be created in response to receiving the Binding Update. If the Binding Cache entry was created by use of return routability nonces, the correspondent node MUST ensure that the same nonces are not used again with the particular home and care-of address. If both nonces are still valid, the correspondent node has to remember the particular combination of nonce indices, addresses, and sequence number as illegal until at least one of the nonces has become too old. 9.2 or 9.5.1, a Binding Acknowledgement MUST NOT be sent. Otherwise, the treatment depends on the following rules. o If the Acknowledge (A) bit is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the next rule. o If the node rejects the Binding Update due to an expired nonce index, sequence number being out of window (Section 9.5.1), or insufficiency of resources (Section 9.5.2), a Binding Acknowledgement MUST be sent. If the node accepts the Binding Update, the Binding Acknowledgement SHOULD NOT be sent. If the node accepts the Binding Update and creates or updates an entry for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. Otherwise, the Status field MUST be set to a value greater than or equal to 128. Values for the Status field are described in Section 6.1.8 and in the IANA registry of assigned numbers . If the Status field in the Binding Acknowledgement contains the value 136 (expired home nonce index), 137 (expired care-of nonce index), or 138 (expired nonces), then the message MUST NOT include the Binding Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option MUST be included, and MUST meet the specific authentication requirements for Binding Acknowledgements as defined in Section 5.2.
If the Source Address field of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. Unlike the treatment of regular packets, this addressing procedure does not use information from the Binding Cache. However, a routing header is needed in some cases. If the Source Address is the home address of the mobile node, i.e., the Binding Update did not contain a Home Address destination option, then the Binding Acknowledgement MUST be sent to that address and the routing header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST be sent using a type 2 routing header that contains the mobile node's home address.
A node MAY choose to drop any entry already in its Binding Cache in order to make space for a new entry. For example, a "least-recently used" (LRU) strategy for cache entry replacement among entries should work well, unless the size of the Binding Cache is substantially insufficient. When entries are deleted, the correspondent node MUST follow the rules in Section 5.2.8 in order to guard the return routability procedure against replay attacks. If the node sends a packet to a destination for which it has dropped the entry from its Binding Cache, the packet will be routed through the mobile node's home link. The mobile node can detect this and establish a new binding if necessary. However, if the mobile node believes that the binding still exists, it may use route optimization and send packets with the Home Address destination option. This can create temporary packet loss, as discussed earlier, in the context of binding lifetime reductions performed by the correspondent node (Section 9.5.2).