1. 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

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

3. 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

4. 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

5. 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.

6. 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.

7. 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.

8. 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

9. 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

10. 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.

11. 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)

12. 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.

13. 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 !!!