Preserving Established Communications in IPv6 Multi-homed Sites with MEX Juan F. Rodríguez, Marcelo Bagnulo, A. García-Martínez, I. Soto, A. Azcorra. Dept. de Ingeniería Telemática Universidad Carlos III de Madrid

Index Introduction Multihoming through Extension Headers (MEX). MEX Walkthrough Normal Operation. Fault Tolerance Support. MEX Requirements Conclusions.

Introduction Multihoming usually means “more than one provider”. Host multihomed: More than one address. More than one link. Provider-A Provider-B What’s a multihomed-network ? It’s a network which has more than one external link to different providers. Why is interesting to be multihomed ? There are a lot of reasons: 1.To improve redundancy against router failure, link failure or ISP failure. 2. To obtain load sharing capabilities Or for example, its been used to get local connectivity by large geographical networks, each of them with their own local internet provider. Regarding the end user, it will be common to see in the future users using both DSL and cable providers. Multi-homed Site

Introduction IPv4 Multihoming announces specific routes Default Free Zone Site addr.block Site reachability information <P.I. addr. block> <ISP-A addr. block> <ISP-B addr. block> Provider-A Provider-B If a multihomed site wants to be acessed from different places, it has to announce its address block globally through its providers, so it des-aggreates routes. IPv4 also has the problem of the limited address space, so it’s not possible to allocate one address block per user. Multi-homed Site

Introduction Routing table scalability issue: CIDR: Aggregates routes. IPv4 Multihoming: Advertises more specific routes. Expected growth will be driven by: The number of providers. The number of multihomed-sites. IPv4 multihoming doesn’t scale well. In the 90’s, the Classless InterDomain Routing Address allocation policy was created to cope with the routing table size problem. CIDR proposes the allocation of IP address blocks to transit providers, instead of obtaining it from a central allocation authority. This strategy allows providers to announce one single route that summarize the reachability information for all the custumers and it makes a better use of the IPv4 address space as well. Every single user is a potetial candidate to be multihomed, so the IPv4 Multihoming solution doesn’t scale well.

Introduction IPv6 routing architecture is stiffer: ISPs don’t announce other ISP’s prefixes. Addresses are aggregated by providers. Some IPv6 Multihoming goals: Scalability. Interoperability with legacy IPv6 hosts. Transport-Layer Survivability Fault detection Recovery process To finish this introduction, I will point out some of the requirements a multihoming solution should fulfill: It’s expected to be scalable, and it should interoperate with legacy Ipv6 hosts. It should impact the less the better on the actual router and hosts implementations, and The most important goal of a multihoming solution, in our opinion, is that it should be Possible to keep the trasport layer connectivity even when the actual path gets to be broken. Every multihoming solution should define how a failure is detected and How to fix the connection in case of a failure condition. Our solution is aimed to assure this trasport layer conectiviy even when An ISP becomes faulty.

MEX Extends the IPv6 protocol to: Host based solution (active): Share reachability information end-2-end. Communicate alternative paths to the routing system. Host based solution (active): Stores different prefixes for a given destination. Sends information to the routing system. Router based solution (passive): The routing system takes over the recovery process.

MEX Alternative Prefix Destination Option: It informs the peer about the alternative prefixes. Alternative Prefix Extension Header: It Informs the routers how to re-route packets if there’s no route to the destination. Opt. Type Opt. Length Reserved Alternative Prefix 1 Alternative Prefix N … The alignement of this option is 8n+2 Next Hdr Hdr Ext Len Reserved Alternative Prefix 1 Alternative Prefix N … Segments Left

Normal Operation ISP-A ISP-B ISP-C “Host A” (addrA1, addrA2) “Host B” DNS “Host A” (addrA1, addrA2) “Host B” (addrB1, addrB2) IPv6 header, dst = <addrB1> IPv6 Ext. Header with <prefixB2> IPv6 Dst. Opt. w/ <prefixA1,prefixA2> Upper Layer Protocol

Fault Tolerance support MEX capable router (MEX-R): It understands the MEX Ext. Header. It’s able to attract packets when there’s a black-hole. MEX-R walkthrough: It looks for the MEX Ext. Header. It swaps dest. prefix with one of the alternative prefixes. It looks at his routing table to forward the packet.

Fault Tolerance support MEX-R ISP-B ISP-A Default Free Zone Host 1 ISP-D ISP-C Host 2 (PA:PC:….::/64) (PB:PD:….::/64)

MEX Requirements Changes on hosts: Changes on routers: It requires upgrades on hosts to achieve multihoming benefits. Changes on routers: Only some routers should be upgraded per ISP. “Normal” routers shouldn’t discard packets with the new Extension Header.

Conclusion Reduce Packet Loss. It doesn’t pollute the IPv6 routing system. Incremental Deployment. Compatible with unmodified hosts. Transparent to upper layers. Peers don’t realize of the addr. swapping. Established communications are preserved. Implemented on a FreeBSD-4.5 kame release. Interoperates with normal hosts, even if they are multhomoed but don’t implement this solution Because …. CREO QUE NO INTEROPERA CON NORMAL-HOSTS !!!