<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br>I do support the proposal<br> <br>
<br>
<em><font face="Comic Sans MS" color="#1f497d">Arbogast Fabian,</font></em><br>
<em><font face="Comic Sans MS" color="#1f497d">cell:+255-78-447-8387</font></em><br><br><br><div>> Date: Fri, 5 Jun 2015 17:15:24 +0300<br>> From: geier@geier.ne.tz<br>> To: rpd@afrinic.net; pdwg@afrinic.net<br>> CC: michuki.mwangi@gmail.com<br>> Subject: [rpd] AFPUB-2014-GEN-004<br>> <br>> Hello colleagues,<br>> <br>> We, the co-authors, hereby submit an update to AFPUB-2014-GEN-004<br>> incorporating the few editorial changes as agreed in the AfriNIC<br>> Public Policy Discussion and which were pre-condition to the consensus call.<br>> <br>> The test follows below.<br>> <br>> Regards,<br>> Nishal Goburdhan<br>> Michuki Mwangi<br>> Frank Habicht<br>> <br>> <br>> Details<br>> Ref. Name: AFPUB-2014-GEN-004-DRAFT-03<br>> Status: Last Call<br>> Date: 03 June 2015<br>> Author(s):<br>> Frank Habicht, Tanzania Internet Exchange, Michuki Mwangi, Internet<br>> Society/KIXP, Nishal Goburdhan, Packet Clearing House/JINX<br>> <br>> 1. Summary of the problem being addressed by this proposal<br>> <br>> AFRINIC has an existing policy to make IPv4 assignments to Critical<br>> Infrastructure, but not one to specifically reserve Internet Number<br>> Reources space for IXPs. As a result, it is anticipated that the<br>> exhaustion of these resources could make it difficult, if not impossible<br>> for IXPs to get sufficient resources to grow.<br>> <br>> 2. Summary of how this proposal addresses the problem<br>> <br>> This policy requests AFRINIC to reserve, and publish IPv4 resources, and<br>> ASNs for use by IXPs only.<br>> <br>> 3.0 Proposal<br>> <br>> 3.1 Introduction<br>> <br>> It is widely considered that Internet Exchange Points (IXPs) are one of<br>> the critical elements needed for Internet economies to develop. Africa<br>> is still in the process of developing these, and is, at the same time,<br>> faced with the imminent exhaustion of its IPv4 resources.<br>> <br>> Not having IPv4 addresses to grow, or start, new IXPs would create<br>> unnecessary and unneeded routing complexity for Internet connected<br>> networks, looking to peer at IXPs to further their network scope.<br>> <br>> AFRINIC already has an existing policy to make allocations to IXPs [1],<br>> but that policy does not specifically reserve IPV4 space to ensure that<br>> there will be such, for future IXPs to grow and develop. Additionally,<br>> this policy reserves a set of ASNs between 0 - 65535 for use by IXPs,<br>> for IXP BGP Route Servers.<br>> <br>> 3.2 Distinction between IXP peering and management networks<br>> <br>> We distinguish between two kinds of IP number resources needed and used<br>> at IXPs.<br>> <br>> An IXP peering LAN is the contiguous network address block that the IXP<br>> would use to assign unique IP addresses to each peering member, for each<br>> peering participant to exchange network traffic across the shared<br>> peering infrastructure. Best practice has the IXP peering LAN not being<br>> visible in a view of the global routing table, among other things to<br>> reduce the attack vectors for ISP border routers via the IXP.<br>> <br>> >From a network identification, monitoring and analysis perspective, it<br>> is thus desirable, that the "peering LAN" space be provided from a<br>> contiguous block. The IXP management LAN is the management network that<br>> the IXP uses to provision services at the IXP, like monitoring,<br>> statistics, mail, ticket systems, provisioning of transit to DNS Roots,<br>> etc. Management networks, are meant to be reachable globally, for<br>> instance to publish data and allow remote access for common good network<br>> infrastructure (such as root and TLD DNS servers) and research projects.<br>> <br>> 3.3 BGP Route Servers use<br>> <br>> Typically IXPs use BGP route servers to help manage peering sessions<br>> between different participants. The route servers implement IXP routing<br>> policy in the form of BGP communities, typically in the form of A:B,<br>> where A,B represent A=IXP BGP route server and B=participant ASN.<br>> <br>> Current BGP implementations utilise 6 bytes for the extended community<br>> attribute. Therefore, an IXP with a 4-byte ASN in use at its route<br>> server would not be able to successfully implement the A:B BGP community<br>> mapping, if an IXP participant has a 4-byte ASN. This situation is<br>> likely to be experienced by more IXPs, as additional 4-byte ASNs are<br>> allocated through the current AFRINIC process.<br>> <br>> If IXP route server communities include the IXP ASN and the peer's ASN<br>> (expected to be 4-byte), and a total of only 6 bytes are available, it<br>> follows that IXP route servers ASN could not be longer than occupying<br>> more than 2 bytes.<br>> <br>> 3.4 Proposal<br>> <br>> To ensure that there are sufficient resources for IXPs to develop, this<br>> policy proposes that AFRINIC reserve IPv4 addresses for IXP peering LANs<br>> out of an address block marked particularly, and exclusively, for IXP<br>> peering LAN use.<br>> <br>> Assignments for IXP peering LANs must be from one dedicated block,<br>> published as such by AFRINIC. The Peering LAN assignments for each IXP<br>> should ensure that the adjacent /24 IP block is reserved (based on the<br>> minimum end-user assignment policy size of /24) to support future growth<br>> of the IXP. This will enable an IXP to increase its peering LAN<br>> resources to /23 without having to renumber to a new contiguous IP block<br>> allocation.<br>> <br>> Assignments for IXP management addresses should NOT be provided from the<br>> same block as the IXP peering LANs.<br>> <br>> It is proposed that a /16 block be reserved for future requirements for<br>> IXP peering LANs in the AFRINIC service region, and that AFRINIC publish<br>> this block as such. In addition, the assignments for the IXP peering LAN<br>> should reserve the adjacent contiguous /24 IP block to the requesting<br>> IXP for future growth. These reservations shall be upheld until such a<br>> time that the available pool of the /16 can no longer allocate /23<br>> assignments. Thereafter, new requests may be assigned from the reserved<br>> space held for future IXP growth.<br>> <br>> It is further proposed to reserve the equivalent of an additional /16<br>> block for IXP management prefixes, separate from the peering LANs.<br>> <br>> It is proposed that AFRINIC reserves a block of ASNs between 0 - 65535<br>> for use in BGP route servers at IXPs in the AFRINIC service region. The<br>> number of ASNs to be reserved should be the larger of 114, or half of<br>> the remaining ASNs between 0 - 65535 within AFRINIC's block at the date<br>> of ratification of this policy. AFRINIC will allocate these resources<br>> on a first come first served basis.<br>> <br>> 3.5 Evaluation criteria<br>> <br>> This policy does not suggest new evaluation criteria for what determines<br>> a valid IXP.<br>> <br>> 4. Revision History<br>> <br>> 23 Oct 2014 AFPUB-2014-GEN-004-DRAFT-01 posted on rpd list.<br>> 05 Nov 2014 AFPUB-2014-GEN-004-DRAFT-02 posted on rpd list.<br>> <br>> References<br>> <br>> [1] AFRINIC Policy for End User Assignments - AFPUB-2006-GEN-001,<br>> http://afrinic.net/en/library/policies/127-afpub-2006-gen-001<br>> Sections 5) and 6)<br>> _______________________________________________<br>> rpd mailing list<br>> rpd@afrinic.net<br>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd<br></div> </div></body>
</html>