Network working group Chern Nam Yap Internet Draft Srba Cvetkovic Matthias Kraner University of Sheffield 20 June 2000 Itinerant Internet Protocol Status of this Memo This document is an internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents, valid for a maximum of six months, and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies a protocol that allows IPv4 nodes to communicate with one another in the mobile environment with minimum changes made to TCP/IP, hence it can be used on IPv6. If communication started by correspondent node, then mobile node must first be identified by its home address, regardless of its current point of attachment. If the mobile node starts the communication, then mobile node must first be identified by its first contact point. While any mobile node nodes moves, it is assigned with a new co- located address, in which will be provided to the mobile node's correspondent nodes. The protocol enables any node to cache the binding of a mobile node's address with its co-located address through query mechanism. It then sends all packets designated for the mobile node directly through standard IP routing. Chern Nam Yap et al. Expires 20 December 2000 Page i Internet Draft Itinerant Internet Protocol 20 June 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Comparison with Mobile IP for IPv4 2 3. Terminology 4 3.1. General Terms 4 3.2. Itinerant Internet Protocol Terms 5 3.3. Specification Language 6 4. Overview of Itinerant Internet Protocol 7 4.1. Basic Operation 7 4.2. Itinerant Internet Protocol Signalling 9 4.3. IPSec Requirements for Binding Updates and Binding Acknowledgement 10 4.4. Conceptual Data Structures 10 4.5. Binding Management 13 5. Itinerant Internet Protocol Signalling Message Type 15 5.1. Binding Update packet 15 5.2. Binding Acknowledgement packet 17 5.3. Binding Request packet 20 6. Requirements for IP Nodes 21 6.1. Requirements for ALL Mobile Aware Nodes 21 6.2. Requirements for Base Home Register 21 6.3. Requirements for Temporary Visit Register 22 7. Correspondent Node Operation 23 7.1. Receiving Binding Updates 23 7.2. Request to Cache a Binding 24 7.3. Requests to Delete a Binding 24 7.4. Sending Binding Acknowledgements 25 7.5. Sending Binding Requests 25 7.6. Cache Replacement Policy 25 7.7. Sending Packet to a Mobile Node 26 8. Base Home Register Operation 27 8.1. Co-located Address Registration 27 8.2. Intercepting Packets for a Mobile Node 28 8.3. Tunnelling Intercepted Packets to a Mobile Node 29 9. Temporary Visit Register Operation 30 9.1. Co-located Address Registration 30 9.2. Intercepting Packets for a Mobile Node 31 Chern Nam Yap et al. Expires 20 December 2000 Page ii Internet Draft Itinerant Internet Protocol 20 June 2000 10. Mobile Node Operation 33 10.1. Sending Packets While Away from Home 33 10.2. Receiving Packets While Away from Home 33 10.3. Movement Detection 33 10.4. Sending Binding Updates to the Base Home Register 34 10.5. Sending Binding Updates to the Temporary Visit Register 34 10.6. Sending Binding Updates to Correspondent Nodes 35 10.7. Retransmit Binding Updates 36 10.8. Receiving Binding Acknowledgements 37 10.9. Routing Multicast Packets 38 11. Protocol Constants 39 References 40 Authors' Addresses 41 Chern Nam Yap et al. Expires 20 December 2000 Page iii Internet Draft Itinerant Internet Protocol 20 June 2000 1. Introduction This document specifies a protocol that allows IP nodes to communicate with one another in the mobile environment with minimum changes made to TCP/IP. Hence this protocol works with both IPv4 and IPv6. Without mobility management on IP machines, there will only be portability. While a mobile node moves, packet destined to the mobile node would not able to reach it. This is due to the mobile node is using a new IP subnet prefix, as routing is base on the subnet prefix in a packet's destination IP address. In order to communicate in spite of its movement, a mobile node should change its IP address each time it moves to a new link. However with portability, the mobile node is unable to maintain application connections when it changes location. Mobility management on IP machines is important, as majority or substantial fraction of the population of the Internet will be mobile machines during the future lifetime of TCP/IP. The protocol defined here, known as Itinerant Internet Protocol (IIP), allows a mobile node to move from one link to another without losing the connection of the application running on the mobile node. A mobile node must first addressed by it "home address" or "visit address", an IP address assigned to the mobile node. 1) If the correspondent node is mobile aware, the correspondent node must first send a query for the mobile node's latest co-located address and then send the actual data with standard IP routing. The movement of the mobile node away from its home link is not only transparent to applications but at the same time lift off the need to route packet via "home link". 2) If correspondent node is not mobile aware then packets may be routed to the mobile node using this address ("home address" or "visit address") regardless of the mobile node's current point of attachment to the Internet. Moreover, the mobile node may continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of the mobile node away from its home link is thus transparent to applications. The IIP is suitable for mobility across homogenous media as well as for mobility across heterogeneous media. For example, IIP facilitates node movement from a Blue-Tooth segment to HIPER-LAN segment without having the worry that "last link" has lost Internet connection. Therefore IIP is a reliable mobile protocol. One can think of IIP as solving the 3G mobility management problems. Higher Generation wireless problem such as Ad Hoc Networking are possibly more suited to other solutions. Chern Nam Yap et al. Expires 20 December 2000 Page 1 Internet Draft Itinerant Internet Protocol 20 June 2000 2. Comparison with Mobile IPv4 and IPv6 The design of Itinerant Internet Protocol (IIP) represents a natural combination of the experiences gained from the development of Mobile IP [7] support both in IPv4 and IPv6. The development of IIP reduces the need to concern or do any harm to the progression of IP development. IIP shares many features of Mobile IP [7], but the protocol is now fully compliant to OSI network modelling. Mobility management is currently done in the management layer. The differences between Mobile IP [7] and IIP are described as follows: - Unlike Mobile IP [7], IIP provides both diversion and forwarding mechanism. IIP allows forwarding and reverse tunnelling for backward compatibility purposes (Non mobile aware system). - IIP emphasizes the use of diversion method that enables mobile aware correspondent node to communicate with any mobile node on standard IP routing, without the need to route any packet via "home link" - IIP also aims to improve the unavoidable triangular routing by using "first communication contact addressing method". - With the standard way of routing packets, IIP coexist efficiently with routers that perform "ingress filtering" [1]. A mobile node uses it co-located address as the Source Address in the IP header of packets it sends, allowing the packets to pass normally through ingress filtering routers. - A Binding Update that carries the latest IP address is sent from the mobile node to the mobile aware correspondent node. It also carries latest transport port value to enable MPLS operation in IPv4 (Port also helps in terms of Security?). Session ID may also be required for identification for authentication for Security as well (Meant for Multi-Path System). - The use of co-located address as the Source Address in each packet's IP header also simplifies routing of multicast packets sent by a mobile node. - RSVP, IPSec [2] and any other IP based protocol can be deployed easily, as IIP does not mess with these protocols. Chern Nam Yap et al. Expires 20 December 2000 Page 2 Internet Draft Itinerant Internet Protocol 20 June 2000 - IIP is capable of using the diversion method to avoid the need for tunnelling. This is due to the fact that IIP sits on top of TCP/IP that does not modify IP packets. - While a mobile node is away from home, it's Base Home Register intercepts Binding Requests and returns Binding Updates to the Correspondent Node. - Strong cell switching method is also used to drop "foreign agent" off the picture. On the other hand, every network would have a Base Home Register, which may act as Temporary Visit Register for any mobile node. - Temporary Visit Register can be upgraded to a Base Home Register to allow a mobile able that will not totally lose capability of being a mobile node. At least functionality of being a client, which most mobile nodes are will likely be used. Chern Nam Yap et al. Expires 20 December 2000 Page 3 Internet Draft Itinerant Internet Protocol 20 June 2000 3. Terminology 3.1. General Terms IP Internet Protocol. IIP Itinerant Internet Protocol. Node It is a device that implements IP. Router It is a node that forwards IP packets not explicitly addressed to it own self. Host It is any node that is not a router. Link It is a communication facility or medium over which nodes can communicate at the link layer, such as an Ethernet (simple or bridged). A link is the layer immediately below IP. Interface It is a node's attachment to a link. Subnet prefix It is a bit string that consists of a number of initial bits of an IP address. Interface Identifier It is a number to identify a node's interface on a link. The Interface identifier is the remaining low-order bits in the node's IP address after the subnet prefix. Link-layer address It is a link layer identifier for an interface, such as IEEE 802 addresses on Ethernet links. Packet It is an IP header plus payload. Chern Nam Yap et al. Expires 20 December 2000 Page 4 Internet Draft Itinerant Internet Protocol 20 June 2000 3.2 Itinerant Internet Protocol Terms Home address An IP address assigned to a mobile node within its home link. Visit address An IP address assigned to a mobile node, where the mobile node first uses it as a source to send to a non-mobile aware correspondent node. Home subnet prefix It is the IP subnet prefix corresponding to a mobile node's home address. Visit subnet prefix It is the IP subnet prefix corresponding to a mobile node's visit address. Home link It is the link that a mobile node's home subnet prefix is defined. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Visit link It is the link that a mobile node's visit subnet prefix is defined. Standard IP routing mechanisms will deliver packets destined for a mobile node's visit address to its visit link. Mobile node It is a node that can change its point of attachment from one link to another, which does not affect network application operation. Movement It is a change in mobile node's point of attachment to the Internet where it is no longer connected to the same link as it was previously. If a mobile node is not currently attached to its home link, the mobile node is said to be "away from home". If a mobile node is not currently attached to its visit link, the mobile node is said to be "away from visit". Correspondent Node It is a peer node that a mobile node is communicating. The correspondent node may be either mobile or stationary. Chern Nam Yap et al. Expires 20 December 2000 Page 5 Internet Draft Itinerant Internet Protocol 20 June 2000 BHR (Base Home Register) It is an entity on a mobile node's home link with which the mobile node has registered its current co-located address. While the mobile node is away from home, the Base Home Register intercepts Binding Request/Data Packets in the home link destined to the mobile node's home address. If Binding a Request is received a Binding Update will be sent. If Data packets are received, the packets will be encapsulated and be tunnelled to the mobile node's registered co-located address. TVR (Temporary Visit Register) It is an entity on a mobile node's visit link with which the mobile node has registered its current co-located address. While the mobile node is away from visit, the Temporary Visit Register intercepts Data Packets on the visit link destined to the mobile node's visit address. Data packets will be encapsulated and be tunnelled to the mobile node's registered co-located address. Co-located address It is an IP address associated with a mobile node while visiting a most current link; the subnet prefix of this IP address is a most current subnet prefix. Mobile node will register this co-located address with Base Home Register / Temporary Visit Register and mobile aware correspondent node. Binding It is the association of the home address of a mobile node with a co-located address for that mobile node, along with the remaining lifetime of that association. 3.3 Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Chern Nam Yap et al. Expires 20 December 2000 Page 6 Internet Draft Itinerant Internet Protocol 20 June 2000 4. Overview of Itinerant Internet Protocol 4.1. Basic Operation A mobile node will be addressed by its home address, whether or not it is currently attached to its home link or is away from home, if the communication is started by the correspondent node. While a mobile node is at home, packets addressed to its home address are routed to it using conventional Internet routing mechanisms in the same way as if the node were never mobile. This is due to the fact that the subnet prefix of a mobile node's home address is the subnet prefix that the packets are addressed to. It is the similar case for communication that is started by the mobile node at "home link" or "visit link". While a mobile node moves to a new link away from "home link" or "visit link", it is addressed by its newly acquired co-located address, in addition to its home/visit address. The subnet prefix of a mobile node's co-located is the subnet prefix of the most current link the mobile node is located. Packets sent to the mobile node will be either forwarded or re-directed to the mobile node's latest co-located address. Example. If a mobile node is at "visit link", and moves to a "home link" or any other link, and the communication is started by the mobile node, the packet will be intercepted by the TVR and tunnelled to the mobile node latest co-located address that happens to be mobile node home address. A co-located address is an IP address associated with a mobile node while movement to a new link takes place. A home address can also be a co-located address in times. The association between a mobile node's home/visit address and co- located address is known as a "binding" for the mobile node. A mobile node typically acquires its co-located address through PPP. Other methods of acquiring a co-located address are also possible, but details of other methods are beyond the scope of this document. While a mobile node moves, it registers its newly acquired address with BHR. At the same time, the mobile node can register its co- located address with a node on its visit link, requesting this node to function as the TVR for the mobile node. A mobile node as well can upgrade one of its TVR to a BHR. A mobile node sends "Binding Update" packet to achieve above binding registration. BHR or TVR will reply the registration by sending a "Binding Acknowledgement" packet. The mobile node's BHR/TVR should use proxy ARP [8] to intercept any IP packets addressed to the mobile node's home/visit address on its link and must either divert or tunnel packets to the mobile node's co- located address. Chern Nam Yap et al. Expires 20 December 2000 Page 7 Internet Draft Itinerant Internet Protocol 20 June 2000 A mobile aware correspondent node must always use the diversion method first. In which case, the correspondent node should send a "Binding Request" followed by a basic ICMP Echo Packet. With a positive ICMP Echo Reply, it is confirmed that either mobile node is at home or Proxy ARP [8] is working. A "Binding Request" will have a lifetime. In most case, before the lifetime expires, the correspondent node would receive a "Binding Updates" and thereafter send the data packet based on the "Binding Updates" mobile node co- located as the destination address. If the lifetime expires, the correspondent node should immediately send the data packet to the mobile node address. TVR aids communication link between correspondent node and mobile node by intercepting packets from any correspondent node to mobile node and tunnelled them to the mobile node. Hence this has reduced data loss between mobile correspondent node and mobile node. Communication with a non-mobile aware node will depend on who has started the communication first. If the correspondent node starts the communication, the correspondent could only possibly know the mobile node's home address, hence BHR will tunnel all traffic from the correspondent node to the mobile node's latest co-located address. TVR would be able to aid in soft handoff in such condition. When mobile node moves from one "Visit Link" to other link, TVR will intercept mobile node's packets by de-encapsulating and then encapsulating the packet to the mobile node's latest co-located address. The reason for doing this is that the TVR is most likely to get the binding updates much earlier than BHR. Hence losing of packets condition will then be minimised. Moreover there will be an improvement over handoffs. If the mobile node starts the communication, then it will depend on where the mobile node is located. The correspondent node identifies the mobile node by the IP header source address. If the mobile node is at home, then it will be the same as above. If the mobile node is not at home, the correspondent node will send the packet directly to the mobile node's source address. Once the mobile node moves TVR will intercepts mobile node's packet and tunnel the packet to the mobile node's latest co-located address. TVR would also able to aid in soft handoff in such condition. Similar to aforementioned, the TVR will always act as an anchoring point for all communication for the mobile node, as well as for the communication that is started in one of the "visit link". Chern Nam Yap et al. Expires 20 December 2000 Page 8 Internet Draft Itinerant Internet Protocol 20 June 2000 All mobile nodes must be mobile aware correspondent node and must be able to do forward and reverse tunnelling. Any node communicating with a mobile node is referred to in this document as a "correspondent node" of the mobile node. It may be either a stationary node or a mobile node. Binding Update, Binding Acknowledgement and Binding Request are all in an UDP [9] packet format. Due to the way IIP manage mobility, a mobile node can always source its packet using co-located address while it is not at home. Many routers implement security policies such as "ingress-filtering" that do not allow forwarding of packets that appear to have a Source Address that is not topologically correct. By using co-located address as IP header Source Address, the packet will be able to pass through such routers, yet ingress-filtering rules will still able to locate the true topological source of the packet in the same way as packets from non-mobile node. 4.2 Itinerant Internet Protocol Signalling As discussed in general in Section 4.1, the following three new UDP [9] packets options are defined for Itinerant Internet Protocol Signalling. Binding Update This packet is used by the mobile node to notify the BHR / TVR / correspondent node; or the BHR to notify a correspondent node of the mobile node's current binding. The Binding Update sent to the mobile node's BHR to register its co-located address known as "home registration". The Binding Update sent to the mobile node's TVR to register its co-located address known as "visit registration". The mobile node as well can upgrade a TVR to a BHR simply by sending a "home registration". This packet should be protected by IPSec [2] as defined in Section 4.3, to guard against any malicious Binding Updates. Binding Acknowledgment This packet is used to acknowledge receipt of Binding Update, if an acknowledgement was requested in the Binding Update. This packet should be protected by IPSec [2] as defined in Section 4.3, to guard against any malicious Binding Acknowledgements. Chern Nam Yap et al. Expires 20 December 2000 Page 9 Internet Draft Itinerant Internet Protocol 20 June 2000 Binding Request This packet is used to request a mobile node to send to the requesting node a Binding Update containing the mobile node's current binding. This packet is normally used by a correspondent node once to acquire the mobile node co-located address. This is send as a normal UDP [9] packet without any IPSec [2] protection. 4.3 IPSec Requirements for Binding Updates and Binding Acknowledgement. Both Binding Updates and Binding Acknowledgement packet MUST be protected by IPSec [2] to guard against malicious Binding Updates or Acknowledgements. Specifically, any Binding Update or Binding Acknowledgement packet MUST utilise IPSec sender authentication, data integrity protection, and replay protection. Currently, IIP requires that this protection covering a Binding Update or Binding Acknowledgement MUST be provided by use of AH [4]. If another Security Association is applied to the packet for other reasons requires the use of ESP [5]. For example to encrypt the transport layer data carried in the packet, the use of ESP [5] is not sufficient to satisfy the authentication requirements of IIP. Instead, the packet MUST use both AH [4] and ESP [5]. Use of ESP [5] for protecting the Binding Update or Binding Acknowledgement is not currently defined in this document, since ESP does not protect the portion of the packet above the ESP [5] header itself. 4.4. Conceptual Data Structures This document describes the IIP in terms of the following three conceptual data structures: Binding Cache It is a cache that is maintained by each mobile aware node. It contains bindings that it has with any mobile nodes. The Binding Cache MAY be implemented in any manner consistent with the external behaviour described in this document. Each Binding Cache entry conceptually contains the following fields: - The home address of a mobile node. This field is used as the key value to aid searching the Binding Cache for the destination address of a packet being sent. When the destination address of the packet matches the home address in the Binding Cache entry, this entry SHOULD be used in routing that packet. Chern Nam Yap et al. Expires 20 December 2000 Page 10 Internet Draft Itinerant Internet Protocol 20 June 2000 - The co-located address of a mobile node indicates by the home address field in this Binding Cache entry. If the destination address of a packet being routed matches the home address in this entry, then the packet SHOULD by routed to this co-located address, as described in Section 7.7, for the packets originated by this node. - A lifetime value indicates the remaining lifetime for this Binding Cache entry. This lifetime value is initialised from the Lifetime field in the Binding Update that was created or last modified this Binding Cache entry. Once the lifetime on this entry expires, the entry MUST be deleted from the Binding Cache. - A flag indicating whether or not this Binding Cache entry is a "home registration" or "visit registration" - The maximum value of the Sequence Number field that is received in previous Binding Updates for this mobile node home address. The Sequence Number field is 16 bits long, and all comparisons between Sequence Number values MUST be preformed modulo 2**16. For example, using an implementation in C programming language, a Sequence Number value A is greater than another Sequence Number value B if ((short) ((a) - (b)) > 0), if a "short" data type is a 16-bit signed integer. - Recent usage information for this Binding Cache entry, as needed to implement the cache replacement policy in use in the Binding Cache and to assist in determining whether a Binding Request should be sent when the lifetime on this entry is near expiration. - The time at which a Binding Request was last sent for this entry, is needed to implement the rate limiting restriction for sending Binding Requests. An entry in a node's Binding Cache for which the node is serving a BHR is marked as a "home registration" entry. The entry SHOULD NOT be deleted by the BHR until the expiration of its binding lifetime. Similarly this also applies to the TVR. Other Binding Cache entries may be replaced at any time by any reasonable local cache replacement policy but SHOULD NOT unnecessarily to be deleted. Node's Binding Cache may contain at most one entry for each mobile node home/visit address. Chern Nam Yap et al. Expires 20 December 2000 Page 11 Internet Draft Itinerant Internet Protocol 20 June 2000 Binding Update List A list, maintained by each mobile node, that records information for each Binding Update sent by this mobile node, for which the Lifetime sent in that Binding Update has not yet expired. The Binding Update List includes all bindings sent by the mobile node to its correspondent nodes, BHR and TVR. However, for multiple Binding Updates sent to the same destination address, the Binding Updates List contains only the most recent Binding Updates (i.e., with the greatest Sequence Number Value) sent to that destination. The Binding Update List MAY be implemented in any manner consistent with the external behaviour as described in this document. Each Binding Update List entry conceptually contains the following fields: - The IP address of the node to which a Binding Update was sent. This node might still have a Binding Cache entry created or updated from this Binding Update, if the Binding Update was successfully received by that node (example, not lost by the network) and if that node has not been deleted by the entry before its expiration (example, to reclaim space in its Binding Cache for other entries). - The home/visit address for which that Binding Update was sent. This is meant for the mobile node to distinguish between co-located and visit/home address. - The co-located address of the Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update giving its co-located address to this destination after changing its co-located address. - The initial value of the Lifetime field sent in that Binding Update. - The remaining Lifetime of that binding. This lifetime is initialised from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List. Chern Nam Yap et al. Expires 20 December 2000 Page 12 Internet Draft Itinerant Internet Protocol 20 June 2000 - The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 16 bits long, and all comparisons between Sequence Number values MUST be performed modulo 2**16. For example, using an implementation in the C programming language, a Sequence Number value A is greater than another Sequence Number value B if ((short)((a) - (b)) > 0), "short" data type is a 16-bit signed integer. - The time at which a Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending Binding Updates. - The state of any retransmissions needed for this Binding Update, if the Acknowledge (A) bit was set in this Binding Update. This state includes the time remaining until the next retransmission attempts for the Binding Update, and the current state of the exponential back-off mechanism for retransmissions. - A flag that, when set, indicates that future Binding Updates should not be sent to this destination. 4.5. Binding Management When a mobile node configures a new co-located address, the mobile node will register this new binding with its BHR by sending the BHR a Binding Update. The mobile node indicates that an acknowledgment is needed for this Binding Update and continues to periodically retransmit it until acknowledged. The BHR acknowledges the Binding Update by returning a Binding Acknowledgement to the mobile node. When a mobile node receives a packets tunnelled to it from the BHR, it will assume that the original sending correspondent node is not mobile aware (the mobile node will do a check in its binding list first, due to the newly added TVR method), since the correspondent node would have otherwise have sent the packet directly to the mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 13 Internet Draft Itinerant Internet Protocol 20 June 2000 A correspondent node with a Binding Cache entry for a mobile node may refresh this binding, for example if the binding's lifetime is near expiration, by sending a Binding Request to the mobile node. Normally, a correspondent node will only refresh a Binding Cache entry in this way if it is actively communicating with the mobile node and has indications, such as an open TCP [10] connection to the mobile node, that it will continue this communication in the future. When a mobile node receives a Binding Request, it replies by returning a Binding Update to the node sending the Binding Request. Since some correspondent nodes are mobile aware, it is expected that correspondent nodes usually will route packets directly to the mobile node's co-located address, so that the BHR is rarely involved with packet transmission to the mobile node. This is essential for scalability and reliability, and for minimizing overall network load. By caching the co-located address of a mobile node, optimal routing of packets can be achieved from the correspondent node to the mobile node. Routing packets directly to the mobile node's co-located address also eliminates congestion at the mobile node's BHR and home link. In addition, the impact of any possible failure of the BHR, the home link, or intervening networks leading to or from the home link is reduced, since these nodes and links are not involved in the delivery of most packets to the mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 14 Internet Draft Itinerant Internet Protocol 20 June 2000 5. Itinerant Internet Protocol Signalling Message Types 5.1. Binding Update Packet The Binding Update is used by a mobile node to notify its BHR/TVR/correspondent nodes of a newly acquired co-located address. The Binding Update packet is encoded in type-length-value (TLV) format 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 |A|M|B|H|T| RSV | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home / Visit / Co-located IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Some other extension (Port / Session ID) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 1 Acknowledge (A) The Acknowledge (A) bit is set by the sending mobile node to request a Binding Acknowledgement (Section 5.2) be returned upon receipt of the Binding Update. Mobile Node (M) The Mobile Node (M) bit is set by the sending mobile node to the correspondent node for identification. Base Home Register (B) The Base Home Register (B) bit is set by the BHR to the correspondent node for identification. Home Registration (H) The Home Registration (H) bit is set by the sending mobile node to request the receiving node to act as this node's BHR. The destination of the packet carrying this option MUST be a node sharing the same subnet prefix as the home/visit address of the mobile node in the binding. Chern Nam Yap et al. Expires 20 December 2000 Page 15 Internet Draft Itinerant Internet Protocol 20 June 2000 Temporary Visit Registration (T) The Temporary Registration (T) bit is set by the sending mobile node to request the receiving node to act as this node's TVR. The destination of the packet carrying this option MUST be a node sharing the same subnet prefix as the visit address of the mobile node in the binding. Reserved This field is unused. It MUST be initialised to zero by the sender and MUST be ignored by the receiver. Sequence Number Used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. Each Binding Update sent by a mobile node MUST use a Sequence Number greater than the Sequence Number value sent in the previous Binding Update (if any) to the same destination address (modulo 2**16, as defined in Section overview: data). There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received. Lifetime It is 32-bit unsigned integer. The number of seconds remaining before the binding MUST be considered expired. A value of all one bits (0xffffffff) indicates infinity. A value of zero indicates that the Binding Cache entry for the mobile node MUST be deleted. Home/Visit/Co-located Address Home/Visit/Co-located IP address will be sent to BHR / TVR / Correspondent Node to update the Binding by the mobile node. The M bit MUST be set. New co-located IP address of the mobile node will be sent to the correspondent node from BHR. The B bit MUST be set. The co-located address for the binding given in the Binding Update is specified by the Source Address field. It is in the IP header of the Binding Updates if a mobile node sends it. Binding Cache entry for the mobile node MUST NOT be created in response to the following Binding Update packet: Chern Nam Yap et al. Expires 20 December 2000 Page 16 Internet Draft Itinerant Internet Protocol 20 June 2000 If present, or in the Source Address field in the packet's IP header is equal to the home address of the mobile node and if the Lifetime field in the Binding Update is equal to 0. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. The last Sequence Number value received from a mobile node in a Binding Update is stored by a correspondent node in its Binding Cache entry for that mobile node. Thus, the mobile node's and the correspondent node's knowledge of the last sequence number will expire at the same time. If the sending mobile node has no Binding Update List entry, the Sequence Number may start at any value. If the receiving correspondent node has no Binding Cache entry for the sending mobile node, it MUST accept any Sequence Number value in a received Binding Update from this mobile node. 5.2. Binding Acknowledgement Packet The Binding Acknowledgement packet is used to acknowledge receipt of a Binding Update (Section 5.1). When a node receives the Binding Update Packet, it MUST return a Binding Acknowledgement to the source of the packet if the Acknowledge (A) bit is set in the Binding Update. The Binding Acknowledgement packet is encoded in type-length-value (TLV) format 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 | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Some other extension (Port / Session ID) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 2 Chern Nam Yap et al. Expires 20 December 2000 Page 17 Internet Draft Itinerant Internet Protocol 20 June 2000 Status It is 8-bit unsigned integer indicating the disposition of the Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined: 0 Binding Update accepted Values of the Status field greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined: 128 Reason unspecified 130 Administratively prohibited 131 Insufficient resources 132 Home registration not support 133 Not home subnet 137 Not Base Home Register for this mobile node 139 Temporary visit registration not support 140 Not temporary visit subnet Sequence Number The Sequence Number in the Binding Acknowledgment is copied form the Sequence Number field in the Binding Update being acknowledge, for use by the mobile node in matching this Acknowledgement with an outstanding Binding Update. Lifetime The granted lifetime, in seconds, for which this node will attempt to retain the entry for this mobile node in its Binding Cache. If the node sending the Binding Acknowledgement is serving as the mobile node's Base Home Register, the Lifetime period will also indicate the period for which this node will continue this service. If the mobile node requires BHR service from this node beyond this period, the mobile node MUST send a new Binding Update to it before the expiration of this period, in order to extend the lifetime. This applies the same for TVR. The value of this field SHOULD be undefined if the Status field indicates that the Binding Update was rejected. Chern Nam Yap et al. Expires 20 December 2000 Page 18 Internet Draft Itinerant Internet Protocol 20 June 2000 Refresh The recommended interval, in seconds, at which the mobile node SHOULD send a new Binding Update to this node in order to "refresh" the mobile node's binding in this node's Binding Cache. This refreshing of the binding is useful in case the node fails and loses its cache state. The Refresh period is determined by the node sending the Binding Acknowledgement (the node caching the binding). If this node is serving as the mobile node's BHR, the Refresh value may be set. For example, based on whether the node stores its Binding Cache in volatile storage or in non-volatile storage. If the node sending the Binding Acknowledgement is not serving as the mobile node's BHR, the Refresh period SHOULD be set equal to the Lifetime period in the Binding Acknowledgement. Even if this node loses this cache entry due to a failure of the node, packets from it can still reach the mobile node through the mobile node's BHR. This will cause a new Binding Update to this node to allow it to recreate this cache entry. The value of this field is undefined if the Status field indicates that the Binding Update was rejected. If the node returning the Binding Acknowledgement accepts the Binding Update for which the Acknowledgement is being returned (the 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 and MUST use this entry (which includes the co-located address received in the Binding Update) to send the Binding Acknowledgement packet to the mobile node. The details of sending this packet to the mobile node are the same for sending any packet to a mobile node using a binding, and are described in Section 7.7. The packet is routed to the mobile node by way of its co-located address recorded in the Binding Cache entry. If the node returning the Binding Acknowledgement instead rejects the Binding Update (the value of the Status field in the Acknowledgement is greater than or equal to 128), the co-located address used by this node for sending the Binding Acknowledgement packet MUST be copied from the co-located address received in the rejected Binding Update; this node MUST NOT modify its Binding Cache in response to receiving this rejected Binding Update and MUST ignore its Binding Cache in sending this Binding Acknowledgement packet. This packet is routed to the co-located address of the rejected Binding Update packet. Chern Nam Yap et al. Expires 20 December 2000 Page 19 Internet Draft Itinerant Internet Protocol 20 June 2000 5.3. Binding Request Packet The Binding Request packet is used to request a mobile node's binding from the Base Home Register. When the Base Home Register receives a Binding Request packet, it SHOULD return a Binding Update (Section 5.1) to the source of the Binding Request. The Binding Request packet is encoded in type-length-value (TLV) format as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 3 Chern Nam Yap et al. Expires 20 December 2000 Page 20 Internet Draft Itinerant Internet Protocol 20 June 2000 6. Requirements for IP Nodes IIP places some requirements on the function to make a node mobile aware. This section summarizes those requirements by identifying the Functionality each requirement it is intended to support. Further details on this functionality are provided in the following sections. 6.1. Requirements for All Mobile Aware Nodes Since any mobile node may at any time be a correspondent node, either sending or receiving a packet, the following requirements apply to ALL mobile nodes: - Every mobile node MUST be able to process a Binding Update packet, and to return a Binding Acknowledgement packet if the Acknowledge (A) bit is set in the received Binding Update. - Every mobile node SHOULD be able to maintain a Binding Cache of the binding received in the accepted Binding Updates. - Every mobile node MUST be able to de-encapsulate and reverse tunnel any packet back to the BHR or the TVR. - Every mobile node MUST maintain a Binding Update List in which it records the IP address of each other node to which it has sent a Binding Update, for which the Lifetime sent in that binding has not expire. 6.2. Requirements for Base Home Register In order to enable a mobile node to operate correctly while away from home, there must be a node to act as a BHR for the mobile node. The following requirements apply to the BHR: - Every BHR MUST be able to maintain an entry in its Binding Cache for each mobile node it is serving. Each Binding Cache entry records the mobile node binding with its co-located address. - Every BHR MUST be able to intercept packets (using proxy ARP [8]) addressed to a mobile node for which it is currently serving as the BHR, on the mobile node's home link, while the mobile node is away from home. Chern Nam Yap et al. Expires 20 December 2000 Page 21 Internet Draft Itinerant Internet Protocol 20 June 2000 - Every BHR MUST be able to encapsulate such packet in order to tunnel them to the co-located address for the mobile node indicated in its binding in the BHR's Binding Cache. - Every BHR MUST be able to return a Binding Acknowledgement packet in response to a Binding Update packets received with (A) bit set. - Every BHR MUST maintain a separate BHR List for each link on which it is serving as a BHR. - Every BHR MUST be able to process a Binding Request packet, and response with a Binding Update of the mobile node. 6.3. Requirements for Temporary Visit Register In order to enable a mobile node to operate correctly while away from visit, there must be a node to act as a TVR for the mobile node. The following requirements apply to the TVR: - Every TVR MUST be able to maintain an entry in its Binding Cache for each mobile node for which it is serving. Each Binding Cache entry records the mobile node binding with its co-located address. - Every TVR MUST be able to intercept packets (using proxy ARP [8]) addressed to a mobile node for which it is currently serving as the TVR, while the mobile node is away from its visit link. - Every TVR MUST be able to encapsulate such packet in order to tunnel them to the new co-located address for the mobile node indicated in its binding in the TVR's Binding Cache. - Every TVR MUST be able to return a Binding Acknowledgement packet in response to a Binding Update packets received with (A) bit set. - Every TVR MUST maintain a separate TVR List for each link on which it is serving as a TVR. - Every TVR should be able to be upgraded to a BHR, if there are such requests from mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 22 Internet Draft Itinerant Internet Protocol 20 June 2000 7. Correspondent Node Operation A correspondent node is any node communicating with a mobile node. The correspondent node, itself, may be stationary or mobile. Here only correspondent node mentioned will be a mobile aware correspondent node as communication of non-mobile aware correspondent node just a standard IP traffic. 7.1 Receiving Binding Updates Upon receiving a Binding Update in some packet, the receiving node MUST validate the Binding Update according to the following tests: - The packet meets the specific IPSec [2] requirements for Binding Updates, defined in Section 4.3. - The address for the binding is specified by the Home Address/Co- located field. Either the M bit or the B bit MUST exist. - The Sequence Number field in the Binding Update is greater than the Sequence Number received in the previous Binding Update for this home address, if any. As noted in Section 4.6, this Sequence Number comparison MUST be performed modulo 2**16. Any invalid Binding Update MUST be silently ignored, and the Binding Update packet MUST be discarded. If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows: - If the Lifetime specified in the Binding Update is nonzero and the specified co-located address is not equal to the home address for the binding, then this is a request to cache a binding for the mobile node. If the Home Registration (H) bit is set in the Binding Update, the Binding Update will be processed according to the procedure specified in Section 8.1; If the Temporary Registration (T) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 9.1; otherwise, it is processed according to the procedure specified in Section 7.2. Chern Nam Yap et al. Expires 20 December 2000 Page 23 Internet Draft Itinerant Internet Protocol 20 June 2000 - If Lifetime specified in the Binding Update is zero or the specified co-located address matches the home address for the binding, then this is a request to delete the mobile node's cached binding. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 8.2. If the Temporary Registration (T) bit is set in the Binding Update, the Binding Update will be processed according to the procedure specified in Section 9.2. Otherwise, it is processed according to the procedure specified in Section 7.3. 7.2 Request to Cache a Binding When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests a node to cache a mobile node's binding, for which the Home Registration (H) bit is not set in the Binding Update. In this case, the receiving node SHOULD create a new entry in its Binding Cache for this mobile node (or update its existing Binding Cache entry for this mobile node, if such an entry already exists). The home address of the mobile node is taken from the Home Address field. The new Binding Cache entry records the association between this home address and the co-located address for the binding, as specified in co-located address field of the Binding Update packet's source address field. The lifetime for the Binding Cache entry is initialised from the Lifetime field specified in the Binding Update, although this lifetime MAY be reduced by the node caching the binding. The lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update. Any Binding Cache entry MUST be deleted after the expiration of this lifetime on the Binding Cache entry. 7.3 Requests to Delete a Binding When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests a node to delete a mobile node's binding from its Binding Cache, for which the Home Registration (H) bit or Temporary Visit Registration (T) is not set in the Binding Update. In this case, the receiving node MUST delete any existing entry in its Binding Cache for this mobile node. The home address of the mobile node is taken from the Home Address field. Chern Nam Yap et al. Expires 20 December 2000 Page 24 Internet Draft Itinerant Internet Protocol 20 June 2000 7.4 Sending Binding Acknowledgements When any node receives a Binding Update packet in which the Acknowledge (A) bit is set, it SHOULD return a Binding Acknowledgement packet acknowledging receipt of the Binding Update. If the node accepts the Binding Update and creates or updates an entry in its Binding Cache for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. If the node rejects the Binding Update and does not create or 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. Specific values for the Status field are described in Section 5.2. The packet in which the Binding Acknowledgement is returned MUST meet the specific IPSec [2] requirements for Binding Acknowledgements; and the packet MUST be sent to the mobile node using its co-located address (even if the binding was rejected), as described in section 7.8. The packet is routed first to the co-located address contained in the Binding Update being acknowledged and then mobile node home address. This ensures that the Binding Acknowledgement packet will be routed to the current location of the node sending the Binding Update, whether the Binding Update was accepted or rejected. 7.5 Sending Binding Requests 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 to a mobile node, a new Binding Request will be sent to the mobile node's home link, where it will be intercepted and the BHR will send a Binding Update to the sender, allowing it to create a new Binding Cache entry for sending future packets to the mobile node. Communication with the mobile node continues uninterrupted, but this diversion creates overhead and latency in delivering packets to the mobile node. If the sender knows that the Binding Cache entry is still in active use, it MAY send a Binding Request packet to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. When the mobile node receives a Binding Request packet from some sender, it returns a Binding Update packet to that sender, giving its current binding and a new lifetime. Chern Nam Yap et al. Expires 20 December 2000 Page 24 Internet Draft Itinerant Internet Protocol 20 June 2000 7.6 Cache Replacement Policy Any entry in a node's Binding Cache MUST be deleted after the expiration of the Lifetime specified in the Binding Update from which the entry was created or last updated. Conceptually, a node maintains a separate timer for each entry in its Binding Cache. When creating or updating a Binding Cache entry in response to a received and accepted Binding Update, the node sets the timer for this entry to the specified Lifetime period. When a Binding Cache entry's timer expires, the node deletes the entry. Each node's Binding Cache will, by necessity, have a finite size. A node MAY use any reasonable local policy for managing the space within its Binding Cache, except that any entry marked as a "home registration" (Section 8.3) MUST NOT be deleted from the cache until the expiration of its lifetime period. When attempting to add a new "home registration" entry in response to a Binding Update with the Home Registration (H) bit set, if insufficient space exists (or can be reclaimed) in the node's Binding Cache, the node MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the sending mobile node, in which the Status field is set to 131 (insufficient resources). When otherwise attempting to add a new entry to its Binding Cache, a node MAY, if needed, choose to drop any entry already in its Binding Cache, other than a "home registration" entry, in order to make space for the new entry. For example, a "least-recently used" (LRU) strategy for cache entry replacement among entries not marked as a "home registration" is likely to work well. Any binding dropped from a node's Binding Cache due to the lack of cache space will be rediscovered and a new cache entry will be created, if the binding is still in active use by the node for sending packets. If the node sends a packet to a destination for which it has dropped the entry from its Binding Cache, the packet will be routed normally, leading to the mobile node's home link. There, the packet will be intercepted by the mobile node's home base register and the Base Home Register will reply with an Binding Updates that allowing the correspondent node to add an entry again for this destination mobile node to its Binding Cache. Chern Nam Yap et al. Expires 20 December 2000 Page 25 Internet Draft Itinerant Internet Protocol 20 June 2000 7.7 Sending Packet to a Mobile Node Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD route the packet to this mobile node (the destination node) by way of the co-located address in the binding recorded in that Binding Cache entry. 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 Binding Request packet and will be intercepted by the mobile node's Base Home Register which will sent the Binding Updates allowing the sending node to create a Binding Cache entry for its use in sending subsequent packets to this mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 26 Internet Draft Itinerant Internet Protocol 20 June 2000 8. Base Home Register Operation A mobile node should have a default BHR, and MUST register itself to the BHR while it is at home. 8.1 Co-located Address Registration When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests the receiving node to serve as its BHR (essentially a TVR), registering its co-located address. To begin processing the Binding Update, the BHR MUST perform the following sequence of tests: - If the home address for the binding is not in the same home link respect to the BHR links, then the BHR MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 133 (not home subnet). - Else, if the BHR chooses to reject the Binding Update for any other reason (e.g., insufficient resources to serve another mobile node as a Home Register), then the BHR SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to an appropriate value to indicate the reason for the rejection. If the BHR does not reject the Binding Update as described above, then it will update its existing Binding Cache entry for this mobile node. The home address of the mobile node is taken from the Home Address field. The co-located address for this Binding Cache entry is taken from the Source Address field in the packet header. The BHR MUST mark this Binding Cache entry as a "home registration" to indicate that the node is serving as a BHR for this binding. Binding Cache entries marked as a "home registration" MUST be excluded from the normal cache replacement policy used for the Binding Cache (Section 7.6) and MUST NOT be removed from the Binding Cache. If the Acknowledge (A) bit is set in the Binding Update (it SHOULD be), then the BHR MUST return a Binding Acknowledgement to the mobile node, constructed as follows: Chern Nam Yap et al. Expires 20 December 2000 Page 27 Internet Draft Itinerant Internet Protocol 20 June 2000 - The Status field MUST be set to a value indicating success (the value MUST be less than 128). The only currently defined success Status value is 0, indicating simply that the Binding Update was accepted. - The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. - The Lifetime field MUST be set to the remaining lifetime for the binding as set by the BHR in its "home registration" Binding Cache entry for the mobile node. - The Refresh field MUST be set to a value less than or equal to the Lifetime value being returned in the Binding Update. If the BHR stores the Binding Cache entry in non-volatile storage (that survives the crash or other failure of the BHR), then the Refresh field SHOULD be set to the same value as the Lifetime field; otherwise, the BHR MAY set the Refresh field to a value less than the Lifetime field, to indicate that the mobile node SHOULD attempt to refresh its home registration at the indicated shorter interval (although the BHR will still retain the registration for the Lifetime period, even if the mobile node does not refresh its registration within the Refresh period). In addition, the BHR MUST follow the procedure defined in Section 8.2 to intercept packets on the mobile node's home link addressed to the mobile node. 8.2 Intercepting Packets for a Mobile Node While a node is serving as the BHR for mobile node (while the node has an entry in its Binding Cache for this mobile node that is marked as a "home registration"), this node MUST attempt to intercept packets on the mobile node's home link addressed to the mobile node. It MUST return any Binding Request for any mobile node in BHR Entry, and it MUST tunnel all data packet that is sent to the mobile node if there is any. In order to intercept such packets on the home link, BHR will send a Proxy ARP [8] broadcast in the home link. Chern Nam Yap et al. Expires 20 December 2000 Page 28 Internet Draft Itinerant Internet Protocol 20 June 2000 8.3 Tunnelling Intercepted packets to a Mobile Node For forwarding each intercepted data packet to the mobile node, the BHR MUST tunnel the packet to the mobile node using IP in IP [6] encapsulation. The tunnel entry point node is the BHR, and the tunnel exit point node is the co-located address as registered with the BHR (which is an address of the mobile node itself). When a BHR encapsulates an intercepted packet for forwarding to the mobile node, the BHR will set the Source Address in the prepended tunnel IP header to the BHR's own IP address, and will set the Destination Address in the tunnel IP header to the mobile node's co-located address. When received by the mobile node (using its co-located address), normal processing of the tunnel header will result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 29 Internet Draft Itinerant Internet Protocol 20 June 2000 9. Temporary Visit Register Operation A mobile node should register itself to the TVR while it is at visit link. 9.1 Co-located Address Registration When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests the receiving node to serve as its TVR, registering its co-located address. To begin processing the Binding Update, the TVR MUST perform the following sequence of tests: - If the visit address for the binding is not in the same TVR links, then the TVR MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 140 (Not temporary visit subnet). - Else, if the TVR chooses to reject the Binding Update for any other reason (e.g., insufficient resources to serve another mobile node as a TVR), then the TVR SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to an appropriate value to indicate the reason for the rejection. If the TVR does not reject the Binding Update as described above, then it will update its existing Binding Cache entry for this mobile node. The visit address of the mobile node is taken from the Visit Address field. The co-located address for this Binding Cache entry is taken from the Source Address field in the packet header. The TVR MUST mark this Binding Cache entry as a "Temporary registration" to indicate that the node is serving as a TVR for this binding. Binding Cache entries marked as a "Temporary registration" MUST be excluded from the normal cache replacement policy used for the Binding Cache (Section 7.6) and MUST NOT be removed from the Binding Cache. Binding Cache entries marked as a "Temporary registration" MUST be remove if it receives a Binding Update without a T bit. Chern Nam Yap et al. Expires 20 December 2000 Page 30 Internet Draft Itinerant Internet Protocol 20 June 2000 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD be), then the TVR MUST return a Binding Acknowledgement to the mobile node, constructed as follows: - The Status field MUST be set to a value indicating success (the value MUST be less than 128). The only currently defined success Status value is 0, indicating simply that the Binding Update was accepted. - The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. - The Lifetime field MUST be set to the remaining lifetime for the binding as set by the TVR in its "Temporary registration" Binding Cache entry for the mobile node. - The Refresh field MUST be set to a value less than or equal to the Lifetime value being returned in the Binding Update. If the TVR stores the Binding Cache entry in non-volatile storage (that survives the crash or other failure of the TVR), then the Refresh field SHOULD be set to the same value as the Lifetime field. Otherwise, the TVR MAY set the Refresh field to a value less than the Lifetime field, to indicate that the mobile node SHOULD attempt to refresh its temporary registration at the indicated shorter interval (although the TVR will still retain the registration for the Lifetime period, even if the mobile node does not refresh its registration within the Refresh period). In addition, the TVR MUST follow the procedure defined in Section 9.2 to intercept packets on the mobile node's TVR link addressed to the mobile node. 9.2 Intercepting Packets for a Mobile Node While a node is serving as the TVR for mobile node (while the node has an entry in its Binding Cache for this mobile node that is marked as a "temporary registration"), this node MUST attempt to intercept packets on the mobile node's visit link addressed to the mobile node. It MUST tunnel all data packet that is sent to the mobile node. In order to intercept such packets on the home link, TVR send a Proxy ARP [8] broadcast in the visit link. Chern Nam Yap et al. Expires 20 December 2000 Page 31 Internet Draft Itinerant Internet Protocol 20 June 2000 For forwarding each intercepted data packet to the mobile node, the TVR MUST tunnel the packet to the mobile node using IP in IP [6] encapsulation. The tunnel entry point node is the TVR, and the tunnel exit point node is the co-located address as registered with the TVR. When a TVR encapsulates an intercepted packet for forwarding to the mobile node, the TVR sets the Source Address in the prepended tunnel IP header to the TVR's own IP address, and sets the Destination Address in the tunnel IP header to the mobile node's new co-located address. When received by the mobile node (using its co-located address), normal processing of the tunnel header will result in de- capsulation and processing of the original packet by the mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 32 Internet Draft Itinerant Internet Protocol 20 June 2000 10. Mobile Node Operation 10.1. Sending Packets While Away from Home While a mobile node is away from home, it uses its newly acquired co- located address. For packets sent by a mobile node while it is at home, no special IIP processing is required for sending this packet. If the mobile node uses any address other than its home address as the source of a packet sent while away from home (from the point of view of applications, as described above), no special Itinerant Internet Protocol processing is required for sending that packet. In each case, the packet is simply addressed and transmitted in the same way as any normal IP packet. By using the co-located address as the Source Address in the IP header, the packet will be able to safely pass through any router implementing ingress filtering. 10.2. Receiving Packets While Away from Home While away from home, a mobile node will receive packets by one of two methods: - The correspondent node will first send a Binding Request to mobile node home address, which will be intercepted and the reply with a Binding Update. Hence the correspondent node sends all its data packets to the mobile node that contains the mobile node's current co-located address. - The non-mobile aware correspondent node will send the data packet to the mobile node home address, which will be intercepted and tunnelled to the mobile node. 10.3. Movement Detection A mobile node uses Strong Cell switching to detect when it has moved from one link to another. A link layer hint is used as a Strong Cell Switching mechanism (For example IIP periodically detect changes in IP address that is being assignment during communication, once a movement is done, PPP will use IPCP function to assign another new IP address, hence that is use as hint of movement.) Chern Nam Yap et al. Expires 20 December 2000 Page 33 Internet Draft Itinerant Internet Protocol 20 June 2000 This method is very reliable as assignment of new IP address on a new prefix means a confirmation establishment in link layer of a new IP subnet. The new assigned IP address will hence be the new co-located address. Once this is being done, mobile node will need to immediately multicast Binding Updates to its BHR/TVR and correspondent node. 10.4. Sending Binding Updates to the Base Home Register After Movement Detection a mobile node MUST register this co-located address with its BHR. To do so, the mobile node will send a Binding Update packet to its BHR and the packet constructed as follows: - The Home Registration (H) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update. - The packet MUST contain a Home Address field which contain its home address. - The mobile MUST use the new co-located address as source to send the Binding Update. - The value specified in the Lifetime field SHOULD be less than or equal to the remaining lifetime of the co-located address specified for the binding. The Acknowledge (A) bit in the Binding Update requests the BHR to return a Binding Acknowledgement in response to this Binding Update. As described in Section 5.2, the mobile node SHOULD retransmit this Binding Update to its BHR until it receives a matching Binding Acknowledgement. Once reaching a retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD continue to periodically retransmit the Binding Update at this rate until acknowledged (or until it begins attempting to register a different co-located). When sending a Binding Update to its BHR, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section 10.6. 10.5. Sending Binding Updates to the Temporary Visit Register After Movement Detection a mobile node MUST register this co-located address with its TVR. To do so, the mobile node will send Binding Update packet to its TVR and the packet constructed as follows: Chern Nam Yap et al. Expires 20 December 2000 Page 34 Internet Draft Itinerant Internet Protocol 20 June 2000 - The TVR (T) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update. - The packet MUST contain a Visit Address field that contains its visit address - The mobile MUST use the new co-located address as source to send the Binding Update. - The value specified in the Lifetime field SHOULD be less than or equal to the remaining lifetime of the co-located address specified for the binding. 10.6. Sending Binding Updates to Correspondent Nodes A mobile node MUST immediately send a Binding Update to all correspondent nodes that it is communicating once it has acquired a new co-located address .The Binding Update requests the correspondent node to update an entry for the mobile node in the correspondent node's Binding Cache to record this co-located address for use in sending packets to the mobile node. In this case, the value specified in the Lifetime field sent in the Binding Update SHOULD be less than or equal to the remaining lifetime of the co-located specified for the binding. If, instead, the packet source address is set to the mobile node's home address, the Binding Update will requests the correspondent node to delete any existing Binding Cache entry that it has for the mobile node. When sending any Binding Update, the mobile node MUST record in its Binding Update List the following fields from the Binding Update: - The IP address of the node to which the Binding Update was sent. - The home address for which the Binding Update was sent (the value in the Home Address field). - The initial lifetime of the binding, initialised from the Lifetime field sent in the Binding Update. Chern Nam Yap et al. Expires 20 December 2000 Page 35 Internet Draft Itinerant Internet Protocol 20 June 2000 - The remaining lifetime of the binding has also initialised from the Lifetime field sent in the Binding Update. This remaining lifetime value counts down and may also be reduced when the matching Binding Acknowledgement is received, based on the Lifetime value specified in that Binding Acknowledgement, as described in Section 10.8. When this remaining lifetime reaches zero, the Binding Update List entry MUST be deleted. The mobile node MUST retain in its Binding Update List information about all Binding Updates sent, for which the lifetime of the binding has not yet expired. However, when sending a Binding Update, if an entry already exists in the mobile node's Binding Update List for an earlier Binding Update sent to that same destination node, the existing Binding Update List entry will be updated to reflect the new Binding Update rather than creating a new Binding Update List entry. Binding Updates sent to correspondent nodes are not generally required to be acknowledged. However, if the mobile node wants to be sure that its new co-located address has been entered into a correspondent node's Binding Cache, the mobile node MAY request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update. In this case, however, the mobile node SHOULD NOT continues to retransmit the Binding Update once the retransmission timeout period has reached MAX_BINDACK_TIMEOUT. 10.7. Retransmit Binding Updates If, after sending a Binding Update in which the Acknowledge (A) bit is set, a mobile node fails to receive a valid, matching Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD retransmit the Binding Update, until a Binding Acknowledgement is received. Such a retransmitted Binding Update MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. The retransmissions by the mobile node MUST use an exponential back-off process, in which the timeout period is doubled upon each retransmission until either the node receives a Binding Acknowledgement or the timeout period reaches the value MAX_BINDACK_TIMEOUT. Chern Nam Yap et al. Expires 20 December 2000 Page 36 Internet Draft Itinerant Internet Protocol 20 June 2000 10.8. Receiving Binding Acknowledgements Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: - The packet meets the specific IPSec [2] requirements for Binding Acknowledgements, defined in Section 4.3. - The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. Any Binding Acknowledgement not satisfying all of these tests MUST be silently ignored. When a mobile node receives a packet carrying a valid Binding Acknowledgement, the mobile node MUST examine the Status field as follows: - If the Status field indicates that the Binding Update was accepted (the Status field is less than 128), then the mobile node MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged. The mobile node MUST then stop retransmits the Binding Update. In addition, if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, then the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry (with a minimum value for the Binding Update List entry lifetime of 0). That is, if the Lifetime value sent in the Binding Update was L_update, the Lifetime value received in the Binding Acknowledgement was L_ack, and the current remaining lifetime of the Binding Update List entry is L_remain, then the new value for the remaining lifetime of the Binding Update List entry should be max((L_remain - (L_update - L_ack)), 0) where max(X, Y) is the maximum of X and Y. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent. Chern Nam Yap et al. Expires 20 December 2000 Page 37 Internet Draft Itinerant Internet Protocol 20 June 2000 - If the Status field indicates that the Binding Update was rejected (the Status field is greater than or equal to 128), then the mobile node MUST delete the corresponding Binding Update List entry (and MUST also stop retransmit the Binding Update). 10.9. Routing Multicast Packets A mobile node that is connected to its home link functions in the same way as any other (stationary) node. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. This section therefore describes the behaviour of a mobile node that is not on its home link. In order to receive packets sent to some multicast group, a mobile node must join that multicast group. A mobile node SHOULD join the group via a (local) multicast router on the foreign link being visited. The mobile node SHOULD use its co-located address sharing a subnet prefix with the multicast router, as the source IP address of its multicast group membership control messages. A mobile node MAY join multicast groups via a bi-directional tunnel to its BHR/TVR. The mobile node tunnels its multicast group membership control packets to its BHR/TVR, and the BHR/TVR forwards multicast packets down the tunnel to the mobile node. Chern Nam Yap et al. Expires 20 December 2000 Page 38 Internet Draft Itinerant Internet Protocol 20 June 2000 11. Protocol Constants INITIAL_BINDACK_TIMEOUT 1 second MAX_BINDACK_TIMEOUT 256 seconds Chern Nam Yap et al. Expires 20 December 2000 Page 39 Internet Draft Itinerant Internet Protocol 20 June 2000 Reference [1] Paul Ferguson and Daniel Senie. Network ingress filtering: Defeating denial of service attacks which employ IP source address spoofing. RFC 2267, January 1998. [2] Stephen Kent and Randall Atkinson. Security architecture for the Internet Protocol. RFC 2401, November 1998. [3] Scott Bradner. Key words for use in RFCs to indicate requirement levels. RFC 2119, March 1997. [4] Stephen Kent and Randall Atkinson. IP Authentication header. RFC 2402, November 1998. [5] Stephen Kent and Randall Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998. [6] Charles Perkins. IP encapsulation within IP. RFC 2003, October 1996. [7] Charles Perkins, editor. IP mobility support. RFC 2002, October 1996. [8] David C. Plummer. An Ethernet address resolution protocol: Or converting network protocol addresses to 48.bit Ethernet addresses for transmission on Ethernet hardware. RFC 826, November 1982. [9] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [10] J. B. Postel, editor. Transmission Control Protocol. RFC 793, September 1981. Chern Nam Yap et al. Expires 20 December 2000 Page 40 Internet Draft Itinerant Internet Protocol 20 June 2000 Comments about this document should be discussed on the mobile-ip@standards.nortelnetworks.com mailing list. Authors' Addresses Questions about this document can also be directed to the authors: Chern Nam Yap University of Sheffield Department of Electronic and Electrical Engineering Regent Court 211 Portobello Street Sheffield S1 4DP, England Phone: +44 114 222 3308 Fax: +44 114 222 8299 Web: http://www.mobile1.net E-mail: cny@dcs.shef.ac.uk Srba Cvetkovic University of Sheffield Department of Electronic and Electrical Engineering Regent Court 211 Portobello Street Sheffield S1 4DP, England Phone: +44 114 222 1825 Fax: +44 114 222 8299 Web: http://www.dcs.shef.ac.uk/~srba E-mail: srba@dcs.shef.ac.uk Matthias Kraner University of Sheffield Department of Electronic and Electrical Engineering Regent Court 211 Portobello Street Sheffield S1 4DP, England Phone: +44 114 222 1921 Fax: +44 114 222 8299 Web: http://www.dcs.shef.ac.uk/~matthi E-mail: m.kraner@dcs.shef.ac.uk Chern Nam Yap et al. Expires 20 December 2000 Page 41