Transcript Automatic Configuration of IP Networks and Routers

Automatic Configuration of
IP Networks and Routers
Kenji Hori, Kiyohito Yoshihara, and Hiroki Horiuchi
KDDI R&D Laboratories Inc.
2-1-15 Ohara Kamifukuoka-Shi Saitama
356-8502, Japan
TEL: +81 49 278 7651 FAX: +81 49 278 7510
{hori, yosshy, hr-horiuchi}@kddilabs.jp
Introduction
• Techniques for automatic configuration of IP networks and routers are
desirable
– The presence of a highly skilled user like a network operator cannot be assumed.
– The deployment of automatically configurable network would be cost-effective in terms
of efficient network operation and management.
• Requirements for automatic configuration are identified, comparing existing
proposals
• ARCP is promising; however, the current version has problems to be solved:
– An address management solution is not provided explicitly.
– A DHCP server cannot provide an appropriate address of the default gateway.
– Operations for discovering addition/deletion of routers (“Peer Discovery”) and for adapting
router settings to network changes(“Renumbering”) can cause unstable repetitive changes of
address.
– “Renumbering” operations can evaporate the addresses of default gateways.
• In this paper:
– We identify requirements for an automatic configuration protocol.
– We compare existing proposals with our requirements, showing that ARCP is the closest to
satisfy our requirements.
– We address the above problems in detail, and propose solutions.
– We describe works in progress and show preliminary simulation results.
Requirements and comparison of existing proposals
Proposals
Requirements (R1)Management by (R2)IP prefix and address
external management assignment and supporting
system
topology
Automatic Router
Configuration Protocol
(ARCP) ([2])
configures according to a
predefined or default scheme of
behavior and address allocation
using DHCP relay agents.
Multilink-subnets ([1])
aggregates L2 links into a single
IPv6 subnet using a sort of ND
(Neighbor Discovery) proxy
called MSR (Multilink Subnet
Router).
Prefix Delegation (PD)
methods *1
delegates some address
space and prefixes to routers
from the management system.
(*1)“PD” is a generic name for
[6], [7], and [8].
(R3)IPv4/
IPv6
Configuration settings
are managed by
external management
systems.
Prefixes and addresses are assigned Supports
under any topology.
IPv4 and
Automatic decision of an appropriate IPv6.
prefix length is not provided.
Not provided.
There is no need to be
managed, if they use
the link-local prefix.
Assignment of prefixes and
Supports
addresses is not required, because it IPv6 only.
assumes a single subnet.
Current support is only star topology.
Provided, but limited.
They provide methods
for prefix delegation
only.
[6], [7], [8] do not provide automatic
decision of addresses and prefix length
for a subnet.
[6] can assign prefixes, and may work
under any topology if used with DHCP
relay agents.
[7] and [8] work only under a single
subnet.
Automatic decision of an appropriate
prefix length is not provided.
Autonomous Prefix and
Address Assignment (APAA) Not provided.
methods *2
assigns a prefix to a subnet by
routers, without assumption of
necessity to distribute global
prefixes.
(*2)“APAA” is a generic name
for [4] and [5].
[6],[7],[8]
supports
only IPv6.
Prefixes and addresses are assigned [4] supports
under any topology.
IPv4 and
A presetted prefix length is applied to IPv6.
all subnets.
Table 1. Comparison of existing proposals
[5] supports
only IPv6.
Overview of ARCP (1)
Fig.1: Basic operation of ARCP
Overview of ARCP (2)
Fig.2: Peer discovery and Renumbering operations
Problem (1): Address management is not explicitly provided.
Solution (1): All addresses are managed originally by a DHCP server.
Fig.4: Address assignment by solution S2
Fig.3: Address assignment by solution S1
Fig.5: Address management solution for ARCP (S2)
Problem (2): DHCP server cannot provide addresses of default gateways.
Solution (2): ARCP routers replace values of DHCP “router” option field.
Fig.6: An example of problem and solution S1
Fig.7: An Example of solution S2
Problem (3): “Peer Discovery” and “Renumbering” operations can
cause repetitive address changes.
Solution (3): The ARCP server presets static priority for each subnet.
Fig.9: Solution with static priority method
Fig.8: Problem of repeating Renumbering operation
Problem (4): “Renumbering” operations can evaporate default gateway address.
Solution (4): ARCP routers suspends actual Renumbering operation until
downstream ARCP routers are configured.
Fig.10: Problem of evaporating default gateway address
Fig.11: Solution with prohibition of actual Renumbering operation
Simulation example of ARCP
Fig.13: An example network
Time of completion of accommodation
[sec]
450.0
Static Priority Enabled
Static Priority Disabled
400.0
350.0
300.0
250.0
200.0
150.0
100.0
50.0
0.0
1
2
3
4
5
6
7
8
Fig.14: Results with example network shown in Fig.13
9
10
Number of
routers (N)
Conclusions
In this paper:
• Requirements for automatic configuration of IP networks and routers are
identified first.
• Comparative study on existing proposals is presented next, which shows that
ARCP under standardization by IETF is the closest to satisfy requirements.
• We examine a basic operation of ARCP in detail.
• We address four problems and propose solutions.
• In order to evaluate proposed solutions, we are developing a simulator. The
work is in progress, and we present preliminary simulation results.
Future work:
• Comparative simulation study of proposed solutions and standardized ARCP
• Development of:
– Advanced decision method of subnet selection priority in “Renumbering”
operation
– Adaptive and dynamic subnet resizing (variable prefix length) method
– Extension for operation on IPv6 and IPv6-IPv4 mixed networks.
– Hybrid method combined with other proposals
• Implementation of proposed solutions and evaluation in operational networks
Reference
[1] D. Thaler and C. Huitema, “Multi-link Subnet Support in IPv6”, http://www.ietf.org/internetdrafts/draft-ietf-ipv6-multilink-subnets-00.txt, Jun. 2002.
[2] J. Linton, “Automatic Router Configuration Protocol”, http://www.ietf.org/internet-drafts/draftlintonarcp-00.txt, Oct. 2002.
[3] J. Linton and G. Chelius, “Zerouter Protocol Requirements”, http://www.ietf.org/internet-drafts/draftlinton-zerouter-requirements-00.txt, Dec. 2002.
[4] A. White and A. Williams, “Zero-Configuration Subnet Prefix Allocation Using UIAP”,
http://www.ietf.org/internet-drafts/draft-white-zeroconf-subnet-alloc-01.txt, Oct. 2002.
[5] G. Chelius, E. Fleury and L. Toutain, “Using OSPFv3 for IPv6 router autoconfiguration”,
http://www.ietf.org/internet-drafts/draft-chelius-router-autoconf-00.txt, Jun. 2002.
[6] O. Troan and R. Droms, “IPv6 Prefix Options for DHCPv6”, http://www.ietf.org/internet-drafts/draftietf-dhc-dhcpv6-opt-prefix-delegation-03.txt, Mar. 2003.
[7] B. Haberman and J. Martin, “Automatic Prefix Delegation Protocol for Internet Protocol Version 6
(IPv6)”, http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-02.txt, Feb. 2002.
[8] N. Lutchansky, “IPv6 Router Advertisement Prefix Delegation Option”, http://www.ietf.org/internetdrafts/draft-lutchann-ipv6-delegate-option-01.txt, Feb. 2002.
[9] http://internet.motlabs.com/mailman/listinfo/zerouter/
[10] http://www.opnet.com/.