1 / 12

Simple Multi-Homing Experiment: Scalable Solutions for IPv6 Networks

This experiment explores multi-homing solutions for IPv6 networks using basic and advanced techniques, addressing challenges like maintaining TCP connections and peer selection. The proposed solutions aim to ensure robust connectivity without major infrastructure changes.

hickst
Download Presentation

Simple Multi-Homing Experiment: Scalable Solutions for IPv6 Networks

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. Simple Multihoming Experiment draft-huitema-multi6-experiment-00.txt Christian Huitema, Microsoft David Kessens, Nokia

  2. Simple bridged network 2 routers, 2 ISP ingress filtering No ISP coordination Example T1 + DSL back-up 2 DSL modems DSL + cable Cable + WiFi mesh Several hosts Simple = IPv6 basic Advanced = multi-homing aware It must work! Simple dual homing problem statement Internet (IPv6) ISP1 ISP2 R1 R2 Single link (bridge) H H H Simple Multi-Homing Experiment

  3. Use for Back-Up Switch R1 on if R2 is down May incur small delay In general, loose TCP connections Typically combined with NAT & DHCP Private addresses, no renumbering IPv4 equivalent: back-up Internet (IPv4) ISP1 ISP2 R1 R2 Single link (bridge) H H H Simple Multi-Homing Experiment

  4. Broad Lines of the Solution • No coordination between ISP • Use of Provider Addresses • Each ISP allocates a prefix • or each ISP allocates an IPv4 address, and the routers use 6to4 • Multi-Addressing • Each router advertises a prefix • Hosts configure addresses with each prefix • Five issues need resolution Simple Multi-Homing Experiment

  5. Multi-addressing issues • Ingress filtering • host pick address from ISP1, send through R2? • Dead default exit router, or dead ISP • host keeps sending packets through a black hole? • Inbound connection through wrong ISP • Peers send packet to the black-holes address? • Maintaining TCP connections • Keep TCP going if the Router or the ISP fails? • Use the right exit/entrance • Maybe some amount of load balancing Simple Multi-Homing Experiment

  6. Ideas, Ingress Filtering • Choice by host • Host treats multiple “auto-config” prefixes as “sub-interfaces”, associates individual IPv6 address and default router. • Easy to implement in “new hosts”. • Redirect at routers • No need for tunnels in single link network. • Guarantees that “old hosts” keep working. • There may be other solutions • New services, ISP involvement, etc. Simple Multi-Homing Experiment

  7. Ideas, dead exit router or dead ISP • If the router notices the problem • Advertises prefix as “deprecated”, or stop advertising • Will not be used for new connections • Will work for old and new hosts. • If the problem is not really detected • New host tries multiple source addresses when establishing a new connection • Host may keep track of the quality of each router connection Simple Multi-Homing Experiment

  8. Ideas, Peer using dead address • If the problem is detected • Update the name server? • If the problem is not detected • DNS advertises multiple addresses • Peer tries several addresses • Issue: TCP timers? Simple Multi-Homing Experiment

  9. Ideas, Maintaining TCP Connections • No good solution for old hosts • But there is no solution in a similar IPv4 set-up either • Many applications will automatically reconnect • New hosts may use MIPv6 • See “Application of the MIPv6 protocol to the multi-homing problem” • draft-bagnulo-multi6-mnm-00 • SCTP may also be used • See “multi-homing issues in SCTP” • draft-coene-sctp-multihome-04.txt Simple Multi-Homing Experiment

  10. Idea, Selecting the right exit/entrance • Right entrance: DNS tricks • In asymmetric scenarios (back-up), only publish the “best address” in the DNS • In symmetric scenarios, publish both • Right exit: Routing tricks • Provide information in router announcement, as in “Default Router Preferences, More-Specific Routes, and Load Sharing “ • draft-ietf-ipv6-router-selection-02.txt Simple Multi-Homing Experiment

  11. Summary • It looks good on paper • All issues have plausible solutions • No change required to IPv6 standards • No need to rewrite the IPv6 address at site exit • We would benefit from “mobile IPv6” and “router selection” work • But we would like an actual deployment… • In theory, there is no difference between theory and practice, but in practice there is! Simple Multi-Homing Experiment

  12. Range of solutions • Small sites • Do as we just explained • Medium sites • Ask the ISP to cooperate, allow both source addresses in ingress filtering • E.g. add a local route to the other prefix • Very large sites • Treat as ISP, get their own prefix & AS# Simple Multi-Homing Experiment

More Related