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

[rpd] proposed policy: reservation of resources for IXPs

Jackson Muthili jacksonmuthi at
Wed Oct 29 14:49:16 UTC 2014


On Wed, Oct 29, 2014 at 5:31 PM, McTim <dogwallah at> wrote:
> I support this proposal.
> --
> Cheers,
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> On Wed, Oct 29, 2014 at 9:01 AM, Frank Habicht <geier at> wrote:
>> 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
>> Author(s):
>> 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
>> Regards,
>> Frank
>> _______________________________________________
>> rpd mailing list
>> rpd at
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list