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