[rpd] proposed policy: reservation of resources for IXPs

[Walubengo J]

jst some questions for Mich & Co.

1) The policy presumes that IXP infrastructure in Africa is best on v4, hence and therefore lets reserve the v4 for this. But Is this true? What's wrong with IXP infrastructure on v6? And if there is nothing wrong, then do we really need this policy?
2) If we adopt this policy, are we implicitly encouraging v4 "comfort zone" in Africa when the rest of the world moves on and tackles any challenges v6 may provide in the context of IXP infrastructure?

just thinking loudly.

walu.
--------------------------------------------
On Wed, 10/29/14, Frank Habicht <geier at geier.ne.tz> wrote:

 Subject: [rpd] proposed policy: reservation of resources for IXPs
 To: "rpd" <rpd at afrinic.net>
 Cc: "Nishal Goburdhan" <nishal at ispa.org.za>
 Date: Wednesday, October 29, 2014, 5:01 PM
 
 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/1231-resource-reservation-for-internet-exchange-points
 
 
 Regards,
 Frank
 _______________________________________________
 rpd mailing list
 rpd at afrinic.net
 https://lists.afrinic.net/mailman/listinfo.cgi/rpd