Network Working Group Zhegming Ma Internet Draft Qingyu Tan Intended status: Standards Track Zheng Xiang Expires: December 2008 Zhongshan University June 28, 2008 Mobility Support in IPv4/v6 draft-ma-mobility-support-ipv4-ipv6-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 obsoleted 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/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies a protocol named Mobile IPv4/v6, which allows mobile nodes to remain reachable while moving in IPv4/v6 mixed networks. A translation gateway called Mobile IPv4/v6 Translation Gateway (MIPv4/v6-TG) is introduced in this protocol. MIPv4/v6-TG is based on NAT-PT gateway and equipped with a newly introduced application level gateway called MIP-ALG. MIPv4/v6-TG is located between IPv4 network and IPv6 network. On IPv4 network side, Ma Expires December 28, 2008 [Page 1] Internet-Draft Mobility Support in IPv4/v6 June 2008 MIPv4/v6-TG acts as a Mobile IPv4 entity and interacts with other Mobile IPv4 entities under Mobile IPv4, while on IPv6 network side, it acts as a Mobile IPv6 entity and interacts with other Mobile IPv6 entities under Mobile IPv6. In MIPv4/v6-TG, Mobile IPv4 entities and Mobile IPv6 entities are translated with each other. In order to maintain each of Mobile IP sessions that pass through MIPv4/v6-TG, a data structure called Mobile IP Table is introduced. Table of Contents 1. Introduction...................................................3 2. Comparison with Mobile IP for IPv4 and IPv6....................5 3. Terminology....................................................6 3.1. General Terms.............................................6 3.2. Mobile IPv4/v6 Terms......................................7 4. Overview of Mobile IPv4/v6.....................................8 5. Extended Messages and New Messages............................10 5.1. Extended Registration Request Message....................11 5.2. Agent Request Message....................................13 5.3. Agent Reply message......................................14 6. Requirements for Types of Nodes...............................16 6.1. All IPv4 Nodes...........................................16 6.2. All IPv6 Nodes...........................................16 6.3. Mobile Nodes moving in IPv4/v6 mixed networks............16 6.4. MIPv4/v6 Translation Gateway.............................17 7. Mobile Nodes Operation........................................18 7.1. Overview.................................................18 7.2. Conceptual Data Structures...............................18 7.3. The Acquisition of Related Addresses.....................19 7.3.1. Acquiring Addresses of HA and CN through DNS Query..19 7.3.2. Acquiring Home Address..............................19 7.4. Movement Detection.......................................20 7.5. Supporting New Messages..................................20 8. MIPv4/v6-TG Operation.........................................21 8.1. Conceptual Data Structures...............................21 8.2. Intercepting Mechanisms of MIPv4/v6-TG...................22 8.3. Creating MIP Table Entries...............................23 8.3.1. Creating Entries triggered by Agent Request messages25 8.3.2. Creating Entries triggered by BU messages...........27 8.3.3. Creating Entries triggered by Extended Registration Request messages...........................................31 8.3.4. Creating Entries triggered by HoTI messages or CoTI messages...................................................34 8.4. The Usage of MIP Table...................................36 8.4.1. The usage of Type 1 MIP Table Entry.................36 8.4.2. The usage of Type 2 MIP Table Entry.................37 Ma Expires December 28, 2008 [Page 2] Internet-Draft Mobility Support in IPv4/v6 June 2008 8.4.3. The usage of Type 3 MIP Table Entry.................38 8.4.4. The usage of Type 4 MIP Table Entry.................38 8.4.5. The usage of Type 5 MIP Table Entry.................38 8.4.6. The usage of Type 6 MIP Table Entry.................39 8.5. The Update of MIP Table Entries..........................40 8.5.1. The Update of Type 1 MIP Table Entries..............40 8.5.2. The Update of Type 2 MIP Table Entries..............41 8.5.3. The Update of Type 3 MIP Table Entries..............42 8.5.4. The Update of Type 4 MIP Table Entries..............43 8.5.5. The Update of Type 5 MIP Table Entries..............44 8.5.6. The Update of Type 6 MIP Table Entries..............45 9. Protocol Constants............................................46 10. Security Considerations......................................46 10.1. Security policy for HA, MN and CN.......................46 10.2. Security Considerations for MIPv4/v6-TG.................46 11. IANA Considerations..........................................47 12. Normative References.........................................48 Authors' Addresses...............................................48 Intellectual Property Statement..................................49 Disclaimer of Validity...........................................49 1. Introduction This document specifies a protocol named Mobile IPv4/v6, which allows mobile nodes to remain reachable while moving in IPv4/v6 mixed networks. Mobile IP studies how to support mobile communications on the Internet. Specifically, Mobile IPv4 [1] studies how to support mobile communications on IPv4 network; Mobile IPv6 [2] studies how to support mobile communications on IPv6 network. Mobile IPv4/v6 studies how to support mobile communications on IPv4/v6 mixed networks. IETF has specified the latest versions of Mobile IPv4 and Mobile IPv6 in RFC3344 and RFC3775. But no RFC on Mobile IPv4/v6 has been published. This document provides a protocol on Mobile IPv4/v6. Mobile IP (Mobile IPv4/Mobile IPv6/Mobile IPv4/v6) defines three entities: mobile node (MN), home agent (HA) and correspondent node (CN). Among these three entities, HA and CN are usually considered as stationary nodes, while MN can move around from one link to another. In IPv4/v6 mixed networks, some entities may be located in IPv4 network, while other entities may be located in IPv6 network. In this circumstance, without additional mobility support, communications between the entities located in the different networks may not be available. Therefore, a new protocol on Mobile IPv4/v6 has to be introduced. Mobile IPv4/v6 studies how to maintain communications between MN and CN when MN moves in IPv4/v6 networks. According to the combination of Ma Expires December 28, 2008 [Page 3] Internet-Draft Mobility Support in IPv4/v6 June 2008 IP versions of networks where HA and CN are located, Mobile IPv4/v6 problems can be divided into the following four base problems: o HA and CN are located in IPv6 network, while MN moves between IPv4/v6 networks. o HA and CN are located in IPv4 network, while MN moves between IPv4/v6 networks. o HA is located in IPv6 network, CN is located in IPv4 network, while MN moves between IPv4/v6 networks. o HA is located in IPv4 network, CN is located in IPv6 network, while MN moves between IPv4/v6 networks. According to the movement of MN, each base problem can further be divided into four sub-problems: o MN moves within IPv6 network. o MN moves within IPv4 network. o MN moves from IPv6 network to IPv4 network. o MN moves from IPv4 network to IPv6 network. Mobile IPv4/v6 will provide detailed solutions to each of the above 16 sub-problems. In order to maintain mobile communications in IPv4/v6 networks, a translation gateway called Mobile IPv4/v6 Translation Gateway (MIPv4/v6-TG) is introduced in this protocol. MIPv4/v6-TG is based on NAT-PT [3][4] gateway and equipped with a newly introduced application level gateway called MIP-ALG. MIPv4/v6- TG is located between IPv4 network and IPv6 network, and functions as follows. o On IPv6 network side, MIPv4/v6-TG acts as one of the Mobile IPv6 entities (HAv6, MNv6 or CNv6) to interact with other MIPv6 entities inside the IPv6 network as specified in RFC3775. o On IPv4 network side, MIPv4/v6-TG acts as one of the Mobile IPv4 entities (HAv4, MNv4 or CNv4) to interact with other MIPv4 entities inside the IPv4 network as specified in RFC3344. o Inside MIPv4/v6-TG, the Mobile IP entities that MIPv4/v6-TG acts as are transformed from one to another, namely, from a MIPv4 entity to a MIPv6 entity or vice versa. Ma Expires December 28, 2008 [Page 4] Internet-Draft Mobility Support in IPv4/v6 June 2008 o MIPv4/v6-TG maintains a conceptual data structure called the Mobile IP Table (MIP Table). The function of MIP table is similar to that of NAT table on NAT-PT. Each entry of MIP table maintains a MIP session that passes through MIPv4/v6-TG. The contents recorded in a MIP table entry are the IP versions of HA, MN and CN, the bindings of home address and care-of address, entrances for the entry, and so on. It is based on the entry contents that MIPv4/v6-TG processes the messages and datagrams involved in the corresponding MIP session. 2. Comparison with Mobile IP for IPv4 and IPv6 Compared with Mobile IPv4 and Mobile IPv6, Mobile IPv4/v6 has the following major differences. o Mobile IPv4/v6 is designed for IPv4/v6 mixed networks, while Mobile IPv4 and Mobile IPv6 are designed for pure IPv4 network and pure IPv6 network, respectively. This makes these three protocols different from each other. o IPv4/v6 mixed network is a transition network from IPv4 to IPv6. Mobile IPv4/v6 is a transition protocol from Mobile IPv4 to Mobile IPv6, and should be able to work compatibly with both Mobile IPv4 and Mobile IPv6 to ensure a smooth transition process. In Mobile IPv4/v6, a translation gateway, called Mobile IPv4/v6 Translation Gateway and made up of NAT-PT and Mobile IP-ALG, is introduced to translate between Mobile IPv4 and Mobile IPv6. o Among the three Mobile IP entities (HA, MN and CN), HA and CN are usually considered as stationary nodes. In this protocol, if HA or CN is located in IPv4 network or IPv6 network, it can operate under Mobile IPv4 or Mobile IPv6, and needn't know whether MN is moving in IPv4 network or IPv6 network. If MN only moves within IPv4 network or IPv6 network, it can operate under Mobile IPv4 or Mobile IPv6, and needn't care whether HA and CN are located in IPv4 network or IPv6 network. If MN moves from IPv4 network to IPv6 network or from IPv6 network to IPv4 network, it should support extra functions introduced in Mobile IPv4/v6. Firstly, MN must be able to detect whether it is in IPv4 network or IPv6 network, and shift to Mobile IPv4 or Mobile IPv6 accordingly. Secondly, MN must keep in mind the domain names of HA and CN. When HA or CN is located in the network of IP version different from that of MN, the addresses acquired through DNS query are in fact the addresses of NAT-PT. Finally, when MN moves from IPv6 network to IPv4 network, it must support the following messages introduced in Mobile IPv4/v6: the extended Registration Request message, the Agent Request message and the Agent Reply message. Ma Expires December 28, 2008 [Page 5] Internet-Draft Mobility Support in IPv4/v6 June 2008 3. Terminology 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 BCP 14, RFC 2119 [5]. 3.1. General Terms IP: Internet Protocol IPv4: Internet Protocol Version 4 IPv6: Internet Protocol Version 6 MIP: Mobile IP MIPv4: Mobile IPv4 MIPv6: Mobile IPv6 Node: A device that implements IP (IPv4, IPv6 or both) Router: A node that forwards IP packets not explicitly addressed to itself. Link: 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: A node's attachment to a link. Packet: An IP header plus payload. Message: A kind of packet specially used in the registration process. MIPv4/v6 messages: The three messages newly introduced in this protocol. They are the extended Registration Request message, the Agent Request message and the Agent Reply message. Datagram: A kind of packet that carries data in the payload, used in the communication process. "#": A symbol that is attached after an IPv4 address to indicate that this is an IPv4 address from the NAT-PT address pool, which is used by the NAT-PT to map an IPv6 address. Ma Expires December 28, 2008 [Page 6] Internet-Draft Mobility Support in IPv4/v6 June 2008 "*": A symbol that is attached after an IPv6 address to indicate that this is an IPv6 address formed by adding a 96-bit NAT-PT prefix to an IPv4 address. "<-->": A symbol connecting two IP addresses, used in a binding or an address mapping. 3.2. Mobile IPv4/v6 Terms Home address (HoA): A unicast routable address assigned to a mobile node. This address is within the mobile node's home link. A mobile node with an IPv4 home agent is assigned an IPv4 home address, while a mobile node with an IPv6 home agent is assigned an IPv6 home address. Home subnet prefix: The IP subnet prefix corresponding to a mobile node's home address. Home link: The link on which a mobile node's home subnet prefix is defined. Mobile node (MN): A node that can change its point of attachment from one link to another within IPv4 network, IPv6 network, or between IPv4/v6 mixed networks, while still being reachable via its home address. Movement: A change in a mobile node's point of attachment to the Internet such that 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". Correspondent node (CN): A peer node with which a mobile node is communicating. The correspondent node may be attached to IPv4 network or IPv6 network, and it may be either mobile or stationary. Foreign subnet prefix: Any IP subnet prefix other than the mobile node's home subnet prefix. Foreign link: Any link other than the mobile node's home link. Care-of address (CoA): A unicast routable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Home agent: A router on a mobile node's home link with which the mobile node has registered its current care-of address. In this protocol, communication between mobile nodes and correspondent nodes Ma Expires December 28, 2008 [Page 7] Internet-Draft Mobility Support in IPv4/v6 June 2008 use "route optimization" mode. Therefore, packets do not have to pass through the home link. This reduce burden of the home link and home agent. HAA: Home Agent Address CNA: Correspondent Node Address Binding: The association of the home address of a mobile node with a care-of address for that mobile node, along with the remaining lifetime of that association. Registration: The process during which a mobile node informs its home agent or correspondent node of the new care-of address. MIP Table: A data structure maintained by MIPv4/v6-TG that is used to record some useful information for all the mobile IP communication. Each entry of the table corresponds to a communication process. There are in sum six different kinds of MIP entries. More information about MIP table is available in chapter 8. 4. Overview of Mobile IPv4/v6 Mobile IPv4/v6 is a protocol that supports mobile communications on IPv4/v6 mixed networks. There are mainly three mechanisms for the transition of IPv4 to IPv6: dual stacks, tunneling and NAT-PT. This protocol is based on NAT-PT. NAT-PT gateway is a network layer device that is located between the IPv4 network and IPv6 network, making the two networks transparent and independent to each other. Due to the differences between IPv4 and IPv6, the ways for them to support the same application, such as mobile communication, are also different. Therefore, an ALG (Application Level Gateway) is often added on the NAT-PT gateway to support an application on the IPv4/v6 mixed network. FTP-ALG and DNS-ALG are two famous examples. Motivated by the idea of ALG, Mobile IPv4/v6 specified in this document adds a MIP-ALG on NAT-PT gateway to support mobile communication on IPv4/v6 mixed network. Mobile IPv4/v6 uses a traditional NAT-PT and a MIP-ALG added on the NAT-PT to form a new device named MIPv4/v6-TG. On IPv6 network side, MIPv4/v6-TG acts as one of the Mobile IPv6 entities (HAv6, MNv6 or CNv6) to combine with other MIPv6 entities inside the IPv6 network to form a complete MIPv6 model described in RFC3775. In this way, inside the IPv6 network, the registration process and communication process can be performed as specified in RFC3775. Similarly, on IPv4 network side, MIPv4/v6-TG acts as one of the Mobile IPv4 entities (HAv4, MNv4 Ma Expires December 28, 2008 [Page 8] Internet-Draft Mobility Support in IPv4/v6 June 2008 or CNv4) to combine with other MIPv4 entities inside the IPv4 network to form a complete MIPv4 model described in RFC3344. In this way, inside the IPv4 network, the registration process and communication process can be performed as specified in RFC3344. Among the MIP entities, HA and CN are regarded as stationary nodes, (although CN may also change its location), while MN can move within the network with the same IP version or across the networks with different IP versions. The role that MIPv4/v6-TG acts varies with the location of HA, MN and CN. (1) HA and CN are located in IPv4 network, while MN moves within IPv4 network. In this scenario, on the IPv6 network side, MIPv4/v6-TG acts as MNv6 and communicates with CNv6 according to RFC3775. On the IPv4 network side, MIPv4/v6-TG acts as CNv4 to receive packets and as HAv4 to send packets through a tunnel according to RFC3344. (2) HA and CN are located in IPv4 network, while MN moves within IPv6 network. In this scenario, on IPv4 network side, MIPv4/v6-TG acts as MNv4 and communicate with HAv4 and CNv4 according to RFC3344. On IPv6 network side, MIPv4/v6-TG acts as CNv6 and communicates with MNv6 according to RFC3775. (3) HA is located in IPv6 network, CN is located in IPv4 network: o MN moves in IPv6 network. In this scenario, on IPv6 network side, MIPv4/v6-TG acts as CNv6 and communicates with MNv6 according to RFC3775. On IPv4 network side, MIPv4/v6-TG acts as HAv4 to receive packets from CNv4 and as MNv4 to send packets to CNv4 according to RFC3344. o MN moves in IPv4 network. In this scenario, on IPv4 network side, MIPv4/v6-TG acts as HAv4 and communicates with CNv4 and MNv4 according to RFC3344. (4)HA is located in IPv4 network, CN is located in IPv6 network. o MN moves in IPv4 network. In this scenario, on IPv4 network side, MIPv4/v6-TG acts as CNv4 and communicates with HAv4 and MNv4 according to RFC3344. On IPv6 network side, MIPv4/v6-TG acts as MNv6 and communicates with CNv6 according to RFC3775. o MN moves in IPv6 network. In this scenario, MNv6 and CNv6 can communicate directly with each other. In order to make HAv4 keep aware the location of MN, MIPv4/v6-TG must maintain the binding of HoA and CoA. Ma Expires December 28, 2008 [Page 9] Internet-Draft Mobility Support in IPv4/v6 June 2008 In order for MIPv4/v6-TG to maintain every communication process that goes through MIPv4/v6-TG, this protocol introduces a data structure called MIP table. The features and functions of MIP table are as follows: (1) MIP table is maintained by MIP-ALG and is used together with NAT table, which is maintained by NAT-PT. (2) There are totally six types of table entries in the MIP table, each of which corresponds with a combination of locations of HA, MN and CN. (3) Each entry of the MIP table maintains a communication process that goes through MIPv4/v6-TG. MIP-ALG handles MIP-related messages and datagrams based on the information recorded in the entry. (4) Each entry has four entrances through which the entry can be accessed. They are the IPv6 message entrance, the IPv6 datagram entrance, the IPv4 message entrance and the IPv4 datagram entrance. The IPv6 message entrance is set to IPv6 home address, the IPv6 datagram entrance is set to the destination address of the coming datagrams, and the IPv4 message entrance and datagram entrance are set to the destination addresses of the coming messages and datagrams, respectively. (5) When MIPv4/v6-TG intercepts a packet, it first judges whether it is a MIP message. If it is a MIP message, MIPv4/v6-TG will further judge whether it is an extended Registration Request message or an agent request message introduced in the protocol. If it is, a new entry is created. If not, MIPv4/v6-TG will lookup the IPv4 or IPv6 message entrances. If no entry matches the message, a new entry is created. (6) If MIPv4/v6-TG judges that the packet is not a message, it will lookup the IPv4 or IPv6 datagram entrances, using the destination address of the packet. If no entry matches the packet, MIPv4/v6-TG will judge that the packet has nothing to do with Mobile IP and will not deliver it to MIP-ALG for further disposal. 5. Extended Messages and New Messages In this protocol, MIPv4 and MIPv6 are reused respectively in IPv4 network and IPv6 network. On IPv6 network side, all MIPv6 messages are reused without any change. On IPv4 network side, MIPv4 messages are reused without any change, except for two circumstances. When HA is located in IPv6 network while MN moves from IPv6 network into IPv4 network, Registration Request message is extended. When HA is located Ma Expires December 28, 2008 [Page 10] Internet-Draft Mobility Support in IPv4/v6 June 2008 in IPv4 network, CN is located in IPv6 network, while MN moves from IPv6 network into IPv4 network, two new messages called Agent Request/Reply message are introduced. 5.1. Extended Registration Request Message The Extended Registration Request message is used in two scenarios. One is HA and CN are located in IPv6 network, while MN moves from IPv6 network to IPv4 network and performs the first registration process. The other is HA is located in IPv6 network, CN is located in IPv4 network, while MN moves from IPv6 network to IPv4 network and performs the first registration process. In both scenarios, the registration needs some additional information that the original Registration Request message does not supply. This additional information should be carried in the extended Registration Request message. Note that the extended message is used only in the first registration process. After that, the original message is used. IP fields: Source Address is the interface address from which the message is sent. Typically, it is the new Care-of Address (CoAv4) that MN wants to register with HA. CoAv4 will be changed to CoAv6* by adding a 96- bit NAT-PT prefix to CoAv4 when the message passes MIPv4/v6-TG. Destination Address is the IP address of the HA (HAAv4#). HAAv4# is acquired through DNS query. It is in fact an IPv4 address from the NAT-PT address pool. Messages or datagrams with such kind of address as the destination address will be routed to the NAT-PT gateway. When passing through MIPv4/v6-TG, HAAv4# will be changed to HAAv6 by searching the NAT table. UDP fields: Source Port: variable Destination Port: 434 The UDP header is followed by the Mobile IP fields shown below: Ma Expires December 28, 2008 [Page 11] Internet-Draft Mobility Support in IPv4/v6 June 2008 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 |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address: 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent: HAAv4# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address: CoAv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension: CNAv4(#) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension: HoAv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Extensions ... +-+-+-+-+-+-+-+-+-+-+- Type: 4. S, B, D, M, G, r, T, x, and Lifetime: the meanings of these fields are the same with those of the original Registration Request message. Home Address: By the time when MN sends this message, it only knows its IPv6 home address and has no idea about the IPv4 home address. Hence, this field is set to 0. Home Agent Address: the IPv4 Home Agent Address HAAv4#. It is the same with the destination address of the message. Care-of Address: the IPv4 care-of address CoAv4#. It is the same with the source address of the message. Identification: A 64-bit number, constructed by MN, used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages, as defined in MIPv4. Extensions: CNAv4/CNAv4# and HoAv6. CNAv4/CNAv4# is the IPv4 address of CN. It is acquired through DNS query. MIPv4/v6-TG can use this address to decide whether CN is in IPv4 network or IPv6 network. If the address is from the NAT-PT Ma Expires December 28, 2008 [Page 12] Internet-Draft Mobility Support in IPv4/v6 June 2008 address pool, it means that CN is in IPv6 network. Otherwise, CN is in IPv4 network. HoAv6 is the IPv6 home address of MN. Here it is used as an identification of MN. After the extended Registration Request message is translated into a BU message, HoAv6 is carried in the BU message so that HAv6 knows which MN is sending the message. Other Extensions: The fixed portion of the extended Registration Request is followed by one or more of the extensions, as defined in MIPv4. 5.2. Agent Request Message The Agent Request message is used in the scenario where HA is located in IPv4 network, CN is located in IPv6 network, while MN moves from IPv6 network to IPv4 network and performs the first registration process. When MN is still in IPv6 network and communicating with CN, CN keeps the cached binding of HoAv6 and CoAv6. After MN moves from IPv6 network to IPv4 network, in addition to Registration Request message sent to HAv4, MN has to send an Agent Request message to MIPv4/v6-TG, requesting MIPv4/v6-TG to update the binding cache on CN so that CN can send the packets to the right place. The format of Agent Request message is the same with that of the Registration Request message except for a different Type value. IP fields: Source Address: CoAv4, the new care-of address MN has just acquired in IPv4 network. Destination Address: CNAv4#. This address is acquired through DNS query. It is in fact an IPv4 address from the NAT-PT address pool. Messages or datagrams with such kind of address as the destination address will be routed to the NAT-PT gateway. UDP fields: Source Port: variable Destination Port: 434 The UDP header is followed by the Mobile IP fields shown below: Ma Expires December 28, 2008 [Page 13] Internet-Draft Mobility Support in IPv4/v6 June 2008 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 |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address: HoAv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent: HAAv4# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address: CoAv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Extensions... +-+-+-+-+-+-+-+-+-+-+- Type: 5. S, B, D, M, G, r, T, x, Lifetime and Identification: the meanings of these fields are the same with those of the original Registration Request message. Home Address: HoAv4. Home Agent Address: HAAv4. Care-of Address: the new IPv4 care-of address that MN wants to register with CN. In MIPv4/v6-TG, this address will be changed to IPv6 form by adding a 96-bit NAT-PT prefix. 5.3. Agent Reply message Agent Reply message is a message sent by MIPv4/v6-TG as a reply to the Agent Request message. It informs MN of the result of the update procedure with CN. The format of Agent Reply message is the same with that of Registration Reply message, as shown below. Ma Expires December 28, 2008 [Page 14] Internet-Draft Mobility Support in IPv4/v6 June 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address: HoAv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent: HAAv4# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+- IP fields: Source Address: CNAv4#. This address can be copied directly from the destination address field of the Agent Request message. Destination Address: CoAv4. This address can be copied directly from the source address field of the Agent Request message. UDP fields: Source Port: 434, copied from the destination port of the Agent Request message. Destination Port: variable, copied from the source port of the Agent Request message. Type: 6. Code: indicates the result of the update procedure. So far only two possible results are defined: 0: unfinished. This means that the procedure is not completed. MN should try again later or try other means. 1: finished. This means that the procedure is completed. And the Lifetime field indicates the lifetime of the new binding. Lifetime: The number of seconds remaining before the binding is considered expired. A value of zero indicates a request for deregistration. A value of 0xffff indicates infinity. Ma Expires December 28, 2008 [Page 15] Internet-Draft Mobility Support in IPv4/v6 June 2008 Home Address: HoAv4, copied from the Agent Request message. Home Agent Address: HAAv4, copied from the Agent Request message. Identification: it is the same with that of the Registration Reply message. 6. Requirements for Types of Nodes 6.1. All IPv4 Nodes Any IPv4 node may be a correspondent node of a mobile node, no matter whether the mobile node is in IPv4 network or IPv6 network. When an IPv4 node acts as a correspondent node, it only needs to meet the requirements described in MIPv4. The protocol presented in this document places no additional requirements on such kind of nodes. This protocol also places no additional requirements on nodes that act as home agents. But when an IPv4 node acts as a mobile node, it needs extending with some new features. This will be discussed later in chapter 7. 6.2. All IPv6 Nodes In MIPv6, communication between a mobile node and a correspondent node may use two possible modes: bidirectional tunneling and route optimization. This protocol suggests that in IPv6 network, route optimization be chosen. Here, "in IPv6 network" refers not only to the scenario where both MN and CN are located in IPv6 network, but also to the scenarios where only MN or CN is located in IPv6 network. Therefore, for any IPv6 node that acts as a correspondent node, it must support route optimization. This implies that when MN changes its location and gets a new care-of address, it must update the binding cache on the correspondent node by some means. Specifically, if MN is also in IPv6 network, MN will itself perform correspondent registration. If MN is in IPv4 network, MIPv4/v6-TG will do the job on behalf of MN. When an IPv6 node acts as home agent, it only needs to meet the requirements described in MIPv6. This protocol places no additional requirements on such kind of nodes. 6.3. Mobile Nodes moving in IPv4/v6 mixed networks Mobile nodes moving in IPv4/v6 mixed networks must meet the following requirements. Ma Expires December 28, 2008 [Page 16] Internet-Draft Mobility Support in IPv4/v6 June 2008 (1) Mobile nodes should support both MIPv4 and MIPv6. They must be able to detect whether they are in IPv4 network or IPv6 network and work under MIPv4 or MIPv6 accordingly. (2) Mobile nodes must support DNS. They should know the domain names of the home agents and the correspondent nodes. When HA or CN is located in a network whose version is different from that of MN, it is through DNS query that MN discovers a suitable MIPv4/v6-TG located between MN and HA or CN. MIPv4/v6-TG will return an IPv4 address from NAT-PT address pool, or an IPv6 address with 96-bit NAT-PT prefix. MN uses the returned address to communicate with HA or CN. MN may periodically perform DNS query to discover a more suitable MIPv4/v6- TG. (3) Mobile nodes must support the MIPv4/v6 messages introduced in this protocol, including: o Mobile Nodes must support the extended Registration Request message. The extended Registration Request message carries some information about MIPv4/v6, and is used in some special circumstances. More detail is available in section 5.1. Mobile nodes should know when and how to use this message. o Mobile Nodes must support the Agent Request message. Agent Request message is one that has a similar format with the Registration Request message. Mobile Nodes use this message to request MIPv4/v6-TG to inform CN of new care-of addresses. More detail is available in section 5.2. Mobile nodes should know when and how to use this message. o Mobile Nodes must support the Agent Reply message. Agent Reply message is a reply sent by MIPv4/v6-TG to inform the MN of the update result. More detail is available in section 5.3. Mobile nodes should know when and how to use this message. 6.4. MIPv4/v6 Translation Gateway MIPv4/v6-TG is made up of NAT-PT and MIP-ALG. MIPv4/v6-TG plays a crucial role in MIPv4/v6. It must meet the following requirements. (1) MIPv4/v6-TG must support all the functionalities of MIPv4 and MIPv6 entities. That is to say, MIPv4/v6-TG will act as a MIPv4 entity on IPv4 network side and as a MIPv6 entity on IPv6 network. (2) MIPv4/v6-TG should have an efficient mechanism to intercept MIP- related messages and datagrams and process them correctly. Ma Expires December 28, 2008 [Page 17] Internet-Draft Mobility Support in IPv4/v6 June 2008 (3) NAT-PT is a fundamental function of MIPv4/v6-TG, and is responsible for address translation and protocol translation between IPv4 and IPv6. In this protocol, NAT-PT must be equipped with DNS-ALG. (4) MIP-ALG maintains a MIP table, a conceptual data structure newly introduced in this protocol. Each entry of MIP table records necessary information for each MIP session that passes through MIPv4/v6-TG. It is based on the information contained in the MIP table that MIP-ALG knows how to process MIP messages and datagrams. 7. Mobile Nodes Operation 7.1. Overview MN moving in IPv4/v6 mixed network must support both MIPv4 and MIPv6. When MN moves within IPv4 network, its operations comply with MIPv4. When MN moves within IPv6 network, its operations comply with MIPv6. Besides, MN must possess the following abilities. o When MN moves from IPv4 network to IPv6 network or from IPv6 network to IPv4 network, it must be able to detect the change of IP versions of the network. o If the IP version of the network in which HA or CN is located is different from that of MN, MN must keep in mind the domain names of HA or CN, and look for an available MIPv4/v6-TG by DNS query. MN communicates with HA or CN through the MIPv4/v6-TG. o When MN moves from IPv6 network to IPv4 network, MN must be able to support the extended Registration Request message, Agent Request message and Agent Reply message newly introduced in this protocol. This chapter will describe the newly introduced abilities of MN in details. Those abilities of MN described in MIPv4 and MIPv6 will be not repeated. 7.2. Conceptual Data Structures In this protocol, when MN moves from IPv4 network to IPv6 network or from IPv6 network to IPv4 network, it should support the extended Registration Request message, Agent Request message and Registration Reply message. Besides the conceptual data structures mentioned in MIPv4 and MIPv6, new conceptual data structures must be introduced for MN to keep in mind the necessary state information of these three messages. Ma Expires December 28, 2008 [Page 18] Internet-Draft Mobility Support in IPv4/v6 June 2008 7.3. The Acquisition of Related Addresses If the IP version of network in which HA or CN is located is different from that of MN, MN must find a MIPv4/v6-TG through which MN can communicate with HA or CN. MIPv4/v6-TG will give MN an IP address. Packets with this IP address as destination address will be routed to MIPv4/v6-TG, and translated and delivered to HA or CN. In addition, if MN and HA are located in the networks of different IP versions, the home address will be not routable in the network in which MN is located. In this circumstance, MN must acquire an IP address from MIPv4/v6-TG to substitute for the home address. 7.3.1. Acquiring Addresses of HA and CN through DNS Query In this protocol, MN is required to know the domain names of HA and CN. DNS query is not only used to get the IP address of HA or CN, but, more importantly, used to find an available MIPv4/v6-TG when MN and HA or CN are located in the networks of different IP versions. When HA is located in IPv6 network and MN is located in IPv4 network, MN can acquire the home agent address of IPv4 version through DNS query. According to RFC2766, NAT-PT will take out an IPv4 address HAAv4# from its address pool and create a mapping of HAAv6<-->HAAv4# in its NAT table. When CN is located in IPv6 network and MN is located in IPv4 network, CNAv4# can be acquired in the same way. When HA is located in IPv4 network and MN is located in IPv6 network, MN can acquire the home agent address of IPv6 version through DNS query. According to RFC2766, NAT-PT will add a 96-bit NAT-PT prefix to HAAv4 to form HAAv6*. When CN is located in IPv4 network and MN is located in IPv6 network, CNAv6* can be acquired in the same way. 7.3.2. Acquiring Home Address The IP version of MN home address is the same with that of home link. When MN moves to a network whose IP version is different from that of home link, its home address is not usable. Under this circumstance, MN must find a way to acquire an IP address used as its home address in the network. If HA is located in IPv4 network and MN moves from IPv4 network to IPv6 network, MN home address HoAv4 is not usable in the IPv6 network. Under this circumstance, MN will add a 96-bit NAT-PT prefix to HoAv4 to form an IPv6 home address HoAv6*. The 96-bit NAT-PT prefix is taken from HAAv6*, which can be acquired by DNS query as described in 7.3.1. Ma Expires December 28, 2008 [Page 19] Internet-Draft Mobility Support in IPv4/v6 June 2008 If HA is located in IPv6 network and MN moves from IPv6 network to IPv4 network, MN home address HoAv6 is not usable in the IPv4 network. Under this circumstance, MN will send to MIPv4/v6-TG an extended Registration Request message, rather than a conventional Registration Request message. In the extended Registration Request message, the home address field is set to 0, and the extended home address field is set to HoAv6. MIPv4/v6-TG will take an IPv4 address from NAT-PT address pool as MN home address HoAv4#. HoAv4# will be sent to MN in a Registration Reply message. 7.4. Movement Detection MN can judge whether it has moved to a new link by comparing the subnet prefix in the Router Advertisements with the prefix of its current care-of address. As a dual stack node, MN can judge whether it is located in IPv4 network or IPv6 network by Router Advertisements. MN records the Lifetime taken from Agent Advertisements. When the Lifetime nearly expires, MN will send an Agent Solicitation message. If MN is not sure whether it is located in IPv4 network or IPv6 network, it can send both IPv4 and IPv6 Agent Solicitation messages. If MN receives an IPv6 reply, it knows that it is now in IPv6 network. If MN receives an IPv4 reply, it knows that it is now in IPv4 network. 7.5. Supporting New Messages In addition to MIPv4 and MIPv6 messages described in MIPv4 and MIPv6, this protocol introduces three new messages for MIPv4/v6. If HA is located in IPv6 network and MN moves from IPv6 network to IPv4 network, MN acquires HAAv4# and CNAv4/CNAv4# by DNS query. MN generates an extended Registration Request message, in which the destination address is set to HAAv4#, the home address field is set to 0, the extended home address field is set to HoAv6, and the extended correspondent node address is set to CNAv4/CNAv4#. If HA is located in IPv4 network, CN is located in IPv6 network, and MN moves from IPv6 network to IPv4 network, MN acquires CNAv4# by DNS query. MN generates an Agent Request message, in which the destination address is set to CNAv4#, the home address field is set to HoAv4, the home agent address field is set to HAAv4, and the care- of address field is set to CoAv4. On receiving this Agent Request message, MIPv4/v6-TG will update the binding cache on CNv6 on behalf of MNv4, and return to MNv4 an Agent Reply message. Ma Expires December 28, 2008 [Page 20] Internet-Draft Mobility Support in IPv4/v6 June 2008 8. MIPv4/v6-TG Operation 8.1. Conceptual Data Structures MIP table is a conceptual data structure newly introduced in this protocol. MIP table records the information for each MIP session that passes through MIPv4/v6-TG, such as the IP versions of HA, MN and CN, the bindings of home address and care-of address, entrances for MIP table entries, and so on. The function of MIP table is similar to that of NAT table on NAT-PT. When a MIP packet passes through MIPv4/v6-TG, MIPv4/v6-TG will lookup the MIP table for a corresponding entry and use the information recorded in the entry to process the packet. The creation of MIP table entry is triggered by some special MIP messages. On IPv4 network side, only Extended Registration Request messages and Agent Request messages can make MIPv4/v6-TG create new MIP table entries. On IPv6 network side, those MIP messages for which no matching entries can be found will make MIPv4/v6-TG create new MIP table entries. Each entry should contain the following fields. o The IP versions of HA, MN and CN. The role that MIPv4/v6-TG plays is determined by the combination of IP versions of the three MIP entities. When a MIP datagram is intercepted, MIPv4/v6-TG lookups the MIP table for the corresponding entry, and in this way, learns the IP versions of three MIP entities. Then MIPv4/v6-TG knows how to process the datagram. o Bindings of home address and care-of address. The bindings of home address and care-of address make possible the transparent routing of packets in MIP communications. The bindings in a particular table entry may be of IPv4 form or IPv6 form. Some of the entries may have IPv4 bindings and IPv6 bindings at the same time. This depends on the combination of IP versions of HA, MN and CN. o Entry entrances. Entry entrances are fields that are particularly set for entry lookup. Packets that MIPv4/v6-TG intercepts may come from IPv4 network or IPv6 network. Therefore, MIP table should support bi-directional lookup. Moreover, the intercepted MIP packets may be messages or datagrams. Therefore, MIP table should further support message and datagram lookup, respectively. In this protocol, four entrances are defined: the IPv6 message entrance, the IPv6 datagram entrance, the IPv4 message entrance and the IPv4 datagram entrance. The IPv6 message entrance is set to IPv6 home address, the IPv6 datagram entrance is set to the destination address of the coming datagrams, and the IPv4 message entrance and datagram entrance are set to the destination addresses of the coming messages and datagrams, respectively. Ma Expires December 28, 2008 [Page 21] Internet-Draft Mobility Support in IPv4/v6 June 2008 o Lifetime of the entry. Lifetime is a positive number indicating how many seconds before the entry is considered expired. This number is set to the minimal one of the lifetimes of the existing bindings. Lifetime can be updated through registration processes. Since MN also knows the value of lifetime, when the lifetime is nearly expired, MN may perform a registration process in order to update the lifetime. If the lifetime becomes zero, MIPv4/v6-TG will delete this entry. o State of the entry. There are two possible states for each entry: finished and unfinished. An unfinished state indicates that the entry is now being created or updated. Entries with an unfinished state can not be used by the MIPv4/v6-TG as a guide to process the packets. 8.2. Intercepting Mechanisms of MIPv4/v6-TG MIPv4/v6-TG is made up of a NAT-PT and a MIP-ALG. Not all coming packets are MIP-related. Therefore, MIPv4/v6-TG should develop a effective mechanism to intercept MIP-related packets and deliver them to MIP-ALG for further processing. In this protocol, MIPv4/v6-TG uses the following rules to intercept MIP-related packets. (1) MIPv4/v6-TG intercepts MIP-related messages based on message types. o On IPv4 network side, MIPv4/v6-TG needs to process four kinds of MIP messages: Registration Request message, Registration Reply message, extended Registration Request message, Agent Request message and Agent Reply message. The first two messages are specified in RFC3344 while the others are newly introduced in this protocol. The registration request message, extended registration request message, and agent request message are all sent through UDP destination port 434. The registration reply message and agent reply message are both sent through UDP source port 434. MIPv4/v6- TG uses these features to distinguish them from other messages. Furthermore, these five MIP-related messages have different type values, and can be distinguished from one another by these type values. The Type values of the Registration Request message and Registration Reply message are 1 and 3, respectively. For extended Registration Request message, Agent Request message and Agent Reply message, 5, 6 and 7 are used, respectively. Ma Expires December 28, 2008 [Page 22] Internet-Draft Mobility Support in IPv4/v6 June 2008 o On IPv6 side, MIPv4/v6-TG needs to process six kinds of messages: HoTI, CoTI, HoT, CoT, BU and BA. These messages contain a mobility header identified by a Payload Proto number 135, and can be distinguished by this feature from other messages. Furthermore, MIP-ALG uses the MH type value in the mobility header to distinguish from one another. For HoTI, CoTI, HoT, CoT, BU and BA, the MH type values are 1, 2, 3, 4, 5 and 6, respectively. (2) MIPv4/v6-TG intercepts MIP-related datagrams by checking their destination addresses. When MIPv4/v6-TG receives a packet, it will check if it is a MIP-related message, using the method described in (1). If it is not a MIP-related message, MIPv4/v6-TG takes out its destination address and compares it with the datagram entrance of the existing entries. If the datagram entrance of any entry equals to the destination address, it means that this is a MIP-related datagram. MIPv4/v6-TG will then deliver it to MIP-ALG for further processing, based on the information recorded in that entry. 8.3. Creating MIP Table Entries In this protocol, there are four kinds of messages that can trigger the creation of new MIP table entries. They are: the extended Registration Request message, Agent Request message, BU, and HoTI or CoTI. There are six kinds of entries in MIP table, each of which corresponds with one possible combination of IP versions of HA, MN and CN. Note that in the scenarios where HA, MN and CN are all located in IPv4 network or IPv6 network, MIPv4/v6-TG needn't participate in MIP registration and communication processes. Therefore, no MIP table entry is needed to be created for such scenarios. An MIP table entry should, typically, have the following fields. Type: A three-bit field indicating the IP versions of HA, MN and CN respectively. For each bit, a value of 1 indicates the MIP entity is located in IPv6 network, while a value of 0 indicates the MIP entity is located in IPv4 network. Type value varies from 001 to 110. 000 and 111 indicate that HA, MN and CN are all located in IPv4 network and IPv6 network, respectively, and do not need to be considered. MIPv6 message entrance: A 128-bit field through which a particular MIP table entry can be found and accessed when a MIPv6 message is intercepted by MIPv4/v6-TG. Usually, this field is set to the IPv6 home address. All MIPv6 messages contain IPv6 home addresses. When a MIPv6 message is intercepted by MIPv4/v6-TG, MIPv4/v6-TG takes out the IPv6 home address from the intercepted message and uses it as an index to search the MIP table. In this process, MIPv4/v6-TG compares Ma Expires December 28, 2008 [Page 23] Internet-Draft Mobility Support in IPv4/v6 June 2008 the IPv6 message entrance field of each entry with the IPv6 home address. If an entry is found, MIPv4/v6-TG will use the information recorded in the entry to process the intercepted message. If no entry is found, MIPv4/v6-TG will create a new entry. MIPv6 datagram entrance: A 128-bit field through which a particular entry can be found and accessed when a MIPv6 datagram is intercepted by MIPv4/v6-TG. If an intercepted packet is not a MIPv6 message, MIPv4/v6-TG will take out its destination address and use the address as an index to search the MIP table. In this process, MIPv4/v6-TG compares the IPv6 datagram entrance filed of each entry with the address. If an entry is found, the intercepted packet is a MIPv6 datagram, and will be processed based on the information recorded in the entry. If no entry is found, the intercepted packet is not a MIPv6 datagram. MIPv4 message entrance: A 32-bit field through which a particular entry can be found and accessed when a MIPv4 message is intercepted by MIPv4/v6-TG. On intercepting a MIPv4 message, MIPv4/v6-TG takes out its destination address and uses the address as an index to search for the corresponding MIP table entry. It is based on the MIP table entry that MIPv4/v6-TG processes the intercepted MIPv4 message. MIPv4 datagram entrance: A 32-bit field through which a particular entry can be found and accessed when a MIPv4 datagram is intercepted by MIPv4/v6-TG. If an intercepted packet is not a MIPv4 message, MIPv4/v6-TG will take out its destination address and use the address as an index to search the MIP table. In this process, MIPv4/v6-TG compares the IPv4 datagram entrance filed of each entry with the address. If an entry is found, the intercepted packet is a MIPv4 datagram, and will be processed based on the information recorded in the entry. If no entry is found, the intercepted packet is not a MIPv4 datagram. Cached bindings: Bindings of home address and care-of address that are used by MIPv4/v6-TG when it acts as a particular MIP entity. Bindings may be of IPv4 form or of IPv6 form. Entries may have no binding, one binding, or two bindings. This depends on the types of the entries. Source port: A 16-bit field that records the source port value of Registration Request message, extended Registration Request message, or Agent Request message. All of these three messages are sent through UDP ports. When MIPv4/v6-TG intercepts such kind of message, it fills this field with the source port value. This field is used as the destination port when MIPv4/v6-TG sends back a reply later. Ma Expires December 28, 2008 [Page 24] Internet-Draft Mobility Support in IPv4/v6 June 2008 Destination port: A 16-bit field that records the destination port value of Registration Request message, extended Registration Request message, or Agent Request message. It will be uses as the source port when MIPv4/v6-TG sends back a reply later. State: A 1-bit field indicating whether the entry is finished or not. There are two possible states for each entry: 1 (finished) and 0 (unfinished). An unfinished state indicates that the entry is now being created or updated. Entries with an unfinished state can not be used by the MIPv4/v6-TG as a guide to process MIP datagrams. Lifetime: A 16-bit field indicating entry lifetime. The meaning of this field depends on the value of the State field. When the State is 0 (unfinished), Lifetime means the entry should be completed before the time expires. When the State is 1 (finished), Lifetime means the number of seconds left before the entry is considered expired. In either case, when this filed becomes 0, MIPv4/v6-TG will delete the entry. 8.3.1. Creating Entries triggered by Agent Request messages Agent Request message is a new message introduced in this protocol. Its format is available in section 5.2. In this protocol, Agent Request message is used only when HA is located in IPv4 network, CN is located in IPv6 network, and MN has just moved from IPv6 network to IPv4 network. Since the IP version of MN has changed from IPv6 to IPv4. The original entry becomes invalid and a new entry should be created. MIPv4/v6-TG takes the following steps to create a new entry. (1) MIPv4/v6-TG intercepts an Agent Request message and delivers it to MIP-ALG for further processing. Here, MIPv4/v6-TG uses the intercepting mechanism described above to intercept and recognize the Agent Request message. (2) On receiving the Agent Request message, MIP-ALG can infer that HA is located in IPv4 network, CN is located IPv6 network and MN has just moved from IPv6 network to IPv4 network, as only in this scenario can MIPv4/v6-TG receive an Agent Request message. Therefore, a new entry with the Type value 001 (binary) is created. MIP-ALG sets the field of MIPv6 Message Entrance to HoAv6*, MIPv6 Datagram Entrance to CoAv6*, MIPv4 Datagram Entrance to CNAv4#, Cached Bindings to HoAv6*<-->CoAv6*, Source Port and Destination Port to the source port number and destination port number of the Agent Request message respectively. HoAv6*, CoAv6* and HAAv6* can be Ma Expires December 28, 2008 [Page 25] Internet-Draft Mobility Support in IPv4/v6 June 2008 acquired by adding a 96-bit NAT-PT prefix to HoAv4, CoAv4, HAAv4, while CNAv6 can be acquired by checking the NAT table, using CNAv4# as the index. HoAv4, CoAv4, HAAv4 and CNAv4# are carried in the Agent Request message. MIP-ALG sets the fields of HoTI/HoT, CoTI/CoT and State to 0, and then sets the Lifetime to a value in which the creation of the entry must be accomplished. (3) MIP-ALG generates HoTI message and CoTI message. The source address and destination address of HoTI message are HoAv6* and CNAv6, respectively, while the source address and destination address of CoTI message are CoAv6* and CNAv6, respectively. Both of these messages will be routed to CNv6. (4) MIPv4/v6-TG intercepts HoT message and CoT message replied from CNv6, uses HoAv6* carried in these messages as an index to search MIP table, and finds this entry. (5) For HoT message, MIP-ALG sets the HoTI/HoT field of the entry to 1, while for CoT message, MIP-ALG sets the CoTI/CoT field of the entry to 1. When both HoTI/HoT field and CoTI/CoT field become 1, MIP-ALG will generate a BU message, with CoAv6* and CNAv6 as its source address and destination address, respectively. This BU message will be routed to CNv6. (6) MIPv4/v6-TG intercepts BA message replied from CNv6. Then, MIPv4/v6-TG uses HoAv6* carried in the message as an index to search MIP table and finds this entry. (7) MIP-ALG generates an Agent Reply message with CNAv4# and CoAv4 as its source address and destination address, respectively. This message is sent through UDP. The source port and destination port are copied from the fields of Destination Port and Source Port, respectively. This Agent Reply message will be routed to MNv4. (8) MIP-ALG sets the State of the entry to 1 (finished), and sets the Lifetime of the entry to the lifetime of the binding cache. When the creation of a Type 1 entry finishes, the value of each field is as follows. Type: 001. HA and MN are located in IPv4 network, CN is located in IPv6 network. On intercepting an Agent Request message, MIPv4/v6-TG knows the IP versions of HA, MN and CN. Ma Expires December 28, 2008 [Page 26] Internet-Draft Mobility Support in IPv4/v6 June 2008 MIPv6 Message Entrance: HoAv6*. HoAv6* is acquired by adding a 96-bit NAT-PT prefix to HoAv4, which is carried in the Agent Request message. MIPv6 Datagram Entrance: CoAv6*. CoAv6* is acquired by adding a 96- bit NAT-PT prefix to CoAv4, which is carried in the Agent Request message. MIPv4 Message Entrance: blank. Except for Agent Request message, MIPv4/v6-TG will not receive any other MIPv4 messages. MIPv4 Datagram Entrance: CNAv4#. CNAv4# is acquired from the destination address field of the Agent Request message. Cache Bindings: HoAv6*<-->CoAv6*. Both HoAv6* and CoAv6 can be acquired from the Agent Request message. HoTI/HoT: 1. HoTI/HoT has arrived. CoT/CoTI: 1. CoTI/CoT has arrived. Source Port: variable. The source port number of the Agent Request message, which is variable. Destination Port: 434. The destination port number of the Agent request message is 434. State: 1. Finished. Lifetime: set to the lifetime of the entry. 8.3.2. Creating Entries triggered by BU messages When MIPv4/v6-TG intercepts a BU message, it takes out HoAv6* from the message and uses it as an index to search the MIP table. If no matching entry is found, MIPv4/v6-TG will create a new entry, using the information carried in the BU message. If a matching entry is found, MIPv4/v6-TG will go further to see if the second bit of the Type is equal to 1 (i.e., MN is in IPv6 network). If so, MIP-ALG will just update the existing entry, without creating a new entry. Otherwise, MIP-ALG will create a new entry and the following steps will be performed. (1) On receiving the BU message, MIP-ALG can infer that HA is located in IPv4 network and MN is located in IPv6 network. However, MIP-ALG does not know the IP version of CN and needs other means to learn this information later. Ma Expires December 28, 2008 [Page 27] Internet-Draft Mobility Support in IPv4/v6 June 2008 MIP-ALG creates a new entry and sets the field of Cached Bindings to HoAv6*<-->CoAv6, MIPv6 Message Entrance to HoAv6*, MIPv4 Message Entrance to CoAv4#. CoAv4# is an IPv4 address taken from the NAT-PT address pool and mapped with CoAv6. The fields of HoTI/HoT, CoTI/CoT and State are all set to 0. Lifetime is set to a value in which the creation of the entry must be accomplished. (2) MIP-ALG translates the BU message into a Registration Request message with CoAv4# and HAAv4 as its source address and destination address, respectively. HoAv4 is carried in the new message. HAAv4 and HoAv4 are acquired from HAAv6* and HoAv6*, respectively. This Registration Request message will be routed to HAv4. (3) MIPv4/v6-TG intercepts the Registration Reply message replied from HAv4, takes out the destination address as an index to search the MIP table and finds this entry. (4) MIP-ALG translates the intercepted Registration Reply message into a BA message with HAAv6* and CoAv6 as its source address and destination address, respectively. HoAv6* is carried in the message. HAAv6* and HoAv6* are acquired by adding a 96-bit NAT-PT prefix to HAAv4 and HoAv4. CoAv6 is acquired by searching the NAT table, using CoAv4# as the index. HAAv4, HoAv4, and CoAv6 can be all acquired from the intercepted Registration Reply message. This BA message will be routed to MNv6. If CN is located in IPv4 network, the following steps will be performed: (1) MIPv4/v6-TG intercepts HoTI message or CoTI message, takes out HoAv6* from the intercepted message as an index to search the MIP table, and finds this entry. Note that HoTI arrives through tunneling. (2) MIP-ALG can judge the IP version of CN by the destination address of HoTI message or CoTI message. Then MIP-ALG sets the field of Type to 010, HoTI/HoT or CoTI/CoT to 1, and then generates HoT message or CoT message as a reply. Note that HoT is sent through tunneling. (3) MIPv4/v6-TG intercepts a BU message, takes out HoAv6* from the intercepted message as an index to search the MIP table and finds this entry. (4) MIP-ALG sets the field of MIPv4 Datagram Entrance to CoAv4#, and MIPv6 Datagram Entrance to CNAv6*. Then MIP-ALG generates a BA message, and its source address and destination address are copied directly from the destination address and source address fields of the BU message. The BA message will be routed to MNv6. Ma Expires December 28, 2008 [Page 28] Internet-Draft Mobility Support in IPv4/v6 June 2008 (5) MIP-ALG sets the State to 1, and then sets the Lifetime to the lifetime of the binding. If CN is located in IPv6 network, the following steps will be performed: (1) MIPv4/v6-TG intercepts HoTI message, takes out HoAv6* from the intercepted message as an index to search the MIP table and finds this entry. Note that HoTI arrives through tunneling. (2) MIP-ALG can judge the IP version of CN by the destination address of HoTI. MIP-ALG sets the field of Type to 011, and then sends HoTI to CNv6. (3) MIPv4/v6-TG intercepts HoT message replied from CNv6, takes out HoAv6* from the intercepted message as an index to search the MIP table and finds this entry. (4) MIP-ALG sets the HoTI/HoT field to 1, and then sends HoT to MNv6. Note that the HoT message is sent through tunneling. (5) MIP-ALG sets the State to 1, and then sets the Lifetime to the lifetime of the binding. When the creation of a Type 2 entry finishes, the value of each field is as follows. Type: 010. HA and CN are located in IPv4 network, MN is located in IPv6 network. On intercepting HoTI or CoTI, MIPv4/v6-TG can judge the IP versions of HA, MN and CN. MIPv6 Message Entrance: HoAv6*. HoAv6* is acquired from the BU message. MIPv6 Datagram Entrance: CNAv6*. CNAv6* is acquired from the destination address of the BU message. MIPv4 Message Entrance: CoAv4#. CoAv4# is a mapping of CoAv6 and can be acquired by searching the NAT table, using CoAv6 as the index. CoAv6 is acquired from the BU message sent to HA. If no mapping is found, MIP-ALG takes an IPv4 address from NAT-PT address pool and uses it as CoAv4#. Meanwhile, a binding of CoAv4# and CoAv6 will be recorded in NAT table. MIPv4 Datagram Entrance: CoAv4#. Ditto. The only difference is that CoAv6 is acquired from the source address of the BU message sent to CN. Ma Expires December 28, 2008 [Page 29] Internet-Draft Mobility Support in IPv4/v6 June 2008 Cache Bindings: HoAv6*<-->CoAv6. Both HoAv6* and CoAv6 are acquired from the BU message sent to CN. HoTI/HoT: 1. HoTI/HoT has arrived. CoT/CoTI: 1. CoTI/CoT has arrived. Source Port: variable. The source port number of the Registration Request message, which is variable. Destination Port: 434. The destination port number of the Registration request message is 434. State: 1. Finished. When the creation of a Type 3 entry finishes, the value of each field is as follows. Type: 011. HA is located in IPv4 network, MN and CN are located in IPv6 network. On Receiving HoTI message, the IP versions of HA, MN and CN can be inferred. MIPv6 Message Entrance: HoAv6*. HoAv6* is acquired from the BU message sent to HA. MIPv6 Datagram Entrance: blank. MIPv4 Message Entrance: CoAv4#. CoAv4# is a mapping of CoAv6 and can be acquired by searching the NAT table, using CoAv6 as the index. CoAv6 is acquired from the BU message sent to HA. If no mapping is found, MIP-ALG takes an IPv4 address from NAT-PT address pool and uses it as CoAv4#. Meanwhile, a binding of CoAv4# and CoAv6 will be recorded in NAT table. MIPv4 Datagram Entrance: blank. Cache Bindings: HoAv6*<-->CoAv6. Both HoAv6* and CoAv6 are acquired from the BU message sent to HAv6. HoTI/HoT: 1. HoTI/HoT has arrived. CoT/CoTI: 1. CoTI/CoT has arrived. Source Port: variable. The source port number of the Registration Request message, which is variable. Ma Expires December 28, 2008 [Page 30] Internet-Draft Mobility Support in IPv4/v6 June 2008 Destination Port: 434. The destination port number of the Registration request message is 434. State: 1. Finished. Lifetime: set to the lifetime of the entry. 8.3.3. Creating Entries triggered by Extended Registration Request messages The format of the Extended Registration Request message is available in section 5.1. In this protocol, MN sends the Extended Registration Request message only when it moves from IPv6 network to IPv4 network and performs the first registration. After MN's movement from IPv6 network to IPv4 network, the original entry becomes invalid. Therefore, a new entry should be created. (1) On receiving the Extended Registration Request message, MIP-ALG can learn the IP versions of the three entities: HA is in IPv6 network, MN is in IPv4 network. As for CN, if the IPv4 address of CN carried in the extension field of the message belongs to the NAT-PT address pool, the IP version of CN is IPv6. Otherwise, the IP version of CN is IPv4. MIP-ALG creates a new entry and sets the fields of Source Port and Destination Port to the source port number and destination port number of the intercepted message, respectively, the field of State to 0, and the field of Lifetime to a value in which the creation of the entry must be accomplished. o If CN is located in IPv4 network, MIP-ALG sets the field of Type to 100, MIPv6 Message Entrance to HoAv6, MIPv4 Message Entrance to HAAv4#, MIPv4 Datagram Entrance to HoAv4#, Cached Bindings to HoAv4#<-->CoAv4. o If CN is located in IPv6 network, MIP-ALG sets the field of Type to 101, MIPv6 Message Entrance to HoAv6, MIPv6 Datagram Entrance to CoAv6*, MIPv4 Message Entrance to HAAv4#, MIPv4 Datagram Entrance to CNAv4#, Cached Bindings to HoAv6<-->CoAv6* and HoAv4#<-->CoAv4, HoTI/HoT and CoTI/CoT to 0. (2) MIP-ALG generates a BU message with CoAv6* and HAAv6 as its source address and destination address, respectively. HoAv6 is carried in the message. Here, HAAv6 is acquired by checking the NAT table using HAAv4# as the index, while CoAv6* is acquired by adding a Ma Expires December 28, 2008 [Page 31] Internet-Draft Mobility Support in IPv4/v6 June 2008 96-bit NAT-PT prefix to CoAv4. Both HAAv4# and CoAv4 are taken from the Extended Registration Request message. This message will be routed to HAv6. (3) MIPv4/v6-TG intercepts the BA message replied from HAv6, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. If CN is located in IPv4 network, the following steps will be performed: (1) MIP-ALG generate Registration Reply message, with HAAv4# and CoAv4 as its source address and destination address, respectively. This message is sent through UDP, with the source port number and destination port number copied from the Destination Port field and Source Port field. This message will be routed to MNv4. (2) MIP-ALG sets the State field to 1, and sets the Lifetime field to the lifetime of the binding. If CN is located in IPv6 network, the following steps will be performed: (1) MIP-ALG generates a HoTI message and a CoTI message. The source address and destination address of HoTI are HoAv6 and CNAv6, respectively. The HoTI message is sent to HAv6 through reverse tunneling, and then sent to CNv6. The beginning point and endpoint of the tunnel are CoAv6* and HAAv6, respectively. The source address and destination of CoTI are CoAv6* and CNAv6. (2) MIPv4/v6-TG intercepts the HoT message or the CoT message, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. (3) MIP-ALG sets the HoTI/HoT field, or the CoTI/CoT field to 1, indicating the arrival of the HoT message or the CoT message. (4) When both HoTI/HoT and CoTI/CoT fields become 1, MIP-ALG generates a BU message, with CoAv6* and CNAv6 as its source address and destination address, respectively. HoAv6 is carried in the message. This message will be routed to CNv6. (5) MIPv4/v6-TG intercepts a BA message replied from CNv6, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. Ma Expires December 28, 2008 [Page 32] Internet-Draft Mobility Support in IPv4/v6 June 2008 (6) MIP-ALG generate Registration Reply message, with HAAv4# and CoAv4 as its source address and destination address, respectively. This message is sent through UDP, with the source port number and destination port number copied from the Destination Port field and Source Port field. This message will be routed to MNv4. (7) MIP-ALG sets the State field to 1, and sets the Lifetime field to the lifetime of the binding. When the creation of a Type 4 entry finishes, the value of each field is as follows. Type: 100. HA is located in IPv6 network, MN and CN are located in IPv4 network. MIPv6 Message Entrance: HoAv6. HoAv6 is acquired from the extension field of the Extended Registration Request message. MIPv6 Datagram Entrance: blank. MIPv4 Message Entrance: HAAv4#. HAAv4# is acquired from the destination address field of the Extended Registration Request message. MIPv4 Datagram Entrance: HoAv4#. HoAv4# is a mapping address of HoAv6 and can be acquired by searching the NAT table, using HoAv6 as the index. HoAv6 is acquired from the Extended Registration Request message. If no mapping is found, MIP-ALG takes an IPv4 address from NAT-PT address pool and uses it as HoAv4#. Meanwhile, a mapping of HoAv4# and HoAv6 will be recorded in NAT table. Cache Bindings: HoAv4#<-->CoAv4. CoAv4 is acquired from the source address field of the Extended Registration Request message. HoTI/HoT: 1. HoTI/HoT has arrived. CoT/CoTI: 1. CoTI/CoT has arrived. Source Port: variable. The source port number of the Extended Registration Request message, which is variable. Destination Port: 434. The destination port number of the Extended Registration Request message is 434. Lifetime: set to the lifetime of the entry. Ma Expires December 28, 2008 [Page 33] Internet-Draft Mobility Support in IPv4/v6 June 2008 When the creation of a Type 5 entry finishes, the value of each field is as follows. Type: 101. HA and CN are located in IPv6 network, MN is located in IPv4 network. MIPv6 Message Entrance: HoAv6. HoAv6 is acquired from the extension fields of extended Registration Request message. MIPv6 Datagram Entrance: CoAv6*. CoAv6* is acquired by adding a 96- bit NAT-PT prefix to CoAv4, which is acquired from the Extended Registration Request message. MIPv4 Message Entrance: HAAv4#. HAAv4# is acquired from the destination address field of the Extended Registration Request message. MIPv4 Datagram Entrance: CNAv4#. CNAv4# is acquired from the extension field of extended Registration Request message. Cache Bindings: HoAv4#<-->CoAv4, HoAv6<-->CoAv6*. HoAv4# is a mapping address of HoAv6 and can be acquired by searching the NAT table, using HoAv6 as the index. HoAv6 is acquired from the Extended Registration Request message. If no mapping is found, MIP-ALG takes an IPv4 address from NAT-PT address pool and uses it as HoAv4#. Meanwhile, a mapping of HoAv4# and HoAv6 will be recorded in NAT table. HoTI/HoT: 1. HoTI/HoT has arrived. CoT/CoTI: 1. CoTI/CoT has arrived. Source Port: variable. The source port number of the Extended Registration Request message, which is variable. Destination Port: 434. The destination port number of the Extended Registration Request message is 434. Lifetime: set to the lifetime of the entry. 8.3.4. Creating Entries triggered by HoTI messages or CoTI messages When MIPv4/v6-TG intercepts a HoTI message or CoTI message, it takes out HoAv6 from the message and uses it as an index to search the MIP table. MIPv4/v6-TG compares the MIPv6 Message Entrance with HoAv6. If no matching entry is found, MIPv4/v6-TG will create a new entry, using the information carried in the HoTI or CoTI message. If a Ma Expires December 28, 2008 [Page 34] Internet-Draft Mobility Support in IPv4/v6 June 2008 matching entry is found, MIPv4/v6-TG will go further to see if the second bit of the Type is equal to 1 (i.e., MN is in IPv6 network). If so, MIP-ALG will just update the existing entry, without creating a new entry. Otherwise, MIP-ALG will create a new entry and the following steps will be performed. (1) MIP-ALG infers that both HA and MN are located in IPv6 network and CN is located in IPv4 network, since only in this scenario can MIPv4/v6-TG receive a HoTI message or CoTI message without receiving BU from the same MN before. MIP-ALG sets the field of Type to 110, MIPv6 Message Entrance to HoAv6, MIPv6 Datagram Entrance to CNAv6*, MIPv4 Datagram Entrance to HoAv4#, State to 0, and Lifetime to a value in which the creation of this entry must be accomplished. (2) MIP-ALG generates a HoT message or CoT message. The HoT message is first sent to HAv6, then to MNv6 by HAv6 through tunneling. CoT message is sent directly to MNv6. (3) MIPv4/v6-TG intercepts the BU message, takes out HoAv6 and uses it as an index to search the MIP table, and finds this entry. (4) MIP-ALG sets the field of Cached Bindings to HoAv6<-->CoAv6, and then generates a BA message, with its source address and destination address copied directly from the destination address and source address of the BU message. The BA message will be routed to MNv6. (5) MIP-ALG sets the State field to 1, and then sets the Lifetime to the lifetime of the binding. When the creation of a Type 6 entry finishes, the value of each field is as follows. Type: 110. Both HA and MN are located in IPv6 network, and CN is located in IPv4 network. On receiving HoTI or CoTI, MIPv4/v6-TG can judge the versions of HA, MN and CN. MIPv6 Message Entrance: HoAv6. HoAv6 is acquired from the HoTI or CoTI message. MIPv6 Datagram Entrance: CNAv6*. CNAv6* is acquired from the destination address field of the HoTI message or CoTI message. MIPv4 Message Entrance: blank. Ma Expires December 28, 2008 [Page 35] Internet-Draft Mobility Support in IPv4/v6 June 2008 MIPv4 Datagram Entrance: HoAv4#. HoAv4# is a mapping address of HoAv6 and can be acquired by searching the NAT table, using HoAv6 as the index. HoAv6 is acquired from the HoTI message or CoTI message. If no mapping is found, MIP-ALG takes an IPv4 address from NAT-PT address pool and uses it as HoAv4#. Meanwhile, a mapping of HoAv4# and HoAv6 will be recorded in NAT table. Cache Bindings: HoAv6<-->CoAv6. Both HoAv6 and CoAv6 are acquired from the BU message sent to CN. HoTI/HoT: blank. CoT/CoTI: blank. Source Port: blank. Destination Port: blank. Lifetime: set to the lifetime of the entry. 8.4. The Usage of MIP Table The introduction of MIP table aims to maintain MIP sessions in IPv4/v6 mixed networks. When a datagram sent by MN or CN passes through MIPv4/v6-TG, MIPv4/v6-TG will take out the destination address of the datagram and uses it as an index to search the MIP table. If a matching entry is found, MIPv4/v6-TG will process the datagram, based on the information recorded in the entry. 8.4.1. The usage of Type 1 MIP Table Entry The contents of Type 1 entry are available in section 8.3.1. (1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG will take out its destination address and uses it as an index to search the MIP table. If a Type 1 entry is found, MIPv4/v6-TG will process the datagram as follows. o NAT-PT, a component of MIPv4/v6-TG, translates the datagram into IPv6 format. o MIP-ALG inserts a Destination Option extension header into the IPv6 datagram, and fills the header with the source address of the IPv6 datagram. Then MIP-ALG uses the source address as an index to search Cached Bindings field, and takes out the care-of address bound with the source address, and replaces the source address with the care-of address. Ma Expires December 28, 2008 [Page 36] Internet-Draft Mobility Support in IPv4/v6 June 2008 o MIPv4/v6-TG sends the processed IPv6 datagram. (2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG takes out its destination address and uses it as an index to search the MIP table. If a Type 1 entry is found, MIPv4/v6-TG will process the datagram as follows. o MIPv4/v6-TG replaces the destination address of the datagram with the IPv6 home address, which is taken from the type 2 routing header of the datagram. o NAT-PT translates the datagram into IPv4 format. o MIPv4/v6-TG sends the processed IPv4 datagram. 8.4.2. The usage of Type 2 MIP Table Entry The contents of Type 2 entry are available in section 8.3.2. (1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG will take out its destination address and uses it as an index to search the MIP table. If a Type 2 entry is found, MIPv4/v6-TG will process the datagram as follows. o MIP-ALG decapsulates the IPv4 datagram and gets the inner datagram. o NAT-PT translates the datagram into IPv6 format. o MIP-ALG inserts a type 2 routing header into the IPv6 datagram, and fills the header with the destination address of the IPv6 datagram. Then MIP-ALG uses the destination address as an index to search Cached Bindings field, and takes out the care-of address bound with the destination address, and replaces the destination address with the care-of address. o MIPv4/v6-TG sends the processed IPv6 datagram. (2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG takes out its destination address and uses it as an index to search the MIP table. If a Type 2 entry is found, MIPv4/v6-TG will process the datagram as follows. o MIPv4/v6-TG replaces the source address of the datagram with the IPv6 home address, which is taken from the Destination Option extension header of the datagram. o NAT-PT translates the datagram into IPv4 format. Ma Expires December 28, 2008 [Page 37] Internet-Draft Mobility Support in IPv4/v6 June 2008 o MIPv4/v6-TG sends the processed IPv4 datagram. 8.4.3. The usage of Type 3 MIP Table Entry A Type 3 entry corresponds to a scenario where both MN and CN are located in IPv6 network. In this scenario, MN and CN can communicate with each other without the participation of MIPv4/v6-TG. Therefore, Type 3 entries will not be used in the communication processes. 8.4.4. The usage of Type 4 MIP Table Entry The contents of Type 4 entry are available in section 8.3.3. When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG will take out its destination address and uses it as an index to search the MIP table. If a Type 4 entry is found, MIPv4/v6-TG will process the datagram as follows. o MIP-ALG encapsulates the datagram in a new IPv4 datagram. The source address of the outer IP header is copied from MIPv4 Message Entrance field. Then MIP-ALG uses the destination address of the inner IP header as an index to search Cached Bindings field, and takes out the care-of address bound with the destination address, and uses the care-of address as the destination address of the outer IP header. o MIPv4/v6-TG sends the processed IPv4 datagram. In the scenarios related to Type 4 entries, no MIPv6 datagrams will arrive at MIPv4/v6-TG. 8.4.5. The usage of Type 5 MIP Table Entry The contents of Type 5 entry are available in section 8.3.3. (1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG will take out its destination address and uses it as an index to search the MIP table. If a Type 5 entry is found, MIPv4/v6-TG will process the datagram as follows. o NAT-PT translates the datagram into IPv6 format. Ma Expires December 28, 2008 [Page 38] Internet-Draft Mobility Support in IPv4/v6 June 2008 o MIP-ALG inserts a Destination Option extension header into the IPv6 datagram, and fills the header with the source address of the IPv6 datagram. Then MIP-ALG uses the source address as an index to search Cached Bindings field, and takes out the care-of address bound with the source address, and replaces the source address with the care-of address. o MIPv4/v6-TG sends the processed IPv6 datagram. (2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG takes out its destination address and uses it as an index to search the MIP table. If a Type 5 entry is found, MIPv4/v6-TG will process the datagram as follows. o MIP-ALG replaces the destination address of the datagram with the IPv6 home address, which is taken from the type 2 routing header of the datagram. o NAT-PT translates the datagram into IPv4 format. o MIP-ALG encapsulates the datagram in a new IPv4 datagram. The source address of the outer IP header is copied from MIPv4 Message Entrance field. Then MIP-ALG uses the destination address of the inner IP header as an index to search Cached Bindings field, and takes out the care-of address bound with the destination address, and uses the care-of address as the destination address of the outer IP header. o MIPv4/v6-TG sends the processed IPv4 datagram. 8.4.6. The usage of Type 6 MIP Table Entry The contents of Type 6 entry are available in section 8.3.4. (1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG will take out its destination address and uses it as an index to search the MIP table. If a Type 6 entry is found, MIPv4/v6-TG will process the datagram as follows. o NAT-PT translates the datagram into IPv6 format. o MIP-ALG inserts a Type 2 routing header into the IPv6 datagram, and fills the header with the destination address of the IPv6 datagram. Then MIP-ALG uses the destination address as an index to search Cached Bindings field, and takes out the care-of address bound with the destination address, and replaces the destination address with the care-of address. Ma Expires December 28, 2008 [Page 39] Internet-Draft Mobility Support in IPv4/v6 June 2008 o MIPv4/v6-TG sends the processed IPv6 datagram. (2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG takes out its destination address and uses it as an index to search the MIP table. If a Type 6 entry is found, MIPv4/v6-TG will process the datagram as follows. o MIPv4/v6-TG replaces the source address of the datagram with the IPv6 home address, which is taken from the Destination Option extension header of the datagram. o NAT-PT translates the datagram into IPv4 format. o MIPv4/v6-TG sends the processed IPv4 datagram. 8.5. The Update of MIP Table Entries When MN moves within network of the same IP version and acquires a new care-of address, it will update the binding caches on HA and CN (when CN is in IPv6 network) as well as the binding caches on the related MIP table entry under some circumstances. Like the creation of MIP table entries, the update of the entry is triggered by MIP messages, such as Registration Request messages, BU messages, HoTI/HoT messages and CoTI/CoT messages. In the creation process, MIPv4/MIPv6 Message Entrance of the entry have been set. MIPv4/v6-TG can access a corresponding entry through these entrances when it intercepts a MIP message, and then updates the entry. Note that when MN moves to a network of a different IP version, the original entry (if any) becomes invalid and a new MIP table entry should be created. This has been discussed in section 8.3. 8.5.1. The Update of Type 1 MIP Table Entries The contents of Type 1 entry are available in section 8.3.1. A Type 1 entry corresponds to a scenario where both HA and MN are located in IPv4 network, and CN is located in IPv6 network. According to RFC3344, MN does not register with CN. Therefore, MIPv4/v6-TG will not receive any Registration Request message sent by MN. The contents of the corresponding entry, except the Lifetime, do not need to be updated. According to RFC3775, CN also maintains a binding cache which should be updated after MN acquires a new care-of address. In this scenario, however, the destination address of datagrams sent by CN consists of two parts: a 96-bit NAT-PT prefix and IPv4 care-of address. It is Ma Expires December 28, 2008 [Page 40] Internet-Draft Mobility Support in IPv4/v6 June 2008 only based on the 96-bit NAT-PT prefix that the datagrams are routed to MIPv4/v6-TG. MIPv4/v6-TG will then send the datagrams to HA, rather than MN. Therefore, as long as the binding cache on HA has been updated, the datagrams sent by CN will be correctly delivered to MN by HA. 8.5.2. The Update of Type 2 MIP Table Entries The contents of a Type 2 MIP table entry are available in section 8.3.2. A Type 2 entry corresponds to a scenario where both HA and CN are located in IPv4 network, and MN is located in IPv6 network. The update process of a Type 2 MIP table entry is as follows. MIPv4/v6-TG intercepts a BU message, takes out the IPv6 home address from the intercepted message, uses it as an index to search the MIP table, and finds the related Type 2 entry. If the State value is equal to 1, then the following steps will be performed: (1) MIP-ALG sets the fields of State to 0, and Lifetime to a value in which the update of this entry must be accomplished. (2) MIP-ALG takes CoAv4# from MIPv4 Message Entrance and uses it as an index to search the NAT table. A mapping of CoAv4#<-->CoAv6 will be found. Then MIP-ALG updates the mapping with the new CoAv6 carried in the BU message. (3) MIP-ALG generates a BA message. The source address and destination address are copied from the destination address and source address of the BU message. HoAv6* is also carried in the BA message. This BA message will be routed to MNv6. (4) MIPv4/v6-TG intercepts a HoTI message or a CoTI message, takes out HoAv6* from the intercepted message as an index to search the MIP table and finds this entry. (5) MIP-ALG replies with a HoT message or CoT message. (6) MIPv4/v6-TG intercepts a BU message, takes out the IPv6 home address from the intercepted message, uses it as an index to search the MIP table, and finds this entry. (7) MIP-ALG updates Cached Bindings HoAv6*<-->CoAv6 with the new CoAv6 carried in the BU message. Ma Expires December 28, 2008 [Page 41] Internet-Draft Mobility Support in IPv4/v6 June 2008 (8) MIP-ALG generates BA message, the source address and destination address are copied from the destination address and source address of the BU message. HoAv6* is also carried in the BA message. This BA message will be routed to MNv6. (9) MIP-ALG sets the State field to 1, and then sets the Lifetime to the lifetime of the binding. If the State value is equal to 0, then the following steps will be performed: (1) MIP-ALG updates Cached Bindings HoAv6*<-->CoAv6 with the new CoAv6 carried in the BU message. (2) MIP-ALG generates BA message, the source address and destination address are copied from the destination address and source address of the BU message. HoAv6* is also carried in the BA message. This BA message will be routed to MNv6. (3) MIP-ALG sets the State field to 1, and then sets the Lifetime to the lifetime of the binding. 8.5.3. The Update of Type 3 MIP Table Entries The contents of a Type 3 MIP table entry are available in section 8.3.2. A Type 3 entry corresponds to a scenario where HA is located in IPv4 network, while MN and CN are located in IPv6 network. The update process of a Type 3 MIP table entry is as follows. (1) MIPv4/v6-TG intercepts a BU message, takes out HoAv6* and uses it as an index to search the MIP table, and finds a related Type 3 entry. (2) MIP-ALG sets the fields of State to 0, and Lifetime to a value in which the update of this entry must be accomplished. (3) MIP-ALG takes CoAv4# from MIPv4 Message Entrance and uses it as an index to search the NAT table. A mapping of CoAv4#<-->CoAv6 will be found. Then MIP-ALG updates the mapping with the new CoAv6 carried in the BU message. (4) MIP-ALG updates Cached Bindings HoAv6*<-->CoAv6 with the new CoAv6 carried in the BU message. (5) MIP-ALG generates a BA message. The source address and destination address are copied from the destination address and Ma Expires December 28, 2008 [Page 42] Internet-Draft Mobility Support in IPv4/v6 June 2008 source address of the BU message. HoAv6* is also carried in the BA message. This BA message will be routed to MNv6. (6) MIPv4/v6-TG intercepts a HoTI message, takes out HoAv6* from the intercepted message as an index to search the MIP table and finds this entry. This HoTI message will be then delivered to CNv6. (7) MIPv4/v6-TG intercepts a HoT message, takes out HoAv6* from the intercepted message as an index to search the MIP table and finds this entry. This HoT message will be routed to MNv6 through tunneling. The beginning point and endpoint of the tunnel are HAAv6* and CoAv6. CoAv6 can be acquired from the Cached Bindings field of the entry. (8) MIP-ALG sets the field of State to 1, and the Lifetime to the lifetime of the binding. 8.5.4. The Update of Type 4 MIP Table Entries The contents of a Type 4 MIP table entry are available in section 8.3.3. A Type 4 entry corresponds to a scenario where HA is located in IPv6 network, while MN and CN are located in IPv4 network. The update process of a Type 4 MIP table entry is as follows. (1) MIPv4/v6-TG intercepts a Registration Request message, takes out destination address from the intercepted message as an index to search the MIP table and finds a related Type 4 entry. (2) MIP-ALG sets the fields of State to 0, Lifetime to a value in which the update of this entry must be accomplished, and Source Port and Destination Port to the source port number and destination port number of the intercepted message. (3) MIP-ALG updates Cached Bindings HoAv4#<-->CoAv4 with the new CoAv4 carried in the Registration Request message. (4) MIP-ALG generates a BU message based on the Registration Request message. The source address and destination address of the BU message are CoAv6* and HAAv6, respectively. HoAv6 is carried in the message. CoAv6* is acquired by adding a 96-bit NAT-PT prefix to CoAv4. HAAv6 and HoAv6 are acquired by checking the NAT table, using HAAv4# and HoAv4# as the index. This BU message will be routed to HAv6. (5) MIPv4/v6-TG intercepts a BA message replied from HAv6, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. Ma Expires December 28, 2008 [Page 43] Internet-Draft Mobility Support in IPv4/v6 June 2008 (6) MIP-ALG generates a Registration Reply message, with HAAv4# and CoAv4 as the source address and destination address. This message is sent through UDP. The source port number and destination port number are copied from the Destination Port and Source Port, respectively. This message will be routed to MNv4. (7) MIP-ALG sets the field of State to 1, and the Lifetime to the lifetime of the binding. 8.5.5. The Update of Type 5 MIP Table Entries The contents of a Type 5 MIP table entry are available in section 8.3.3. A Type 5 entry corresponds to a scenario where both HA and CN are located in IPv6 network, and MN is located in IPv4 network. The update process of a Type 5 MIP table entry is as follows. (1) MIPv4/v6-TG intercepts a Registration Request message, takes out destination address from the intercepted message as an index to search the MIP table and finds a related Type 5 entry. (2) MIP-ALG sets the fields of State, HoTI/HoT and CoTI/CoT to 0, MIPv6 Datagram Entrance to CoAv6*, Lifetime to a value in which the update of this entry must be accomplished, and Source Port and Destination Port to the source port number and destination port number of the message. CoAv6* is acquired by adding a 96-bit NAT-PT prefix to CoAv4. CoAv4 can be acquired from the source address field of the Registration Request message. (3) MIP-ALG generates a BU message based on the Registration Request message. The source address and destination address of the BU message are CoAv6* and HAAv6, respectively. HoAv6 is carried in the message. CoAv6* is acquired by adding a 96-bit NAT-PT prefix to CoAv4. HAAv6 and HoAv6 are acquired by checking the NAT table, using HAAv4# and HoAv4# as the index. This message will be routed to HAv6. (4) MIPv4/v6-TG intercepts a BA message, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. (5) MIP-ALG generates a HoTI message and a CoTI message. The source address and destination address of the HoTI message are HoAv6 and CNAv6, respectively. The HoTI message is first sent to HAv6 through reverse tunneling and then to CNv6. The beginning point and endpoint of the tunnel are CoAv6* and HAAv6, respectively. The source address and destination address of the CoTI message are CoAv6* and CNAv6, Ma Expires December 28, 2008 [Page 44] Internet-Draft Mobility Support in IPv4/v6 June 2008 respectively. CNAv6 is acquired by checking the NAT table, using CNAv4# as the index. (6) MIPv4/v6-TG intercepts a HoT message or a CoT message, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. (7) MIP-ALG sets the fields of HoTI/HoT or CoTI/CoT to 1. When both HoTI/HoT and CoTI/CoT fields become 1, MIP-ALG generates a BU message with CoAv6* and CNAv6 as the source address and destination address. This message will be routed to CNv6. (8) MIPv4/v6-TG intercepts the BA message replied from CNv6, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. (9) MIP-ALG updates Cached Bindings HoAv4#<-->CoAv4 and HoAv6<-- >CoAv6* with the new CoAv4 and CoAv6*, respectively. (10) MIP-ALG generates a Registration Reply message, with HAAv4# and CoAv4 as the source address and destination address. This message is sent through UDP. The source port number and destination port number are copied from Destination Port and Source Port. This message will be routed to MNv4. (11) MIP-ALG sets the State field to 1, and then sets the Lifetime to the lifetime of the binding. 8.5.6. The Update of Type 6 MIP Table Entries The contents of a Type 6 MIP table entry are available in section 8.3.4. A Type 6 entry corresponds to a scenario where both HA and MN are located in IPv6 network, while CN is located in IPv4 network. The update process of a Type 6 MIP table entry is as follows. (1) MIPv4/v6-TG intercepts a HoTI message or a CoTI message, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds a related Type 6 entry. (2) MIP-ALG sets the State field to 0. (3) MIP-ALG generates a HoT message or a CoT message. HoT message is first sent to HA and then delivered to MNv6 through tunneling. CoT message is sent directly to MNv6. Ma Expires December 28, 2008 [Page 45] Internet-Draft Mobility Support in IPv4/v6 June 2008 (4) MIPv4/v6-TG intercepts a BU message, takes out HoAv6 from the intercepted message as an index to search the MIP table and finds this entry. (5) MIP-ALG updates the binding of HoAv6<-->CoAv6 with the new CoAv6 acquired from the BU message. (6) MIP-ALG generates a BA message, the source address and destination address of which are copied from the destination address and source address of the BU message. This message will be routed MNv6. (7) MIP-ALG sets the State field to 1, and then sets the Lifetime to the lifetime of the binding. 9. Protocol Constants MAX_MIP_CREATE_TIMEOUT 30 seconds In this protocol, the creation of MIP table entry should be accomplished within an interval of 30 seconds after the creation begins. If the creation is not accomplished after 30 seconds, the unfinished MIP table entry will be deleted. 10. Security Considerations 10.1. Security policy for HA, MN and CN This protocol places no additional requirements on HA, MN and CN. Security policy for a particular entity depends on which network the entity is located in. If it is located in IPv4 network, it should meet the security requirements described in RFC3344. If it is located in IPv6 network, it should meet the security requirements described in RFC3775. 10.2. Security Considerations for MIPv4/v6-TG As for MIPv4/v6-TG, the following aspects should be considered. MIPv4/v6-TG is made up of NAT-PT and MIP-ALG. Security threats to NAT-PT, such as DoS attacks, single point failure, are also potential threats to MIPv4/v6-TG. There have been some methods to deal with such threats. These methods can be applied to MIPv4/v6-TG. For example, to avoid single point failure, a backup MIPv4/v6-TG can be introduced. Ma Expires December 28, 2008 [Page 46] Internet-Draft Mobility Support in IPv4/v6 June 2008 On IPv4 network side, MIPv4/v6-TG acts as an IPv4 entity, while on IPv6 network side, it acts as an IPv6 entity. MIPv4/v6-TG has to deal with MIPv4 or MIPv6 messages and datagrams. When processing these messages and datagrams, MIPv4/v6-TG also faces the same security threats as any MIPv4 or MIPv6 entity. In RFC3344 and RFC3775, some security policies have been introduced to protect MIPv4 registration processes and communication processes. These security policies are adopted in this protocol. For example, when MIPv4/v6-TG acts as a MIPv6 entity, it should support the Return Routability Procedure. When MIPv4/v6-TG acts as a MIPv4 entity, it should use Authentication extension to protect the registration processes. 11. IANA Considerations This protocol introduces three news messages: the extended Registration Request message, the Agent Request message and the Agent Reply message. These three messages have similar message format with the Registration Request/Reply message in RFC3344, but with different message Type values. In this document, the Type values of these three messages are 4, 5 and 6, respectively. These values are to be determined by IANA. Ma Expires December 28, 2008 [Page 47] Internet-Draft Mobility Support in IPv4/v6 June 2008 12. Normative References [1] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002 [2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004 [3] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. [4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Zhengming Ma Zhongshan University Department of Electronics and Engineering, Zhongshan University, 135 Xingangxi Road, Guangzhou, P.R. China Email: issmzm@mail.sysu.edu.cn Qingyu Tan Zhongshan University Department of Electronics and Engineering, Zhongshan University, 135 Xingangxi Road, Guangzhou, P.R. China Email: tqytan@163.com Zheng Xiang Zhongshan University Department of Electronics and Engineering, Zhongshan University, 135 Xingangxi Road, Guangzhou, P.R. China Email: rousseau2000@163.com Ma Expires December 28, 2008 [Page 48] Internet-Draft Mobility Support in IPv4/v6 June 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ma Expires December 28, 2008 [Page 49]