NGTRANS WG Shiao-Li Tsao Internet Draft CCL, ITRI Document: draft-ietf-ngtrans-moving-01.txt George Tsirtsis Category: Informational Flarion Technologies Expires: September 2002 Wolfgang Boehm Siemens March 2002 Moving in a Dual Stack Internet <draft-ietf-ngtrans-moving-01.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document provides an analysis of the requirements to support mobility in a dual stack network. In this document, combinations of IPv4, IPv6, and dual stack mobile node moving in IPv4, IPv6, and dual stack networks are listed and the requirements to support mobility under different network and mobile node configurations are investigated. This document aims to reassess next generation transition (NGTRANS) tools from the point of view of mobility. 1. Introduction Mobile IP (MIP) is capable of offering IP mobility to hosts. Mobile IPv4 (MIPv4) [1] was designed for Internet Protocol version 4 (IPv4) and mobile IPv6 (MIPv6) [2] has been also defined for IPv6. Considering IPv4 to IPv6 transition, a number of protocols and mechanisms are proposed to facilitate IPv4/IPv6 communication in a transition network for different purposes or under different assumptions. <Tsao, Tsirtsis, Boehm> 1 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> [3] gives an overview of transition mechanisms within IETF NGTRANS working group. However, these transition mechanisms assume that hosts attach to the network statically. As for mobile nodes (MN) roaming in IPv4/IPv6 transition networks, impacts to these mechanisms have not been investigated. In this document, the requirements to support mobility in a dual stack network are analyzed. Combinations of mobile nodes moving in networks with various configurations are first listed and then mechanisms to support handoffs in different scenarios are examined. This document does not introduce new protocols and mechanisms, but recommend implementations and configurations for some specific handoffs. The principles behind this analysis are to maintain the existing connections of mobile nodes after handoff as much as possible, and to maximize accessibility to the visited networks. Moreover, tunneling mechanism is preferred rather than translators due to security concerns. Finally, route optimization issues are also addressed. 2. Terminology IPv4-only network A network that only implements IPv4. It can understand and process IPv4 packets and MIPv4 messages but can not understand IPv6 and MIPv6. IPv6-only network A network that only implements IPv6. It can understand and process IPv6 packets and MIPv6 messages but can not understand IPv4 and MIPv4. Dual stack network (DS network) A network that implements both IPv4 and IPv6. It can understand and process both IPv4/IPv6 packets and MIPv4/MIPv6 messages. IPv4-only mobile node (IPv4-only MN) A node that implements IPv4, MIPv4 and can be reached by an IPv4 address. IPv6-only mobile node (IPv6-only MN) A node that implements IPv6, MIPv6 and can be reached by an IPv6 address. Dual stack mobile node with an IPv4 address (DS MNv4) A node that has IPv4/IPv6 dual stack and an IPv4 address. The node can change its point of attachment from one link to another, while still being reachable via its IPv4 address. Dual stack mobile node with an IPv6 address (DS MNv6) A node that has IPv4/IPv6 dual stack and an IPv6 address. The node can change its point of attachment from one link to another, while still being reachable via its IPv6 address. Dual stack mobile node with an IPv4 and an IPv6 address (DS MN) A node that has IPv4/IPv6 dual stack and an IPv4 address and an IPv6 address. The node can change its point of attachment from one link to another, while still being reachable via its IPv4 or IPv6 address. <Tsao, Tsirtsis, Boehm> 2 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> IPv4-compatible IPv6 address An address of the form 0::0:a.b.c.d which refers to an IPv6/IPv4 node that supports automatic tunneling. 3. Combinations Table 1 lists all combinations of mobile node and its located networks. The located network means the network the mobile node settles. It might be MN's home network or a visited network. The definitions of the categories of mobile nodes and networks can refer to the terminologies defined in the previous section. For example, Combination 1 is an IPv6-only mobile node staying in an IPv6-only network. The case of a MN with both IPv4 and IPv6 address (DS MN) is not in the list since the MN can perform MIPv4 and MIPv6 procedures separately depending on the networks it locates. Regarding of interchanging information between MIPv4 and MIPv6 for a DS MN, it is not coverred in this document. Among twelve combinations, Combination 2 and Combination 5 result in the loss of connectivity to the network. In the next section, handoff scenarios based on the remaining 10 combinations are examined. Table 1. List of combination of mobile node and its Located networks ---------------------------------------------------- Combination Mobile Node Located Network ---------------------------------------------------- 1 IPv6-only IPv6-only 2(*) IPv4-only IPv6-only 3 DS MNv6 IPv6-only 4 DS MNv4 IPv6-only 5(*) IPv6-only IPv4-only 6 IPv4-only IPv4-only 7 DS MNv6 IPv4-only 8 DS MNv4 IPv4-only 9 IPv6-only DS Network 10 IPv4-only DS Network 11 DS MNv6 DS Network 12 DS MNv4 DS Network ---------------------------------------------------- (*)loss of network connectivity 4. Handoff Scenarios In this section, procedures and mechanisms to fulfill handoffs are examined. Here, handoff is defined as a MN moving from one network to another network. The handoff procedures include the registration of MN's care-of address (COA) to its home agent and the maintenance of the existing connections, said native connections, to its correspondent nodes (CN). The emphases of this document are the MIP registration process and the maintenance of the native connections between MN and its CNs during handoff. <Tsao, Tsirtsis, Boehm> 3 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> 4.1 Handoffs of IPv6-only MN Table 2. List of handoffs of IPv6-only MN and mechanisms can be applied to the communications with CNs. --------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN --------------------------------------------------------- IPv6-only IPv6-only TR NA6 IPv6-only DS TR NA6 DS IPv6-only TR NA6 DS DS TR NA6 --------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA6 : Native IPv6 For IPv6-only MN, there are four handoff scenarios. That is, from an IPv6-only network to another IPv6-only network, from an IPv6-only network to a DS network, from a DS network to an IPv6-only network, and from a DS network to another DS network. Table 2 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. While moving to a visited IPv6-only or DS network, IPv6- only MN can send MIPv6 messages to its home agent to perform MIP registration. After registration, the mobile node can be reached by its IPv6 address in a visited network. Considering the existing connections, IPv6-only and DS CNs can communicate with the MN using native IPv6. As for the communication with IPv4-only CNs, incoming packets should go through the translators in the MN's home network and then be tunneled to the visited network. Regarding of the communications with DS CNs, native IPv6 is used. In summary, there is no problem introduced in the handoffs of IPv6-only MNs in an IPv6-only or DS network. 4.2 Handoffs of IPv4-only MN Table 3. List of handoffs of IPv4-only MN and mechanisms can be applied to the communications with CNs. -------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN -------------------------------------------------------- IPv4-only IPv4-only NA4 TR IPv4-only DS NA4 TR DS IPv4-only NA4 TR DS DS NA4 TR --------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA4 : Native IPv4 <Tsao, Tsirtsis, Boehm> 4 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> For IPv4-only MN, there are four handoff scenarios. That is, from an IPv4-only network to another IPv4-only network, from an IPv4-only network to a DS network, from a DS network to an IPv4-only network, and from a DS network to another DS network. Table 3 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. The situations are quite similar as that of IPv6-only MN. IPv4-only MN moves to a visited IPv4-only or DS network, and performs MIPv4 registration. Regarding of the existing connections, IPv4-only CNs can communicate with MN using native IPv4. For the communications between MN and IPv6-only CNs, incoming packets have to go to translators in the MN's home network first and then be tunneled to the visited network. As for DS CNs, native IPv4 is used. In summary, there is no new problem introduced in this category. 4.3 Handoffs of DS MNv6 Table 4. List of handoffs of DS MNv6 and mechanisms can be applied to the communications with CNs. -------------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN -------------------------------------------------------------- IPv6-only IPv6-only TR, DSTM NA6 IPv6-only DS TR, DSTM NA6 DS IPv6-only TR, DSTM NA6 DS DS TR, DSTM NA6 IPv6-only IPv4-only DSTM(v6), NA4(v4) NA6 IPv4-only IPv6-only DSTM(v6), NA4(v4) NA6 IPv4-only IPv4-only NA4 NA6 IPv4-only DS NA4 NA6 DS IPv4-only NA4 NA6 --------------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA4 : Native IPv4 NA6 : Native IPv6 (v6) : in IPv6-only network (v4) : in IPv4-only network Table 4 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. For a DS MNv6, two sub-categories of handoffs are further classified. The first sub-category of handoffs includes DS MNv6 moving from an IPv6-only network to another IPv6- only network, from an IPv6-only network to a DS network, from a DS network to an IPv6-only network, and from a DS network to another DS network. This sub-category is very similar to that of IPv6-only MN handoffs. DS MNv6 can access IPv6-only and DS networks and perform MIPv6 registration. The difference is the communication between DS MNv6 and IPv4-only CNs. Since DS MNv6 is dual stack, MN can request an IPv4 address via DSTM and send IPv4 packets encapsulated in IPv6 to IPv4-only CNs through TEP. In this case, translator is no more necessary. <Tsao, Tsirtsis, Boehm> 5 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> Imagine a DS MNv6 that only performs MIPv6 registration and not MIPv4. While stationary and at home the MN does not use its MIPv6 capabilities and thus looks like a regular Dual Stack node. In an environment like that, one of the most appealing interoperability mechanisms proposed by the NGTRANS WG is called DSTM[6]. DSTM allows a dual stack node to use DHCPv6 [8] to configure on demand its IPv4 stack. This offers high utilization of IPv4 address space and no requirements for IPv4 support in the domain. Additionally, while the node has an IPv4 address, it can communicate with IPv4-only nodes without the use of Protocol Translators and/or Address Translators. DSTM has been mainly designed for stationary dual stack nodes. We will now examine how a DS MNv6 can take advantage of DSTM in a mobile environment. It is clear that if the DS MNv6 is not moving, DSTM can be directly applicable i.e., the DS MNv6 can use DHCPv6 over MIPv6 to communicate with the DSTM server in the home network and request an IPv4 address. The problem is that while MIPv6 can "move" the mobile's IPv6 stack between access points in the network, it is not obvious how it can move the IPv4 stack of the same DS MNv6. [6] assumes that IPv4 routing is not available in the DSTM domain. The Dynamic Tunneling Interface (DTI) is defined as an interface that encapsulates IPv4 packets into IPv6 packets. The TEP is also defined as the destination of the IPv6 packet containing an IPv4 packet. Providing the DS MNv6 knows where the TEP is, in the domain it happens to be in, it can use MIPv6 to send an encapsulated IPv4 packet to the IPv4-only CN. DS MNv6 essentially uses its MIPv6 COA in the foreign domain to request an IPv4 address (and the local TEP) from the local DHCPv6 server. It then uses IPv6 to communicate with the local TEP and encapsulate IPv4 packets destined to external IPv4-only nodes. Even if DS MNv6 moves to a new Access Router in this domain, a BU to the TEP will allow the IPv6 tunnel and the IPv4 packets it encapsulates to be maintained. Note that like [9] the level of IPv6 connectivity offered by the above combination is very similar to MIPv4 without route optimization since the IPv4 address used is in fact a dynamically allocated IPv4 Home Address. Also like [9], MIPv6 Route optimization is of course used for the path between the MN and the TEP in that domain. It might also be possible for the MN to use the Home DHCPv6 server when in a foreign domain e.g: if the foreign domain does not support DHCPv6. This would require DHCPv6 request to be sent through the Home Agent of the MN. The reply would then include an IPv4 address and a TEP address from the home domain. Data would have to be sent from the MN to the HA, then to the TEP and eventually to the CN. <Tsao, Tsirtsis, Boehm> 6 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> Second sub-category of handoffs are DS MNv6 moving from an IPv6-only network to an IPv4-only network, from an IPv4-only network to an IPv6-only network, from an IPv4-only network to another IPv4-only network, from an IPv4-only network to a DS network, and from a DS network to an IPv4-only network. The problem of this sub-category is that a DS MNv6 with an IPv6 address moves to an IPv4-only network and can not have MIPv6 support in the visited IPv4-only network. The mobile node can still receive IPv6 packets from IPv4- only network if IPv4-only network implements 6over4 [10] on the boundary routers. However, if IPv4-only network does not implement 6over4 mechanism, the mobile node cannot receive IPv6 packets. Since the mobile node is IPv4/IPv6 dual stack, it receives foreign agent advertisement messages from the IPv4 protocol stack. The MN detects the movement to an IPv4-only network without 6over4, and then the MN can perform the the procedures below. First, DS MNv6 asks for a co-located IPv4 COA from the local FA. Once it has an IPv4 COA and the IPv4 address of its home agent in IPv6 home network, it can generate an IPv4-compatible IPv6 address and perform the MIPv6 registration. The IPv4 COA can be obtained by DHCP or some other dynamic address allocation schemes [4][8]. The address allocation issue is out of the scope of this document. To support DS MNv6 roaming to IPv4-only networks, MIPv6 home agent MUST broadcast its IPv6 and its IPv4 address by home agent advertisement. MN MUST keep both IPv6 and IPv4 addresses of its home agent while it received the HA advertisement. After the MN has these addresses, it sends MIPv6 binding update (BU) encapsulated in IPv4 packets to its home agent. Here, we assume that home agent is IPv4/IPv6 dual stack. The IPv6 home agent decapsulates the MIPv6 BU and updates the new COA of the mobile node. Packets to the MN go to the home agent first, and then be tunneled to the visited network. The MN thus can receive and decapsulate the packets. The procedures are summarized as: o In IPv6-only network, IPv6 packets are received and processed by IPv6 protocol stack on a mobile node. o MN received home agent advertisement with HA's IPv4 and IPv6 addresses, it keeps both two addresses. o The MN, which moves to an IPv4-only network without 6over4 support, receives the agent advertisement from MIPv4 foreign agent via the IPv4 protocol stack. o The mobile node obtains an IPv4 COA by certain mechanisms. It generates the IPv4-compatible IPv6 address. MN also has the IPv4 address of the MIPv6 home agent. <Tsao, Tsirtsis, Boehm> 7 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> o The MN sends MIPv6 BU encapsulated in IPv4 packets to its home agent. The home agent decapsulates the MIPv6 BU messages and updates the COA of the mobile node. o Packets to the mobile node go to its home network, and then be tunneled to the visited network. Then, packets are encapsulated in IPv4 and sent to MN. Regarding of DS MNv6 moving back to IPv6-only or DS networks from IPv4-only networks, DS MNv6 releases IPv4 COA and registers a new IPv6 COA or deregisters with its home agent. 4.4 Handoffs of DS MNv4 Table 5. List of handoffs of DS MNv4 and mechanisms can be applied to the communications with CNs. ---------------------------------------------------------------- From Network To Network IPv4-only CN IPv6-only CN ---------------------------------------------------------------- IPv4-only IPv4-only NA4 NA6(in), TR(out) IPv4-only DS NA4 NA6(in), TR(out) DS IPv4-only NA4 NA6(in), TR(out) DS DS NA4 NA6 IPv4-only IPv6-only NA4 NA6(in), TR(out) IPv6-only IPv4-only NA4 NA6(in), TR(out) IPv6-only IPv6-only NA4 NA6 IPv6-only DS NA4 NA6 DS IPv6-only NA4 NA6 ---------------------------------------------------------------- TR : Translator mechanisms such as SIIT and NAT-PT NA4 : Native IPv4 NA6 : Native IPv6 (in) : CN originated (out) : MN originated Table 5 also lists all handoff scenarios and mechanisms can be used for the communication with CNs. For a DS MNv4, two sub-categories of handoff are also classified. First sub-category includes DS MNv4 moving from an IPv4-only network to another IPv4-only network, from an IPv4-only network to a DS network, from a DS network to an IPv4- only network, and from a DS network to another DS network. This sub-category is very similar to that of the IPv4-only MN handoff. DS MNs can access IPv4-only and DS networks, and perform MIPv4 registration procedure to its IPv4 home agent. The difference is in the communication between MN and IPv6-only CNs. Since MN is dual stack, MN can be reached by its IPv4-compatible IPv6 address. For the IPv6-only/DS CNs initiates the communication to DS MNv4 using IPv4-compatible IPv6 address, no translator is required. <Tsao, Tsirtsis, Boehm> 8 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> Second sub-category of handoffs are DS MNv4 moving from an IPv4-only network to an IPv6-only network, from an IPv6-only network to an IPv4-only network, from an IPv6-only network to another IPv6-only network, from an IPv6-only network to a DS network, and from a DS network to an IPv6-only network. The problem of this sub-category is that a DS MNv4 with an IPv4 address moves to an IPv6-only network and obtains no MIPv4 messages and supports. Since the mobile node is IPv4/IPv6 dual stack, it still can receive router advertisement from IPv6 routers and learn that it situates in an IPv6-only network. If the IPv6-only network supports DSTM [6], the mobile node can ask for a co-located COA, obtain TEP, and then send MIPv4 registration request encapsulated in IPv6 packets to its home agent. Then, the registration procedure is complete. If the IPv6-only network does not support DSTM, the DS MNv4 can perform the procedures below. The MN detects no DSTM support but receives the IPv6 packets, it realizes that it moves to an IPv6-only network. The IPv6 stack generates an IPv6 COA by using subnet prefix of the visited network. Once the mobile node obtains an IPv6 COA, it resolves an IPv4 address by the IPv6 address and also requests the IPv6 address of its IPv4 home agent. Here, we assume that IPv4 home agent is also IPv4/IPv6 dual stack. The IPv6 COA and its mapped IPv4 address must be co- located addresses allocated by the visited network using any mechanism. The mapping between IPv6 and IPv4 addresses can be obtained by issuing DNS queries. The allocation of the COA in the visited network can be static assignment or dynamic allocation. The generation of the IPv6 address and the mapping of IPv4 and IPv6 addresses are out of the scope of this document. The related information can be found in [4][8]. Since the home agent is IPv4/IPv6 dual stack, the mobile node has the IPv6 address of home agent, the MN can then tunnel MIPv4 registration request message to its home agent. Home agent decapsulates the IPv6 packets, receives the registration message and update MN COA. Therefore, packets to the mobile node can be transmitted to the new IPv4 COA. The procedures for DS MNv4 which moves from an IPv4-only network to an IPv6-only network are summarized as: o In IPv4-only network, IPv4 packets are received and processed by IPv4 protocol stack on a mobile node. o The MN, which moves to an IPv6-only network, receives the router advertisement from IPv6 router via the IPv6 protocol stack. o The MN requests an IPv4 address and TEP via DSTM. The MN then sends MIPv4 registration request to its HA via TEP. Packets to MN should go to the home agent first and then be tunneled to the visited network. <Tsao, Tsirtsis, Boehm> 9 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> o If DSTM is not supported, MN tries to obtain an IPv6 COA by other mechanisms such as autoconfiguration or DHCP in the visited network. Then, it resolves an IPv4 address by the IPv6 address, and also requests the IPv6 address of its home agent. The mechanisms to obtain an IPv6 COA and the mapping between IPv6 and IPv4 addresses are out of the scope of the document. o The MN sends MIPv4 registration request encapsulated in IPv6 packets to IPv4 HA. HA updates the COA of the MN. o Packets to the MN are first routed to its home network. Home agent tunnels the packets to the IPv4 COA. Regarding of moving back to IPv4-only or DS networks from IPv6-only networks, DS MNv4 releases IPv6 COA and registers a new IPv4 COA or deregisters with its home agent. 5. Route optimization For some specific handoffs, packet routing between CN and MN can be further optimized. Here, we assume that MIPv4 implements route optimization. 5.1 DS MNv6 talks to IPv4-only CN While DS MNv6 moves to the visited IPv6-only or DS networks with DSTM support, DS MNv6 requests an IPv4 address and the local TEP from the local DSTM. It can encapsulate IPv4 packets destined to IPv4-only CNs in IPv6 packets and sends to the CNs through the local TEP. Therefore, DS MNv6 can further send MIPv4 binding update to IPv4-only CN. The IPv4-only CN updates its binding caches. After that, the CN sends packets to the MN new IPv4 address via the new TEP. Packet routing between DS MNv6 and IPv4-only CN is optimized. Another situation is that DS MNv6 moves from an IPv6-only network to an IPv4-only network while talking to an IPv4-only CN. In this case, DS MNv6 uses native IPv4 to talk to CN and sends MIPv4 binding update to CN in the visited network. After that, the packets need not go through the home TEP anymore. 5.2 DS MNv6 talks to IPv6-only/DS CN Considering another scenario that a DS MNv6, talks to an IPv6-only or DS CN. The MN changes its point of attachment to an IPv4-only network. If the visited network supports 6over4 [3] on the boundary routers, the MN can act as a normal IPv6-only MN, and update binding information to its home agent and CNs. If the visited network does not support 6over4, mechanisms mentioned above present the procedures to request an IPv4 COA and register the IPv4-compatible IPv6 address to its home agent. <Tsao, Tsirtsis, Boehm> 10 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> Regarding of packets from IPv6-only CNs to the MN, they go to the home network first, and be tunneled to the MN. To optimize routing, the MN can send MIPv6 BU messages to IPv6-only/DS CNs to update their binding caches. However, the visited network is IPv4-only, IPv6 packets from DS MNv6 can not go to the IPv6-only/DS CNs. To solve this problem, the MN can send MIPv6 BU to IPv6-only CNs using reverse tunneling. That is, MIPv6 BU is tunneled to its home agent first and then sent to IPv6-only CNs. CNs can obtain a tunneling server by tunnel broker mechanisms [12] or obtain a pre-configured router [3][11] with dual stack functions, and send IPv6 packets to the TEP. The TEP encapsulates the packets into IPv4 packets and sends to the MN. Therefore, the routing between TEP/MN, and TEP/CN are both optimized. 5.3 DS MNv4 talks to IPv4-only CN The DS MNv4 might change its point of attachment to an IPv6-only network. The DS MNv4 node requests an IPv4 COA by using DSTM[6] or the mechanisms presented above. It then can perform MIPv4 registration to its home agent. For the incoming packets from IPv4- only CNs, they go to the home agent first, and then be tunneled to the MN. To optimize routing, MN can send MIPv4 BU messages to IPv4-only CNs. Since MN is in an IPv6-only network, the MIPv4 BU needs to be encapsulated in IPv6 packets to CNs via TEPs. TEP decapsulates packets and then forwards the IPv4 packets to IPv4-only CNs. Once the IPv4-only CNs get the MIPv4 BU, they send packets to the new IPv4 COA address through the new TEP. The routing between TEP/MN, and TEP/CN are optimized. 6. Acknowledgments The authors would like to thank Jen-Chi Liu(CCL, ITRI), Alan O'Neill (Flarion Technologies ) and Scott Corson (Flarion Technologies) for their contributions to this memo. We would also like to thank Ra Chen(Siemens), Moter Du(Siemens), and YokeJen Lim(Siemens) for their many useful comments. 7. References [1] Charles E. Perkins, "IP Mobility Support", IETF RFC 2002, Oct. 1996. [2] David B. Johnson and Charles E. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-15.txt, July 2001, (work in progress). [3] W. Biemolt et al., "A Guide to the Introduction of IPv6 in the IPv4 World (TRANSITION)", draft-ietf-ngtrans-introduction-to-ipv6- transition-07.txt, July 2001, (work in progress). [4] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", IETF RFC 2462, Dec. 1998. [5] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", IETF RFC 2461, Dec. 1998. [6] Jim Bound et.al, "Dual Stack Transition Mechanism (DSTM)", <draft-ietf-ngtrans-dstm-07.txt>, February 2002, (Work in Progress). <Tsao, Tsirtsis, Boehm> 11 <draft-ietf-ngtrans-moving-01.txt> <March, 2002> [7] Carpenter, B., and Jung., C. "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529. [8] J. Bound, M. Carney, C. Perkins, and R. Droms. "Dynamic Host Configuration Protocol for IPv6", draft-ietf- dhc-dhcpv6-16.txt, November 2000 (work in progress). [9] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for enhanced routing of inbound packets", <draft-soliman-siit-dstm- 01.txt>, November 2001, (Work in Progress). [10] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC2529, March 1999. [11] R. Gilligan et. al, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893. [12] A. Durand et. al, "IPv6 Tunnel Broker", RFC 3053, January 2001. Author's Addresses Shiao-Li Tsao Computer and Communication Research Labs., Industrial Technology Research Institute K400 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan, 310, R.O.C. Tel: +886-3-5914651 Fax: +886-3-5820310 E-mail: sltsao@itri.org.tw George Tsirtsis Flarion Technologies Phone: +44-20-88260073 Email: G.Tsirtsis@Flarion.com Wolfgang Boehm Siemens Mobile Internet Postal Address: Siemens AG, ICM CA MS MI E Hofmannstr. 51, 81379 Munich / Germany Phone: +49 89 722 31462 Fax: +49 89 722 37661 e-mail: wolfgang-j.boehm@icn.siemens.de Copyright Notice Placeholder for ISOC copyright. <Tsao, Tsirtsis, Boehm> 12
Datatracker
Report a datatracker bug
draft-ietf-ngtrans-moving-01
None
| Document | Document type |
Expired Internet-Draft
(ngtrans WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author |
Shiao Tsao
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |