Site Multihoming for IPv6 Brian Carpenter IBM TERENA Networking Conference, Poznan, 2005

Topics What is a site? What is site multihoming? Goals Difficulties Choices Proposed shim6 architecture Status

What is a site? As far as multihoming goes, it is anything from a single host up to an intercontinental company network covering many geographical sites. –One host –Simple home or office network –Campus –Linked campuses –Tricky case: mobile network (car etc.)

What is site multihoming? A site that is connected to more than one ISP is "multi-homed" –Reason is usually reliability, but could be load-sharing In the general case, two or more multi- homed sites must communicate with each other

The Internet Site S1 ISP D Site S2Site S3 Multihoming topology Host H3 Host H2 Host H1 ISP C ISP F ISP B ISP A ISP E

Goals 1 (from RFC 3582) Redundancy - survive ISP failures –Transport layer survivability Load sharing Protect performance Policy support for ISP selection Simplicity Minimal impact on DNS Compatible with packet filtering

Goals 2 (from RFC 3582) Scaleability –especially, avoid BGP4 table explosion Backwards compatible with routers and legacy hosts –"First do no harm" principle Do not require cooperation between ISPs Must not increase security vulnerability –"First do no harm" principle

Difficulties - why is this hard? Scaleability - must not explode IPv6 BGP4 tables, so cannot simply advertise long ISP A prefixes to ISP B Compatibility and deployability - cannot change API for applications, cannot reasonably expect legacy applications to understand multihoming Deployment must be progressive Must support "referrals" where Host 1 hands off communication with Host 2 to Host 3

Choices IPv6 has a big advantage over IPv4: the address space has enough flexibility that the solution is much less constrained than for IPv4 –for IPv4 the only real choices are NAT or advertising long prefixes to the "wrong" ISP –NAT breaks referrals and peer to peer –prefix advertising doesn't scale For IPv6 we can do better –Three general approaches now outlined –The common feature is that if a site has N active ISPs, each host will use up to N different addresses, one per ISP. Such addresses are called locators.

Choice 1: Routers do everything No changes in hosts. Site egress router –chooses the ISPs –changes the locators accordingly –remote site ingress router changes them back –(this class of solution was first proposed by Mike O'Dell in 1996) Not compatible with IPSec –would probably create issues for SCTP, too –other security concerns never resolved Stepwise deployment very hard

Choice 2: Transport does everything No changes in routers. Transport layer –chooses the locator pair (effectively, chooses the ISPs) –this process is hidden from applications –SCTP already does this Not considered practical to change the transport layer globally (TCP, DCCP,...) Doesn't help for UDP Proposed in multi6 WG but not developed

Choice 3: IP layer does most of it IP layer –chooses the locator pair (effectively, chooses the ISPs) –this process is hidden from transport and applications –will also work for UDP In practice, egress router selection is a problem and some interaction with routing is needed This is the direction preferred by multi6 WG and proposed at shim6 BOF

What's a shim ? Main Entry: 1 shim Pronunciation: 'shim Function: noun Etymology: origin unknown : a thin often tapered piece of material (as wood, metal, or stone) used to fill in space between things (as for support, leveling, or adjustment of fit) (Merriam Webster on line, )

Proposed shim6 architecture Sender A Receiver B src = ULID(A) dst = ULID(B) src = ULID(A) dst = ULID(B) src = Loc(A) dst = Loc(B) src = Loc(A) dst = Loc(B) SHIM MAPPING Identity Locator Slide by Geoff Huston

Position of the shim TCPUDPDCCP Transport Protocols IP Endpoint Sublayer AHESPFrag/Reassembly Destination Options Multi6 SHIM IP Routing … Slide by Geoff Huston

What's a ULID? Upper Layer IDentifier –A selection from the set of locators associated with an endpoint It’s (probably) a viable locator It’s drawn from a structured space (reverse mappable) It's better if it were a unique (deterministic) selection for each host It's useable in a referral context within and between hosts It's semi-persistent Slide by Geoff Huston

Other issues with the shim Shim to shim protocol to exchange address lists –Security - need a cryptographic way to avoid attacks on this exchange Need egress router selection method –Packet must leave towards the ISP that delegated the source locator it is using Need failure detection mechanism to trigger a change to a new locator –Optionally, policy mechanism in addition, to share load Need enhanced API for smart transport layers Need to clarify DNS interactions

IETF status Multi6 WG has completed its tasks (goals, analysis, recommended direction) Shim6 BOF was held at March IETF Hoped to be WG by August IETF in Paris Venez nombreux à Paris!