simple multihoming experiment draft-huitema-multi6-experiment-00.txt christian huitema, microsoft...

Simple Multihoming Experiment

draft-huitema-multi6-experiment-00.txtChristian Huitema, MicrosoftDavid Kessens, Nokia

7/11/2003Simple Multi-Homing

Experiment 2

Simple dual homing problem statement

Simple bridged network2 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 awareIt must work!

Single link (bridge)

H HH

R1 R2

ISP1 ISP2

Internet(IPv6)


Experiment 3

IPv4 equivalent: back-up

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

Single link (bridge)

H HH

R1 R2

ISP1 ISP2

Internet(IPv4)


Experiment 4

Broad Lines of the Solution

No coordination between ISPUse 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


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


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.


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


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?


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


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


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!


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 multihoming experiment draft-huitema-multi6-experiment-00.txt christian huitema, microsoft...

Documents