[rpd] AFPUB-2014-GEN-004

Fri Jun 5 14:15:24 UTC 2015

Hello colleagues,

We, the co-authors, hereby submit an update to AFPUB-2014-GEN-004
incorporating the few editorial changes as agreed in the AfriNIC
Public Policy Discussion and which were pre-condition to the consensus call.

The test follows below.

Regards,
Nishal Goburdhan
Michuki Mwangi
Frank Habicht

Details
Ref. Name: AFPUB-2014-GEN-004-DRAFT-03
Status: Last Call
Date: 03 June 2015
Author(s):
Frank Habicht, Tanzania Internet Exchange, Michuki Mwangi, Internet
Society/KIXP, Nishal Goburdhan, Packet Clearing House/JINX

1. Summary of the problem being addressed by this proposal

AFRINIC has an existing policy to make IPv4 assignments to Critical
Infrastructure, but not one to specifically reserve Internet Number
Reources space for IXPs. As a result, it is anticipated that the
exhaustion of these resources could make it difficult, if not impossible
for IXPs to get sufficient resources to grow.

2. Summary of how this proposal addresses the problem

This policy requests AFRINIC to reserve, and publish IPv4 resources, and
ASNs for use by IXPs only.

3.0 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 ASNs between 0 - 65535 for use by IXPs,
for IXP BGP Route Servers.

3.2 Distinction between IXP peering and management networks

We distinguish between two kinds of IP number 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. 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 occupying
more than 2 bytes.

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. The Peering LAN assignments for each IXP
should ensure that the adjacent /24 IP block is reserved (based on the
minimum end-user assignment policy size of /24) to support future growth
of the IXP. This will enable an IXP to increase its peering LAN
resources to /23 without having to renumber to a new contiguous IP block
allocation.

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. In addition, the assignments for the IXP peering LAN
should reserve the adjacent contiguous /24 IP block to the requesting
IXP for future growth. These reservations shall be upheld until such a
time that the available pool of the /16 can no longer allocate /23
assignments. Thereafter, new requests may be assigned from the reserved
space held for future IXP growth.

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 ASNs between 0 - 65535
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 ASNs between 0 - 65535 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. Revision History

23 Oct 2014            AFPUB-2014-GEN-004-DRAFT-01 posted on rpd list.
05 Nov 2014            AFPUB-2014-GEN-004-DRAFT-02 posted on rpd list.

References

[1] AFRINIC Policy for End User Assignments - AFPUB-2006-GEN-001,
http://afrinic.net/en/library/policies/127-afpub-2006-gen-001
Sections 5) and 6)