Network Working Group Chern Nam Yap Internet Draft Matthias Kraner University of Sheffield Srba Cvetkovic Logica 10 January 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 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.ieft.org/shadow.html Abstract This document specifies a protocol that allows any IP node to communicate with other IP nodes in the mobile environment without any fundamental changes to TCP/IP. Any mobile aware nodes are able to communicate with one another with standard IP routing. Mobile awareness is achieved by means of address updates through a query mechanism. Backward compatibility capability is supported via the means of one or more anchoring points that are put in place. Chern Nam Yap et al. Expires 10 July 2001 Page i Internet Draft Itinerant Internet Protocol 10 January 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 . . . . . . . . . . . . 4 3.3. Specification Language . . . . . . . . . . . . . . . . . 6 4. Overview of Itinerant Internet Protocol 7 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 4.2. Short Circuit Mechanism . . . . . . . . . . . . . . . . . 9 4.2. Itinerant Internet Protocol Signalling . . . . . . . . .10 4.3. IPSec Requirements for Binding Updates and Binding Acknowledgement . . . . . . . . . . . . . . . . . . . . .11 4.4. Conceptual Data Structures . . . . . . . . . . . . . . .11 4.5. Binding Management . . . . . . . . . . . . . . . . . . .14 5. Itinerant Internet Protocol Signalling Message Type . . . . . .15 5.1. Binding Update packet . . . . . . . . . . . . . . . . . .15 5.2. Binding Acknowledgement packet . . . . . . . . . . . . .18 5.3. Binding Request packet . . . . . . . . . . . . . . . . .20 6. Requirements for IP Nodes 22 6.1. Requirements for All Mobile Aware Nodes . . . . . . . . .22 6.2. Requirements for Base Home Register . . . . . . . . . . .22 6.3. Requirements for Temporary Visit Register . . . . . . . .23 6.4. Requirements for Near Correspondent Register . . . . . .24 7. Correspondent Node Operation 25 7.1. Receiving Binding Updates . . . . . . . . . . . . . . . .25 7.2. Request to Cache a Binding . . . . . . . . . . . . . . .26 7.3. Sending Binding Acknowledgements . . . . . . . . . . . .26 7.4. Sending Binding Requests . . . . . . . . . . . . . . . .27 7.5. Cache Replacement Policy . . . . . . . . . . . . . . . .27 7.6. Sending Packet to a Mobile Node . . . . . . . . . . . . .28 8. Base Home Register Operation 29 8.1. Co-located Address Registration . . . . . . . . . . . . .29 8.2. Intercepting Packets for a Mobile Node . . . . . . . . .30 8.3. Tunnelling Intercepted Packets to a Mobile Node . . . . .30 Chern Nam Yap Expires 10 July 2001 Page ii Internet Draft Itinerant Internet Protocol 10 January 2000 9. Temporary Visit Register Operation 31 9.1. Co-located Address Registration . . . . . . . . . . . . .31 9.2. Intercepting Packets for a Mobile Node . . . . . . . . .32 10. Near Correspondent Register Operation 33 10.1. Near Correspondent Registration . . . . . . . . . . . .33 10.2. Intercepting Packets for a Mobile Node . . . . . . . . .34 10.3. Tunnelling Intercepted Packets to a Mobile Node . . . .34 11. Mobile Node Operation 35 11.1. Sending Packets While Away from Home . . . . . . . . . .35 11.2. Receiving Packets While Away from Home . . . . . . . . .35 11.3. Movement Detection . . . . . . . . . . . . . . . . . . .35 11.4. Sending Binding Updates to the Base Home Register . . .36 11.5. Sending Binding Updates to the Temporary Visit Register.37 11.6. Sending Binding Updates to the Near Correspondent Visit Register . . . . . . . . . . . . . . . . . . . . . . . .37 11.7. Sending Binding Updates to Correspondent Nodes . . . . .38 11.8. Retransmit Binding Updates . . . . . . . . . . . . . . .39 11.9. Receiving Binding Acknowledgements . . . . . . . . . . .39 11.10. Routing Multicast Packets . . . . . . . . . . . . . . .40 12. Protocol Constants 42 13. IANA Considerations 43 References 44 Authors' Addresses 45 Chern Nam Yap Expires 10 July 2001 Page iii Internet Draft Itinerant Internet Protocol 10 January 2000 1. Introduction This document specifies a protocol that allows any IP node to communicate with any other IP node in the mobile environment with minimum changes to TCP/IP. Without mobility awareness or mobility management on an IP machine, communicating would not be possible when either side changes IP subnets. This is because current IP routing is subnet prefix based and not Host based. In order to allow communication in spite of the move, address updating to all sides of the communication is required. This allows communication in this scenario to be unaffected. Such a scheme is defined as a protocol known as "Itinerant Internet Protocol" (IIP). - In the basic scheme, all nodes are mobile aware. The initialising node MUST send a query for the destination node's latest address. In order not to incur any delay, data is sent immediately after the query has been sent. The query SHOULD be responded to and the initialising node SHOULD reconstruct the data packet destination address with the latest information to send to the mobile node. Moreover, data transmission and subsequent updates of address MAY be multi-homed. All data traffic is pure standard IP routing. - In the backward compatibility scheme where the correspondent node is not mobile aware, there are two cases of communication. Case 1 The initialising node is the mobile node. When the mobile node leaves a particular subnet and the correspondent node sends data to the mobile node, the previous subnet's anchoring point SHOULD forward all the packets to the mobile node. Case 2 The initialising node is the correspondent node. The mobile node's home anchoring point SHOULD always first forward all the packets to the mobile node. If a mobile aware anchoring point is discovered between correspondent node and the home anchoring point, this mobile aware anchoring point will the forward the packets to the mobile node. In order to support ingress filtering, in the reverse traffic (from the mobile node to the correspondent node) will still done through the home anchoring point. IIP is suitable for mobility across both homogenous and heterogeneous media. One can think that IIP is a solution to the 3G IP mobility problems as it is designed to do so. Chern Nam Yap Expires 10 July 2001 Page 1 Internet Draft Itinerant Internet Protocol 10 January 2000 2. Comparison with Mobile IP IIP is designed to work across both IPv4 and IPv6. IIP is situated at a layer between TCP/IP and applications. This layer is known as Management Layer, and because of this IIP reduces the need to concern or to do any harm to the progression of IP development. The differences between Mobile IP and IIP are described as follows: - Diversion is a MUST for IIP mobile aware correspondent nodes. Data traffic after diversion does not incur encapsulation. IIP always tries to avoid using the forwarding mechanism whenever possible. Diversion is a method to change IP address of any IP packet before the packet is being sent out. This is normally done after the packet is formed. This is so that there SHOULD NOT have any effect on the transport layer whenever a mobile node moves hence it is transparent to any transport layer. - IIP uses a "first communication contact addressing mechanism" and "short circuit mechanism" to improve triangular routing. Temporary Visit Register and Near Correspondent Register are invented to achieve such effect. In many case, IIP SHOULD assume each subnet would have at least one anchoring entity that act as a BHR/NCR/TVR. Temporary Visit Register can be upgraded to a Base Home Register to increase reliability in connections. NCR is assumed MAY exist in between Correspondent Node and BHR. Thus there is no complex Hierarchical topology in IIP scheme for mobile network. - A mobile node in IIP MUST always use its latest co-located address in the source field in any of its IP packets. In such manner, mobile node is always in the right topology, and hence it has no problem with ingress filtering [1]. - IIP Binding Updates contain the latest transport port value allowing multi-home and MPLS operation to be carried out. Many application uses dynamic ports allocation while the connection is kept. With support latest transport port value allows easier applications creation. - No mobility action takes place during cell-to-cell switching in a single IP subnet. This is due to fact subnet prefix switching mechanism, like PPP [12], is used. Hence no periodic Agent Advertisements would be need that significantly cut down traffic between mobile node and the core network. Thus IIP uses simple control signalling rather many different complex type of signalling. Chern Nam Yap Expires 10 July 2001 Page 2 Internet Draft Itinerant Internet Protocol 10 January 2000 - No need to worry for IPv4 to IPv6 transitions, fully compatible with both IPv4 and IPv6 at the same time. Machines that can handle both IPv4 and IPv6 SHOULD not have problems receiving IPv4 and IPv6 packets in the mobile environment. Chern Nam Yap Expires 10 July 2001 Page 3 Internet Draft Itinerant Internet Protocol 10 January 2000 3. Terminology 3.1 General Term IP Internet Protocol. IIP Itinerant Internet Protocol. Node A device that implements IP. Router A node that forwards IP packets not explicitly address to itself. Host Any node that is not a router. Link The Layer underneath IP. Subnet prefix A bit string that consist of a number of initial bits of an IP address. Packet An IP header plus payload. 3.2 Itinerant Internet Protocol Terms Home Address An IP address assigned to a mobile node within the HOME link. Visit Address An IP address assigned to a mobile node within a visit link. Near Address An IP address either belongs to a Near Correspondent Register Home Subnet Prefix The subnet prefix associated with the mobile node's Home Address. Visit Subnet Prefix The subnet prefix associated with mobile node's Visit Address. Chern Nam Yap Expires 10 July 2001 Page 4 Internet Draft Itinerant Internet Protocol 10 January 2000 HOME link The link where the mobile node's home subnet prefix is defined. Visit Link The link where mobile node's visit subnet prefix is defined. Old link The link where a mobile node is assigned a Home/Visit Address. It can be either HOME link or Visit link. New link The link that a mobile node has just entered, it can be either a HOME link or Visit link. Mobile node A node whose movement between subnets has minimum effect on its applications. Movement A change in link, when a mobile node moves from an OLD link to a NEW link. Correspondent node A peer node that the mobile node is communicating with. It can be mobile or stationary. BHR (Base Home Register) An anchoring point for the mobile node at the HOME link that aids the mobile node to diverse its address. It also forwards packets to the mobile node when there is necessity to do so. TVR (Temporary Visit Register) An anchoring point for the mobile node at a visit link that aids in forwarding packets to the mobile node when the mobile node leaves the OLD link. NCR (Near Correspondent Register) An anchoring point for the mobile node situate between the correspondent node and BHR. It aids in forwarding packets to the mobile node to route optimise the link from the correspondent node to the mobile node if the correspondent node is not mobile aware and initialised the traffic first. Chern Nam Yap Expires 10 July 2001 Page 5 Internet Draft Itinerant Internet Protocol 10 January 2000 Co-located Address An IP address that the mobile node uses to co-locate itself. This address is used by the Mobile aware correspondent nodes, the BHR and the TVR to send packets to the mobile node. Binding The association of the Home/Visit address with the co-located address for any mobile node, along with the remaining lifetime of that association. Shorted Flag A flag in TOS field for mobile short-circuiting. 3.3 Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENEDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Chern Nam Yap Expires 10 July 2001 Page 6 Internet Draft Itinerant Internet Protocol 10 January 2000 4. Overview of Itinerant Internet Protocol 4.1 Basic Operation In the basic scheme, a mobile node SHOULD be addressed by its co- located address, whether or not it is currently attached to the HOME link or a visit link. Standard IP routing is used when the mobile node is at home and there is no OLD link after the mobile node is switched on. When a mobile node moves to a NEW link, it SHOULD be assigned a co- located address. The mobile node SHOULD then register this address with its BHR and TVR. This is done through the means of address binding updates. Similarly, a correspondent node that is in communication with the mobile node SHOULD also get address binding updates. Packets sent to the mobile node SHOULD then either be forwarded or diverted to mobile node's latest co-located address. Example: A mobile node is switched on at Visit link, and it moves to its HOME link. In this case the Visit link is its OLD link and the HOME link is its NEW link. A new co-located address SHOULD be assigned to the mobile node and SHOULD be sent to the BHR and TVR. Since the mobile node is in the HOME link, the home address SHOULD be assigned to it. Packets that go straight to the HOME link SHOULD have not additional processing. If a communication was started in the OLD link (Visit link), the packets SHOULD be forwarded to the mobile node via the TVR by the means of tunnelling [6]. Hence the co-located address can either be the Home address or a Visit Address. The association between a mobile node's Home/Visit Address and co- located address is known as "Binding" for the mobile node. A mobile node typically acquires its co-located address through PPP [12]. Other methods of acquiring a co-located address are possible, but details of other methods are currently beyond the scope of this document. While a mobile node moves, it registers it newly acquired address with the BHR and TVR. Moreover, a mobile node can also upgrade one of its TVR to BHR in the case if its BHR is not working. The mobile node sends a "Binding Update" packet to achieve the above binding registration. The BHR or TVR SHOULD reply to the registration by sending a "Binding Acknowledgement" packet. Chern Nam Yap Expires 10 July 2001 Page 7 Internet Draft Itinerant Internet Protocol 10 January 2000 In IPv4, the mobile node's BHR/TVR SHOULD use "proxy ARP/gratuitous ARP" [7] to intercept any IP packets addressed to the mobile node's home/visit address. In IPv6, the mobile node's BHR/TVR SHOULD use "neighbour discovery mechanism" to intercept any IP packets addressed to the mobile node's home/visit address. The BHR/TVR MUST then divert (Address Binding Updates) or tunnel [6] the packets to the mobile node's co-located address. A mobile aware correspondent node MUST always use the diversion method. In which case, the correspondent node MUST send a "Binding Request". It is RECOMMENDED that data packets be sent immediately, without waiting for the "Binding Update" reply. In the backward compatibility scheme, communication between the mobile node and the correspondent node SHOULD depend on who has started the communication first. If the correspondent started the communication, the correspondent node could only have known the mobile node's home address (through DNS). Hence the BHR SHOULD tunnels [6] all traffic to the mobile node's latest co-located address. When the mobile node moves from one Visit Link to another, the TVR MUST intercept the mobile node's traffic and aid the tunnelling [6] process. The reason for this is simple, since the TVR in this sense provides smooth handoffs. Moreover, the mobile node will initiate a NCR discovery mechanism (Short Circuit mechanism). Once a NCR is found along the way between the correspondent node and BHR, NCR will take over the forwarding functionality of the BHR in the direction towards the mobile node. If the mobile node starts the communication, then it SHOULD depend on where the mobile node is located. If the mobile node is located at the HOME link, then it is very much the same as if the correspondent node started the communication. If the mobile node is located at a visit link, due to the fact the mobile node SHOULD use the visit address as the source field in the IP packet, the correspondent SHOULD send all the traffic to this visit address. As the mobile node moves to a NEW link, the OLD link TVR SHOULD intercept the packets for the mobile node and tunnel [6] them to the mobile node. Chern Nam Yap Expires 10 July 2001 Page 8 Internet Draft Itinerant Internet Protocol 10 January 2000 All mobile nodes MUST be mobile aware correspondent nodes and MUST be able to do forwarding and reverse tunnelling [6]. In any case a BHR/TVR/NCR can be a mobile node as well. If a BHR/TVR/NCR works as a mobile node, it MUST first handover its functionality before it becomes mobile. This functionality of BHR and TVR being mobile SHOULD not be mentioned in this document, but on another document. Any peer communicating with a mobile node is referred to in this document as a "correspondent node". It MAY be either a mobile node or stationary node. Currently Binding Update, Binding Acknowledgment and Binding Request are all in UDP [9] payload format. This might change in the future to SCTP [14] payload format as well. Currently, the protocol will work on port 700 that currently is unassigned by any protocol. Mobile node MUST always source its packets using its NEW link co- located address, whether it is a Home address or Visit address. Hence the mobile node is always topologically correct. Thus IIP does not need to deal with "ingress-filtering issues" [1]. 4.2 Short Circuit Mechanism As aforementioned this is a NCR discovery mechanism. Whenever a non- mobile-aware correspondent node sends a packet to mobile node. The packet will be tunnelled through the BHR. This forwarding process indicated that the either mobile node is in anonymous mode or the correspondent node is not mobile-aware. If shorted circuit were done, the mobile node would as well receive a forwarded packet. Mobile Node would ignore to re preformed "Short Circuit Mechanism" as there isn't a need to. The first packet that mobile node send back to the correspondent node in the IP header would have a flag in the unused TOS field. Normal IPv4 header with the unused TOS field flag This flag is known as Shorted Flag throughout this document 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | IHL | TOS |1| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | Chern Nam Yap Expires 10 July 2001 Page 9 Internet Draft Itinerant Internet Protocol 10 January 2000 IP version 6 is not mentioned here is assumed that all IP version 6 node SHOULD be mobile aware, hence this feature is not required. Since every router along the way would have to decode the IP header (i.e. between the BHR and the Correspondent Node). If a NCR exist, it should be able to pick up this and send a "Near Registration" to the Mobile Node. Hence once the two-way "Near Registration" (explained in 10.1) is completed, the route from non-mobile aware correspondent node to mobile node will be "short circuited" as the NCR would intercept mobile node packet and forward to the mobile node's latest link. The mobile node SHOULD send Binding Update refresh to keep this short circuit. 4.2 Itinerant Internet Protocol Signalling As discussed in general in Section 4.1, the following three new UDP [9] packets are defined for IIP Signalling. Binding Update The mobile node notifies the BHR/TVR/NCR as well as in communication with correspondent nodes using this packet. This packet is also used by the BHR to reply to a correspondent node request of the mobile node's current co-located address. At the same time this packet is also used by the NCR start "short circuiting". The Binding Update sent to the BHR to register the mobile node's co-located address is known as "Home Registration". The Binding Update sent to the TVR to register the mobile node's co-located address is known as "Visit Registration". Any mobile node can upgrade its TVR to BHR using "Home Registration". The Binding Update sent by NCR to Mobile Node for "short circuiting" is known as "Near Registration". This packet SHOULD be protected from security attacks. Currently, IPSec [2] is used to protect this Binding Update packet 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 from security attacks. Currently, IPSec [2] is used to protect this Binding Acknowledgment packet as defined in Section 4.3 to guard against any malicious Binding Acknowledgment. Chern Nam Yap Expires 10 July 2001 Page 10 Internet Draft Itinerant Internet Protocol 10 January 2000 Binding Request Correspondent node uses this packet to request for mobile node's latest co-located. This packet is normally sent to BHR/TVR, and a correspondent node for refreshing binding also can use it. This is sent as a normal packet, or it can also be sent with security protection. 4.3 IPSec [2] Requirements for Binding Updates and Binding Acknowledgement. Currently, IPSec [2] MUST be used to protect both Binding Update and Binding Acknowledgement packets. Specifically, any Binding Update or Binding Acknowledgement packet MUST utilise IPSec [2] sender authentication, data integrity protection, and replay protection. Currently, IIP requires that this protection covering a Binding Update or Binding Acknowledgement MUST use AH [4] and ESP [5]. IIP is a transport payload, hence it is easily protected by AH [4] and ESP [5]. 4.4 Conceptual Data Structures This document describes IIP in terms of the following conceptual data structures: Mobile Binding Cache Each mobile aware node needs to maintain a binding cache. This cache contains bindings of the mobile aware node with any mobile nodes. The Mobile Binding Cache MAY be implemented in any manner consistence with the external behaviour described in this document. Each Mobile Binding Cache entry conceptually contains the following fields: - Home/Visit 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 Home/Visit Address in the Binding Cache entry, this entry SHOULD be used in routing that packet. - The co-located address of mobile node. It is the field in the same entry that is associated with the Home/Visit field. If the destination address of a packet being sent matches Home/Visit Address, then the packet SHOULD be routed to this co-located address. Chern Nam Yap Expires 10 July 2001 Page 11 Internet Draft Itinerant Internet Protocol 10 January 2000 - A lifetime value that shows the remaining lifetime for this Binding Cache entry. This value is initialised from the lifetime field in the Binding Update that created or last modified this Binding Cache entry. Once the lifetime on this entry has expires, the entry MUST be deleted from the Binding Cache. - A flag indicating whether this Binding Cache entry is a "Home Registration" or "Visit Registration" or "Near 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 32 bit long, and all comparisons between Sequence Number values MUST be performed modulo 2^32. - Binding Cache entry recent usage information. It is needed to implement cache replacement policy in use in the Binding Cache. This also assists in determining whether a Binding Request SHOULD be sent when the lifetime on this entry is near expiration. An entry in a node's Binding Cache for which the node is serving as a BHR is marked as "Home Registration" entry (TVR is marked as "Visit Registration" entry, NCR is marked as "Near Registration" entry). This entry SHOULD NOT be deleted by the BHR/TVR/NCR until the expiration of its binding lifetime. Other Binding Cache entries MAY be replaced at any time by any reasonable local cache replacement policy but SHOULD NOT unnecessary to be deleted. The node's Binding Cache MAY contain at most one entry for each mobile node Home/Visit Address. Binding Update List Binding Update list that is maintained by each mobile node, records information for each Binding Update sent by the mobile node for which the lifetime sent in that Binding Update has not been expired. It includes all bindings sent by the mobile node to its correspondent nodes, BHR/TVR/NCR. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Updates (where Greatest Sequence Number is used in this case to confirm the most recent Binding Updates) sent to the destination. The Binding Update list MAY be implemented in any manner consistent with the external behaviour as described in this document. Each Biding update list entry conceptually contains the following fields: Chern Nam Yap Expires 10 July 2001 Page 12 Internet Draft Itinerant Internet Protocol 10 January 2000 - The IP address of the node to which a Binding Update was sent. If the Binding Update was successfully received by that node and if that node has not been deleted the entry before its expiration, this node might still have a Binding Cache entry. - The Home/Visit address for which that Binding update was sent. This is meant for the mobile node to distinguish between co-located and Home/Visit address. - The co-located address of the Binding Update. This value is necessary for the mobile node to determine if it has sent its latest co-located address in the Binding Update to the right 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. - The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 32 bit long, and all comparisons between Sequence Number values MUST be performed modulo 2^32. - 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. 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 indicates that future Binding Updates SHOULD not be sent to any particular destination when it is being set. Chern Nam Yap Expires 10 July 2001 Page 13 Internet Draft Itinerant Internet Protocol 10 January 2000 4.5 Binding Management When a mobile node acquires a new co-located address, the mobile node SHOULD register this new binding with its BHR/TVR/NCR by sending the BHR/TVR/NCR a Binding Update. The mobile node indicates that an acknowledgement is needed for this Binding Update and continues to periodically retransmit it until it receives an acknowledgment. The acknowledgement is in the form of Binding Acknowledgement packet as mentioned above. When a mobile node receives a packet tunnelled [6] to it from the BHR/TVR/NCR, it SHOULD assume that the original sender is not mobile aware, until it receives a packet that is send directly from the sender to the mobile node, if the communication is not initiated by the mobile node. When this takes place, as aforementioned "short circuit mechanism" should take place. A correspondent node with a Binding Cache entry for a mobile node MAY wanted to refresh this binding, for example if the binding's lifetime is near expiration, by the correspondent node MAY send a Binding Request to the mobile node for a refresh for the Binding. Normally, a correspondent node SHOULD only refresh a Binding Cache entry in this way if it is actively having a ongoing communication with the mobile node. (For example as an open TCP [10] connection to the mobile node) 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 SHOULD usually route packets directly to the mobile node's co-located address, so that the BHR is rarely involved with the packet transmission to the mobile node. This is essential for scalability and reliability, and for minimising overall network load. Optimal routing of packets can be achieved from the correspondent node to the mobile node, by caching the co-located address of a 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. Mobile node should try to upgrade all of its TVR to BHR to allow minimum loss of connection when BHR fails. Hence IIP is a more reliable protocol. Chern Nam Yap Expires 10 July 2001 Page 14 Internet Draft Itinerant Internet Protocol 10 January 2000 5. Itinerant Internet Protocol Signalling Message Types 5.1 Binding Update Packet The Binding Update is used by the mobile node to notify its BHR/TVR/NCR Correspondent nodes of a newly assigned 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 | Length | Options | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home / Visit / Near / Co-located IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length The total length of the message, in bytes, excluding the Type and Length bytes. Options: Based on 8bit ASCII code ______________________________________________________________________ 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. Chern Nam Yap Expires 10 July 2001 Page 15 Internet Draft Itinerant Internet Protocol 10 January 2000 Temporary Visit Register (T) The Temporary Visit Register (T) bit is set by the TVR to the correspondent node for identification. Home Registration (H) The Home Registration (H) bit is set by a mobile node to request the receiving node to be its BHR. The destination of the packet carrying this option MUST be a node sharing the same subnet prefix as the mobile node Home address. Visit Registration (V) The Visit Registration (V) bit is set by a mobile node to request the receiving node to be its TVR. The destination of the packet carrying this option MUST be a node sharing the same subnet prefix as the mobile node Visit address. Near Registration (N) The Near Registration (N) bit is set by a mobile node/NCR to register/update NCR. Privacy (P) Privacy (P) bit is set by mobile node to allow it to run in privacy, no binding update SHOULD be sent to correspondent node as the mobile node wish to be anonymous. 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^32). 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. Chern Nam Yap Expires 10 July 2001 Page 16 Internet Draft Itinerant Internet Protocol 10 January 2000 Home/Visit/Co-located Address If the Home/Visit IP Address is sent to the BHR/TVR/NCR/Correspondent Node to update Binding by the mobile node, then the M bit MUST be set here. If the Near IP Address is set to Mobile Node to "short-circuit" by the NCR, then the N bit MUST be set here. If the Co-located IP Address is sent to Correspondent Node to update the Binding by the BHR, then the B bit MUST be set here. If the Co-located IP Address is sent to Correspondent Node to update the Binding by the TVR, then the T bit MUST be set here. Port Number This is a 16-bit value to allow change of port number that mobile node and the correspondent node would agree on using for the future communication. Session ID This is a 16-bit value to allow identification for corresponding Binding Request/Binding Updates/Binding Acknowledgement. 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 Update. A Binding Cache entry for the mobile node MUST NOT be created in response to the following Binding Update packet: 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 mobile node stores the Last Sequence Number value in Binding Update list entry for a destination that it sent a Binding Update. The correspondent node store the Last Sequence Number value that is received from a mobile node in a Binding Update in its Binding Cache entry for that mobile node. Thus, the mobile node and correspondent node SHOULD have the knowledge of the Last Sequence Number and SHOULD 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 the mobile node. Chern Nam Yap Expires 10 July 2001 Page 17 Internet Draft Itinerant Internet Protocol 10 January 2000 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 | Length | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length The total length of the message, in bytes, excluding the Type and Length bytes. Status It is an 8-bit unsigned integer indicating the disposition of the Binding Updates. Values of the Status field less than 128 indicate that the receiving node accepted the Binding Updates. The following such Status values are currently defined: 0 Binding Update accepted Chern Nam Yap Expires 10 July 2001 Page 18 Internet Draft Itinerant Internet Protocol 10 January 2000 Values of the Status field greater than or equal to 128 indicate that the receiving node rejected the Binding Updates. The following such Status values are currently defined: 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Not BHR for this mobile node 132 Not TVR for this mobile node 133 Not NCR for this mobile node 134 Home registrations not supported 135 Visit registrations not supported 136 Not home subnet 137 Not visit subnet Reserved This field is unused. It MUST be initialised to zero by the sender and MUST be ignored by the receiver. Sequence Number 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 is in terms of seconds. If the node sending the Binding Acknowledgement is serving as the mobile node's BHR/TVR, the lifetime period SHOULD also indicate the period for which this node SHOULD continue this service. If the mobile node requires BHR/TVR 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. The value of this field SHOULD be undefined it the Status field indicated that the Binding Update was rejected. Port Number This is a 16-bit value to allow change of port number that mobile node and the correspondent node would agree on using for the future communication. Session ID This is a 16-bit value to allow identification for corresponding Binding Request/Binding Updates/Binding Acknowledgement. Chern Nam Yap Expires 10 July 2001 Page 19 Internet Draft Itinerant Internet Protocol 10 January 2000 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 SHOULD 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 Updated packet. 5.3 Binding Request Packet The Binding Request Packet is used to request a mobile node's binding from the BHR. When the BHR receives a Binding request packet, it SHOULD return a Binding Update (Section 5.1) to the source of the Binding Request, if the mobile node has not requested privacy through the use of the P bit. The Binding Request 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 | Length | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length The total length of the message, in bytes, excluding the Type and Length bytes. Chern Nam Yap Expires 10 July 2001 Page 20 Internet Draft Itinerant Internet Protocol 10 January 2000 Session ID This is a 16-bit value to allow identification for corresponding Binding Request/Binding Updates/Binding Acknowledgement. Session ID Chern Nam Yap Expires 10 July 2001 Page 21 Internet Draft Itinerant Internet Protocol 10 January 2000 6. Requirement for IP Nodes IIP places some requirements on the functions needed to make a node mobile aware. This section summarises those requirements by identifying the functionality each requirement 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 decapsulate and reverse tunnel [6] any packet to the BHR or TVR. -Every mobile node MUST maintain a Binding Update List in which it records the IP address of each node to which it has sent a Binding Update, for which the lifetime sent in that binding has not expired. 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 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. Chern Nam Yap Expires 10 July 2001 Page 22 Internet Draft Itinerant Internet Protocol 10 January 2000 - Every BHR MUST be able to intercept packets as mentioned above, addressed to the 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. - Every BHR MUST be able to encapsulate such packets in order to tunnel [6] them to the co-located address of 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. This Binding Update is sent back to the correspondent node, and holds the requested mobile node's latest co-located IP address. 6.3 Requirement 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 it serves. Each Binding Cache entry records the mobile node's binding with its co-located address. - Every TVR MUST be able to intercept packets 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 packets in order to tunnel [6] 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 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 TVR. - Every TVR SHOULD be able to upgraded to a BHR, if there are such requests from a mobile node. Chern Nam Yap Expires 10 July 2001 Page 23 Internet Draft Itinerant Internet Protocol 10 January 2000 6.4 Requirements for Near Correspondent Register In order to enable a mobile node to "short circuit", it is assume that there MAY be a node to act as NCR for the mobile node. The following requirements apply to the NCR: - Every NCR 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 NCR MUST be able to intercept packets as mentioned above, addressed to the mobile node, for which it is currently serving as the NCR. - Every NCR MUST be able to encapsulate such packets in order to tunnel [6] them to the co-located address of the mobile node indicated in its binding in the NCR's Binding Cache. - Every NCR MUST be able to return a Binding Acknowledgement packet in response to a Binding Update packets received with (A) bit set. - Every NCR MUST maintain a separate NCR List for each link on which it is serving as a NCR. - Every NCR MUST be able to process Shorted Flag and perform Near Registration. - A NCR MAY be upgraded to a BHR, if a mobile node requested and the NCR can provide an IP address to the mobile node. Chern Nam Yap Expires 10 July 2001 Page 24 Internet Draft Itinerant Internet Protocol 10 January 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. In this section, only the mobile aware correspondent node SHOULD be mentioned, as there is no point in mentioning non-mobile aware correspondent node. 7.1 Receiving Binding Updates Upon receiving a Binding Update in some packet, the receiving node MUST validate the Biding 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 binding is specified by the Home/Visit/Co-located field. Either the M bit or the B bit MUST be set. - 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 note in Section 4.6, this Sequence Number comparison MUST be performed modulo 2^32. 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 SHOULD be processed according to the procedure specified in Section 8.1. If the Visit Registration (V) 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. - If the 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 Visit Registration (V) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 9.2. Otherwise, it is processed according to the procedure specified in Section 7.3. Chern Nam Yap Expires 10 July 2001 Page 25 Internet Draft Itinerant Internet Protocol 10 January 2000 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 or Visit Registration (V) 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/Visit 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 the node caching the binding MAY reduce this lifetime. 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 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. The packet MUST be sent to the mobile node using mobile node's 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 SHOULD be routed to the current location of the node sending the Binding Update, whether the Binding Update was accepted or rejected. Chern Nam Yap Expires 10 July 2001 Page 26 Internet Draft Itinerant Internet Protocol 10 January 2000 7.4 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 SHOULD be sent to the mobile node's HOME link, where it SHOULD be intercepted and the BHR SHOULD 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. Any correspondent node will use the Session ID value that it sent to the BHR/TVR or the mobile node to verify which is the right session it is talking about. 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. 7.5 Cache Replacement Policy After the expiration of the Lifetime specified in the Binding Update from which any entry was created or last updated, the entry in a node's Binding Cache MUST be deleted. Conceptually, a node SHOULD maintain a separate timer for each entry in its Binding Cache. The node sets the timer for this entry to the specified Lifetime period when creating or updating a Binding Cache entry in response to a received and accepted Binding Update. When a Binding Cache entry's timer expires, the node deletes the entry. Chern Nam Yap Expires 10 July 2001 Page 27 Internet Draft Itinerant Internet Protocol 10 January 2000 Each node's Binding Cache SHOULD, by necessity, has 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. This SHOULD as well apply to "Visit Registration". 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 130 (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" or "Visit Registration" entry, in order to make space for the new entry. Normally a BHR/TVR should have much more resources than normal nodes in a subnet, as it is RECOMMENDED that these nodes are able to work in such environment. Any binding dropped from a node's Binding Cache due to the lack of cache space SHOULD be rediscovered and a new cache entry SHOULD 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 SHOULD be routed normally, leading to the mobile node's HOME link. There, the packet SHOULD be intercepted by the mobile node's BHR and the BHR SHOULD reply with a Binding Updates that allowing the correspondent node to add an entry again for this destination mobile node to its Binding Cache. 7.6 Sending Packets 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 SHOULD be intercepted by the mobile node's BHR which SHOULD 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 Expires 10 July 2001 Page 28 Internet Draft Itinerant Internet Protocol 10 January 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 135 (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 SHOULD 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 mark 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: - 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. Chern Nam Yap Expires 10 July 2001 Page 29 Internet Draft Itinerant Internet Protocol 10 January 2000 - 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. 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 the 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 [6] all data packets that are sent to the mobile node if there are any. 8.3 Tunnelled [6] Intercepted packets to a Mobile Node For forwarding each intercepted data packet to the mobile node, the BHR MUST tunnelled [6] 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 (It is the mobile node NEW link assigned address). When a BHR encapsulates an intercepted packet for forwarding to the mobile node, the BHR SHOULD set the Source Address in the tunnel IP header to the BHR own IP address, and SHOULD 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 SHOULD result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap Expires 10 July 2001 Page 30 Internet Draft Itinerant Internet Protocol 10 January 2000 9. Temporary Visit Register Operation A mobile node MUST 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 136 (Not 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 SHOULD 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 "Visit Registration" to indicate that the node is serving as a TVR for this binding. Binding Cache entries marked as a "Visit 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 mark as a "Visit Registration" MUST be remove if it receives a Binding Update without a "V" bit. 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: Chern Nam Yap Expires 10 July 2001 Page 31 Internet Draft Itinerant Internet Protocol 10 January 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 TVR in its "Visit Registration" Binding Cache entry for the mobile node. 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 "Visit Registration"), this node MUST attempt to intercept packets on the mobile node's visit link addressed to the mobile node. It MUST tunnel [6] all data packet that is sent to the mobile node. For forwarding each intercepted data packet to the mobile node, the TVR MUST tunnels [6] the packets to the mobile node using IP in IP 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 tunnel IP header to the TVR 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 SHOULD result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap Expires 10 July 2001 Page 32 Internet Draft Itinerant Internet Protocol 10 January 2000 10. Near Correspondent Register Operation If a mobile node receives a tunnelled packet, it SHOULD perform "short circuit mechanism". 10.1 Near Correspondent Registration When a node picks up the Shorted Flag, it MUST validate it by sending a Binding Update to the mobile node. This node would only know about the mobile node's home address. The mobile node would acknowledge and at the same time send a Binding Updates with its latest co-located address to the NCR. N bit MUST be set when these Binding Updates is sent. This process is known as the two-way Near Correspondent Registration. When the NCR receives the 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 update its co-located address. To begin processing the Binding Update, the NCR MUST perform the following sequence of tests: The NCR MUST mark this Binding Cache entry as a "Near Registration" to indicate that the node is serving as a NCR for this binding. Binding Cache entries mark as a "Near Registration" MAY be excluded from the normal cache replacement policy used for the Binding Cache (Section 7.6) and MAY be removed from the Binding Cache. This is because there is always a BHR to fall back on. If the Acknowledge (A) bit is set in the Binding Update (it SHOULD be), then the NCR 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 NCR in its "Near Registration" Binding Cache entry for the mobile node. Chern Nam Yap Expires 10 July 2001 Page 33 Internet Draft Itinerant Internet Protocol 10 January 2000 In addition, the NCR MUST follow the procedure defined in Section 10.2 to intercept packets on the mobile node's HOME link addressed to the mobile node. 10.2 Intercepting Packets for a Mobile Node While a node is serving as the NCR for the mobile node, this node MAY attempt to intercept packets. It MUST tunnel [6] all data packets that are sent to the mobile node if there are any. 10.3 Tunnelled [6] Intercepted packets to a Mobile Node For forwarding each intercepted data packet to the mobile node, the NCR MUST tunnelled [6] the packet to the mobile node using IP in IP [6] encapsulation. The tunnel entry point node is the NCR, and the tunnel exit point node is the co-located address as registered with the NCR (It is the mobile node NEW link assigned address). When a NCR encapsulates an intercepted packet for forwarding to the mobile node, the NCR SHOULD set the Source Address in the tunnel IP header to the NCR own IP address, and SHOULD 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 SHOULD result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap Expires 10 July 2001 Page 34 Internet Draft Itinerant Internet Protocol 10 January 2000 11. Mobile Node Operation 11.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 SHOULD be able to safely pass through any router implementing ingress filtering [1]. 11.2 Receiving Packets While Away from Home While away from home, a mobile node SHOULD receive packets by one of two methods: - The mobile aware correspondent node SHOULD first send a Binding Request to mobile node home address, which SHOULD be intercepted and the reply with a Binding Update. Hence the correspondent node sends all its data packets to the mobile node, using its co-located address as the destination IP address of these packets. - The non-mobile aware correspondent node SHOULD send the data packets to the mobile node's home address, which SHOULD be intercepted and tunnelled [6] to the mobile node. 11.3 Movement Detection A mobile node uses Subnet Prefix Matching Switching mechanism method to detect when it has moved from one link to another. The Prefix Matching Switching mechanism (For example IIP periodically detects changes in IP address that is being assigned during communication. Once a movement is done, PPP SHOULD use IPCP [12] function to assign another new IP address, hence that is used as a hint of movement.) Chern Nam Yap Expires 10 July 2001 Page 35 Internet Draft Itinerant Internet Protocol 10 January 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 SHOULD hence be the new co-located address. Once this is being done, the mobile node SHOULD need to immediately send Binding Updates to its BHR/TVR/NCR and correspondent node. 11.4 Sending Binding Updates to the Base Home Register After a mobile node has changed one of its addresses to a new co- located address, a mobile node MUST register this co-located address with its BHR. To do so, the mobile node SHOULD 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 that 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 from the BHR to return a Binding Acknowledgement in response to this Binding Update. As described in Section 5.2, the mobile node MUST retransmit this Binding Update to its BHR until it receives a matching Binding Acknowledgement. Once reaching a retransmission timeout period of MAX_TIMEOUT, the mobile node SHOULD continue to periodically retransmit the Binding Update at this rate until acknowledged. 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. Chern Nam Yap Expires 10 July 2001 Page 36 Internet Draft Itinerant Internet Protocol 10 January 2000 11.5 Sending Binding Updates to the Temporary Visit Register After a mobile node has changed one of its addresses to a new co- located address, a mobile node MUST register this co-located address with its TVR. To do so, the mobile node SHOULD send a Binding Update packet to its OLD link TVR and the packet constructed as follows: - The Visit Registration (V) 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. 11.6 Sending Binding Updates to the Near Correspondent Register After a mobile node has changed one of its addresses to a new co- located address, a mobile node MUST register this co-located address with its NCR. To do so, the mobile node SHOULD send a Binding Update packet to all its NCR and the packet constructed as follows: - The Near Registration (N) 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 that contains 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. Chern Nam Yap Expires 10 July 2001 Page 37 Internet Draft Itinerant Internet Protocol 10 January 2000 11.7 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 SHOULD request 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. - The remaining lifetime of the binding is 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 SHOULD be updated to reflect the new Binding Update rather than creating a new Binding Update List entry. Chern Nam Yap Expires 10 July 2001 Page 38 Internet Draft Itinerant Internet Protocol 10 January 2000 Binding Updates that is sent to all its correspondent nodes has no requirement for acknowledgement. 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_TIMEOUT. 11.8 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_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_TIMEOUT. 11.9 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. Chern Nam Yap Expires 10 July 2001 Page 39 Internet Draft Itinerant Internet Protocol 10 January 2000 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 , the Lifetime value received in the Binding Acknowledgement was , and the current remaining lifetime of the Binding Update List entry is , then the new value for the remaining lifetime of the Binding Update List entry SHOULD be MAX((remain - (update - 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. - 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). 11.10 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. Chern Nam Yap Expires 10 July 2001 Page 40 Internet Draft Itinerant Internet Protocol 10 January 2000 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 Visit link. 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 [6] to its BHR/TVR. The mobile node tunnels [6] its multicast group membership control packets to its BHR/TVR, and the BHR/TVR forwards multicast packets down the tunnel [6] to the mobile node. Chern Nam Yap Expires 10 July 2001 Page 41 Internet Draft Itinerant Internet Protocol 10 January 2000 12. Protocol Constants INITIAL_TIMEOUT 1 second MAX_TIMEOUT 256 seconds Chern Nam Yap Expires 10 July 2001 Page 42 Internet Draft Itinerant Internet Protocol 10 January 2000 13. IANA Considerations This document defines three new types of UDP packets, which need to have assigned a port number (Section 4.1). Moreover each of which must be assigned an Option Type value: - The Binding Update packet, described in Section 4.1; - The Binding Acknowledgement packet, described in Section 4.2; - The Binding Request packet described in Section 4.3. Chern Nam Yap Expires 10 July 2001 Page 43 Internet Draft Itinerant Internet Protocol 10 January 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. [11] Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 1998. [12] Glenn McGregor. The PPP Internet Protocol Control Protocol (IPCP). RFC 1332, May 1992 [13] Charles Perkins, editor. IP mobility support for IPv6. Internet Draft version 12, April 2000. [14] Stewart, editor. Stream Control Transmission Protocol. Internet Draft version 13, July 2000. Chern Nam Yap Expires 10 July 2001 Page 44 Internet Draft Itinerant Internet Protocol 10 January 2000 Comments about this document SHOULD be discussed on the seamoby@egroups.com mailing list or Authors' Addresses Questions about this document can also be directed to the authors: Chern Nam Yap Centre for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mapping Street Sheffield S3 3JD Phone: +44 114 222 5182 Web: http://www.mobile1.net E-mail: cny@ieee.org