Search RPD Archives
[rpd] proposed policy: reservation of resources for IXPs
marty at akamai.com
Thu Oct 30 18:21:50 UTC 2014
/speaking with open-IX.org hat on
I'm neutral on the proposal, but David's suggestion re prefix adjacency is worth discussion.
> On Oct 30, 2014, at 14:02, David Huberman <David.Huberman at microsoft.com> wrote:
> In regard to the proposed policy, "Resource Reservation for Internet Exchange Points", I have two comments:
> 1) I support the policy as written.
> 2) I ask the community for input on a separate policy proposal I would like to make, which is related.
> One of the lessons we've learned over 20+ years of operating public IXes is that the worst thing that can happen to an IX is to grow so big that it outgrows its peering fabric /24. Renumbering a peering fabric is a nightmare scenario. It is preventable by having allocation policies which keep successful IXes in mind.
> I propose, therefore, text which directs AFRINIC staff to:
> - issue no less than a /24 to each IX peering fabric
> - either reserve the adjacent /24 so the /24 can grow to a /23 in the case where the IX is successful; or
> - issue the /24s sparsely (using the bisection method) to ensure the most number of /24s can grow into /23s over time.
> By carefully issuing /24s on /23 boundaries, it allows the (relatively few) IXes that will outgrow a /24 to easily move into a /23 with the same starting IP address, which makes it easy for the participants at the exchange.
> Would this proposal have support?
> Thanks and with regards,
> David R Huberman
> Microsoft Corporation
> Principal, Global IP Addressing
>> 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
>> 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 , 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
>> 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
>> 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
>> 3.5 Evaluation criteria
>> This policy does not suggest new evaluation criteria for what
>> determines a valid IXP.
>> 4.0 References
>>  AfriNIC Policy for End User Assignments -
>> Sections 5)
>> and 6)
>> Note: proposal also available at
>> rpd mailing list
>> rpd at afrinic.net
> rpd mailing list
> rpd at afrinic.net
> rpd mailing list
> rpd at afrinic.net
More information about the RPD