USING HIP TO SOLVE MULTI-HOMING IN IPV6 NETWORKS

Transcription

1 USING HIP TO SOLVE MULTI-HOMING IN IPV6 NETWORKS Zhangyi Yuan 1, Xiaohong Huang 1, Junyi Zhang 2, Fred Baker 3 1 Research Institute of Networking Technology, Beijing University of Posts and Telecommunications, Beijing 2 Hitachi Medical Corporation & CUST, Changchun University of Science and Technology, Changchun 3 Cisco Systems, Inc rinceyuan@gmail.com, huangxh@bupt.edu.cn, zjyyxn11@yahoo.com.cn, fred@cisco.com Abstract Multi-homing and mobility can provide more stability and convenience in the future network, but they still bring new challenges such as addresses change in mid-session. This paper introduces a new application context which integrates NAT66 environment with multi-homing and the implementation of HIP in solving this challenge. This paper also specializes in the implementation of HIP on solving mobile IP and addresses change. Finally, there is a test scenario to show that. Keywords: HIP; Multi-homing; IPv6; 1 Introduction Nowadays, enterprises prefer PI addresses (Provider Independence) in company-internal network. It also works in the future IPv6 environment. This address independence requirement has been a primary driver for IPv6 NAT deployment [1] in small to medium enterprise networks. While some new services such as multi-homing and mobile IP integrated with this network, some problems occur [2]. initiates a session with B, the data exchange will be like following: 1. A obtains B's external addresses (J' and K') from DNS server or others, 2. Selects one and sends a datagram to it, perhaps A'->J'. 3. A's source address is translated in ISP H, so that the datagram is now H'->J'. 4. ISP J conveys the datagram to B's network, and the router changes the destination address from J' to B'. 5. B ultimately receives a datagram that it perceives as arriving from H'. [2] Note that A's choice of an address for B had nothing to do with B's routing policy; it had to do with the correctness of the assertion that the use of the address would get the datagram to B. At this point, B replies: 1. B' sends a datagram in reply, B'->H'. 2. Routing takes the datagram to one of the ISPs, perhaps K. 3. B's source address is translated so that the datagram is now K'->H'. 4. ISP H conveys the datagram to A's network, and the router changes the destination address from H' to A'. 5. A ultimately receives a datagram that it perceives as arriving from K'. [2] Figure1. Multi-homing Problems Taking a classic customer multi-homing application as an example. As is shown in Figure1, when host A At this point, the transmitting protocol will not recognize it as a responding datagram - it seems like a SYN-ACK or response on a different session.

2 2 Instruction of NAT66 and HIP 2.1 NAT66 NAT66, referred in an IETF draft, may be implemented in an IPv6 router to map one IPv6 address prefix to another IPv6 address prefix as each IPv6 packet transits the router. [1] NAT66 provides a simple and compelling solution to meet the Address Independence requirement in IPv6. It doesn t include a port mapping function, and the address mapping mechanism is checksum-neutral. This avoids the need for a NAT66 device to re-write transport layer headers, making it feasible to deploy new or improved transport layer protocols without upgrading NAT66 devices. Because NAT66 does not involve re-writing transport-layer headers, it will not interfere with encrypting the full IP payload in many cases. It adopts a clever way to make checksum neutral named two-way algorithmic [1] before and after NAT. Also in our lab, we choose FTPv6 and TFTPv6 to verify it works after NAT66. In Figure 2, we use an example to explain this mapping algorithm. Figure2. NAT66 Address Mapping We have implemented it as a module in a Linksys router. [3] 2.2 HIP HIP, Host Identity Protocol, brings in a new identity--hi, Host Identifier, to mark all the hosts which connect to the Internet. It is global unique. The main purpose is to disconnect the close connection between Network layer and Transport layer so that the function of IP will be concentrated on IP routing and the mark of service in the upper layer will rely on HIP layer. [5][8] As is show in Figure3, HIP insert a complete new layer between layer3 and layer4---host identity layer (HIL). After that, upper layer will use Host Identity Tag (HIT) instead of IP address: Transport layer use <HIT, port > instead of <IP address, port>. HIL realizes identity transition between IP address and HIT. As a result, any changes in Network layer will not affect the upper applications. Figure3. New Architecture Any HIP base host will initiates four packets handshake before the HIP connection is built. The first packet, I1, initiates the exchange, and the last three packets, R1, I2, and R2, constitute an authenticated Diffie-Hellman [DIF76] key exchange for session key generation [6]. 3 HIP implementation in multi-homing networks We build a test bed in Figure4 to simulate a IPv6 multi-homing enterprise internal network. HIP is implemented in two Linux hosts, NAT66 module development is based on IPv6-to-IPv6 Network Address Translation (NAT66) [1] and it was inserted in the four edge routers. [3] The whole work is divided into two parts. In the first one, we test HIP solving multi-homing without NAT66 module. In the other one, we repeat the same steps with NAT66 module inserted. Some interesting things are revealed. FD01:0203:0405:0001::2/48 PC A FD01:0203:0405:0001::1/48 NAT OUTSIDE: 2001:0DB8:0001:D550::1/48 Switch A FD01:0203:0405:0001::3/48 Linksys Router 1 Linksys Router ::2/ ::1/48 NAT OUTSIDE: 2002:0DB8:0001:D54F::1/ ::1/ ::1/48 PC with ::2/48 NAT OUTSIDE: 2001:0DB8:0000:D550::1/ ::2/ ::1/48 Linksys Router ::2/48 Linksys Router 4 FD00:0203:0405:0001::2/48 Switch B FD00:0203:0405:0001::3/48 NAT OUTSIDE: 2002:0DB8:0000:D54F::1/48 Figure4. Experiment Environment

3 3.1 IPv6 Environment In order to make comparison, we firstly tested HIP with NAT66 disabled. For there was no NAT on Linksys, changing route would be meaningless. So we only change Entry s IP address to see whether HIP support mobility. After we deleted the original IP address fd01:203:405:1::1, Entry set up another UPDATE handshake with its new locator inside the packet. From the packages caught by Wireshark we could see that Entry would initiate a three-way handshake to inform Terminal that its IP had been changed. And Terminal accepted the new IP address and the connection continued. 3.2 NAT66 Environment Figure5. HIP Base Exchange As is shown in Figure5, HIP will exchange four packets before the connection is built. After that we change the IP address of Entry from fd01:0203:0405:0001::1 to fd01:0203:0405:0001::4. According to RFC4423[6] and RFC5206[7], when a node moves, the existential communication can survive because the mobile node will send a HIP address update message to inform the peer about the new address(es). The peer must verify that the mobile node is reachable through those new addresses. HIP supports mobility and multi-homing by implementing such end to end UPDATE signaling mechanism between communication nodes. In order to change the IP address, we first added a new address fd01:203:405:1::4 to Entry s interface eth1. Entry initiated a three-way UPDATE handshake with Terminal with a new Locator in its packet. (Figure 6) Then we activated NAT66 on the four Linksys boxes. First, we tested whether HIP connection could set up if the route from Entry to Terminal was different from the route from Terminal to Entry. The packets got by Wireshark showed that the four-way handshake cannot be built in this situation. Therefore, during the four-way handshake, host cannot be multi-homed. It cannot be recognized by the peer if it changes its IP address Mobility Case Then we tested whether HIP support mobility with NAT66 enabled on Linksys boxes. After adding a new IP address fd01:203:405:1::4 to interface eth1 on Entry. Wireshark captured three UPDATE packets initiated by Entry with the new IP address along with the original IP address in Locator parameter in the first UPDATE packet. (Figure 7) Figure7. Three-way Update Handshake (1) Then we deleted the original IP address fd01:203:405:1::1. Entry initiated another update. But this time the three-way handshake failed. (Figure 8) Figure6. Three-way Update Handshake

4 Figure8. Three-way update handshake (2) There were only UPDATE packets from Entry to Terminal without any responds, which meant the new IP address fd01:203:405:1::4 was unreachable for Terminal. The following ESP packets were sent from Entry to Terminal while getting no reply, which meant the communication terminated. (Figure 9) sent the first UPDATE packet to Terminal with its new IP address as the Locator. When Terminal received this UPDATE packet, it tried to send a responding packet to Entry using the new address as the destination address. Because the new IP address was the private address behind nat66, it is unreachable for Terminal. Therefore, the three-way UPDATE handshake failed to set up and the connection lost Multi-homing Case Then we changed the default route from Terminal to Router. Previously the packets sending out from Terminal went to Linksys3 and now we changed the default route to Linksys4. From the packets caught by Wireshark, we surprisingly noticed that the connection was not interrupted. Entry accepted the packets from Linksys4, even though the source IP address was not the address on its Hit-IP Address mapping table. Figure9. Packets Captured On Router In order to analyze why the update handshake failed, we captured some packets on Terminal when changing Entry s IP address. The packets below shows that when Terminal received the first UPDATE packet from Entry, it did send a reply packet with fd01:203:405:1::4, which was the Entry s new IP address, as the destination address. From the packets caught on Router, we can t find this packet. The packet must be dropped by Linksys3 who didn t know how to route this packet. (Figure 10) Figure10. Packets Captured On Terminal The whole process suggested that Entry did send HIP UPDATE packets to Terminal notifying its IP address had changed. It initiated a three-way handshake and Figure11. Packets Captured On Router The packets above show that the source IP address changed silently, without disturbing the communication. (Figure 11) If the address changes but SPI remains the same and the checksum is valid, HIP is intended to report to the transport that it was received from the original address. 4 Conclusion This paper verifies HIP on solving multi-homing and mobility though deploying it on the test environment. HIP can support mobility in the environment without NAT-like module through sending UPDATE packets. HIP cannot support mobility in our environment with NAT66 functioning in the edge router, unless more mechanism, like a RVS server, is getting involved. As for multi-homing, HIP does help solving this problem. Our source code is in the following website:

5 References [1] M. Wasserman, F. Baker: IPv6-to-IPv6 Network Address Translation (NAT66), IETF draft-mrw-behave-nat66-02, 2008 [2] F. Baker: Implementing GSE using IPv6/IPv6 Network Address Translation, IETF draft-baker-nat66-gse-00, 2008 [3] Yuan Zhangyi, Ma Yan, Fred Baker, Huang Xiaohong, Zhang Xiaodong, The Implementation of NAT66 and The Solutions of Multi-homing in NAT66 Environment, September, 2009 [4] O'Dell, M.: GSE - An Alternate Addressing Architecture for IPv6, IETF RFC 1884, February 1997 [5] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson: Host Identity Protocol, IETF RFC 5201, April 2008 [6] Moskowitz, R. and P. Nikander: Host Identity Protocol (HIP) Architecture, IETF RFC 4423, May 2006 [7] Nikander, P., Henderson, T., Vogt, C., and J. Arkko: End-Host Mobility and Multi-homing with the Host Identity Protocol, IETF RFC 5206, April [8] Wang Jizeng, Guo ge, Zhang yanlong: NAT traversal solution based on host identity protocol, Computer Engineering and Design,May 2008