[rpd] proposed policy: reservation of resources for IXPs

[Badru Ntege]

I support this proposal






On 10/29/14, 5:01 PM, "Frank Habicht" <geier at geier.ne.tz> 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
>http://afrinic.net/en/library/policies/127-afpub-2006-gen-001 Sections 5)
>and 6)
>
>
>
>
>Note: proposal also available at
>http://www.afrinic.net/en/community/policy-development/policy-proposals/12
>31-resource-reservation-for-internet-exchange-points
>
>
>Regards,
>Frank
>_______________________________________________
>rpd mailing list
>rpd at afrinic.net
>https://lists.afrinic.net/mailman/listinfo.cgi/rpd