Multihoming in IPV6 Habib Naderi Department of Computer Science University of Auckland.

Multihoming in IPV6

Habib Naderi

Department of Computer ScienceUniversity of Auckland

Definition of Multihoming• Having connection to the Internet through

more than one provider

Provider1Provider2

Internet

Multihoming Benefits

• Redundancy: having backup links to protect against failures.

• Traffic engineering: distributing traffic on different links to achieve better performance.

• Policy selection: assigning different traffics to different links based on site’s policies (cost, commercial reasons, ...).

• Around 60 % of stub networks are multihomed and this number is growing.

How Multihoming Is Achieved in the Current Internet

• The site acquires its own address block, can be Provider Independent or Provider Aggregatable, and announces that through all its providers.

Provider1Provider2

Internet

169.254.187.0/2420.0.123.0/24

20.0.0.0/8169.254.187.0/24

30.0.0.0/8169.254.187.0/2420.0.123.0/24

PI addressPA address

Is Current Solution deployable in IPV6?

• Scalability concerns: each MH site inserts new routing entries in global BGP routing tables.

• As the number of MH sites grows, the routing table size will cause a big problem. It needs more memory and processing power.

• Current studies show a growth of about 25% per annum in routing table. 20% of the entire size is related to multi-homing prefixes.

Solutions for IPV6

• Router based: routing system should provide the MH functionality

- MH with BGP: like ipv4- MH using cooperation between providers- MH support at site exit router

• Middle Box: a box between multihomed hosts and Internet provides MH functionality.

- NAT- Multihoming Aliasing Protocol- Multihoming Translation Portocol

Solutions for IPV6

• Host Centric: multihomed hosts with multiple prefixes provide MH

functionality.- HIP- SHIM6

- SCTP- multihomed TCP...

Shim6

• Shim6 is a host centric solution, chosen by IETF, for providing MH in IPV6 Internet (RFC 5533).

• It inserts a shim layer between IP and transport layer which switches between different IP addresses transparently.

Transport (TCP, UDP, ...)

IP routing sub-layer

Shim6

IP endpoint sub-layer (Frag/Reass, Dst opts)

Shim6

• To be transparent to the transport layer, shim6 uses the concept of ID/Locator separation.

• Transport layer uses one of the host’s IPV6 addresses , which is called ULID, for establishing connection. This ID will not change during the connection life.

• When a failure happens, shim6 will pick one of other host’s addresses, which are called set of locators, and switch to that. Switching is completely transparent to the transport layer.

Shim6

• One important part of shim6 is failure detection and recovery mechanism.

• A protocol called REAchability Protcol (REAP) has been designed for this purpose.

• RFC 5534

Failure Detection in REAP

• REAP uses FBD (Force Bidirectional Detection) for verifying reachability.

• When there is a traffic in one direction, there should be also traffic in the other direction.

• REAP sends KEEP_ALIVE messages in the case that there is no data to be sent.

• So, when there is an outgoing traffic but no return traffic, it’s a sign of failure.

• REAP employs two timers (send timer and keep alive timer) to manage this process.

Recovery Mechanism in REAP

• When a failure is detected, REAP starts the exploration process to find a working pair of locators.

• A set of locator pairs are built using host and peer locator sets. The set is pruned and ordered using DAS rules(RFC 3484).

• Then REAP starts to send probe messages for each member of the resulting set to test its reachability. This process finishes when an operational address pair is found.

An Example

B1B2

A1A2

A1, B1A1, B2A2, B1A2, B2

Candidate Set

B1B2

A1A2

B1B2

A1A2

Our Current Research Topic

• Analyzing the behaviour of the REAP in large sites to answer the following questions:

- If the REAP is deployed in future internet what will happen if a failure happens in a site with thousands of hosts?

- How much traffic will be generated? - How long the recovery process will take?

Our Current Research Topic

• To answer these questions, we have built and simulated a model of the REAP by using Möbius modeling tool.

• We have performed some experiments with 3000 instances of the REAP to measure the generated traffic and recovery time.

Some Preliminary results• Delay: Normal• No congestion• Mean= 0.08, 0.09, 0.1, 0.11, 0.12 sec Variance=0.04 • Number of shim6 contexts: 3000 Send timer = 10 sec

Some Preliminary Results

Some Preliminary Results(including congestion)

Some Preliminary Results(including congestion)

Some Preliminary Results(more congestion)

Some Preliminary Results(more congestion)

Research Areas in Networking Field in the Department of Computer Science

• DNS History Database– Tracks FQDNs and their IP addresses, keeping first and last

appearance dates– Started in 2006, now10 collectors world-wide– Around 750 million entries overall– Current Auckland research on tracking Fast Flux Networks (Leo)– Working on a web site for the project!

Traffic Flow measurements (DongJin, Jerry)• DNS RTT: long-term measurements (Nevil)• Performance Measurements of NZ ISPs (Nevil)• For more details contact Nevil Brownlee at

[email protected]

Research Areas in Networking Field in the Department of Computer Science

• Routing issues • IPv6 deployment • For more details contact Brian Carpenter at

[email protected]