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

Multihoming in IPV6

  • Upload
    favian

  • View
    77

  • Download
    0

Embed Size (px)

DESCRIPTION

Multihoming in IPV6. Habib Naderi Department of Computer Science University of Auckland. Definition of Multihoming. Having connection to the Internet through more than one provider. Internet. Provider2. Provider1. Multihoming Benefits. - PowerPoint PPT Presentation

Citation preview

Page 1: Multihoming  in IPV6

Multihoming in IPV6

Habib Naderi

Department of Computer ScienceUniversity of Auckland

Page 2: Multihoming  in IPV6

Definition of Multihoming• Having connection to the Internet through

more than one provider

Provider1Provider2

Internet

Page 3: Multihoming  in IPV6

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.

Page 4: Multihoming  in IPV6

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

Page 5: Multihoming  in IPV6

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.

Page 6: Multihoming  in IPV6

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

Page 7: Multihoming  in IPV6

Solutions for IPV6

• Host Centric: multihomed hosts with multiple prefixes provide MH

functionality.- HIP- SHIM6

- SCTP- multihomed TCP...

Page 8: Multihoming  in IPV6

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)

Page 9: Multihoming  in IPV6

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.

Page 10: Multihoming  in IPV6

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

Page 11: Multihoming  in IPV6

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.

Page 12: Multihoming  in IPV6

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.

Page 13: Multihoming  in IPV6

An Example

B1B2

A1A2

A1, B1A1, B2A2, B1A2, B2

Candidate Set

B1B2

A1A2

B1B2

A1A2

Page 14: Multihoming  in IPV6

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?

Page 15: Multihoming  in IPV6

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.

Page 16: Multihoming  in IPV6

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

Page 17: Multihoming  in IPV6

Some Preliminary Results

Page 18: Multihoming  in IPV6

Some Preliminary Results(including congestion)

Page 19: Multihoming  in IPV6

Some Preliminary Results(including congestion)

Page 20: Multihoming  in IPV6

Some Preliminary Results(more congestion)

Page 21: Multihoming  in IPV6

Some Preliminary Results(more congestion)

Page 22: Multihoming  in IPV6

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]

Page 23: Multihoming  in IPV6

Research Areas in Networking Field in the Department of Computer Science

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

[email protected]