[rpd] proposed policy: reservation of resources for IXPs

Wed Oct 29 16:22:52 UTC 2014

Hi Walu,

On 10/29/2014 6:23 PM, Walubengo J wrote:
> 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?

This policy does not presume that IXP infrastructure in Africa is best on
v4. It actually implies that IXPs are key infrastructure that need to
support the transition towards IPv6. Therefore they need to be dual-stacked.

Based on that point, think of those countries in Africa that have
ISPs/Operators, etc but do not have an IXP. This map provides information
about the countries without an IXP.
 https://www.google.com/maps/ms?msid=203451807916585765419.0004d984b1be3af823a35&msa=0&ll=-1.406109,22.675781&spn=94.302473,132.539063

The consideration being sought is; those countries currently without an IXP
are likely to establish an IXP based on the ongoing efforts in the region
to assist in setting up IXPs. It is worth noting that most of these
countries without an IXP have ISPs/operators on IPv4. Therefore when the
country is ready to establish an IXP, it is important to ensure that it can
support legacy networks on IPv4 and IPv6.

We want us to be prepared for new IXPs to be established even after IPv4
resources at AfriNIC run out.

> 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?

On the contrary. The adoption of this policy ensures that the objective of
keeping local traffic within the region is supported by providing future
IXPs with the resourced needed to interconnect both IPv4 and IPv6 networks
using best practices. As the map shows, we will need to have more IXPs in
Africa, and as IPv4 will stay with us for some more time, these new IXPs
need to have IPv4 addresses for participants.

Regards,
Frank ( & Michuki & Nishal )

PS: sorry for non-ascii, URI would wrap without :-(

> 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
>  