1 / 13

Preserving Established Communications in IPv6 Multi-homed Sites with MEX

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

dsoto
Download Presentation

Preserving Established Communications in IPv6 Multi-homed Sites with MEX

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. Provider-A Introduction • Multihoming usually means “more than one provider”. • Host multihomed: • More than one address. • More than one link. Provider-B Multi-homed Site

  4. <P.I. addr. block> Site reachability information Site addr.block Provider-A Introduction • IPv4 Multihoming announces specific routes Default Free Zone <ISP-B addr. block> <ISP-A addr. block> Provider-B 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.

  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

  7. MEX • Extends the IPv6 protocol to: • 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. Opt. Type Opt. Length Reserved Alternative Prefix 1 … Alternative Prefix N Segments Left Next Hdr Hdr Ext Len Reserved Reserved Alternative Prefix 1 … Alternative Prefix N 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.

  9. Normal Operation ISP-B ISP-A ISP-C 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: • 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.

More Related