Search RPD Archives
afabbie at hotmail.com
Sun Jun 7 17:57:13 UTC 2015
I do support the proposal
> Date: Fri, 5 Jun 2015 17:15:24 +0300
> From: geier at geier.ne.tz
> To: rpd at afrinic.net; pdwg at afrinic.net
> CC: michuki.mwangi at gmail.com
> Subject: [rpd] AFPUB-2014-GEN-004
> 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.
> Nishal Goburdhan
> Michuki Mwangi
> Frank Habicht
> Ref. Name: AFPUB-2014-GEN-004-DRAFT-03
> Status: Last Call
> Date: 03 June 2015
> 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 ,
> 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
> 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.
>  AFRINIC Policy for End User Assignments - AFPUB-2006-GEN-001,
> Sections 5) and 6)
> rpd mailing list
> rpd at afrinic.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPD