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

[rpd] proposed policy: reservation of resources for IXPs

Badru Ntege badru.ntege at
Wed Oct 29 14:56:03 UTC 2014

I support this proposal

On 10/29/14, 5:01 PM, "Frank Habicht" <geier at> wrote:

>Hello all,
>please find this proposed policy, which we (3 co-authors) have submitted
>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
>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
>critical elements needed for Internet economies to develop. Africa is
>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
>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
>allocations to IXPs [1], but that policy does not specifically reserve
>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
>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
>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
>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,
>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
>(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
>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
>for IXP management prefixes, separate from the peering LANs. It is
>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