MultiGate6: An IPv6 multihoming gateway using a hybrid approach *

Transcription

1 Computer Communications 29 (2006) MultiGate6: An IPv6 multihoming gateway using a hybrid approach * Chung-ming Huang *, Ching-hsien Tsai, Po-chou Su Laboratory of Multimedia Networking (LMN), Department of Computer Science and Information Engineering, National Cheng Kung University, No. 1 University Road, Tainan 70101, Taiwan, ROC Received 17 January 2005; received in revised form 22 September 2005; accepted 6 October 2005 Available online 20 December 2005 Abstract Multihoming allows a site/host to connect to multiple Internet Service Providers (ISPs) simultaneously. Network fault tolerance (service resilience), load balancing, and provider independent service can thus be achieved using the multihoming technique. With the benefits of the eased renumbering network mechanism and the large addressing space introduced by IPv6 network, multihoming will become much more popular. In this paper, a hybrid IPv6 multihoming approach, which combines the host-based multihoming approach and the router-based multihoming approach, is proposed. In the proposed design, Router Advertisements defined in Internet Control Message Protocol version 6 (ICMPv6) is adopted to handle the multihoming message exchange between the router and the hosts within the IPv6 multihomed network. The corresponding system implementation called MultiGate6 offers fault tolerance, load balancing, and provider independence services to both site and host levels. Hosts within the multihomed network are able to establish connections through multiple links simultaneously. With the five load balancing policies provided in MultiGate6, congestion of a single link can be prevented and thus bandwidths of links can be utilized more efficiently. q 2005 Elsevier B.V. All rights reserved. Keywords: Multihoming; Router advertisement; Fault tolerance; Load balancing; IPv6; ICMPv6 1. Introduction The general definition of multihoming is that a host, a site, or a network is able to connect to the Internet through multiple external links or Internet Service Providers (ISPs) rather than a Abbreviations BB, the Best Bandwidth policy type that can be applied by MultiGate6 for the load balancing function; FT, fault tolerance; HD, the Host Defined option that the host can use to ignore the indicated load balancing policy sent from MultiGate6; LB, load balancing; LLF, the Least Load First policy type that can be applied by MultiGate6 for the load balancing function; LSD, the Link Status Daemon by which MultiGate6 can detect the status of each link; MH, multihoming; MHH, multihomed host; RA, Router Advertisement; RAD, the Router Advertisement Defined option that the host can use to accept the indicated load balancing policy sent from MultiGate6; RADVD, Router Advertisement Daemon; RR, the Round Robin policy type that can be applied by MultiGate6 for the load balancing function; SRTT, the Shortest Round Trip Time policy type that can be applied by MultiGate6 for the load balancing function; UD, the User Default policy type that can be applied by MultiGate6 for the load balancing function. * This research is supported by Taiwan NICI IPv6 Steering Committee, R&D Division, under contract number R-0300, and the National Science Council of the Republic of China under the grant number E * Corresponding author. Tel.: C /62523; fax: C address: huangcm@locust.csie.ncku.edu.tw (C.-m. Huang) /$ - see front matter q 2005 Elsevier B.V. All rights reserved. doi: /j.comcom single one. The Internet Engineering Task Force (IETF) IPv6 Multihoming (multiv6) WG [1] also gives multihoming a formal definition as a site that has more than one connection to the public Internet with those connections through either the same or different ISPs. From the above definition, if a node is able to connect to the Internet with more than one IP address as alternatives (even those IP addresses belong to the same ISP), the node can be regarded as multihomed. Although using more than one IP address belonging to a single ISP can prevent a node from being totally inaccessible to the Internet due to some attacks, such as Deny of Service (DoS) attack, to one specific IP address, it does not provide resilience if critical failure happens in the ISP. On the contrary, multihoming with different ISPs can tolerate the fault of an ISP at one time because the host/site can still connect to the Internet through the other ISPs. A node or a host can be multihomed in two basic ways. The first one is a single network interface that is bound to multiple IP addresses, even if these IP addresses belong to the same ISP. The original use of binding multiple IP addresses to a single network interface is to achieve smooth transition in the case of address changes of servers. Recently, this method is widely used to create virtual servers in World Wide Web (WWW) servers. The second one is multiple network interfaces, which may be homogeneous, e.g. multiple b WLAN interfaces, or heterogeneous, e.g. a Wireless LAN interface, a Bluetooth

2 C.- Huang et al. / Computer Communications 29 (2006) network interface, and a UMTS 3G network interface, that are bound to multiple addresses. One reason for equipping a computer with more than one network interface is cost: sometimes two low bandwidth connections cost less than a single high bandwidth connection. Many concerns motivate a host or a site to be multihomed, such as (i) fault tolerance: the connections to the Internet can migrate to alternative links to prevent the loss caused by the sudden failure of the primary link, (ii) load balance: the load can be spread across multiple links to prevent a specific link from being overloaded, (iii) provider selection: selecting an ISP that can provide more cost-effective quality of service, (iv) performance: in the event that a site is multihomed with several low-bandwidth links, the overall performance may be equal to a single high-bandwidth link but with lower cost, and (v) policy concern: a government department or a campus network may not be allowed to serve commercial traffic through its connectivity provider. In Ipv4 network, one method to achieve multihoming is to advertise the ASN prefix of a multihomed site to BGP neighbors. An alternate method is to advertise non-aggregated PA (Provider Assigned) prefix of one ISP through all other connected ISPs. Both methods would place more cost on the ISPs and cause a serious routing problem. Another method to carry out multihoming is to adopt the use of Network Address Translation. A gateway with built-in NAT service provides the ease of renumbering by overwriting IP headers depending on some specific needs or policies for outbound links. Although the NAT gateway approach offers the advantage of minimal administration, it also causes other problems, e.g. lack of external reachability into the local site, and the barrier of some end-to-end network applications. Two particular solutions for achieving multihoming are router-based solutions and host-based solutions. Methods described in the previous paragraph can be categorized as router-based solutions, but they are not suitable for the IPv6 multihoming environment. The advertisements of Provider Independent (PI) blocks for all multihomed sites or networks to Default Free Zone (DFZ) will cause overloads to the global Internet routing infrastructure and therefore it is not a scalable approach. On the other hand, one essential reason driven for IPv6 is to avoid the use of NAT. Thus the NAT approach introduced in IPv4 should not be considered in the IPv6 network environment. For the host-based solution, the multihoming support is enabled in hosts. One method is to assign multiple network addresses to a host and do network address selection while establishing connections. However, due to the lack of the status information about links, the selected address may not be the best one for the connection, and moreover, load balancing among links is unable to be achieved. The host-based approach may also cause ingress filtering problem. That is, when a host multihomed to providers A and B selects a source address from provider A, and sends the packets towards provider B, provider B may reject the packets because the source address is not within its own address space. On the other hand, the Default Address Selection (RFC3484) [2] algorithm used to select source address Fig. 1. An example of using the longest-match algorithm to select source address. is defined on a longest-match prefix basis. However, although the longest-match prefix essentially means the selected source address is closer to the destination node, using the selected source address does not guarantee a better transmission performance. Fig. 1 depicts an illustrated example, in which the selected path is via ISP-A using the longest-match method, but the available bandwidth of path-a is lower than that of path- B. Under this concern, selecting ISP-B address as the source address, i.e. the connection is via path-b, will contribute better transmission performance, even though the prefix of ISP-B is not the longest-match one to the address of the server. In this paper, an IPv6 multihoming gateway system called MultiGate6 is designed and implemented. MultiGate6 adopts a hybrid approach which merges both host-based and routerbased solutions to achieve multihoming. MultiGate6 is an IPv6 multihoming gateway which connects to multiple external links. MultiGate6 also functions as a router which can broadcast Router Advertisements with multihoming information to hosts. Within the multihomed network administrated by MultiGate6, connections of hosts can be held through multiple links and thus multihoming function is enabled in hosts. On detecting the failure of a link, MultiGate6 will let it known to all hosts to prevent the loss caused by hosts trying to establish connections through the failed link. Five link selection policies are provided in MultiGate6 to allow a host to do provider selection for its preference, or to use the network address indicated by MultiGate6 for load balance consideration. Hence, bandwidths of links can be utilized more efficiently to provide hosts better network service experiences. The rest of this paper is organized as follows. In Section 2, current multihoming approaches for IPv6 network environments are described. In Section 3, the functional scenario of

3 1844 C.- Huang et al. / Computer Communications 29 (2006) MultiGate6 is depicted. In Section 4, protocols inside Multi- Gate6 that are used to achieve Fault Tolerance and Load Balancing are presented. In Section 5, details of MultiGate6 implementation are described. In Section 6, performance evaluation of MultiGate6 is presented, and in Section 7, conclusion remarks are given. 2. Related works The solutions for achieving IPv6 multihoming can be classified as five categories: (1) router-based solutions, (2) twospace identifier/locator solutions, (3) mobility solutions, (4) transport layer solutions, and (5) host-based solutions. Since the approaches for IPv6 multihoming are numerous, we choose part of the approaches for each category to expound the specialities of each one. 1. IPv6 router-based solutions: These solutions are designed in the way that no change is needed for hosts. This category of approaches uses the IPv6 routing system like the IPv4 approach. However, mechanisms are added to solve the scalability problem of injecting prefixes to the DFZ. The use of provider aggregatable (PA) addressing is also considered in IPv6 routing solutions. Multihoming mechanisms of router-based solutions are summarized as follows. IPv6 multihoming with route aggregation [3]: In this approach, a site that is multihomed will choose one of its ISPs as the primary link. Assuming an IPv6 site is multihomed with ISP A and ISP B, and ISP A is chosen as the primary link of the site. The multihomed site will advertise the prefix of ISP A to all of its connected ISPs, including ISP B. ISP B will propagate the advertisement of prefix A only to ISP A, and thus this approach does not cause the routing table explosion of DFZ. Since ISP A advertises its own aggregation into the Internet, the packets destined to prefix A are routed to ISP A. ISP A can achieve load balancing by directly forwarding these packets to the site, or to ISP B according to proper routing policies. The drawback of this approach is the single point of failure problem of the primary link. The site will become unreachable when the ISP of the primary link fails. Routing header usage [4,5]: This approach enforces a multihomed site to have routing via a specific ISP. It inserts a routing header containing an intermediate any cast address that identifies the routers of the intended ISP. Therefore, the packets with such routing header will be routed to the selected ISP. The drawback of this solution is that the ISP must process the routing header, which causes extra overhead. 2. Two-space identifier/locator solutions: IP addresses are used for both locators of the nodes and identifiers of endpoints. Applications handle identifiers, while locators become the responsibility of the network layer. Therefore, guaranteeing the uniqueness of identifier is an important requirement that may affect IPv6 stateless autoconfiguration. The summary of each two-space identifier/- locator solution is as follows. Host Identity Protocol (HIP) [6]: HIP decouples the transport layer from the network layer and introduces a new host namespace between. Thus the sockets are not bound to IP addresses as they used to be. Applications see the HIP identifiers instead of seeing IP addresses. The mapping between host identifiers and IP addresses can be one to many, hence multihoming can be achieved. Hosts can also change their IP addresses even the communication sessions have been established. When the host is going to change its IP address, it sends an HIP Readdress packet to its peer. After the peer checks the reachability using HIP Address Check and Address Check Reply packets, the new address of the host can actually be used. During the change of IP address, the connectivity can still be preserved. However, the way how HIP hosts interoperate with legacy hosts and the address selection mechanism of HIP are not clear now. Layer 3 shim approach [7]: In this approach, a shim layer is inserted into the host s IP stack. The shim layer maps the single identifier, which is referred as the upper layer ID (ULID), and the set of available locators in the communication session. Unlike HIP, the layer 3 shim approach does not introduce new namespace as its identifier, it uses one locator from the locator set as its identifier instead. Furthermore, the shim layer is located between the IP layer and the transport/upper layers, which can only see the ULIDs. Thus the packets are transmitted end-to-end using the ULIDs by applications. Conceptually, the shim layer functions by placing an extension header before all other IPv6 extension headers. Thus this approach will cause packet overhead and reduce the available MTU (Maximum Transmission Unit) as a result. Location Independent Addressing for IPv6 (LIN6) [8]: LIN6 is a protocol supporting IPv6 multihoming and host mobility. The approach introduces two types of IPv6 addresses, including the LIN6 generalized ID and the LIN6 address. The LIN6 generalized ID is 128 bits, which consist of a 64-bit LIN6 prefix and a 64-bit LIN6- ID. The LIN6 ID is a global unique identifier and is only used in the transport and upper layers of a host. The LIN6 ID does not change even the host moves from one network to another one. The LIN6 address is 128-bit, consisting of a 64-bit network prefix and a 64-bit LIN6- ID. The network prefix is the network prefix at which the node is actually located. The LIN6 address is used by the network layer to designate the location and the identity of a node. The mapping between the LIN6 generalized ID and the LIN6 address is done by mapping agents, which will resolve the LIN6 generalized IDs to the current LIN6 addresses when the host is about to establish connection. 3. Mobility solutions: Mobility can be regarded as a special case of multihoming. In Mobile IPv6 [9], a mobile node

4 C.- Huang et al. / Computer Communications 29 (2006) (MN) always uses its home address (HoA), and the change of addresses when MN moves is hidden from the transport layer and the upper layer protocols. When a MN moves and acquires a care-of-address (CoA), it sends binding update (BU) to inform the corresponding node (CN) of the change of its address. After receiving the BU, CN can map MN s HoA and the new CoA, and then can redirect the connection to MN. In a multihoming scenario, the above procedure of Mobile IPv6 can be used to inform other hosts when the multihomed host is re-homed. However, the authentication mechanism of Mobile IPv6 needs the cooperation of the host s home agent, which does not exist in multihomed network because the original path used by the multihomed host is not available when it is re-homed. Therefore, modifications are necessary if Mobile IPv6 is intended to be adopted as a multihoming solution. 4. Transport layer solutions: Traditional transport layer protocols, e.g. TCP and UDP, do not support multihoming in nature. The change of IPv6 address will break the ongoing connection semantics. Currently, there are new protocols, e.g. Stream Control Transmission Protocol (SCTP), or the enhanced version of traditional protocols, e.g. Preserving TCP, that can support multihoming features. The protocols and their mechanisms of supporting multihoming are summarized as follows. Stream Control Transmission Protocol (SCTP) [10]: SCTP passes initial endpoint addresses on startup, and each endpoint address can be regarded as a transmission path of the association (SCTP s term for connection ). One of the paths of the association is chosen to be the primary path, in which new data is transmitted through, whereas another path can be used as the path for retransmission if it is necessary. After the association is setup, the HEARTBEAT messages can be used to probe the reachability of each address combination. The SCTP ADDIP extension allows the SCTP association to dynamically add, delete, or change the address being used to achieve multihoming on both peers. The drawbacks of SCTP are heartbeat overhead, security issues on address change, and the requirement to have hosts and applications being SCTP-enabled. Preserving TCP [11]: This approach assumes that each participant in a TCP session may potentially have multiple global IPv6 addresses, and the valid set of these IPv6 addresses that can be used during the lifetime of the TCP connection should be exchanged among participants. The proposal introduces a PREFIXES IPv6 option with the SYN and SYN/ACK packets during the 3-way handshake of a TCP connection establishment. PREFIX_ACK is used by each participant to acknowledge the received PREFIXES. 5. Host-based solutions: The multihoming support is enabled in the end hosts with the benefit of not altering router devices or not introducing new special devices. Multiple addresses and relexing source address checks: Multiple IPv6 addresses can be achieved with router renumbering and multiple Router Advertisements. Although hosts can have multiple globally routable IPv6 addresses, there are some associated issues, such as the ingress filtering problem service provider may reject the packets which are not within its own address space. If the ISPs could switch off the source address checks altogether, the ingress filtering problem then could be solved. However, it needs the cooperation of ISPs and may cause some serious security problems. Source address selection by the host: This approach allows a host to select its source address according to proper algorithms or policies using source address discovery when it is configured with multiple IPv6 addresses. Alternately, the host can tunnel its packets to the correct site exit router using exit router discovery. Both the two approaches require significant changes in the IPv6 implementation in hosts, extra changes in routers, or new ICMP packets. Currently, there are not a lot of implementations for multihoming gateways. In [12], the authors proposed a dynamic traffic sharing method with the IPv4 NAT function and a backbone selection metrics based on connection set-up time. The router tries to establish a connection through each backbone simultaneously and selects the first backbone through which a connection has been actually established. Since the approach adopts TCP SYN packet for implementation, the work does not support UDP traffic sharing. In [13], an IPv6 gateway with a prefix translation mechanism and a backbone selection scheme are presented. The gateway in this approach examines the packets from the host and collect the information of its destination. Then, the gateway measures the Round-trip Time (RTT) of the destination via each available external link and selects the most appropriate one having the minimum RTT. The packet is then translated into the prefix of the selected backbone. This approach may suffer performance degradation because packets must wait at the gateway for the RTT measurement and prefix rewriting. Both the above two related works adopt the NAT technique to implement their multihoming gateways. However, NAT may cause some serious problems, e.g. single point of failure, increasing network latency, and lack of support for some end-to-end applications. Thus, the NAT approach may not be a considerable approach in IPv6 network. 3. The functional scenario of MultiGate6 The functions that the MultiGate6 provides are as follows: Multihomed network: MultiGate6 provides an IPv6 multihomed network environment to hosts. Thus hosts can establish their connections with multiple link choices. Link status monitoring: MultiGate6 detects and monitors the network status of each link. Fault tolerance: MultiGate6 will let the failed link be known to all hosts to prevent the loss caused by hosts trying to establish connections through the failed link. Load balancing: By calculating loads, measuring

5 1846 C.- Huang et al. / Computer Communications 29 (2006) Fig. 2. The abstract multihomed network environment using MultiGate6. bandwidths of all links, and measuring Round-Trip Time to ISPs gateways, MultiGate6 and hosts apply a messagebased mechanism to achieve load balancing. The scenarios corresponding to the functions described above are depicted as follows Multihomed network The basic function of MultiGate6 is to provide an IPv6 multihomed network to hosts. To achieve this, MultiGate6 connects to multiple external links and thus the internal network is multihomed. Fig. 2 depicts an abstract multihomed network environment using MultiGate6. To enable host-level multihoming, MultiGate6 also acts as an IPv6 router, which broadcasts Router Advertisements periodically. The prefixes of alive (working) links will be broadcasted to hosts via Router Advertisements. For example, assume a MultiGate6 is multihomed with two links connected to two different ISPs, such as ISP-A, and ISP-B, and assume both links works well. MultiGate6 will, respectively, broadcast Router Advertisements with the prefix of ISP-A and ISP-B periodically or on receiving router solicitations from hosts. Hosts within the multihomed network environment administrated by the MultiGate6 receive Router Advertisements of different network prefixes and hence multiple network addresses are available for a host. When a host is going to establish a connection to the Internet, it is able to select whatever network address it prefers, or apply the network address specified by the MultiGate6 for the load balancing concern. In this way, there will be no ingress filtering problem because the packets will follow the right route to the destination after mapping the MultiGate6 s routing table of the multihoming gateway. For example, packets that have ISP-A s prefix address as their source addresses will be transmitted through ISP-A s network. Moreover, MultiGate6 will not cause the routing problem because there would be no non-aggregated routes needed to be advertised specifically to the backbone routers. Fig. 3 shows a scenario that a MultiGate6 works to provide a multihomed network environment for hosts. A host then can establish connections of different source addresses Link status monitoring and fault tolerance If one of the external links suddenly fails and becomes inaccessible to the Internet, hosts should be prevented to try connecting through the failed link. To actively prevent the host from trying to connect via failed links, MultiGate6 periodically measures the link status between MultiGate6 and the ISP s gateway. On detecting a link outage between, MultiGate6 broadcasts messages indicating the faulty condition, which includes the prefix of the link, to hosts. When a host receives the message indicating the faulty condition, the host disables the network address of the indicated prefix in the message, and thus the host will not try to establish connections through the failed link. Fig. 3. The scenario of enabling host-level multihoming on a host s startup.

6 C.- Huang et al. / Computer Communications 29 (2006) Fig. 4. An illustrated scenario of fault tolerance. If the failed link later recovers to work and is detected by MultiGate6, MultiGate6 will broadcast messages indicating the well-functioning condition, which includes the link prefix to hosts. On receiving the messages of the same indicated prefix again, the host enables the use of the link s network address. Thus the address becomes usable for hosts further connections. Fig. 4 depicts an illustrated scenario for having fault tolerance Load balancing The other essential benefit using the multihoming technique is load balancing. For host-based solutions, load balancing is hard to achieve due to the lack of the network status information. As an IPv6 multihoming gateway, MultiGate6 can be in charge of collecting and calculating the needed data for load balancing. In the design of the MultiGate6 s load balancing function, five kinds of load balancing policies are developed for different preferences. When the load balancing function is enabled and a preferred load balancing policy is set, MultiGate6 starts to periodically broadcasts messages of load balancing to hosts. The load balancing message contains the information of the selected load balancing policy, e.g. the type of the policy and the prefix of the link to apply after evaluating loads of all links. For example, assuming the load balancing policy is set as Best Bandwidth, which evaluates loads by calculating available bandwidths of links. Under the setting, MultiGate6 will periodically calculate and compare bandwidths of all connected links. After comparing bandwidths of all links, the link with the largest available bandwidth will be selected and the prefix of the link will then be contained in the message, which is going to be broadcasted to hosts. When a host receives the message, which includes information of the load balancing type, such as Best Bandwidth and a specific prefix, the host will apply the network address of the specific prefix for its further connection establishments. That is, further connections of multihomed hosts will be established through the link that has the largest bandwidth. MultiGate6 repeats the action and broadcasts messages for the load balancing if the selected link changes after load evaluation for load balancing concern. Fig. 5 depicts such a scenario. In our design, a host can decide whether to accept to apply the address selected by MultiGate6, or use its own preferred address for other concerns, e.g. some services are limited to specific addresses. In this way, load balancing can still be done Fig. 5. An illustrated scenario of load balancing.

7 1848 C.- Huang et al. / Computer Communications 29 (2006) Fig. 6. The modified format of the prefix option of Router Advertisements. even in the case that some hosts intend to use specific addresses. 4. Protocol design In this section, the protocols designed for MultiGate6 to achieve fault tolerance and load balancing corresponding to the scenarios described in Section 3 are introduced in detail. According to the MultiGate6 s functional scenario depicted in Section 3, in addition to regular Router Advertisement messages, two more kinds of messages are necessary to achieve fault tolerance and load balancing. MultiGate6 utilizes some optional fields exist in Router Advertisements to achieve multihoming. To accomplish fault tolerance and load balancing, part of the reserved field is defined as the Multihoming Option to carry extra information to hosts. Two fields in Multihoming Option are MH Service Type and Policy Type. The modified prefix option format is depicted in Fig. 6, and the definitions of the multihoming option fields are depicted in Fig Fault tolerance MultiGate6 enables a host to establish connections through alternate links if a failure occurs in the currently used link. A link status daemon is created in MultiGate6 to detect whether any of the links fails. The link status daemon is based on Internet Control Message Protocol version 6 (ICMPv6) [14] packets and keeps the information of each link status. The information refers to the status of each link, such as link alive and link failed. If MultiGate6 probes a specific path is out of linkage, the link status daemon updates the status information of the link and informs the hosts within the multihomed network by broadcasting a Router Advertisement, in which the value of the MH Service Type field of the multihoming option is filled with 0001, and the prefix field is filled with the prefix of the ISP which is suffering a linkage failure. On receiving the Router Advertisement of the fault tolerance type, the host reads the value of the multihoming option field, and disables the corresponding IP address, of which the prefix is the same as the indicated one in the prefix field. Hence, new connections will not be established through the failed link. On the other hand, since MultiGate6 checks the status information of each link before broadcasting Router Advertisements to announce available prefixes to hosts, Router Advertisements will not contain the prefix of the failed link. When the failed link recovers to work correctly and detected by the link status daemon of MultiGate6, the link status daemon again updates the link status information and broadcasts the Router Advertisement of the fault tolerance type including the prefix of the recovered link to hosts. On receiving the Router Advertisement, the host enables the network address corresponding to the indicated prefix in the Router Advertisement. Then, hosts are able connect to the Internet through the recovered link as an alternative Load balancing Load balancing means distributing the traffic evenly and dynamically among different paths to avoid link congestion and saturation. The load balancing function of the MultiGate6 allows hosts in the multihomed network to establish connections through links that are less loaded. In this way, load is shared as equivalently as possible within all available links and all available bandwidths can be utilized as much as possible. In other words, hosts in the multihomed network can access the Internet with better connection quality, such as more bandwidth and faster transmission rate than the single-homed network. Fig. 7. Definitions of the Service Type field and the Policy Type field.

8 C.- Huang et al. / Computer Communications 29 (2006) In Section 4.1 we have defined the fields of Multihoming Option inserted in the reserved field of Router Advertisement for multihoming. With value 0010 in the MH Service Type field, the Router Advertisement is used for load balancing. The Policy Type field is used to indicate which policy is applied for load balancing. Five defined load balancing policies are RR (Round Robin), LLF (Least Load First), SRTT (Shortest Round Trip Time), BB (Best Bandwidth), and UD (User Default). Administrator of the MultiGate6 is in charge of deciding which load balancing policy is to be adopted within the multihomed network. These five load balancing policies and the corresponding actions taken by hosts after receiving the Router Advertisements are as follows. On MultiGate6 s side: RR (Round Robin) policy: It is the simplest load balancing policy. When the Router Advertisement is broadcasted to hosts, value 0000 will be filled in the Policy Type field to inform hosts to change their load balancing policy to Round Robin. LLF (Least Load First) policy: MultiGate6 periodically calculates amounts of data (in bytes) transferred for each of its network interfaces, which are connected to different external links. The link with least load will be chosen for further connection establishments of hosts. When the Router Advertisement is broadcasted to hosts, the prefix of the least-load link will be used as the prefix in the prefix option and 0001 will be filled in the Policy Type field. SRTT (Shortest Round Trip Time) policy: MultiGate6 uses the response time to each ISP s gateway in conjunction with heuristics to evaluate loads of links. The link with the Shortest Round Trip Time will be chosen for further connection establishments of hosts. When the Router Advertisement is broadcasted to hosts, the prefix of the shortest-round-trip-time link will be used as the prefix in the prefix option and 0010 will be filled in the Policy Type field. BB (Best Bandwidth) policy: MultiGate6 uses the Pchar [15], a tool for Measuring Internet Path Characteristics to detect the available bandwidth of each link. The link with the best measured bandwidth is regarded as having the least load and will be chosen for further connection establishments of hosts. When the Router Advertisement is broadcasted to hosts, the prefix of the best-bandwidth link will be used as the prefix in the prefix option and 0011 will be filled in Policy Type field. UD (User Default) policy: This policy provides the simplest administration in the hosts use of IP addresses. When the Router Advertisement is broadcasted to hosts, 0100 will be filled in the Policy Type field to inform hosts to change their load balancing policy to User Default. On the host s side: RR (Round Robin) policy: On receiving this kind of Router Advertisement, a host will change its IP address in its address list alternatively to establish connections through different links sequentially, until it receives a new Router Advertisement indicating other load balancing policy. LLF (Least Load First), SRTT (Shortest Round Trip Time), or BB (Best Bandwidth) policy: On receiving these kinds of Router Advertisements, a host will use the IP address of which the prefix is the same as which is indicated in the prefix option of the Router Advertisement. The host will use this address for further connections until it receives a new Router Advertisement indicating other load balancing policy. UD (User Default) policy: On receiving this kind of Router Advertisement, the host will use its default IP address (from manual settings or network address auto-configuration) for further connections until it receives a new Router Advertisement indicating other load balancing policy. On the other hand, a host shall be able to decide whether to accept Router Advertisements of the load balancing type or not. A host may have to use a specific network address for some reasons, i.e. services that can only be accessible from specific addresses. Therefore, a host can switch between two kinds of status: RAD (Router Advertisement Defined) and HD (Host Defined). On the RAD Status, the host receives the Router Advertisement and alternates its network addresses according to the load balancing policy indicated in the Policy Type field. On the HD status, the host ignores the indicated load balancing policy and establishes connections with the network address specified by the user. If the user does not specify which network address to use, the host will use the network address which has been advertised in previous Router Advertisements. 5. System development The design and implementation of MultiGate6 is based on the Router Advertisement Daemon (RADVD) [16] executed in the RedHat 9.0 operating system. RADVD is executed in a Linux or BSD system acting as an IPv6 router. RADVD sends Router Advertisement messages, specified by RFC 2461 [17], to a local Ethernet LAN periodically or when requested by a node sending a Router Solicitation message. In this section, the implementation of MultiGate6 is presented in detail System architecture Fig. 8 shows the system architectures of MultiGate6 and Multihomed Hosts (MHHs). The system consists of the following components: Multihoming module, Router Advertisement generator, Neighbor Discovery mechanism, ICMPv6 module and source address selection module. Each of the components defines a set of functions, which are used to access each component s services. The features of each component are as follows: Multihoming module: The multihoming module in Multi- Gate6 consists of (1) Load Balance Module (LB) and (2) Fault Tolerance Module (FT). The LB module is implemented to achieve the load balancing function

9 1850 C.- Huang et al. / Computer Communications 29 (2006) Fig. 8. System flow chart of MultiGate6. MHH refers to the host within multihomed network administrated by MultiGate6. described in Section 4.2, and the FT module is implemented to avoid the hosts to establish connections through the failed links. Router advertisement generator: Router advertisement generator periodically generates a Router Advertisement, which specifies the multihoming policy option in the Router Advertisement. ICMPv6 module: ICMPv6 module is a multi-functional control program that supports error reporting, Neighbor Discovery Address Resolution/Configuration and Redirect. Neighbor Discovery is used by IPv6 nodes to implement important functions, among which are the following: Locating neighbor routers Learning prefixes and configuring parameters related to address configuration Auto-configuring addresses to establish relationships between link layer addresses and IPv6 addresses Discovering duplicated addresses The Neighbor Discovery mechanism in MultiGate6 contains the main function achieved by the Router Solicitation packets and the Router Advertisement packets, which realize the auto-configuration of multiple addresses in MHHs. Source address selection module: The source address selection module in the MHH is used to let the MHH receive address selection information broadcasted by MultiGate Implementation of load balancing function A network environment is changeable and the network status is not stable all the time, such as network delay, packet loss, congestion, failed link and narrow available bandwidth. Load Balancing (LB) Module and Fault Tolerance (FT) Module are implemented to efficiently utilize the multihomed network resources. With the two modules, MultiGate6 achieves load balancing and fault tolerance by processing the Router Advertisement with the multihoming option to notify MHHs to apply the indicated address. A LB daemon is invoked by RADVD on MultiGate6. After the startup of RADVD, it instructs which kind of policy the LB should apply. Then, an MHH can make simultaneous use of several IP addresses and dynamically alternate the address used for each connection according to the policy. Fig. 9 is a functional flow example which applies the SRTT load balancing policy. The execution steps are as follows. 1. When an MHH starts up, it sends a Router Solicitation message to MultiGate6. 2. MultiGate6 executes ProcessRA( ) to broadcast Router Advertisements and apply SRRTMode( ) to adopt the policy of Shortest Round Trip Time. 3. MultiGate6 broadcasts Router Advertisements to the MHH. 4. MultiGate6 measures the Round-Trip Time via each available external link to each ISP. If the default path should be changed for the load balancing concern, the Load Balance Daemon (LBD) will call the SelectionChange( ) function. 5. Multigate6 executes the AddMHOption function of RADVD to fill the multihomed option with service type load balancing, policy type SRTT, and the preferred prefix. 6. MultiGate6 broadcasts the Router Advertisements to MHHs. 7. After the MHH receives the message, it will call the PrefixChange( ) function to alternate the relevant IP addresses when the connection is to be initiated.

10 C.- Huang et al. / Computer Communications 29 (2006) Fig. 9. The functional flow example of applying the SRTT load balancing policy Implementation of fault tolerance function After the LB daemon is startup, the FT module will also be driven. In the FT module, The Link state daemon (LSD) is implemented to detect the situation of each link. The daemon measures Round-Trip Time (RTT) using the ping6 utility. The ping6 utility uses the ECHO_REQUST datagram to elicit an ICMPv6 ECHO_RESPONSE from the ISP gateway in a predefined period of time. If ECHO_TIMEOUT happens, the LSD will instruct the host to disable the prefix of this path. Fig. 10 depicts the functional flow for achieving the fault tolerance function in MultiGate6. The execution step is as follows. 1. When an MHH starts up, it sends a Router Solicitation message to MultiGate6. 2. MultiGate6 calls ProcessRA( ) to send Router Advertisements. 3. MultiGate6 broadcasts Router Advertisements to the MHH. 4. If the link of an ISP fails, the link status daemon will call the LinkStateChange( ) function to update the status flag. 5. The next stage requires calling the AddMHOption( ) function of RADVD to fill the multihoming option with service type Fault Tolerance and deprecate the prefix. 6. MultiGate6 broadcasts the Router Advertisements to the MHHs. 7. After the MHH receives the message, it will call the PrefixDisable( ) function to deprecate the prefix Implementation of the source address selection function The source address selection module is implemented in the MHH to select the address indicated by MultiGate6. We modify addrconf_prefix_rcv in Linux kernel to receive the multihoming option and modify ipv6_get_saddr to support the IPv6 multihoming selection policy. If the application does not request a particular IPv6 address, the ipv6_get_saddr will check the policy of multihoming option and apply the indicated address. The following recapitulates the manner by which the kernel determines what the source address of an outbound packet is based on our IPv6 Multihominmg scheme. The application is already using the socket, in which case, the source address has been chosen. Also, the application can specifically request a particular address by using the bind call. So the kernel will apply the source address given by the application. Fig. 10. The functional flow for achieving the fault tolerance function.

11 1852 C.- Huang et al. / Computer Communications 29 (2006) If the application does not select the source address for the outbound packets, the kernel will select the source address according to the policy type of the Multihoming option. If the load balancing policy is not specified, the first address configured on the interface is to be applied. 6. Performance evaluation In this section, some performance evaluations of Multi- Gate6 are given. The average load ratio and the variance for each load balancing policy are calculated to evaluate the load balancing efficiency. Moreover, some experiments specific to load balancing policies are designed to evaluate the effect of applying the policy. The influence of the Router Advertisement interval on load balancing efficiency is also examined in this section Experimental environment According to the characteristic of IPv6, a host can be assigned with multiple IPv6 addresses using IPv6 autoconfiguration [18]. In order to configure multiple addresses in a host, we add two different prefixes to the RADVD configuration file (/etc/radvd.conf) of MultiGate6. Upon the execution of RADVD, a host can have multiple addresses using stateless configuration. Fig. 11 is the configuration of the experimental environment. The MMNET is established in Department of Computer Science and Information Engineering, National Cheng Kung University with standard Ethernet supporting 100 Mbps. Two IPv6 experimental network backbones in Taiwan that the MultiGate6 connects are HINET and ASNET. The IPv6 network address prefixes that HINET and ASNET offered are 3ffe:3600:1a::/48 and 3ffe:4001:212a::/48, respectively. By using Pchar, each one of the two links is measured to provide 10 Mbps bandwidth. Thus the HINET and ASNET can be regarded as the two ISPs that can provide 20 Mbps bandwidth in total for the multihomed network. Network traffic is Fig. 11. Configuration of the experimental environment. randomly produced by using scripts to execute network applications repeatedly, e.g. web browsing and FTP services, to emulate actual mass bandwidth usage of many hosts. In our experiment, lftpget is adopted to connect to the FTP service at 2001:770:18:2::1:3 and perform downloading tasks of random files. On the other hand, MultiGate6 adopts Router Advertisements to achieve load balancing. RADVD with the default configuration, which may send the Router Advertisement at a maximum interval of 600 s, is not suitable to evaluate the load balancing performance of MultiGate6. Thus, to have the evaluating experiments described in Sections 6.2 and 6.3, the interval of broadcasting Router Advertisements is set to 10 s, which is a legal value allowed in RFC 2461, by modifying RADVD. In Section 6.4, the interval of broadcasting Router Advertisements is changed to other values in order to evaluate its influence on load balancing performance Evaluation results on path load ratio According to our load balancing policies, the administrator of MultiGate6 is able to choose a suitable policy to optimize the network performance. In this experiment, we evaluate the traffic load ratio of HINET (Path-HI) and ASNET (Path-AS) for each policy. Fig. 12 illustrates the traffic load ratio of Path-AS for each policy. For both RR and UD policies, the source address is decided by the MHH. Thus, they cause less system overhead in MultiGate6. For the UD policy, the host is free to choose which link to establish its connections for the provider selection concern. If the user does not request a particular IPv6 address, the system will choose the first address configured for the host. Connections of a host will go through the same path on MultiGate6. Therefore, the traffic load is far from being balanced between Path-HI and Path-AS. Fig. 12(a) and (b) shows the evaluation results of RR and UD, respectively. SRTT, LLF and BB policies let MHHs apply the source address indicated by MultiGate6. MultiGate6 measures the network status of each link and informs MHHs to connect through the selected path. Fig. 12(c) shows the evaluation result of policy SRTT. The SRTT policy calculates the response time of each ISP, and the one with faster response time will have higher priority. Once the response time becomes longer, which means the traffic of the path may be crowdy, MultiGate6 will choose the other link for MHHs further connections. Fig. 12(d) is the evaluation result of policy LLF. The LLF policy calculates the amount of data (in bytes) transferred in each of its network interfaces in a pre-defined period time. MultiGate6 will choose the path with lower load for MHHs further connections. Since an ISP gateway may also be connected with some subnets other than MultiGate6 s subnet, the path load should also consider other subnets bandwidth usage. Therefore, it may not be accurate enough for load balancing if the load is only calculated in each network interface by one subnet itself. Furthermore, the LLF policy is not suitable under the circumstance that bandwidths of links are not similar, e.g. Path-A offers a high bandwidth and path-b

12 C.- Huang et al. / Computer Communications 29 (2006) Fig. 12. Traffic load ratio of Path-AS Traffic load ratio of Path-AS: (a) for policy RR, (b) for policy UD, (c) for policy SRTT, (d) for policy LLF, and (f) for policy BB. offers a much lower bandwidth than Path-A. If the traffic load calculated in Path-A is a little bit heavier than that of Path-B, although the available bandwidth of Path-A is likely to be higher than that of Path-B, the LLF policy will still choose Path-B for MHHs to connect through. Thus, the above factors should be considered to apply the LLF policy for the multihomed network. Fig. 12(e) is the evaluation result of policy BB. The BB policy uses the Pchar to calculate the bandwidth of each link. Comparing with other policies, policy BB achieves the best load balance between path-as and path-hi. However, in order to calculate the available bandwidth, MultiGate6 has to send a lot of packets to ISPs, which may waste some bandwidth and cause extra overheads. In order to evaluate the load balancing efficiency of the load balancing policies for more detail, the average load ratio, variance, and standard deviation of each policy is calculated. We do not calculate the data of the UD policy because it lets MHHs apply their default addresses without maintaining the balance of load actively. Table 1 shows that the average load ratio is around 50G10%. However, it may not be precise enough to evaluate load balancing efficiency using the average load ratio. Taking into comparison of Fig. 12(a) and (e) as an illustration. Although the average load ratio of RR (50.9%) is better than that of BB (57.6%), from the two figures we can observe that the variance of policy RR s load ratio curve is larger than that of policy BB. Therefore, the variance is also calculated to be taken into consideration to evaluate load balancing efficiency. The result shows that, policy BB has the smallest load ratio variance value (0.0133), and the SRTT policy has the largest one (0.0361), whereas the standard deviations are 11.5 and 19.0%, respectively. From the aforementioned experimental results, except the UD policy, load balancing policies of MultiGate6 can conduct Table 1 The load ratios and variances of Path-AS with different load balancing policies Policy Avg. load ratio of Path-AS (%) Load ratio variance of Path-AS Standard deviation (%) RR LLF SRTT BB

13 1854 C.- Huang et al. / Computer Communications 29 (2006) Fig. 13. The measurements of Round-Trip Time in Path-HI and Path-AS after applying the SRTT policy. MHHs to distribute the load nearly evenly in the two paths. On the other hand, any MHH can choose whether to accept MultiGate6 s load balancing Router Advertisements or not. Thus, some MHHs can connect through some specific links on their demands without breaking the whole load balance of all links Evaluation results on effects of SRTT, BB, and LLF Some additional experiments are done to evaluate the effects of applying the SRTT, BB, and LLF policy. The SRTT policy selects the path that has the Shortest Round Trip Time. For the SRTT policy, we evaluate its efficiency by measuring the Round-Trip Time of Path-HI and Path-AS. From Fig. 13, we can observe that the curves of Path- HI and Path-AS are likely to be symmetric. It means that, after applying the SRTT policy, MHHs tend to establish connections through the path that has the Shortest Round Trip Time. More connections will cause more load in a path and hence the delay will increase. Once the path with the shorter Round-Trip Time formerly has longer Round-Trip Time than the other one later due to the more load caused by the connections built by MHHs, MultiGate6 will inform the MHHs to connect through the other path. The load will be distributed to the two paths and therefore the Round-Trip Time of the two paths will likely to be similar. Fig. 14 shows the available bandwidths of Path-HI and Path- AS after applying the BB policy. The BB policy measures the bandwidths of the paths and selects the path that has the larger available bandwidth for MHHs to connect through. In our experimental environment, both Path-HI and Path-AS have the Fig. 14. The measurements of available bandwidths in Path-HI and Path-AS after applying the BB policy.

14 C.- Huang et al. / Computer Communications 29 (2006) Fig. 15. The measurements of loads in Path-HI and Path-AS after applying the LLF policy. same bandwidth of 10 Mbps. From Fig. 14, we can observe that the available bandwidth curves of the two paths are also likely to be symmetric. It means that the load is distributed to the two paths evenly. For the LLF policy, MultiGate6 calculates the amount of data transmitted in each path and selects the least-load link for MHHs further connections. Fig. 15 shows the loads of Path-HI and Path-AS after applying the LLF policy. The loads are measured at every 10 s. The result shows that the loads do not differ much in the two paths, and no path is overloaded particularly. In our experiment, the average load of Path-AS is 86.6 KB whereas the average load of Path-HI is 72.8 KB Evaluation results on interval of Router Advertisements Since MultiGate6 periodically broadcasts Router Advertisements with the multihoming option to MHHs to achieve load balance, the length of the interval that Router Advertisements are sent will influence the load balancing efficiency. For LLF, SRTT, and BB policies, if the interval of broadcasting Router Advertisements is too long, the load will be distributed to the same link for a long time period because MHHs would not change their paths to connect until Router Advertisements of the load balancing type are received. Thus, the bandwidths of all links cannot be utilized because connections are established through the same path for a long period of time. However, the shorter the interval is, the more Router Advertisements will be broadcasted at the same time. More Router Advertisements will also cause more overheads. Therefore, an appropriate interval should be set to achieve better load balancing efficiency without causing too many overheads. Fig. 16 shows the average load ratios of Path-AS corresponding to different Router Advertisement intervals, from 5 to 60 s. We do not do experiments on RR and UD policies because the RR policy lets the MHH alternate the address automatically in MHH itself, whereas the UD policy lets the MHH apply its default address to connect. The length of the Router Advertisement interval does not affect the RR and UD policies. From Fig. 16, we can observe that the value of the average load ratio is unrelated to different Router Advertisement intervals. However, from Fig. 17, which shows the load ratio variance of Path-AS corresponding to different Router Advertisement intervals, we can observe that the load variance is smaller with the smaller values of Router Advertisement interval. It means that when the Router Advertisement interval is smaller, the variance of the load ratio is also smaller. In other words, smaller Router Advertisement intervals result in better load balancing efficiency and better bandwidth utilization. Fig. 16. The average load ratios of Path-AS corresponding to different Router Advertisement intervals. Fig. 17. The variances of the load ratio of Path-AS corresponding to different Router Advertisement interval.

15 1856 C.- Huang et al. / Computer Communications 29 (2006) To setup an appropriate Router Advertisement interval, some factors should be taken into consideration, such as the number of MHHs, bandwidth usage of each MHH, and bandwidths of links, etc. More MHHs potentially mean more total bandwidth usage. Bandwidth usage of each MHH will also affect the total bandwidth usage. That is, the more the number of MHHs and the larger of the bandwidth usage of each MHH is, the shorter the Router Advertisement interval should be set to achieve better load balancing efficiency. On the other hand, low bandwidth links mean more congestions may happen. Thus the Router Advertisement interval should also be set shorter to prevent the congestions in low-bandwidth links Summary and discussion From the evaluation results of the above experiments, the usefulness of MultiGate6 is described as follows. MultiGate6 can be used as the multihoming Gateway of a site, a SOHO network, or a small enterprise network that wants to have a multihomed network. MultiGate6 can connect to more than one ISP and provide a multihomed network that is associated with fault tolerance and load balancing functions. The advantages of the hybrid approach adopted in MultiGate6 are summarized as follows: Since the packets of MHHs will follow the right routes after mapping the MutiGate6 s routing table, there is no ingress filtering problem. Fault tolerance function is achieved by informing MHHs through Router Advertisements broadcasted by MultiGate6. No extra work or cooperation, e.g. tunnelling, is needed between transit ISPs. The approach does not cause the increment of DFZ. Therefore, the routing table explosion problem is not suffered and thus this approach is scalable. No new protocol is introduced. Only the Router Advertisements sent by MutliGate6 need to be modified. The approach is not complex for deployment. The approach is backward-compatible. The modification of the router advertisement does not affect the hosts/routers that do not support this approach. The approach does not modify the DNS system and hence no impact is caused on DNS. This approach can support all types of traffic, e.g. TCP and UDP. The approach is extendible. More load balancing policies can be developed according to specific requirements, e.g. a policy that enforces MHHs to connect through a specific ISP at specific time. Except the UD policy, the evaluation results also show that the four kinds of load balancing policies achieve the approximate balance of load in our experimental environment, in which the two links have the same bandwidth. However, each load balancing policy has its own advantages, disadvantages, and applicable situations, which are summarized as follows. RR: Sine the RR policy lets the MHH choose the link to establish connection in a round-robin way and does not consider the differed bandwidth between links, it is suitable for the multihomed network in which the bandwidths of links are similar. In our evaluation results, it has a large variance of load balancing performance. However, the RR policy is the simplest way to have load balance and nearly causes no overhead to the multihomed network. LLF: The LLF policy measures the load of each link and chooses the smallest one for MHH s connection of the next time. As that is mentioned before, since the LLF policy does not consider the load caused by other subnets, the LLF policy may not provide good load balancing performance as a result. Moreover, the LLF policy does not consider the differed bandwidth between links. Hence, the LLF policy is only suitable for the multihomed network in which the bandwidths of links are similar. SRTT: In our evaluation results, the SRTT policy achieves good average load ratio, but it also has the largest load ratio variance. The possible reason is that the link with the Shortest Round Trip Time might not promise the best reachability to hosts destinations. The SRTT policy is also suitable for the multihomed network in which the bandwidths of links are not very similar. BB: The BB policy takes some time to measure the bandwidth of each link and chooses the link with best bandwidth. Since the network status keeps changing at all time, the measured bandwidth may not represent the real status of the current time. It also causes the most overhead among the load balancing policies. However, the BB policy achieves the best load ratio variance in our evaluation results, and it is also applicable for the multihomed networks in which the bandwidths of links are not similar. 7. Conclusion In this paper, we have designed and implemented an IPv6 multihoming gateway called MultiGate6. MultiGate6 provides multihomed network, fault tolerance, load balancing, and provider selection functions to hosts. In our proposed method, a Multihoming Option field is inserted in Router Advertisements broadcasted by MultiGate6. With the Multihoming Option field, MultiGate6 can specify two multihoming service types fault tolerance and load balancing, and five load balancing policies RR, LLF, BB, SRTT, and UD, to hosts. The source address selection module is implemented in the host to accept Router Advertisements containing multihoming information, and then the host can apply the indicated network address for different load balancing concerns. On detecting a link failure, MultiGate6 broadcasts the Router Advertisement of fault tolerance to inform hosts not to connect through the failed link. The results of evaluating load balancing effect of the five policies are given in this paper. In our experiment, although Best Bandwidth (BB) policy works best, measuring bandwidths of links also brings overheads to network traffic.

16 C.- Huang et al. / Computer Communications 29 (2006) Therefore, a load balancing policy should be appropriately chosen for the corresponding multihomed network to achieve the best load balancing efficiency. Moreover, we also analyze the effect of load balancing when different intervals are set for MultiGate6 to broadcast Router Advertisements. A short time interval will cause more overhead, while a larger time interval will cause larger variance of load ratio. It can conclude that the following factors the number of MHHs, bandwidth usage of each MHH, and bandwidths of links, should be taken into consideration to set up a proper time interval of broadcasting Router Advertisements. For the future work, an adaptive mechanism can be designed to automatically configure the best load balancing policy and Router Advertisement interval for the administrated network, instead of setting up manually. More load balancing polices can also be designed to achieve better efficiency with minimized overhead, too. References [1] The IETF IPv6 Multihoming Working Group, charters/multi6-charter.html. [2] R. Draves, Default address selection for internet protocol version 6 (IPv6), RFC 3484, IETF, February [3] J. Yu, IPv6 multihoming with route aggregation, IETF Internet Draft: draft-ietf-ipngwgipv6multihome-with-aggr-01.txt, August [4] M. Bagnulo, A. Garcia-Martinez, A. Azcorra, D. Larrabeiti, Survey on proposed IPv6 multi-homing network level mechanisms, IETF Internet Draft draft-bagnulo-multi6-survey6-00.txt, July [5] D. Johnson, S. Deering, Reserved IPv6 subnet anycast addresses, IETF RFC 2526, March [6] IETF Internet-Draft: Host Identity Protocol, [7] IETF Inter-Darft: Architectural Commentary on Site Multi-homing Using a Level 3 Shim, html [8] Internet-Draft: LIN6 (Location Independent Networking for IPv6), [9] D. Johnson, C. Perkins, J. Arkko, Mobility support in IPv6, IETF RFC 3775, June [10] R. Stewart, Q. Xie, et al., Stream control transmission protocol, RFC 2960, IETF, October [11] P. Ferguson, D. Senie, Network ingress filtering: defeating denial of service attacks which employ IP source address spoofing, IETF RFC 2827, May [12] N. Yamai, K. Okayama, H. Shimamoto, T. Okamoto, A dynamic traffic sharing with minimal administration on multihomed networks, Proceedings of the IEEE International Conference on Communications 2001 (ICC2001), vol. 5, June 2001, pp [13] Y. Hori, K. Onimaru, T. Ikenaga, Y. Oie, Design and implementation of IPv6 gateway allowing effective use of multihome network, IEEE PACRIM 03, Victoria, BC, Canada, August 2003, pp [14] A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) specification, RFC 2463, IETF, December [15] B.A. Mah, Pchar: a tool for measuring internet path characteristics, February [16] Linux IPv6 Router Advertisement Daemon (radvd), org/radvd/index.html [17] T. Narten, E. Nordmark, W.A. Simpson, Neighbor discovery for IP version 6 (IPv6), RFC [18] S. Thomson, T. Narten, IPv6 stateless address autoconfiguration, RFC2462, IETF, December Chung-Ming Huang received the B.S. degree in electrical engineering from National Taiwan University on 1984/6, and the M.S. and Ph.D. degrees in computer and informatioin science from The Ohio State University on 1988/12 and 1991/6 respectively. He is currently a professor in Dept. of Computer Science and Information Engineering, National Cheng Kung University, Taiwan, R.O.C. He is the director of The Promotion center for Network Applications and Services Education, National Innovative Communication Education Program, Ministry of Education, Taiwan, R.O.C. He has published more than 100 referred journal and conference papers in wireless and mobile communication protocols, interactive multimedia systems, audio and video streaming and formal modeling of communication protocols. He is entitled as a Distinguished Professor of National Cheng Kung University since 2004/8. His research interests include broadband/mobile Internet, wireless and mobile communication protocols and software, wireless and mobile interactive multimedia systems, and media streaming protocols and applications. Ching-Hsien Tsai received the B.S. degree from Department of Computer Science and Information Engineering, National Cheng Kung University on 2001/6. He is currently a Ph.D. candidate in Department of Computer Science and information Engineering, National Cheng Kung University. His research interests are wireless and mobile network protocols, multihoming protocols and applications, and multimedia streaming. Po-Chou Su received the B.S. degree from Department of Computer Science and Information, Feng Chia University on 2002/6, and the M.S. degree from Department of Computer Science and Information Engineering, National Cheng Kung University on 2004/6. His research interests are embedded systems and multihoming protocols and applications.