A Secure Mechanism for Address Block Allocation andDistribution

Damien Leroy∗, Olivier BonaventureUniversite catholique de Louvain (UCL) - Louvain-la-Neuve, Belgium

{Damien.Leroy,Olivier.Bonaventure}@uclouvain.behttp://inl.info.ucl.ac.be

April 30, 2008

Contents1 Introduction 2

1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Architecture of our solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Parts of an IPv6 address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Address status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Requirements 42.1 Existing address allocation mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Description of our solution 53.1 Security threat model and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.2 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Address block distribution protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.1 Network discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2.2 Hello request and response messages . . . . . . . . . . . . . . . . . . . . . . . . 73.2.3 Prefix advertisement message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.4 Address block advertisement message. . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Address block allocation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.1 Allocation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.2 Size of local trees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3.3 Allocation in the local tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3.4 Integrating a growth factor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Evaluation 11

5 Conclusion 13

∗Supported by a grant from FRIA (Fonds pour la formation à la Recherche dans l’Industrie et dans l’Agriculture, rue d’Egmont 5- 1000 Bruxelles, Belgium).

1

1 Introduction

The growth of the BGP routing tables in the default-free zone is again a concern for many network opera-tors [MZF07]. A key reason for this is the way IP addresses are allocated and used. The pool of availableIP addresses is managed by the regional registries (RIPE, APNIC, . . . ). These registries define two types ofaddresses : Provider Aggregatable (PA) and Provider Independent (PI). To limit the size of the BGP routingtables, only large ISPs should obtain PI addresses while customer networks should receive PA addressesfrom the PI block of their upstream provider. Unfortunately, if a corporate network uses a PA addressblock, it should renumber all its network when it changes from its upstream provider. For this reason, mostcorporate networks insist on obtaining PI addresses, even with IPv6 [Pal]. Combined with the growth ofmultihoming [Hus01], this explains the growth of the BGP routing tables. This growth could be avoidedif corporate networks and smaller ISP networks were able to more easily use PA addresses. Unfortunately,with the current Internet architecture, using PA addresses implies that each corporate network must berenumbered each time it changes from provider and several studies have shown this to be painful with bothIPv4 and IPv6 [BLD05].

During the last years, extensions to the Internet architecture have been proposed. Several of thesesolutions rely on the separation between the two distinct roles of IP addresses : identifier and locator. Anidentifier is an address used to identify (the applications running on) one endsystem. An endsystem usuallyhas one identifier. It can be a cryptographic identifier (such as with HIP [MN06]) or an IP address (such aswith LISP [FFOM]) obtained from PI space. A locator indicates the attachment point of an endsystem or arouter. A router and a multihomed host have multiple locators assigned to them. A mapping mechanism isused to derive one locator from an identifier. When an endsystem moves or its upstream provider changes,its locator(s) change(s) but its identifier remains the same.

In the early days, IP addresses were allocated manually to both routers and endsystems. However, thismanual allocation was a cause of errors and problems. As a consequence, most endsystems now obtaintheir IP address automatically either via DHCP or via auto-configuration. Despite the widespread use ofautomatic configuration of endsystems, the addresses used by the routers are still manually configured(except in small networks by using DHCP extensions) and several studies have shown that configurationerrors are responsible for a large number of operational problems [MWA02]. In this paper, we propose andevaluate a new distributed mechanism which is able to automatically allocate IPv6 prefixes to routers andLANs in an ISP, corporate or campus network.

1.1 Definitions

We call router a device in our network that runs our protocol, host an end-device in our network that cannotrun our protocol. The term subnet is used to define a subnetwork (a LAN or a customer network) that needsto obtain an address block (e.g. customer 1 or LAN in Fig. 1.

1.2 Architecture of our solution

Our address distribution mechanism is targeted for edge networks as well as ISP networks that need toprovide address blocks to their subnets. The typical environment where it should be run is representedat Fig. 1. In this figure, arrows represent the direction of address block allocation. Our mechanism iscomposed of three main parts. One or several prefixes are obtained from upstream ISPs by border routers(A, B on Fig. 1). Subnets needing an address block ask for it at border routers (D, E, F on Fig. 1). Therouters negotiate which parts of the obtained prefixes have to be allocated to subnets. The term “prefix” isused to indicate a prefix allocated by one of our providers (i.e. ISP α or ISP β in Fig. 1) while “addressblock” is used to indicate a group of addresses allocated by our protocol to subnets.

1.3 Parts of an IPv6 address

An IPv6 address can be viewed as three different parts as shown on Fig. 2 and seen through an enterprisenetwork view:

2

ISP α

ISP β

Customer 1

Customer 2

LAN

Servers

Our ISPs Core of our network Our subnets

A

B

C

D

E

F

Figure 1: The protocol does apply on hierarchical topologies

1. A global routing prefix that we will simply call prefix in this document. The number of bits ofthis prefix will be referred as PS . PS should be equals to 48 in most edge networks (an enterprise,...) [II01, APN07]. In our case, we will consider 3 < PS < 64. This prefix will be attributed to usby our provider. We can receive several prefixes if we are multihomed.

2. A subnet ID (SID) uniquely identifies a subnet in our network. Its size is equals to 64− PS and has16 as a typical value. For our protocol, we will split it into 2 parts:

(a) An attributed subnet ID (ASID) that is uniquely attributed by the network to a customer. Thenumber of bits allocated to ASID will be referred as ASIDS .

(b) A delegated subnet ID (DSID) that is the part of the address that under the customer’s authority.The number of bits for customer allocation will be referred as DSIDS .

Note that DSIDS and ASISS are ranged between 0 and 64− PS . In the case of a local subnet or acustomer that only need a single subnet, DSIDS is equals to zero. ASISS will never be set to zero(i.e. DSIDS = 64− PS) since there would be no more address available for our network.

3. An interface ID (noted IID) that is uniquely attributed in a subnet and that identify the host in it.The size of IID will always be 64, it can be attributed by egress router using DHCP [DBV+03] orby the host itself using the Neigbor Discovery protocol [NNS98] or SEND, the secure version ofit [AKZN05].

Figure 2: Structure of an global unicast address according to [II01]

If we consider that our customers use the same definitions than ours, customer’s prefix corresponds toour prefix concatened with the DSID we have attributed to him.

1.4 Address statusThis section describes an extension to the standard IPv6 address status [II01]. These new status are ofcourse only used for internal conventions in this protocol. They can be used with either a single address oran address block.

Here a list of these status with a short word about them. A representation of them on a timeline isshowed below the list.

3

Free : it is not really a status, an address is considered as “free” when it has no other status i.e. when it isnot reserved by anyone.

Pending is used to annonce that this address will be used in a few second and is waiting for collisionnotification if any.

Preferred status means that this address is used for the moment and is defined as preferred to hosts towhich it has been attributed.

Deprecated is used to annonce that an address is still used by hosts but that it should be avoided as muchas possible for new connections.

Valid is corresponding to an address with either the preferred or deprecated status.

Reserved status is used in our protocol when an address valid time is elapsed but is still reserved for useto the former router in charge of it.

-------------------------------------------------------------------->free | pending | preferred | deprecated | reserved | free

| | valid | |-------------------------------------------------------------------->

2 RequirementsIn this section, we summarize the main requirements that must be fulfilled by an address allocation mech-anism as well as a state of the art of such mechanisms.

Utilization of address space. A first goal is to support an Host-Density ratio (noted HD) equals to0.8. The HD is a way to measure address space usage [DH01]. It is expressed as the ratio of log(numberof allocated address blocks) to log(maximum number of allocatable address blocks). Several regionalregistries defined the value 0.8 as an acceptable IPv6 address utilization for justifying the allocation ofadditional address space [APN07]. As in [APN07], we

Compatibility with existing protocols. Since the role of the mechanism is limited to address blockallocation, it must be independent from the routing protocol. The network operator should be free to useeither IS-IS, OSPF, RIP or EIGRP.

Security. The Internet started as an open network mainly used by researchers. Nowadays, IP networksare used to support mission critical business services and security matters. We discuss the security threatsin more details in Sect. 3.1.

Roles. In an ISP, enterprise or campus network, network operators usually group the hosts that havesimilar roles in contiguous address blocks. For example, all loopback addresses of routers usually belong tothe same prefix, all servers are grouped in a few prefixes and the hosts used by students in a campus networkare grouped in contiguous prefixes as well. ISPs also group their customers in prefixes depending on theirtype (e.g. home users, business customers, . . . ). This allows to define and deploy policies on routers (e.g.,QoS, traffic engineering, . . . ) that are more scalable and easier to maintain. Common examples are thepacket filters deployed on most routers and firewalls to filter unwanted packets. Chown et al. have shownthat updating packet filters is a difficult problem when renumbering a network [CFV06].

Prefix coloring. Another requirement is that the prefixes received from different providers are notnecessarily equals. Due to routing policies, it can be necessary to classify the prefixes received fromproviders in different categories. For instance, if a National Research Network has been allocated a prefixfrom a backbone research network, it should only allocate address blocks from it to its customers that areresearch labs. K12 schools should not be allocated an address block from such a research prefix.

2.1 Existing address allocation mechanismsSeveral researchers have studied the problem of automatically configuring the addresses used by routers.

4

The NAP Protocol (No Administration Protocol) by Chelius et al. [CFT05] is targeted at SOHO (SmallOffice and Home Office) network. They provide a protocol for allocating an address block to /64 LANonly. The NAP protocol is integrated in OSPFv3 using its link state advertisements and a prototype NAProuter has been implemented. Unfortunately, NAP does not consider the problems faced by campus andenterprise networks such as the need for roles and the security issues.

The address allocation problem has also been studied within ad-hoc networks and notably within theautoconf working group of the IETF [BMRS07]. A detailed survey of the solutions that have been dis-cussed within this working group may be found in [BCM07]. The solutions developed for wireless ad-hocnetworks cannot easily be reused for ISP networks because that assume that all routers will receive prefixeshaving the same size and do not take security into account.

Other solutions proposed at IETF such as DHCP prefix delegation [TD03] or router renumbering [Cra00]do not meet all requirements. They require manual configurations and cannot be adapted to provide mini-mum security features without difficulties.

3 Description of our solution

This section describes in more details our proposed mechanism. We first present the security risks andsolutions. Next, we describe the address block distribution protocol. This section ends with the explanationof the address block allocation algorithm.

The distributed IPv6 addresses are composed of three parts as illustrated in Fig. 3. Here are somenotations we use in this paper. The first part is the prefix given by the upstream ISP. These leftmost bits arecommon for all hosts and routers in our network. The last 64 bits of the address are used for the InterfaceID (IID). The bits between these two parts uniquely identify a subnet and are called Subnet ID (SID). Wewill consider two parts in this SID: the allocated SID (ASID) and the delegated SID (DSID). The ASID isthe part that our mechanism allocates and provides as a prefix to subnets. The DSID is the part of the SIDthat the subnet is free to allocate inside its network. In other words, a subnet obtains a /(prefixs+ASIDs)prefix1.

0010000000000001:0101100001010011:1011110001110101:0010000011110011:0001010111001100:0111001010100111:1001101010001111:0001100100000000

End-host partPrefix SID

DSID (Delegated SID) (here size 6)ASID (Allocated SID) (here size 10)

Figure 3: Different parts of an IPv6 address

The protocol for prefix delegation used with the providers of our network and with our customers isoutside the scope of this paper. It could be designed as an extension to BGP, using DHCP with prefixdelegation option [TD03] or a new protocol using the X.509 certificates being defined by the IETF SIDRworking group. The only requirement we impose is security, as discussed below.

3.1 Security threat model and solutions

It is easy to be convinced that an address block allocation mechanism is a key component of an IP networkand could be the target of attacks. Indeed, this protocol, in the network configuration process, runs prior tothe other IP protocols. Therefore, if this protocol were compromised, the entire network or a large part ofit could be compromised.

The first risk comes from a malicious router that could be interpolated in the network. In addition tothe security threats on all the routing and IP protocols, this router could send several kinds of messages inorder to confuse the address block distribution protocol. It should be possible for a router to detect whetherits neighbor is a legitimate router. For instance, if router D on Fig. 1 were unauthorized, router A and Eshould not trust it and thus not forward its messages.

1s subscripted means “size” in this paper. For instance, SIDs for the size of the SID.

5

The second risk could be another possibility of obtaining similar rights but without inserting a router.It consists in intercepting the packets exchanged between two routers and performing a man-in-the-middleattack.

The last two risks are based on abusing a link between border routers and their providers or customers(e.g. between ISP α and router A or between router D and customer 1 on Fig. 1). Invalid prefix announce-ments can cause a global unavailability or traffic hijacking. Abuse can also appear with address blockrequests if there are automated and not secure.

3.1.1 Solutions

The first idea is that IPv6 prefix delegations and certificate delegations go together. In other words, eachnetwork that possesses a prefix has obtained, from its ISP, a certificate proving that it is allowed to use anddelegate it. In our mechanism, these are mainly used to authenticate our ISP’s routers. Actually, we relyon the X.509 extensions for IP addresses [LKS04].

To allow a provider to authenticate its customers, our network has its own certification authority andeach router is configured with a certificate (as suggested by Greenberg et al. [GHM+05]) to confirm thatit does belong to the network. An X.509 certificate signed by our local certification authority (CA) canbe used by its owner to provide an authorization evidence to nodes of our network. A certificate itselfidentifies its owners and we associate them with attribute certificates [FH02a] to provide authorization.These attributes are used by our subnets to specify their role, their provided prefix colors and their addressblock size. These certificates could be given offline to customers when the contract is signed and are usedwhen the customer connects to one of our border routers. Secondly, attribute certificates are also used toauthenticate connections between routers : a neighbor is considered as a legitimate router if and only if itcan be authenticated.

The connection between two routers do not need any confidentiality but, as previously asserted, has tobe protected against injections, replays and message modifications. Therefore security parameters must beused in each message sent between routers. This can be made using IPSec, SSL or by defining some newfields to our protocol messages.

3.1.2 Certificates

The certificates used for top-down authentication, this is of ISP to their customer, should use the certificatedefined by the SIDR working group at the IETF [LKS04]. The architecture of this PKI has been definedin [LKB08]. When a customer try to authenticate its ISP, it has typically no Internet connectivity to valid theISP’s certificate. The border router of the ISP can help its customer obtaining evidences using a certificationpath that can be checked by the customer. All the certificates should be distributed along with the prefixesusing the prefix delegation protocols.

Different certificates are used from bottom-up authentication, in order for customers to authenticatethemself. It consists of a Internet X.509 Certificate [HPFS02] and one or several Attribute Certificates [FH02b](AC). The X.509 Certificate associates a key pair with a unique 64-bits identifier associated with its owner.The AC associate the identifier with the role or the colors of an entity. These certificates must be usedfor routers as well as for child networks. As the “just connected” routers have no IP address yet whenmaking contact with neighbors, a router that need to be authenticated must provide its certicates along withevidence. It can be empty if it is supposed that all routers possess the public key of the local CA or basedon the certification path if not.

3.2 Address block distribution protocol

Our protocol is distributed, each router is responsible for its address blocks and has to choose and advertisethem. In practice, each router chooses one or several address blocks and advertises them through thenetwork. A distributed protocol avoids the single point of failure problem. Chelius et al. also showed thatit is more efficient for address block distribution, especially if the network is multihomed [CFT05].

6

Each router is configured with one 64-bits router id (derived from MAC address or crypto based), itsX.509 and attribute certificates and information about the subnets attached to itself. The loopback addressof each router can be derived from the router id using a fixed SID for all routers.

Routers use discover and hello messages for, respectively, discovering their direct neighbors and ini-tializing connections with them. Since this is very similar to other protocols such as LDP, we will not enterinto detail about these. The prefix and address block advertisement messages are flooded to all routers.

Notations for the following messages are the following :

RIDX : The router id of X

NX : A nonce, choosen by X , that also corresponds to a session id used to retrieve the entry in datastructures

PKCX : The Public Key Certificate (X.509 Certificate) of X

ACX : The Attribute Certificate(s) of X

SignX(s): The signature of the string s with the private key of X

NE: Number of entries of the message

sX,Y Sequence number of the message sent from X to Y

Except for the discover ones, messages are sent over a TCP connection.

3.2.1 Network discovery

A “discover message” is a router multicast2 UDP packet periodically sent on each interface of the router.When such a message is received from an unknown neighbor, a connection is initiated with the sender.Neighbor information will be stored in a table we will call the neighbor table.

Before continuing the next steps, a loopback address have to be assigned to each router. It is generatedby concatenating the Unique Local Address (ULA) [HH05] prefix with zeros as SID and with the routerID (given in the certificate) as IID.

At startup and every tdiscover seconds, a router send a discover message on each its interfaces thatrun our protocol. This message is sent to the link-local router multicast group (ff02::1) that have to belistened by all the interface using the protocol. This message contains the router id of the sender.

When a discover message is received with r as router id :

• If r belongs to the neighbor table, ignore the message.

• If not, initiate a TCP connection with this node and send it a hello req message.

A more complete state machine of the discover daemon is depicted in Fig. 4.

3.2.2 Hello request and response messages

To initiate a connection with a neighbor, a router has to send an hello request message providing its IDand security parameters. If the receiver accepts the connection, it replies with a hello response messagecontaining its own security parameters. Once this message has been received, the connection is consideredas established. The following messages will only be sent on an established connection. A router stores alist of its direct neighbors with their security parameters associated in a neighbor table.

If we consider A as the hello request sender and B its destination. The hello request contains : RIDA,NA, SignA(RIDA, NA), PKCA, ACA. A hello response (from B to A) contains : RIDB , NB , NA,SignB(RIDB , NB , NA), PKCB , ACB .

When a hello request message is received :

2Router multicast is a particular link-local IPv6 address that should be listened by routers on a LAN and that must not be for-warded [HD06].

7

Figure 4: State machine of the discovery daemon

• If an entry with this neighbor appears in the neighbor table, close the connection.

• Check the signature of the message with the supplied PKC, if it fails, close the connection.

• Check the validity of the PKC and AC and their matching with RIDA. If it fails, close the connec-tion.

• Add an entry in the neighbor table

• Send a hello resp message in response.

When a hello response message is received :

• Check the sA in the message that has to be the one the router has generated, if it fails, close theconnection.

• Check the signature of the message with the supplied PKC, if it fails, close the connection.

• Check the validity of the PKC and AC and their matching with RIDB . If it fails, close the connec-tion.

• Add an entry in the neighbor table

When the hello resp message has been sent or received, the address allocation protocol itself canstart.

3.2.3 Prefix advertisement message.

When a border router learns that a new global prefix has been allocated to the network, it floods immediatelythe information. Each prefix is associated with a preferred and a valid lifetime and so must be regularlyrenewed as long as it remains valid. A prefix advertisement message contains : the size of the prefix,the prefix itself, the deprecated and validity lifetime, the prefix color, a sequence number and securityparameters. The sequence number is incremented each time a new message about a specific prefix isgenerated. Until the lifetime expires, an entry per prefix is stored in a prefix table in each router.

8

3.2.4 Address block advertisement message.

When a router chooses new address blocks, it floods an address block advertisement message. This messagecontains a list of address block entries, one for each entry it chooses. When such a message is received, theproposed address blocks are checked and new address blocks are stored with the already allocated ones.The way address blocks are chosen and stored is explained in Sect. 3.3. An address block advertisementmessage contains the router id of its issuer and a list of address block entries. An entry contains a role, Ps,ASIDs, ASID, a timestamp, the preferred and valid lifetime and a sequence number. As for prefixes, thesequence number is incremented each time an address block entry is changed (ASID changed, preferredtime redefined, . . . ). As the mechanism is distributed, there is a non-zero probability that two routerschoose conflicting blocks nearly at the same time; we call this a collision. The issue is solved by usinglogical clocks and randomness for tie-breaking.

If A is the sender of the message, a Address block advertisement message contains : RIDA, sA, nB , alist of address entries and the signature of all the previous field. Each address entry containing : the RIDof the router in charge of it, the customer id, the role of the customer (if it applies), the color (if it applies),PS , ASIDS , ASID, preferred time left, valid time left, sequence number of the entry.

3.3 Address block allocation algorithm

This section explains the way subnet address blocks are chosen in the address space. The following rulesapply to any prefix for which the subnets should obtain an address block. The only part of the addressblock that our mechanism has to determine is the ASID as shown in Fig. 3. For instance, consider that thenetwork has obtained two /48 prefixes, 2001:4bc7:9377::/48 and 2001:3def:73cb::/48, from its ISPs. If theASID “1ed6” is allocated a /64 subnet, this subnet will obtain as prefixes 2001:4bc7:9377:1ed6::/64 and2001:3def:73cb:1ed6::/64.

In our mechanism, each router chooses a large address block that can contain all the subnets attachedto itself, we will call it the “router block”. Inside this block, each router allocates address blocks for itssubnets, we will call these the “subnet blocks”. In the topology depicted in Fig. 1, it means that router Fallocates two address blocks inside its own router block : one for Customer 2 and one for LAN. The routersblocks are chosen by routers using heuristics such as role aggregation and optimization of the addressspace. Due to space limitation, these cannot be explained in this paper. The addresses of the router blocksare flooded through the network and are therefore known by all the routers. On the other hand, the subnetblock allocations are only known by the router in charge of them. We use two types of tree to represent theallocation: global and local trees. Global trees store the set of the router block chosen by each router. Localtrees are used to store and allocate the address blocks of the subnets. Whereas global trees are common toall routers, local trees are restricted to each one and are never published.

The left part of Fig. 5 depicts the global tree stored by all routers. Since two /48 prefixes have beenreceived from our providers, a global tree rooted at “global depth” 48 has been created. White nodes repre-sent unallocated blocks, black entirely allocated ones and grey partially allocated ones. Router A requeststwo address blocks, the first one for subnets with the “server” role. A /50 has been allocated for this firstrequest. The second request is for a /50 customer block. Router B makes one /51 address block reser-vation for customers, its address blocks being 2001:4bc7:9377:8000::/51 and 2001:3def:73cb:8000::/51.Note that reservations are grouped by role : in this example, customers are aggregated within a /49 prefix.

On the right part of Fig. 5, this is the local tree corresponding to the /51 address block for customersof router B. This tree, only stored in router B, details the allocation of this address block. Router Bhas five customers, four requesting a /54 prefix and one requesting a /53. Each customer has thereforeobtained two prefixes. For instance, the customer that needs a /53 obtains 2001:4bc7:9377:9800::/53 and2001:3def:73cb:9800::/53.

3.3.1 Allocation algorithm

consists in choosing a large address block in global tree that can contain all the subnets. Next, allocationof this address block is made in a local tree in order for each subnet to obtain an address block of the size itneeds. The main modifications in allocations are done in each router at its startup, when a subnet is added,

9

root

router: BDSIDs: 13

role: customer

router: ADSIDs: 14role: server

router: ADSIDs: 14

role: customer

global depth

50

51

01

0 1 0 1

0 1

router Brole: customer

Subnet DSIDs: 10

Subnet DSIDs: 10

Subnet DSIDs: 10

Subnet DSIDs: 10

Subnet DSIDs: 11

0 1

0 1

0 1 0 1

0 1

49

48

global depth

53

54

52

512001:4bc7:9377::/482001:3def:73cb::/48

Figure 5: A global (left) and a local (right) tree containing some reserved address blocks. (black trianglesare attributed nodes, white circles free ones and grey square partially attributed ones.)

removed or updated. We only describe the main ideas of the algorithm. Its objective is to find an allocationfor each subnet that has not yet received an address block. To achieve it, we start by checking if there werea place where we would prefer for them to be. If it is not possible, we lower the requirements and so on.Typically, we prefer to place subnets in an already attributed address block, if not possible we try to placethem grouped in a same new address block and finally if not possible we allocate the larger subnet aloneand restart this rules.

3.3.2 Size of local trees.

When a new address block is reserved in the global tree, which size should it have ? Too narrow reservationmay have the following consequences : a new subnet cannot be added, an existing subnet cannot be enlargedand subnets have to be tightened. These can have consequences such as address blocks moving, lots ofaddress block update messages sent or repartition of the address space of router into lots of small slots. Onthe other hand, if the reserved block is very large in comparison to its use, it becomes difficult to hold 0.8as HD. For measuring occupation more easily than with HD, we introduce the occupation ratio (OR) as theratio between the number of reserved addresses and the total address space available. OR is linked to HDby : OR = 2SIDs(HD−1). We also define two markers: minimum occupation ratio (OR) and maximumoccupation ratio (OR). At any moment, if the OR of a local tree is greater or equals to OR, it should beenlarged. On the opposite, if it is smaller or equals to OR, the tree should be reduced or split. Furtherdiscussions about the optimal values of these parameters are out of the scope of this paper.

3.3.3 Allocation in the local tree

The current way address blocks are allocated in the local tree is the following. We always prefer a nodewithout any direct neighbor (e.g. in Fig. 5, the two leftmost nodes of local trees are neighbors). Next, weprefer having a neighbor node with a single attributed subnet to one with several subnets (e.g. in Fig. 5, wewould prefer having a black node as neighbor to a grey one with several black nodes as children). Finally,between preferred solutions, we choose the leftmost one. This allocation scheme could be inaccurate ifwe had very scattered subnet sizes (very small ones and very large ones at the same size) since it wouldlead to high fragmentation. On the other hand, this scheme could also be inaccurate if subnets enlargedand reduced their size very often. In this case, there would be not enough fragmentation. Allocation couldjustify an entire study based on the subnet size in an edge or ISP network and so are cannot be detail in thispaper.

10

3.3.4 Integrating a growth factor.

[Wan05] performs the analysis of address block allocation schemes by comparing the bisection schemewith a growth-based one. The bisection scheme consists in placing new address block halfway through thebiggest free space of the address space. The idea of the growth-based scheme is to allocate more spacedirectly to a subnet that is subjected to increase its size. Despite the solution itself is very interesting, thequestion is for us how to obtain this growth information and how to monetize it. Since the implementationoverhead is very low compared to the difficulties of evaluating the real impact of ISP and edge network,we decided not to implement it for the moment. However, it is a good lead for further improvements whileevaluating in real architecture.

3.4 Areas

In a large network containing a large number of routers or high delay links, it is sometimes interesting tosplit the network into smaller areas. It is even more important for our protocol since otherwise floodingcan be quite long and tables stored pretty large. Moreover, areas can be useful for efficently improving theaddress aggregation in FIBs.

To deal with areas, the decision has been made to let them be configured manually by network admin-istrator. Indeed, we believe that these are large scale choices that still need human decisions. Moreover,when a router move from an area to another, some other reconfigurations have still to be made.

The way areas work in our protocol is quite simple. If they are used, each router has an area numberassociated with it. This number is coded with few bits. These bits will corresponds to the first bits of theASID that will be choosen. All the area number must have the same length in a network.

Areas number is configured for each interface, so a router can have interfaces on different areas. Onlythe prefix advertisement messages are forwarded from an area to another one.

4 EvaluationIn order to validate our assumptions, we have written a simulator that allows us to evaluate the performanceof our mechanism. Some results of our simulations are shown in this section.

Simulations are run on a 110-routers-topology coming from a real ISP network. Subnets with randomDSIDs are uniformally associated to routers to obtain the HD-Ratio we want to observe. Since we want toevaluate the protocol on a large number of subnets, the size of blocks requested is quite small, DSID sizesare comprised between 0 and 2. We consider that we obtain a /48 from our ISPs, so SID size equals to 16.The test set consists in starting this configuration and applying every minute modifications to the subnettopology. Modifications include adding new subnets, removing subnets, reducing and enlarging the addressblock they need. These modifications are uniformally performed unless we obtain a larger HD-Ratio thanthe one we want to maintain. We consider 10,000 changes for each experiment.

The set of address blocks globally reserved is one of the information that is stored on all routers.Therefore, the number of such allocations should be as low as possible and can be viewed as a way tomeasure the performance of the allocation algorithm. If there is at least one subnet managed by eachrouter, the minimum value of this is the number of routers. In our test bed, this value should be as close aspossible to 110. Figure 6 shows the evolution of this value when the HD-Ratio is changing. The upper partshows number of global address blocks for each experiment. The lower part represents the mean numberof subnets per router. The first vertical line shows the 0.8 value of HD-Ratio, i.e. the ratio we want to reachwithout any problem. The second vertical line shows the HD value (0.95) from which our mechanism isnot able to place all the subnets. The dotted horizontal line represent the number of routers (110), i.e. theoptimum value we could obtain. Note that for the results obtained in these experiments, we did not have tomove any already allocated address block.

We can see at the left of Fig. 6 some points below the “110 line”. They correspond to experimentsin which some routers have no subnet to place. Next, we see an increase followed by a drop. In theseexperiments, there is a small number of customers allocated in each router address block. Therefore, whenmodifications are performed (e.g. addition of new subnet) the router address block can be full and a new

11

address block requested. When the number of customers increases, these modifications do not fill entirelythe router address blocks anymore. That is why the number of address blocks decreases and stays equalsor nearly equals to 110. From 0.95 as an HD-ratio, some routers do not succeed in allocating address blockfor all their subnets.

Figure 6: Evolution of the number of global address blocks reserved when HD is increased.

For the protocol overhead analysis, we can consider the handshake messages between neighbors, i.e. theauthenticated hello exchange and the keepalives. These messages never exceed 10 messages per minutewith one hop. Next, let us consider the messages sent by the core routers when one of their subnets ismodified. Since a router makes the reservation of an address block for all its clients, only one message issent at startup by router having clients. Next modifications do not generate lots of messages since mostchanges can be done within the reserved blocks of the router. We have measured a mean rate of 0.03messages received per router and per modification, i.e. 3 messages on each link for 100 modifications.

Convergence time measured is usually very short. Since routers do not start reserving a block at thesame time (in order to avoid collisions), the convergence time will be equals to this bootstrap time. Whilerunning, modifications will be applied either directly if no new block has to be requested or after a shortwhile corresponding to collision notification waiting otherwise.

Another interesting result is the number of entries stored in router tables about other router reservations.The router forwarding table will also be proportional to this number. Since each router makes reservationof one prefix for several clients, we known that the lower bound of prefixes known is the number of routersthat have clients. The upper bound is the case in which each client has a specific prefix. With the test beddescribes above, we observe a size of 110 most of the time and a maximum value of 112.

#routers #clients #prefixesmin 110 4,225 110max 110 4,765 112mean 110 4,453 110.4std dev 0 151 1.37

Table 1: Number of entries in prefix tables

Finally, evaluations of the role impact has been performed. Using some roles do not change anything

12

to protocol performance. Since the different roles must stay in different prefixes, the router tables can bebigger. Our simulations show that the number of entries is multiply by the number of roles. This result iscoherent with the protocol definition. So a router with three different roles will have at least three prefixes.As well, the maximum HD-Ratio to avoid allocation difficulties is around 0.92 with three roles and thesame parameters than the experiment explained at the previous paragraph.

5 ConclusionIn this paper, we have proposed a distributed mechanism to allocate and distribute address blocks in ISP,campus and enterprise networks. We have first listed the requirements for such a protocol and discussed thesecurity threats and how to handle them. The allocation based on roles permits to aggregate subnets to makerules, such as firewall ones, simpler and shorter. When subnets have obtained address blocks, renumberingand topology changes can be performed without introducing any important perturbation in the rest of thenetwork. Our simulations shows that our protocol holds 0.8 as HD-Ratio without any problem. However,lots of parameters of the mechanism can still be discussed, most of all concerning allocation, even thoughsome of them could be found in our technical report. We are currently implementing the proposed protocolin the XORP platform.

References[AKZN05] J. Arkko, J. Kempf, B. Zill, and P. Nikander. SEcure Neighbor Discovery (SEND). RFC 3971,

Internet Engineering Task Force, March 2005.

[APN07] APNIC, ARIN, RIPE NCC. IPv6 address allocation and assignment policy. “ripe-412”, July2007. http://www.ripe.net/ripe/docs/ipv6policy.html.

[BCM07] C. Bernardos, M. Calderon, and H. Moustafa. Survey of IP address autoconfiguration mech-anisms for MANETs. Internet Draft (work in progress) “ draft-bernardos-manet-autoconf-survey-02”, Internet Engineering Task Force, October 2007.

[BLD05] F. Baker, E. Lear, and R. Droms. Procedures for renumbering an IPv6 network without a flagday. RFC 4192, Internet Engineering Task Force, September 2005.

[BMRS07] E. Baccelli, K. Mase, S. Ruffino, and S. Singh. Address autoconfiguration for MANET:Terminology and problem statement. Internet Draft (work in progress) “draft-ietf-autoconf-statement-02”, Internet Engineering Task Force, November 2007.

[CFT05] G. Chelius, E. Fleury, and L. Toutain. No Administration Protocol (NAP) for IPv6 routerauto-configuration. Int. J. Internet Protocol Technology, 1(2), 2005.

[CFV06] T. Chown, A. Ford, and S. Venaas. Things to think about when renumbering an IPv6 network.Internet Draft (work in progress) “draft-chown-v6ops-renumber-thinkabout-05”, Internet En-gineering Task Force, September 2006.

[Cra00] M. Crawford. Router renumbering for IPv6. RFC 2894, Internet Engineering Task Force,August 2000.

[DBV+03] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney. Dynamic host configura-tion protocol for IPv6 (DHCPv6). RFC 3315, Internet Engineering Task Force, July 2003.

[DH01] A. Durand and C. Huitema. The Host-Density Ratio for Address Assignment Efficiency: Anupdate on the H ratio. RFC 3194, Internet Engineering Task Force, November 2001.

[FFOM] D. Farinacci, V. Fuller, D. Oran, and D. Meyer. Locator/ID Separation Protocol (LISP). Tech-nical report, Internet Engineering Task Force.

13

[FH02a] S. Farrell and R. Housley. An Internet Attribute Certificate Profile for Authorization. RFC3281, Internet Engineering Task Force, April 2002.

[FH02b] S. Farrell and R. Housley. An internet attribute certificate - profile for authorization. RFC3281, Internet Engineering Task Force, April 2002.

[GHM+05] Albert Greenberg, Gisli Hjalmtysson, David A. Maltz, Andy Myers, Jennifer Rexford, Ge-offrey Xie, Hong Yan, Jibin Zhan, and Hui Zhang. Refactoring Network Control and Man-agement: A Case for the 4D Architecture. Technical Report CMU-CS-05-117, CMU CS, sep2005.

[HD06] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. RFC 3513, Internet Engi-neering Task Force, February 2006.

[HH05] R. Hinden and B. Haberman. Unique Local IPv6 Unicast Addresses. RFC 4193, InternetEngineering Task Force, October 2005.

[HPFS02] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastructure - Cer-tificate and Certificate Revocation List (CRL) Profile. RFC 3280, Internet Engineering TaskForce, April 2002.

[Hus01] Geoff Huston. Analyzing the Internet’s BGP routing table. The Internet Protocol J., 4(1), jan2001.

[II01] IAB and IESG. IAB/IESG recommendations on IPv6 address allocations to sites. RFC 3177,Internet Engineering Task Force, September 2001.

[LKB08] M. Lepinski, S. Kent, and R. Barnes. An infrastructure to support secure internet routing.Internet Draft (work in progress) “draft-ietf-sidr-arch-03”, Internet Engineering Task Force,2008.

[LKS04] C. Lynn, S. Kent, and K. Seo. X.509 Extensions for IP Addresses and AS Identifiers. RFC3779, Internet Engineering Task Force, June 2004.

[MN06] R. Moskowitz and P. Nikander. Host Identity Protocol (HIP) Architecture. RFC 4423, InternetEngineering Task Force, May 2006.

[MWA02] Ratul Mahajan, David Wetherall, and Tom Anderson. Understanding BGP misconfiguration.In SIGCOMM ’02: Proceedings of the 2002 conference on Applications, technologies, ar-chitectures, and protocols for computer communications, pages 3–16, New York, NY, USA,2002. ACM.

[MZF07] D. Meyer, L. Zhang, and K. Fall. Report from the IAB Workshop on Routing and Addressing.RFC 4984, Internet Engineering Task Force, September 2007.

[NNS98] T. Narten, E. Nordmark, and W. Simpson. Neighbor discovery for IP Version 6 (IPv6). RFC2461, Internet Engineering Task Force, December 1998.

[Pal] J. Palet. Provider independent (PI) IPv6 assignments for end user organisations. RIPE PolicyProposal 2006-01, http://www.ripe.net/ripe/policies/proposals/2006-01.html.

[TD03] O. Troan and R. Droms. IPv6 Prefix Options for Dynamic Host Configuration Protocol(DHCP) version 6. RFC 3633, Internet Engineering Task Force, December 2003.

[Wan05] Mei Wang. A Growth-Based Address Allocation Scheme for IPv6. In Proc. IFIP/TC6 Net-working 2005, LNCS 3462, pages 671–683, 2005.

14