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, JapanTEL: +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

Table 1. Comparison of existing proposals

RequirementsProposals

(R1)Management by external management system

(R2)IP prefix and address assignment and supporting topology

(R3)IPv4/IPv6

Automatic Router Configuration Protocol (ARCP) ([2])configures according to a predefined or default scheme of behavior and address allocation using DHCP relay agents.

Configuration settings are managed by external management systems.

Prefixes and addresses are assigned under any topology. Automatic decision of an appropriate prefix length is not provided.

Supports IPv4 and IPv6.

Multilink-subnets ([1])aggregates L2 links into a single IPv6 subnet using a sort of ND (Neighbor Discovery) proxy called MSR (Multilink Subnet Router).

Not provided. There is no need to be managed, if they use the link-local prefix.

Assignment of prefixes and addresses is not required, because it assumes a single subnet.Current support is only star topology.

Supports IPv6 only.

Prefix Delegation (PD) methods *1delegates some address space and prefixes to routers from the management system.(*1)“PD” is a generic name for [6], [7], and [8].

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.

[6],[7],[8] supportsonly IPv6.

Autonomous Prefix and Address Assignment (APAA) methods *2assigns 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].

Not provided. Prefixes and addresses are assigned under any topology. A presetted prefix length is applied to all subnets.

[4] supports IPv4 and IPv6.

[5] supports only IPv6.

Overview of ARCP (1)

Fig.1: Basic operation of ARCP

(9)DHCPDISCOVER(10)DHCPOFFER(13)DHCPREQUEST

(14)DHCPACKARCPREGARCPCFG

(7)dummy BOOTREQUEST

(16)dummy BOOTREQUEST

ARCP ServerDHCP Server

(16)dummy BOOTREQUEST

(16)dummy BOOTREQUEST

ARCP Router2

IF1 IF2

ARCP Router 1

IF1 IF2

3.

1.

2.

4.

(7)dummy BOOTREQUEST

(7)dummyBOOTREQUEST

(12)DHCPREQUEST

(8)DHCPDISCOVER(11)DHCPOFFER

(15)DHCPACK

Relayed Message

Message

Copied and RelayedMessage

(2)DHCPOFFER

(1)DHCPDISCOVER

(4)DHCPACK(3)DHCPREQUEST

(5)ARCPREG(6)ARCPCFG

Overview of ARCP (2)

Fig.2: Peer discovery and Renumbering operations

(A)ARCP Server

ARCP Router 1DHCP ServerARCP Router2

(1)dummy BOOTREQUEST(1)dummy BOOTREQUEST

(3)ARCPCFG

if ( (prefix of ciaddr) != (prefix of giaddr) ) { renumber one of interfaces found on this link;}

Renumber IF1 of ARCP router 2 to {1.1.1.2}

ciaddr = {1.1.2.1}(2)dummy BOOTREQUEST

(Address Pool)1.1.1.0/241.1.2.0/24

(B)ARCP Server

ARCP Router 1DHCP Server ARCP Router2

1.1.1.1 1.1.1.2

IF1

IF1

IF2

IF2

(C)

Relayed Message

Message

Copied and Relayed Message

1.1.1.11.1.2.1

giaddr = {1.1.1.1} ciaddr = {1.1.2.1}

(A)

(B)

ARCP ServerDHCP Server

ARCP Router21.1.2.1

(1)dummy BOOTREQUEST(1)dummy BOOTREQUEST

(6)ARCPCFG

(1)dummy BOOTREQUEST

ARCP ServerDHCP Server ARCP Router2

1.1.1.2

IF1IF2

(7)DHCPRELEASERelease unnecessary 1.1.2.1 from IF1

(Actually managing no addresses)

Acts as a"Proxy DHCP client"

(use giaddr ={1.1.1.1})

ARCP Router 11.1.1.1

IF1 IF2

ARCP Router 1

1.1.1.1

1.1.2.1

1.1.1.2

(5)DHCPACK

(2)DHCPDISCOVER(3)DHCPOFFER

(4)DHCPREQUEST(A)

(B)

(Address space)1.1.1.0/241.1.2.0/24

(Note: )

(Given address space)1.1.1.0/291.1.2.0/29

(Given address space)1.1.1.0/291.1.2.0/29

(A)ARCP Server DHCP Server

1.1.1.51.1.1.4

1.1.1.[1-3] 1.1.1.[4-6]

addresses for the renumberings exhausted

1.1.1.31.1.1.2

1.1.1.1

1.1.2.[1-3] 1.1.2.[4-6]

1.1.2.1

(E)

(C)(D)

ARCP Server DHCP Server

(B)

(no address pool)

1.1.1.[1-6]

1.1.2.[1-6]

1.1.1.51.1.1.41.1.1.31.1.1.2 1.1.1.6

1.1.1.1

(B)

(A)

addresses assigned by DHCPaddresses assigned by ARCP

Problem (1): Address management is not explicitly provided.

Fig.5: Address management solution for ARCP (S2)

Fig.3: Address assignment by solution S1

Solution (1): All addresses are managed originally by a DHCP server.

Fig.4: Address assignment by solution S2

Problem (2): DHCP server cannot provide addresses of default gateways.

Fig.6: An example of problem and solution S1

Fig.7: An Example of solution S2

Solution (2): ARCP routers replace values of DHCP “router” option field.

DHCP Server

ARCP Server

ARCP Router 2

1.1.1.1

(1)DHCPDISCOVER(2)DHCPDISCOVER

(3)DHCPOFFER (4)DHCPOFFERrouter = 1.1.1.1

ARCP Router 1

IF1 IF2

giaddr = 1.1.1.1DHCP Server creates "router" value from"giaddr " value.

(B)

(C)

IF1subnet 1.1.1.0 netmask 255.255.255.0 { range 1.1.1.1 1.1.1.254; option routers 1.1.1.???(unknown);} (A)

DHCP Server

ARCP ServerARCP Router 2

1.1.1.1

(1)DHCPDISCOVER(2)DHCPDISCOVER

(3)DHCPOFFER (4)DHCPOFFERrouter = 1.1.1.xxx

ARCP Router 1

IF1 IF2

giaddr = 1.1.1.1

subnet 1.1.1.0 netmask 255.255.255.0 { range 1.1.1.1 1.1.1.254; option routers 1.1.1.xxx(unused);}

(B)

IF1

router = 1.1.1.1

Relay agent replaces "router" option to the value of "giaddr".

(A)

Priority Table Subnets Priority

123 (1)

ARCP Router 1

ARCP Router2

IF1

IF1 IF2

IF2

ARCP Server

1.1.3.1

ARCP Router3

IF1 IF2(A)

ARCP Router 1

ARCP Router 21.1.2.1

ARCP Router 3(B)

1.1.1.1dBR 1.1.2.1

1.1.1.1

dBR 1.1.3.1 1.1.1.1

1.1.1.1

1.1.1.2

ARCP Router 1

ARCP Router21.1.2.1

ARCP Router3(C)

dBR 1.1.3.2

1.1.1.1

1.1.1.21.1.3.1

1.1.3.1

1.1.3.2

1.1.1.2

ARCP Router 1

ARCP Router21.1.2.1

ARCP Router3(D)1.1.1.1

1.1.1.21.1.3.11.1.3.21.1.1.1

Return to state of (B)

Rn

Rn

Rn

ARCP Router 1

ARCP Router2

IF1

IF1 IF2

IF2

1.1.3.1

ARCP Router3

IF1 IF2(A)

1.1.1.1dBR 1.1.2.1

ARCP Router 1

ARCP Router21.1.2.1

ARCP Router3(B)

dBR 1.1.3.1 1.1.1.1

1.1.1.1

1.1.1.21.1.3.1

Rn

ARCP Router 1

ARCP Router21.1.2.1

ARCP Router3(C)1.1.1.1

1.1.1.21.1.3.11.1.1.3

Rn

Accomodation finishes with thefewer number of renumberings

1.1.2.1

1.1.2.1

1.1.1.1

1.1.1.0/241.1.2.0/241.1.3.0/24(1)

(2)

(3)

dBR BA ・・・dummy BOOTREQUEST messagehas giaddr A and ciaddr B

Rn ・・・Renumbered interface

Problem (3): “Peer Discovery” and “Renumbering” operations can cause repetitive address changes.

Fig.8: Problem of repeating Renumbering operation

Fig.9: Solution with static priority method

Solution (3): The ARCP server presets static priority for each subnet.

Problem (4): “Renumbering” operations can evaporate default gateway address.

Fig.11: Solution with prohibition of actual Renumbering operation

Solution (4): ARCP routers suspends actual Renumbering operation until downstream ARCP routers are configured.

Fig.10: Problem of evaporating default gateway address

(2)DHCPACK(1)DHCPACK

(3)ARCPCFG

ARCP Server

ARCP Router 1DHCP Server

IF1 IF2 IF1

ARCP Router 2

ARCP router 2 cannot communicate with ARCP server

(4)ARCPREG(5)ARCPCFG

(C) Default gateway unreachableRenumber IF2 of Router 1 (B)

Default gateway for ARCP router 2(A)

(D)

(6)dummyBOOTREQUEST

(2)DHCPACK(1)DHCPACK

(3)ARCPCFG

ARCP ServerARCP Router 1DHCP Server

IF1 IF2 IF1

ARCP Router 2null;

(4)ARCPREG(5)ARCPCFG

(6)dummyBOOTREQUEST

[IF1:ARCP router 2] = {DHCPACK relayed};

[IF1:ARCP router 2] = {dummy BOOTREQUEST relayed};

ARCP Router 1 renumbers IF2 actually (E)

Renumbering of IF2 of ARCP router 1 should beprohibitted in this period

Configuration status table ofdownstream routers of IF 2 of ARCP router 1:

(D)

(B)

(A)

ARCP server requested renumbering of IF2 of Router 1 (C)

0.0

50.0

100.0

150.0

200.0

250.0

300.0

350.0

400.0

450.0

1 2 3 4 5 6 7 8 9 10

Static Priority Enabled

Static Priority Disabled

Simulation example of ARCP

Fig.13: An example network

Fig.14: Results with example network shown in Fig.13Number of routers (N)

Tim

e o

f c

om

ple

tio

n o

f a

cc

om

mo

da

tio

n

[se

c]

ARCP server DHCP server

Hub 2Link 1

Number of ARCP routers connected inparallel is simulation parameter ( N )

............ARCP

router 2ARCP

router 1ARCP

router 3ARCP

router 10

Hub 1

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/internet-

drafts/draft-ietf-ipv6-multilink-subnets-00.txt, Jun. 2002.

[2] J. Linton, “Automatic Router Configuration Protocol”, http://www.ietf.org/internet-drafts/draft-linton-

arcp-00.txt, Oct. 2002.

[3] J. Linton and G. Chelius, “Zerouter Protocol Requirements”, http://www.ietf.org/internet-drafts/draft-

linton-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/draft-

ietf-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/internet-

drafts/draft-lutchann-ipv6-delegate-option-01.txt, Feb. 2002.

[9] http://internet.motlabs.com/mailman/listinfo/zerouter/

[10] http://www.opnet.com/.