Title: Multihoming Issues
1Multihoming Issues on IPv6 networks
APRICOT2002 Dongkyun Kim, Ilsun Whang E-mail
mirr_at_kreonet2.net
2Contents
- Introduction to KREONet2 6Bone
- About IPv6
- Interdomain Routing Issues
- IPv6 Multihoming Requirements
- Related Mechanisms
- IPv6 Multihoming issues
- Summary
3Introduction to KREONet2 6Bone
- KREONet2
- stands for Korea Research Environment Open
Network 2 - National RD network, run by KISTI, supported by
Korean government. - Upgraded name of KREONet and next generation
research network. - KREONet2 6Bone
- KREONet2 sTLA 2001320/35
- Peering with 6TAP, KOREN, and 6NGIX.
- Web, DNS, and Tunnel Broker service is ongoing.
- Plan to provide end-to-end IPv6 service this
year.
4Introduction to KREONet2 6Bone
KIX
STAR TAP 6TAP
200Mbps
10Mbps
Chunchon
Seoul
Seoul
45Mbps
Inchon
45Mbps
Suwon
155Mbps
IMNet
KREONet2 6Bone (AS17579)
256Kbps
Chonan
Chungju
10Mbps
45Mbps
1Gbps
Daejon
Daejeon
16Mbps
Internet
45Mbps
45Mbps
4Mbps
Pohang
Daegu
Jeonju
Ulsan
2Mbps
45Mbps
45Mbps
45Mbps
Kwangju
Pusan
Changwon
4 Mbps
Jeju
5About IPv6
- Background
- Rising crisis of IPv4 address depletion
- Non-hierarchical routing system problem
- Growth of the applications
- Temporary solutions
- - Renumbering, CIDR, NAT, DHCP
- Benefits
- Increased IP address size
- Increased addressing hierarchy support
- Simplified host adddressing
- Simpler Autoconfiguration of address
- And so on
6About IPv6
- The need for further development
- The multihoming problem
- Less-rigid structure for global unicast
addresses - Anycast details
- And so on
7Interdomain Routing Issues
- Growth of interdomain routing tables
By Geoff Huston (2001.1)
8Interdomain Routing Issues
- More specific prefixes advertisement
KREONet2 NOC, http//measurement.ipv6.re.kr/bgp/
9Interdomain Routing Issues
KREONet2 NOC, http//measurement.ipv6.re.kr/bgp/
10Interdomain Routing Issues
By Geoff Huston, http//www.telstra.net/ops/bgp/
11IPv6 Multihoming Requirements
- Scalability
- Redundancy
- Physical / logical link failure
- Routing protocol failure
- Transit provider failure
- Load Sharing
- Inbound traffic load sharing
- outgoing traffic load sharing
- Performance
- e.g. Avoiding long-term congestion between
providers
12IPv6 Multihoming Requirements
- Policy
- e.g. cost, acceptable use conditions, etc.)
- Provider selection for a certain traffic class
or application - Simple operations and management
- Current multihoming solution is quite
straightforward to deploy and maintain. - Transport-layer Survivability
- providing re-homing transparency
13IPv6 Multihoming Requirements
- Security Considerations
- Denial Service attack and spoofing attacks are
possible, so multihomed sites must be protected
against such attacks at least as well as
single-homed sites - More considerations should be taken into
possible tunnel link - Encryptions
- Packets may travel an unwanted path, otherwise
secondary links are configured with care
14Related Mechanisms
- IPv6 multihoming with route aggregation
- draft-ietf-ipngwg-ipv6multihome-with-aggr-01
(now obsolete) - a site multi-homed to more than one ISPs
- Provider level multihoming technique
- IPv6 multihoming support at site exit routers
- RFC 3178
- a site multi-homed to more than one ISPs using
different site border routers - Site level multihoming technique
15Related Mechanisms
- Multihoming Mechanism with route aggr.
Inbound Traffic 1. Customer-A Addr-1-A,
specific route advertising (ISP-1, ISP-2) 2.
ISP-2 advertises Addr-1-A to ISP-1 only. 3.
ISP-1 advertises Addr-1-A aggregation block to
ISP-3, ISP-4
ISP-4
ISP-3
3
3
ISP-2
ISP-1
2
Outgoing Traffic - Default route advertising
ISP-1 and ISP-2 - Or selective set of specific
prefixes advertising According to the requirement
of customer-A
1
1
Customer-A
16Related Mechanisms
- Multihoming Mechanism with route aggr.
Load Sharing 1. Inbound Traffic - Achieved by
careful controlling route policy of ISP-1 -
Using IGP Metric, BGP route selection 2. Outbound
Traffic - Achieved by controlling
advertisement from ISP-1 and ISP-2
ISP-4
ISP-3
ISP-2
ISP-1
Redundancy 1. Link-1 failure - In ISP-1
-gt ISP-2 -gt Customer-A - Out Customer-A -gt
ISP-2 2. Link-2 failure - In ISP-1 -gt
Customer-A - Out Customer-A -gt ISP-1
Link-1
Link-2
Customer-A
17Related Mechanisms
- Most Suitable Environments for deploying
- In case that ISPs supporting multi-homed site
have direct connection to each other gt simple
arrangement and improved aggregation - In case of needing good redundancy, not absolute
redundancy - Sites with limited to resource for onsite
sophisticated network administrators Primary
ISP takes the most part. - Sites that able to choose a robust ISP as
primary provider
18Related Mechanisms
- IPv6 multihoming support at site exit routers
- Goals
- Scalability
- Redundancy
- Non-goals
- Choose the best exit link as possible
- Load balancing between multiple exit link
19Related Mechanisms
- multihoming mechanism at site exit routers
- Establish secondary link using IP-over-IP tunnel
- Secondary link should be established through
different medium with primary link.
ISP-B
ISP-A
ISP-BR-A
ISP-BR-B
Secondary link
Multi-homed Site
E-BR-A, Pref-A
E-BR-B, Pref-B
20Related Mechanisms
- multihoming mechanism at site exit routers
- Redundancy and Scalability
Inbound Traffic 1. Strong Pref-A 2. Weak
Pref-B 3. Strong Pref-B 4. Weak Pref-A
Outbound Traffic 1. Strong Default 4. Weak
Default 3. Strong Default 2. Weak Default
1
2
3
4
21IPv6 Multihoming Issues
- Scalability
- Routing table size has been a major issue (IPv4,
IPv6) - In IPv6, routing table size issue is more
serious negative effects on router memory usage,
routing table lookup performance - Global routing table could be reduced using
aggregation hierarchy in IPv6, but the
alternatives for multihoming are still be on the
construction. - Redundancy
- inbound and outgoing link redundancy
22IPv6 Multihoming Issues
- Load Sharing
- inbound traffic load sharing
- Router Renumbering
- Source address selection between different
prefixes - Reliable link operation using tunneling
- Managing and operating tunneled link
- In case of long-term primary link down, usage of
other ISPs primary link is more efficient. - Marking Pref-A prefix as deprecated no new
connection allowed - New connection requests are to be done using
newly assigned Pref-B - RRP makes this work automatic, but be very
cautious of the links flap
23Summary
- Global routing table issues - Scalability
- Entries advertising more specific prefixes of
aggregates - Prefix distribution
- Growth of AS numbers
- IPv6 Multihoming Issues
- Need mechanism that can support scalability,
load sharing, redundancy. - Need to achieve better reachability without
impacting worldwide routing table size issues.
24Thank You !
- Contact Info
- Director
- Il-sun Whang
- - his_at_kreonet2.net
- Engineers
- Dongkyun Kim
- - mirr_at_kreonet2.net
- Hyeakro Lee
- - leehr_at_kreonet2.net