<p dir="ltr">Good work guys.... In full support.</p>
<p dir="ltr">Cheers</p>
<p dir="ltr">Noah</p>
<div class="gmail_quote">On 5 Jun 2015 17:23, "Frank Habicht" <<a href="mailto:geier@geier.ne.tz">geier@geier.ne.tz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<a href="http://afrinic.net/en/library/policies/127-afpub-2006-gen-001" target="_blank">http://afrinic.net/en/library/policies/127-afpub-2006-gen-001</a><br>
Sections 5) and 6)<br>
_______________________________________________<br>
rpd mailing list<br>
<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
</blockquote></div>