1. NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering A solution to perform traffic engineering in a IPv6 multihomed end-site, using a multi-addressing scheme draft-de-launois-multi6-naros-00.txt Cédric de Launois delaunois@info.ucl.ac.be 1. Introduction 2. NAROS Principle 3. NAROS Protocol 4. NAROS Features 5. Conclusion

2. 1. Introduction Host-Centric IPv6 multihoming : (see draft-huitema-multi6-hosts-01.txt) Each host has several IPv6 addresses : one per provider Site prefixes are aggregated within the larger prefixes of the providers  full route aggregation possible Providers perform ingress filtering  choosing a source address = choosing a provider

3. 1. Introduction (continued) Problem : Which source address to use when a host contacts a destination ? « RFC3484 IPv6 default address selection algorithm » does not help when different global-scope IPv6 addresses are available (longest matching prefix rule used) A host has no information about which provider is the « best » for a particular destination. Best = With shortest path towards destination With lower delay, higher bandwidth, lower cost…

4. Proposed solution : An IPv6 multihomed host inquires a NAROS server to determine the source address to use to contact a destination Examples : Host X uses PA:SA:X to reach Host W (shortest path) Host X uses PB:SB:X to reach Host Z (B-C outbound load-balancing) Host Y uses PC:SC:Y to reach Host Z (B-C outbound load-balancing) Multihomed site Host X PA:SA:X PB:SB:X PC:SC:X Host Y PA:SA:Y PB:SB:Y PC:SC:Y RCRB INTERNET ISP BISP C Host Z Accepts only PB:SB::Accepts only PC:SC:: 2. NAROS Principle Research Network Host W ISP A RA NAROS Accepts only PA:SA::

5. NAROS rationale : the burden of selecting the source address is delegated to the NAROS server, which has access to all the requirements and informations about the actual environnement. NAROS gives only a hint about the best source address to use. The final decision is still taken by the host (preserve end- to-end failure detection) NAROS is not intended to preserve flows. Other mechanisms can be used for this purpose. NAROS server : stateless wrt clients NAROS service : –can be anycast (avoid single point of failure !) –can be set up independently from the providers 2. NAROS Principle (continued)

6. 3. NAROS Protocol NAROS Request : host  server « I want to contact Host Z, select my best address between PA:SA:X and PB:SB:X » NAROS Response : server  host « To contact any destination inside prefix PZ, your best address is PB:SB:X. This response is valid for 300 seconds. » The response is cached in the host until the lifetime expires. Multihomed site Host X PA:SA:X PB:SB:X Host Y PA:SA:Y PB:SB:Y RB + NAROS RA + NAROS INTERNET ISP AISP B Host Z PZ:SZ:Z request response

7. 4. NAROS Features Outbound load-balancing The server can use a round-robin or another scheme when selecting the best address. Unequal load-balancing possible without any additionnal complexity. Redundancy : NAROS can detect failures in the Internet if it gets access to the BGP tables of the site exit routers. NAROS can integrate in its address selection algorithm : –Administrative policies –Traffic engineering requirements –Quality of Service requirements, …

8. 5. Conclusion With NAROS, a IPv6 multihomed host is able to select its best source address. Route aggregation is preserved. By selecting the best source address, a NAROS server can influence the outbound load-balancing and can provide better redundancy. Requirements like cost, delay, bandwidth,… can be taken into account.

9. 6. NAROS Simulation Simulation : Based on a real traffic trace, during 24 hours More than 7500 active hosts Prefixes associated with the destinations are extracted from a BGP table (±14000 different destination prefixes). The lifetime used is 300s. Results : Expected bandwidth overhead : ±0.4% NAROS server load average : 35 req/s Cache size < 100 entries for 95% hosts Good load-balancing performances (similar as classical load-balancing mechanisms) NAROS CRC16