Internet Engineering Task Force J. Bi Internet-Draft Y. Wang Intended status: Experimental L. Xie Expires: July 10, 2009 Tsinghua University Jan 6, 2009 A Multihoming Based IPv4/IPv6 Transition Approach draft-jbi-transition-multihoming-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Copyright and License Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bi, et al. Expires July 10, 2009 [Page 1] Internet-Draft Multihoming Based Transition Approach Jan 2009 Abstract How to make IPv4 users utilize IPv6 applications is a typical scenario of the IPv4/IPv6 inter-operation. Nowadays, Tunnel Broker and 6to4 tunnel mechanisms are the popular solutions for this problem. This paper proposes a multihoming based algorithm MI46 to integrate Tunnel Broker and 6to4 tunnel mechanism. It overcomes the shortcomings of both Tunnel Broker and the 6to4 tunnel mechanism to form an optimized method to make the IPv4 users use the IPv6 applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Background of Tunnel Broker and 6to4 Tunnel . . . . . 4 2.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 3. The MI46 Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 3.1. The Background of SHIM6 . . . . . . . . . . . . . . . . . 7 3.2. The MI46 Algorithm . . . . . . . . . . . . . . . . . . . . 7 3.3. The Advantage of the MI46 Algorithm . . . . . . . . . . . 10 4. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Generation of 6to4 Address . . . . . . . . . . . . . . . . 13 4.2. Relation with shim6 Protocol . . . . . . . . . . . . . . . 13 5. Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Incentive for Deployment . . . . . . . . . . . . . . . . . 14 5.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Bi, et al. Expires July 10, 2009 [Page 2] Internet-Draft Multihoming Based Transition Approach Jan 2009 1. Introduction The Internet running IPv4 protocol has gained huge success in the past 20 years. However, it has grown to a scale well beyond the designers envisioned over decades ago. In 1998, The IETF (Internet Engineer Task Force) introduced IPv6 protocol which is designed to overcome the limitation of IP address and security problem. In recent years, a lot of countries (North America, Europe and East Asia) drive the development of the IPv6 protocol by constructing IPv6 operational network. Nowadays, more and more people have realized that it is inevitable to transit from IPv4 to IPv6. Transition from IPv4 to IPv6 is a very complex problem, which involves the compatibility of the equipments, techniques, applications and so on. The IETF established a working group called "IPng Transition" (ngtrans) to study these problems, and proposed plenty of transition methods. But, recently the IETF uses the 'IPv6 Operations' (v6ops) working group and the new term "inter-operation" instead of the ngtrans working group and the term "transition". The IETF believes that the transition from IPv4 to IPv6 is a long-term process and the inter-operation of the IPv4/IPv6 network is extremely necessary. So, the current main point is to study how to make the IPv4 and IPv6 network inter-operate well enough, rather than how to replace the IPv4 network with the IPv6 network. Though the coexistence of IPv6 and IPv4 network will last a long time, the IPv6- only applications will be more and more popular when network application providers and application users realize that the IPv6 network is a definite trend. In this situation, it is very significant to study how to make the users in the IPv4 network use the IPv6- only applications, which is a typical scenario of the application inter-operation of the IPv4/IPv6 networks. Tunnel broker [RFC3053] and 6to4 tunnel [RFC3056] mechanism is the typical solutions to make the IPv4 users utilize IPv6 applications. This paper points out the pitfalls of these two solutions, and proposes a simplified-SHIM6 based mechanism MI46 which integrates Tunnel Broker and 6to4 tunnel solutions. In the MI46 mechanism, the dual-stack host in the IPv4 network holds both global IPv6 address and the 6to4 address. It uses the global IPv6 address and Tunnel Broker mechanism to visit the pure IPv6-host in the native IPv6 network, whereas it employs the 6to4 address and 6to4 tunnel mechanism to visit another dual-stack host in the IPv4 network via IPv6 protocol. In this way, we form a new optimized algorithm to make the IPv4 users use the IPv6 applications by integrating the advantages of Tunnel Broker and the 6to4 tunnel mechanisms. Bi, et al. Expires July 10, 2009 [Page 3] Internet-Draft Multihoming Based Transition Approach Jan 2009 2. Problem Statement 2.1. The Background of Tunnel Broker and 6to4 Tunnel Tunnel broker is used to help users to manage the configured tunnels automatically. With the help of the tunnel broker, the dual-stack host in the IPv4 network can obtain the global permanent IPv6 address from the IPv6 ISP. Then, in order to form the IPv6 connectivity, an IPv6-in-IPv4 tunnel is set up between the dual-stack host and the IPv6-relay gateway, which is called tunnel server in Tunnel Broker mechanism. So, in Tunnel Broker mechanism, all traffic has to be forwarded by the IPv6-relay gateway. The 6to4 tunnel is another automatic way to connect isolated IPv6 sites/hosts attached to an IPv4 network which has no native IPv6 support. An IPv6-relay gateway, which is called 6to4 Relay in the 6to4 tunnel mechanism, is provided for such IPv6 sites/hosts to visit IPv6 native network before they can obtain native IPv6 connectivity. With 6to4, the current IPv4 network is treated as the link layer, and the existing IPv4 routing infrastructure is utilized to forward IPv6- in-IPv4 encapsulated packet. The 6to4-host uses a 6to4 IPv6 address (2002:IPv4 Address:: /80) as the communication identifier. When the IPv6 packet is sent, the IPv4 address of tunnel end point can be found within the 6to4 address, and then a tunnel is formed without explicit configuration. 2.2. Problem Statement How to make the IPv4 users use the IPv6 applications is a typical scenario of the application inter-operation of IPv4/IPv6 network. When a dual-stack host in the IPv4 network wants to use the IPv6 applications, the following two scenarios are possible: o Scenario 1: The dual-stack host in the IPv4 network visits the pure IPv6-host in the native IPv6 network. With the deployment of the IPv6, a lot of IPv6 applications will be located at the native IPv6 network. The dual-stack host in the IPv4 network must visit the pure IPv6-host/server in the native IPv6 network if it wants to use these IPv6 applications. o Scenario 2: Two or more dual-stack hosts in the IPv4 network communicate with each other using the IPv6 protocol in order to use the IPv6-only applications. In the future, many IPv6 applications will have no IPv4 support. Therefore, the dual-stack hosts in the IPv4 network must communicate with each other using the IPv6 protocol if they want to use the IPv6-only applications. As mentioned above, Tunnel Broker and the 6to4 tunnel mechanisms are the typical solutions to make the IPv4 users use the IPv6 Bi, et al. Expires July 10, 2009 [Page 4] Internet-Draft Multihoming Based Transition Approach Jan 2009 applications. However, each of these two solutions can not be applied to both the above scenarios appropriately. Tunnel Broker can work well in the scenario 1, but when it works in the scenario 2 (Fig.1), the traffic between the two dual-stack hosts must be forwarded by the IPv6-relay gateway. So, the IPv6-relay gateway may potentially become the communication bottleneck. Besides, a packet from one dual-stack host to another must be encapsulated and dencapsulated twice. The first time encapsulation/ dencapsulation occurs between the sender and the IPv6- relay gateway and the second time encapsulation/ dencapsulation occurs between the IPv6-relay gateway and the receiver. This behavior may lead to bad user experience. ,-----------------------------------. ,' IPv4 Network ` / \ / Dual-stack Dual-stack \ ; Host A Host B : | +---+ +---+ | : | A | | B | ; \ +---+ +---+ / \ \ / / `. \ / ,' '----------\----------/------------- \ / \ / +----+ ,--------------| |---------------. ,' +----+ IPv6-relay ` / \ Gateway \ / \ \ ; \ : | ' +---+ | : Host C | C | ; \ +---+ / \ / `. IPv6 Network ,' '--------------------------------- Figure 1. Scenario that IPv4 users use IPv6 applications by tunnel broker In Figure 1, the dual-stack hosts A、B in the IPv4 network and the host C in the IPv6 network all run the IPv6 applications. The dual- stack host A and B obtain the global IPv6 addresses from the IPv6 ISP. When the host A communicates with the host C, there is no doubt that the traffic need to be forwarded by the IPv6-relay Bi, et al. Expires July 10, 2009 [Page 5] Internet-Draft Multihoming Based Transition Approach Jan 2009 gateway. However, when the host A communicates with the host B, the traffic still need to be forwarded by the IPv6-relay gateway, which increases the burden of the IPv6-relay gateway unnecessarily. Apparently, it is a better way that the host A communicates with B via a direct tunnel. That is just the behavior of the 6to4 tunnel mechanism. The 6to4 tunnel mechanism can work well in the scenario 2 since there is no need to employ a relay gateway to forward the traffic between the dual-stack hosts. However, because of the special format of 6to4 address, it's hard to do routing aggregation for 6to4 address. Hence, the 6to4 tunnel mechanism is not very suitable as a common approach for IPv6 communication. So, it is not a good method in scenario 1. In summary, Tunnel Broker can work better in scenario 1 than in scenario 2, while the 6to4 tunnel mechanism is more suitable in scenario 2 than in scenario 1. So, one interesting problem is how to integrate these two mechanisms and form an optimized solution. That is just the topic we discuss next. Bi, et al. Expires July 10, 2009 [Page 6] Internet-Draft Multihoming Based Transition Approach Jan 2009 3. The MI46 Algorithm 3.1. The Background of SHIM6 Currently, the SHIM6 mechanism [draft-ietf-shim6-proto-10] is the most promising multihoming approach in the IETF's viewpoint. Multihoming refers to the phenomena that one network end node accesses to the Internet through multiple network paths mainly due to the consideration of fault resilience. For the purpose of access to the Internet via multiple network paths, the multihomed network end node often possesses several addresses. Once the current network path fails, the multihomed network end node can immediately switch to another address and use another network path to communicate. Therefore, as a technical solution of multihoming, SHIM6 has dealt with the problem of address switch, which is just the key problem of the MI46 algorithm. In the SHIM6 approach, a new 'SHIM6' sub-layer is inserted into the IP stack in end hosts that wish to take advantage of multihoming. The SHIM6 sublayer is located within the IP layer between the IP endpoint sub-layer and IP routing sub-layer. With the SHIM6, hosts have to deploy multiple provider-assigned IP address prefixes from multiple ISPs. These IP addresses are used by applications and if a session becomes inoperational, SHIM6 sub-layer can switch to use a different address pair. The switch is transparent to applications as the SHIM6 layer rewrites and restores the addresses at the sending and receiving host. For the purpose of transport-layer communication survivability, the SHIM6 approach separates the identity and location functions for IPv6 addresses. In SHIM6, the identifier is used to uniquely identify endpoints in the Internet, while the locator is used to perform the role of routing. There is a one-to-more relationship between the identifier and locator. The SHIM6 layer performs the mapping function between the identifier and the locator consistently at the sender and the receiver. The upper layers above the SHIM6 sub-layer just use the unique identifier to identify the communication peer, even though the locator of the peer has changed. Hence, when the multihomed host switches to another locator, the current transport layer communication does not break up since the identifier is not changed. 3.2. The MI46 Algorithm In the MI46 algorithm, for the purpose of integrating Tunnel Broker and the 6to4 tunnel mechanisms, we construct a virtual IPv6 network for upper-layer IPv6 applications by inserting a SHIM6 sub-layer in the IPv6 stack of the dual-stack host within the IPv4 network. The Bi, et al. Expires July 10, 2009 [Page 7] Internet-Draft Multihoming Based Transition Approach Jan 2009 SHIM6 sub-layer distinguishes that the peer is located in the IPv4 or IPv6 network, and selects the 6to4 tunnel or Tunnel Broker mechanism to communicate. The architecture of the MI46 mechanism is shown in Figure 2. +-----------------------------------------+ | IPv6 Applications | +-----------------------------------------+ +-----------------------------------------+ | TCP UDP AH ESP | +-----------------------------------------+ + - - - - - - - - - - - - - - - - - - - - + | Simplified SHIM6 | + - - - - - - - - - - - - - - - - - - - - + +-------------------+ +-------------------+ |Global IPv6 Address| | 6to4 Address | | Tunnel Broker | | 6to4 Tunnel | +-------------------+ +-------------------+ +-------------------+ +-------------------+ | IPv6 Network | | IPv4 Network | +-------------------+ +-------------------+ Figure 2. MI46 Architecture In the MI46 mechanism, the dual-stack host in the IPv4 network need hold both the global IPv6 address and the 6to4 address. We choose the global IPv6 address as the primary address since it is hard to do aggregation for 6to4 address. The global IPv6 address is assigned by the IPv6 ISP, while the 6to4 address is generated by the dual-host itself. Applications and transport layer, which are above the SHIM6 sublayer, just use the global IPv6 address as its identifier. And the IP layer, which is below the SHIM6 sub-layer, uses the global IPv6 address or 6to4 address as the locator. When a dual-stack host that has deployed the MI46 mechanism in the IPv4 network initially contacts with another IPv6 host (a dual-stack host in the IPv4 network or a host in the native IPv6 network), it uses the global IPv6 address and Tunnel Broker mechanism. In succession, the dual-stack host sends a probe message to examine the correspondent whether or not supports the MI46 mechanism. If the correspondent deploys the MI46 mechanism, it will return a response message to the initiator. Then, they exchange their respective 6to4 address through two handshakes. The whole process of the four handshakes is shown in Figure 3. Bi, et al. Expires July 10, 2009 [Page 8] Internet-Draft Multihoming Based Transition Approach Jan 2009 Initiator Correspondent --------- --------- | Probe message to examine support of MI46 | |------------------------------------------------->| | | | Response message to claim support of MI46 | |<-------------------------------------------------| | | | 6to4 Address of the initialor | |------------------------------------------------->| | | | 6to4 Address of the Correspondent | |<-------------------------------------------------| | | Figure 3. Four handshakes process If the four handshakes complete, the initiator can deduce that the correspondent is also in the IPv4 network. They both establish the mapping state between the peer's global IPv6 address (identifier) and the 6to4 address (locator). Then all the subsequent traffic between the initiator and the correspondent change the locators from the global IPv6 addresses to the 6to4 addresses. But the identifiers used by upper layer keep consistent due to the mapping function of the MI46 sub-layer. That guarantees the transport layer communications are not terminated. Now, all traffic goes through the direct 6to4 tunnel (Figure 4). Initiator A Correspondent B +-----------------------+ +-----------------------+ | Src addr = | | Src addr = | | A Global IPv6 address | | A Global IPv6 address | | Dst addr = | | Dst addr = | | B Global IPv6 address | | B Global IPv6 address | +-----------------------+ +-----------------------+ | SHIM6 mapping | | SHIM6 mapping | +-----------------------+ +-----------------------+ | Src addr = | | Src addr = | | A 6to4 address | | A 6to4 address | | Dst addr = | | Dst addr = | | B 6to4 address | | B 6to4 address | +-----------------------+ +-----------------------+ | /\ ------------- 6to4 Tunnel -------------| Figure 4. The communication process between two dual-stack hosts by MI46 Bi, et al. Expires July 10, 2009 [Page 9] Internet-Draft Multihoming Based Transition Approach Jan 2009 After the dual-stack host in the IPv4 network completes current communication with the correspondent, they both keep the mapping state of the peer's global IPv6 address and the 6to4 address for a while. Next time when they communicate with each other, they can look up he mapping state directly and use the 6to4 address as both the identifier and the locator. In this situation, the mapping function of the SHIM6 is turned off automatically to improve the packet handling performance. The expired mapping states are deleted by the garbage collecting system. If the dual-stack host in the IPv4 network visits the pure IPv6-host in the native IPv6 network, the second handshake of the four handshakes will not complete since it's unnecessary to support the MI46 mechanism for the hosts in the native IPv6 network. Thus, the whole communication uses the global IPv6 address and Tunnel Broker mechanism. 3.3. The Advantage of the MI46 Algorithm As we mentioned above, Tunnel Broker and the 6to4 tunnel are the popular solutions to make the IPv4 users use the IPv6 applications. Tunnel Broker mechanism is very suitable for the scenario that the IPv4 hosts visit the hosts in the IPv6 network. But when it works in the situation that two dual-stack hosts use IPv6 protocol to communicate, it may make the burden of IPv6-relay gateway heavier and make it become the potential communication bottleneck; meanwhile, it brings bad user experience due to encapsulation and decapsulation twice. The 6to4 tunnel mechanism establishes the direct tunnel using the 6to4 addresses when two dual-stack hosts in the IPv4 network communicate with each other, so it's a good approach in this scenario. But because the 6to4 address is a kind of special format address, it is hard to do aggregation and leads to the fact that routing system works in an uncomfortable way. Hence, 6to4 address is not preferred for common IPv6 communication like the situation that IPv4 hosts visit the native IPv6 network. The MI46 integrates Tunnel Broker and the 6to4 tunnel mechanisms well, which looks transparent for the applications and the upper layers. When the dual-stack host in the IPv4 network visits the pure IPv6-hosts in the native IPv6 network, the whole communication uses the global IPv6 address and Tunnel Broker mechanism. When two dual- stack hosts communicate with each other, they seamlessly switch to 6to4 addresses and use the direct 6to4 tunnel. Figure 5 shows how the MI46 works well in above two scenarios. Bi, et al. Expires July 10, 2009 [Page 10] Internet-Draft Multihoming Based Transition Approach Jan 2009 ,-----------------------------------. ,' IPv4 Network ` / \ / Dual-stack Dual-stack \ ; Host A Host B : | +---+ 6to4 Tunnel +---+ | : | A |--------------| B | ; \ +---+ +---+ / \ \ / `. \ ,' '----------\------------------------ \ \ +----+ ,--------------| |---------------. ,' +----+ IPv6-relay ` / \ Gateway \ / \ \ ; \ : | ' +---+ | : Host C | C | ; \ +---+ / \ / `. IPv6 Network ,' '--------------------------------- Figure 5. Scenario that IPv4 users use IPv6 applications by MI46 In Figure 5, the dual-stack host A in the IPv4 network communicates with the host C in the IPv6 network using the global IPv6 address and Tunnel Broker mechanism. When A communicates with the dual-stack host B in the IPv4 network, they seamlessly switch to the 6to4 addresses and use the direct 6to4 tunnel to communicate. With the MI46 algorithm, when two or more dual-stack hosts communicate with each other, the burden of the IPv6-relay gateways can be reduced effectively. And it is expected that users will get better experience with the direct 6to4 tunnel instead of IPv6-relay gateway's forward. Since we use the global IPv6 addresses in the situation that the dual-stack host visits the native IPv6 network, the problem that the 6to4 address is hard to aggregate can be avoided. The comparison of Tunnel Broker, 6to4 tunnel and MI46 is shown in Figure 6. Bi, et al. Expires July 10, 2009 [Page 11] Internet-Draft Multihoming Based Transition Approach Jan 2009 --------------------------------------------------------------------- |Dual-stack hosts in |Dual-stack hosts in the |IPv4 network visit the |IPv4 network |pure-IPv6 host in the |communicate with each |native IPv6 network |other using IPv6 protocol -------------|--------------------------|---------------------------- Tunnel Broker|Very suitable |Unsuitable. The burden of | |the IPv6-relay gateway is | |heavy and the user | |experience is bad -------------|--------------------------|---------------------------- 6to4 Tunnel |Unsuitable. 6to4 address |Very suitable |ishard to do aggregation | -------------|--------------------------|---------------------------- MI46 |Very suitable |Very suitable --------------------------------------------------------------------- Figure 6. Comparison of Tunnel Broker, 6to4 tunnel and MI46 Bi, et al. Expires July 10, 2009 [Page 12] Internet-Draft Multihoming Based Transition Approach Jan 2009 4. Other Issues 4.1. Generation of 6to4 Address In Section 3 we assume that the host in IPv4 native network has 6to4 address. The host can get the 6to4 address in two possible ways: o If this host has global IPv4 address, it can directly derive 6to4 address from the IPv4 address. o If this host is behind a NAT gateway and it only has a private IPv4 address, we assume that there is a 6to4 gateway which can advertise 6to4 prefix in the advertisement. Also, this gateway should support 6to4 tunnel to other IPv4 host. In current stage, we don't consider the situation that a host is behind a NAT gateway and there isn't any 6to4 routers. We know it is a very important problem to solve, and we will investigate it in the future. Teredo [RFC4380] is a good reference for the future investigation on this topic. 4.2. Relation with shim6 Protocol This proposal applies some solution defined in shim6. However, to realize this proposal, it does not require the full implementation of shim6 protocol. Only a subset of shim6 mechanism is required. Two important assumptions in this problem that make it different from the shim6 problems are: o We assume that the host can reliably communicate with both PA IPv6 address and 6to4 address. While in shim6, it is assumed that some address may be unreliable. o We assume that relay gateway is the bottleneck, and 6to4 address is preferred when the peer host also has 6to4 address. Mitigating the burden of relay gateway is the goal of this proposal. While in shim6, it can't make such deterministic decision. So the implementation of this proposal can be much simpler than full shim6 protocol. First, after getting the peer IPv6 address list, it is easy to decide whether to make a switching. Second, after switching to 6to4 address, it is not required to test the reachability of 6to4 address periodicly. Since there is no shim6 prototype available at current time, we plan to implement a subset of shim6 protocol which can support the function defined in this document in the near future. Bi, et al. Expires July 10, 2009 [Page 13] Internet-Draft Multihoming Based Transition Approach Jan 2009 5. Benefit Analysis The beauty of this proposal mainly shows at two aspects: first, it provides enough incentive for the deployment; second, it can be incrementally deployed. 5.1. Incentive for Deployment The proposal will benefit three parties involved in IPv6 network: the end users, the ISP of IPv6 access service, the ISP of IPv6 application: o For the end users. With directly connected 6to4 tunnels, it is expected that users will get better experience in most cases. The incentive to the end users is the most important, since the modification is made at the host. o For the ISP of IPv6 access service. This proposal can decrease the cost of the ISP, both at buying the bandwidth and at buying high performance relay gateways. It is expected that ISPs will encourage their customers to deploy this solution on their hosts. o For the ISP of IPv6 application. Since the cost of providing IPv6 access service is decreased, it will encourage more users to access IPv6 network and use IPv6 applications. 5.2. Incremental Deployment The property of incremental deployment is inherited from shim6. First, as it is an end-to-end solution, it does not require any modification at the relay gateways. Second, it is an "add-on" feature for the host. If either of the hosts doesn't support this function, they can still communicate with PA IPv6 address. Bi, et al. Expires July 10, 2009 [Page 14] Internet-Draft Multihoming Based Transition Approach Jan 2009 6. IANA Considerations This document makes no request of IANA. Bi, et al. Expires July 10, 2009 [Page 15] Internet-Draft Multihoming Based Transition Approach Jan 2009 7. Security Considerations TBD Bi, et al. Expires July 10, 2009 [Page 16] Internet-Draft Multihoming Based Transition Approach Jan 2009 8. Acknowledgements The authors gratefully acknowledge the comments from Eric Nordmarkand Tony Hain. Bi, et al. Expires July 10, 2009 [Page 17] Internet-Draft Multihoming Based Transition Approach Jan 2009 9. References 9.1. Normative References [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. 9.2. Informative References [draft-ietf-shim6-proto-10] Nordmark, E. and M. Bagnulo, "Level 3 Multihoming Shim Protocol for IPv6", Feb 2008. Bi, et al. Expires July 10, 2009 [Page 18] Internet-Draft Multihoming Based Transition Approach Jan 2009 Authors' Addresses Jun Bi Tsinghua University FIT 3-212 Beijing 100084 P.R.C Phone: +86-10-62795818-6270 Email: junbi@tsinghua.edu.cn You Wang Tsinghua University FIT 4-204 Beijing 100084 P.R.C Email: wangyou@netarchlab.tsinghua.edu.cn Lizhong Xie Tsinghua University FIT 4-204 Beijing 100084 P.R.C Email: xlz@netarchlab.tsinghua.edu.cn Bi, et al. Expires July 10, 2009 [Page 19]