
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>Yes, the IXP community agrees that dual stacking is required;</div><div><br></div><div><a href="http://www.open-ix.org/standards/ixp-technical-requirements/">http://www.open-ix.org/standards/ixp-technical-requirements/</a></div><div><br></div><div><br></div><div>Best, </div><div><br></div><div>Marty<br><br><br></div><div><br>On Oct 30, 2014, at 14:45, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>It is very unusual to find myself on the opposite side of this question, Walu. As you know, I am a very strong proponent of IPv6 and will be very happy the day we start turning off IPv4 peering on the global internet.</span><br><span></span><br><span>However, I don’t think the policy makes any such assumption.</span><br><span></span><br><span>I think the policy assumes that IXP infrastructure must be dual-stacked and that in order to be dual-stacked, one needs IPv4 addresses.</span><br><span>There is no need to reserve IPv6 addresses because there is no shortage.</span><br><span></span><br><span>I do not believe that this policy encourages an IPv4 “comfort zone”. I believe it sets aside space so that infrastructure can be developed to support increased peering density on both protocols throughout the region.</span><br><span></span><br><span>Owen</span><br><span></span><br><blockquote type="cite"><span>On Oct 29, 2014, at 8:23 AM, Walubengo J <<a href="mailto:jwalu@yahoo.com">jwalu@yahoo.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>jst some questions for Mich & Co.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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?</span><br></blockquote><blockquote type="cite"><span>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?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>just thinking loudly.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>walu.</span><br></blockquote><blockquote type="cite"><span>--------------------------------------------</span><br></blockquote><blockquote type="cite"><span>On Wed, 10/29/14, Frank Habicht <<a href="mailto:geier@geier.ne.tz">geier@geier.ne.tz</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Subject: [rpd] proposed policy: reservation of resources for IXPs</span><br></blockquote><blockquote type="cite"><span>To: "rpd" <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>></span><br></blockquote><blockquote type="cite"><span>Cc: "Nishal Goburdhan" <<a href="mailto:nishal@ispa.org.za">nishal@ispa.org.za</a>></span><br></blockquote><blockquote type="cite"><span>Date: Wednesday, October 29, 2014, 5:01 PM</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hello all,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>please find this proposed policy, which we (3 co-authors)</span><br></blockquote><blockquote type="cite"><span>have submitted to</span><br></blockquote><blockquote type="cite"><span>the pdpwg last week:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Resource Reservation for Internet Exchange Points</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Author(s):</span><br></blockquote><blockquote type="cite"><span>a) Frank Habicht, Tanzania Internet Exchange</span><br></blockquote><blockquote type="cite"><span>b) Michuki Mwangi, Internet Society/KIXP</span><br></blockquote><blockquote type="cite"><span>c) Nishal Goburdhan, Packet Clearing House/JINX</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>1) Summary of the Problem being addressed by this proposal</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This policy reserves IPv4 and 2-byte ASNs resources for</span><br></blockquote><blockquote type="cite"><span>public Internet</span><br></blockquote><blockquote type="cite"><span>Exchange Points (IXPs) in the African region, ensuring that</span><br></blockquote><blockquote type="cite"><span>there would be</span><br></blockquote><blockquote type="cite"><span>discrete IPv4 resources to allow the establishment and</span><br></blockquote><blockquote type="cite"><span>growth of future IXPs.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>2) Summary of How this Proposal Addresses the Problem</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This policy requests AfriNIC to reserve, and publish IPv4</span><br></blockquote><blockquote type="cite"><span>resources, and</span><br></blockquote><blockquote type="cite"><span>2-byte ASNs for use by IXPs only.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>3) Proposal</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>3.1 Introduction</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It is widely considered that Internet Exchange Points (IXPs)</span><br></blockquote><blockquote type="cite"><span>are one of the</span><br></blockquote><blockquote type="cite"><span>critical elements needed for Internet economies to develop.</span><br></blockquote><blockquote type="cite"><span>Africa is still</span><br></blockquote><blockquote type="cite"><span>in the process of developing these, and is, at the same</span><br></blockquote><blockquote type="cite"><span>time, faced with</span><br></blockquote><blockquote type="cite"><span>the imminent exhaustion of its IPv4 resources. Not having</span><br></blockquote><blockquote type="cite"><span>IPv4 addresses to</span><br></blockquote><blockquote type="cite"><span>grow, or start new, IXPs would create unnecessary and</span><br></blockquote><blockquote type="cite"><span>unneeded routing</span><br></blockquote><blockquote type="cite"><span>complexity for Internet connected networks, looking to peer</span><br></blockquote><blockquote type="cite"><span>at IXPs to</span><br></blockquote><blockquote type="cite"><span>further their network scope. AfriNIC already has an existing</span><br></blockquote><blockquote type="cite"><span>policy to make</span><br></blockquote><blockquote type="cite"><span>allocations to IXPs [1], but that policy does not</span><br></blockquote><blockquote type="cite"><span>specifically reserve IPV4</span><br></blockquote><blockquote type="cite"><span>space to ensure that there will be such, for future IXPs to</span><br></blockquote><blockquote type="cite"><span>grow and</span><br></blockquote><blockquote type="cite"><span>develop. Additionally, this policy reserves a set of 2-byte</span><br></blockquote><blockquote type="cite"><span>ASNs for use by</span><br></blockquote><blockquote type="cite"><span>IXPs for use at IXP BGP Route Servers.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>3.2 Distinction between IXP peering and management networks</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>We distinguish between two kinds of IP address resources</span><br></blockquote><blockquote type="cite"><span>needed and used at</span><br></blockquote><blockquote type="cite"><span>IXPs. An IXP peering LAN is the contiguous network address</span><br></blockquote><blockquote type="cite"><span>block that the</span><br></blockquote><blockquote type="cite"><span>IXP would use to assign unique IP addresses to each peering</span><br></blockquote><blockquote type="cite"><span>member, for</span><br></blockquote><blockquote type="cite"><span>each peering participant to exchange network traffic across</span><br></blockquote><blockquote type="cite"><span>the shared</span><br></blockquote><blockquote type="cite"><span>peering infrastructure. Best practice has the IXP peering</span><br></blockquote><blockquote type="cite"><span>LAN *not* being</span><br></blockquote><blockquote type="cite"><span>visible in a view of the global routing table, among other</span><br></blockquote><blockquote type="cite"><span>things to reduce</span><br></blockquote><blockquote type="cite"><span>the attack vectors for ISP border routers via the IXP.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>From a network identification, monitoring and analysis</span><br></blockquote></blockquote><blockquote type="cite"><span>perspective, it is</span><br></blockquote><blockquote type="cite"><span>thus desirable, that the "peering LAN" space be provided</span><br></blockquote><blockquote type="cite"><span>from a contiguous</span><br></blockquote><blockquote type="cite"><span>block. The IXP management LAN is the management network that</span><br></blockquote><blockquote type="cite"><span>the IXP uses</span><br></blockquote><blockquote type="cite"><span>to provision services at the IXP, like monitoring,</span><br></blockquote><blockquote type="cite"><span>statistics, mail, ticket</span><br></blockquote><blockquote type="cite"><span>systems, provisioning of transit to DNS Roots, etc.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Management networks, are meant to be reachable globally, for</span><br></blockquote><blockquote type="cite"><span>instance to</span><br></blockquote><blockquote type="cite"><span>publish data and allow remote access for common good network</span><br></blockquote><blockquote type="cite"><span>infrastructure</span><br></blockquote><blockquote type="cite"><span>(such as root and TLD DNS servers) and research projects.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>3.3 BGP Route Servers use</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Typically IXPs use BGP route servers to help manage peering</span><br></blockquote><blockquote type="cite"><span>sessions</span><br></blockquote><blockquote type="cite"><span>between different participants. The route servers implement</span><br></blockquote><blockquote type="cite"><span>IXP routing</span><br></blockquote><blockquote type="cite"><span>policy in the form of BGP communities, typically in the form</span><br></blockquote><blockquote type="cite"><span>of A:B, where</span><br></blockquote><blockquote type="cite"><span>A,B represent A=IXP BGP route server and B=participant ASN.</span><br></blockquote><blockquote type="cite"><span>Current BGP</span><br></blockquote><blockquote type="cite"><span>implementations utilise 6 bytes for the extended community</span><br></blockquote><blockquote type="cite"><span>attribute</span><br></blockquote><blockquote type="cite"><span>[RFC5668]. Therefore, an IXP with a 4-byte ASN in use at its</span><br></blockquote><blockquote type="cite"><span>route server</span><br></blockquote><blockquote type="cite"><span>would not be able to successfully implement the A:B BGP</span><br></blockquote><blockquote type="cite"><span>community mapping,</span><br></blockquote><blockquote type="cite"><span>if an IXP participant has a 4-byte ASN. This situation is</span><br></blockquote><blockquote type="cite"><span>likely to be</span><br></blockquote><blockquote type="cite"><span>experienced by more IXPs, as additional 4-byte ASNs are</span><br></blockquote><blockquote type="cite"><span>allocated through</span><br></blockquote><blockquote type="cite"><span>the current AfriNIC process.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If, IXP route server communities include the IXP ASN and the</span><br></blockquote><blockquote type="cite"><span>peer's ASN</span><br></blockquote><blockquote type="cite"><span>(expected to be 4-byte), and a total of only 6 bytes are</span><br></blockquote><blockquote type="cite"><span>available, it</span><br></blockquote><blockquote type="cite"><span>follows that IXP route servers ASN could not be longer than</span><br></blockquote><blockquote type="cite"><span>a 2-byte ASN.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>3.4 Proposal</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>To ensure that there are sufficient resources for IXPs to</span><br></blockquote><blockquote type="cite"><span>develop, this</span><br></blockquote><blockquote type="cite"><span>policy proposes that AfriNIC reserve IPv4 addresses for IXP</span><br></blockquote><blockquote type="cite"><span>peering LANs</span><br></blockquote><blockquote type="cite"><span>out of an address block marked particularly, and</span><br></blockquote><blockquote type="cite"><span>exclusively, for IXP</span><br></blockquote><blockquote type="cite"><span>peering LAN use. Assignments for IXP peering LANs must be</span><br></blockquote><blockquote type="cite"><span>from one</span><br></blockquote><blockquote type="cite"><span>dedicated block, published as such by AfriNIC. Assignments</span><br></blockquote><blockquote type="cite"><span>for IXP</span><br></blockquote><blockquote type="cite"><span>management addresses should NOT be provided from the same</span><br></blockquote><blockquote type="cite"><span>block as the IXP</span><br></blockquote><blockquote type="cite"><span>peering LANs.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It is proposed that a /16 block be reserved for future</span><br></blockquote><blockquote type="cite"><span>requirements for IXP</span><br></blockquote><blockquote type="cite"><span>peering LANs in the AfriNIC service region, and that AfriNIC</span><br></blockquote><blockquote type="cite"><span>publish this</span><br></blockquote><blockquote type="cite"><span>block as such.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It is further proposed to reserve the equivalent of an</span><br></blockquote><blockquote type="cite"><span>additional /16 block</span><br></blockquote><blockquote type="cite"><span>for IXP management prefixes, separate from the peering LANs.</span><br></blockquote><blockquote type="cite"><span>It is proposed</span><br></blockquote><blockquote type="cite"><span>that AfriNIC reserves a block of 2-byte ASNs for use in BGP</span><br></blockquote><blockquote type="cite"><span>route servers</span><br></blockquote><blockquote type="cite"><span>at IXPs in the AfriNIC service region.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The number of ASNs to be reserved should be the larger of</span><br></blockquote><blockquote type="cite"><span>114, or half of</span><br></blockquote><blockquote type="cite"><span>the remaining 2-byte ASNs within AfriNIC's block at the date</span><br></blockquote><blockquote type="cite"><span>of</span><br></blockquote><blockquote type="cite"><span>ratification of this policy.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>AfriNIC will allocate these resources on a first come first</span><br></blockquote><blockquote type="cite"><span>served basis.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>3.5 Evaluation criteria</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This policy does not suggest new evaluation criteria for</span><br></blockquote><blockquote type="cite"><span>what determines a</span><br></blockquote><blockquote type="cite"><span>valid IXP.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>4.0 References</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>[1] AfriNIC Policy for End User Assignments -</span><br></blockquote><blockquote type="cite"><span>AFPUB-2006-GEN-001</span><br></blockquote><blockquote type="cite"><span><a href="http://afrinic.net/en/library/policies/127-afpub-2006-gen-001">http://afrinic.net/en/library/policies/127-afpub-2006-gen-001</a></span><br></blockquote><blockquote type="cite"><span>Sections 5)</span><br></blockquote><blockquote type="cite"><span>and 6)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Note: proposal also available at</span><br></blockquote><blockquote type="cite"><span><a href="http://www.afrinic.net/en/community/policy-development/policy-proposals/1231-resource-reservation-for-internet-exchange-points">http://www.afrinic.net/en/community/policy-development/policy-proposals/1231-resource-reservation-for-internet-exchange-points</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Regards,</span><br></blockquote><blockquote type="cite"><span>Frank</span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>rpd mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>rpd mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a></span><br></blockquote><span></span><br><span>_______________________________________________</span><br><span>rpd mailing list</span><br><span><a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a></span><br><span><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a></span><br></div></blockquote></body></html>