[rpd] proposed policy: reservation of resources for IXPs

Wed Oct 29 17:26:03 UTC 2014

Support.

Mark.

On Wednesday, October 29, 2014 04:01:37 PM Frank Habicht 
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-ge
> n-001 Sections 5) and 6)
> 
> 
> 
> 
> Note: proposal also available at
> http://www.afrinic.net/en/community/policy-development/po
> licy-proposals/1231-resource-reservation-for-internet-exc
> hange-points
> 
> 
> Regards,
> Frank
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141029/4f87184f/attachment.sig>