Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] proposed policy: reservation of resources for IXPs

Fiona Asonga tespok at
Tue Nov 4 08:19:38 UTC 2014

Hallo All

Based on our experience at KIXP and growth strategy moving forward. I support the proposal as it allows room for the IXPs to grow with minimum challenges on management of their allocation space.

Kind regards

Fiona Asonga 

Chief Executive Officer 

Telecommunications Service Providers Association of Kenya/ Kenya Internet Exchange Point 

Member Strategic Committee of the Africa Computer Emergency Response Team 

NRO Number Council 

ASO Address Council 

14 th Floor, Bruce House 

Standard Street 

Tel: +254 20 2245 036 

Cell: +254 721 713 504 

----- Original Message -----
From: "Frank Habicht" <geier at>
To: "rpd" <rpd at>
Cc: "Nishal Goburdhan" <nishal at>
Sent: Wednesday, October 29, 2014 7:31:37 PM
Subject: [rpd] proposed policy: reservation of resources for IXPs

Hello all,

please find this proposed policy, which we (3 co-authors) have submitted to
the pdpwg last week:

Resource Reservation for Internet Exchange Points

a) Frank Habicht, Tanzania Internet Exchange
b) Michuki Mwangi, Internet Society/KIXP
c) Nishal Goburdhan, Packet Clearing House/JINX

1) Summary of the Problem being addressed by this proposal

This policy reserves IPv4 and 2-byte ASNs resources for public Internet
Exchange Points (IXPs) in the African region, ensuring that there would be
discrete IPv4 resources to allow the establishment and growth of future IXPs.

2) Summary of How this Proposal Addresses the Problem

This policy requests AfriNIC to reserve, and publish IPv4 resources, and
2-byte ASNs for use by IXPs only.

3) Proposal

3.1 Introduction

It is widely considered that Internet Exchange Points (IXPs) are one of the
critical elements needed for Internet economies to develop. Africa is still
in the process of developing these, and is, at the same time, faced with
the imminent exhaustion of its IPv4 resources. Not having IPv4 addresses to
grow, or start new, IXPs would create unnecessary and unneeded routing
complexity for Internet connected networks, looking to peer at IXPs to
further their network scope. AfriNIC already has an existing policy to make
allocations to IXPs [1], but that policy does not specifically reserve IPV4
space to ensure that there will be such, for future IXPs to grow and
develop. Additionally, this policy reserves a set of 2-byte ASNs for use by
IXPs for use at IXP BGP Route Servers.

3.2 Distinction between IXP peering and management networks

We distinguish between two kinds of IP address resources needed and used at
IXPs. An IXP peering LAN is the contiguous network address block that the
IXP would use to assign unique IP addresses to each peering member, for
each peering participant to exchange network traffic across the shared
peering infrastructure. Best practice has the IXP peering LAN *not* being
visible in a view of the global routing table, among other things to reduce
the attack vectors for ISP border routers via the IXP.

>From a network identification, monitoring and analysis perspective, it is
thus desirable, that the "peering LAN" space be provided from a contiguous
block. The IXP management LAN is the management network that the IXP uses
to provision services at the IXP, like monitoring, statistics, mail, ticket
systems, provisioning of transit to DNS Roots, etc.

Management networks, are meant to be reachable globally, for instance to
publish data and allow remote access for common good network infrastructure
(such as root and TLD DNS servers) and research projects.

3.3 BGP Route Servers use

Typically IXPs use BGP route servers to help manage peering sessions
between different participants. The route servers implement IXP routing
policy in the form of BGP communities, typically in the form of A:B, where
A,B represent A=IXP BGP route server and B=participant ASN. Current BGP
implementations utilise 6 bytes for the extended community attribute
[RFC5668]. Therefore, an IXP with a 4-byte ASN in use at its route server
would not be able to successfully implement the A:B BGP community mapping,
if an IXP participant has a 4-byte ASN. This situation is likely to be
experienced by more IXPs, as additional 4-byte ASNs are allocated through
the current AfriNIC process.

If, IXP route server communities include the IXP ASN and the peer's ASN
(expected to be 4-byte), and a total of only 6 bytes are available, it
follows that IXP route servers ASN could not be longer than a 2-byte ASN.

3.4 Proposal

To ensure that there are sufficient resources for IXPs to develop, this
policy proposes that AfriNIC reserve IPv4 addresses for IXP peering LANs
out of an address block marked particularly, and exclusively, for IXP
peering LAN use. Assignments for IXP peering LANs must be from one
dedicated block, published as such by AfriNIC. Assignments for IXP
management addresses should NOT be provided from the same block as the IXP
peering LANs.

It is proposed that a /16 block be reserved for future requirements for IXP
peering LANs in the AfriNIC service region, and that AfriNIC publish this
block as such.

It is further proposed to reserve the equivalent of an additional /16 block
for IXP management prefixes, separate from the peering LANs. It is proposed
that AfriNIC reserves a block of 2-byte ASNs for use in BGP route servers
at IXPs in the AfriNIC service region.

The number of ASNs to be reserved should be the larger of 114, or half of
the remaining 2-byte ASNs within AfriNIC's block at the date of
ratification of this policy.

AfriNIC will allocate these resources on a first come first served basis.

3.5 Evaluation criteria

This policy does not suggest new evaluation criteria for what determines a
valid IXP.

4.0 References

[1] AfriNIC Policy for End User Assignments - AFPUB-2006-GEN-001 Sections 5)
and 6)

Note: proposal also available at

rpd mailing list
rpd at

More information about the RPD mailing list