From ernest at afrinic.net Thu Feb 9 11:34:47 2006 From: ernest at afrinic.net (Ernest, B.M (AfriNIC - ZA)) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies Message-ID: <43EB0CB7.9080803@afrinic.net> Dear Colleagues, During the 3rd AfriNIC Public Policy Meeting in Cairo held from 12th to 13th December 2005, the community consented and voted to forward the following policy proposals to the AfriNIC Board of Directors for approval: o Policy for PI/Direct Assignments to End-User Organisations http://www.afrinic.net/docs/policies/afpol-v4eu200504.htm o Temporary Address Assignments / Assignments for Critical network/internet infrastructure http://www.afrinic.net/docs/policies/afpol-tmpal200504.htm o Change to criteria for ASN assignments http://www.afrinic.net/docs/policies/drafts/afpol-chgasn200508.htm o IPv6 IANA to RIR allocations http://www.afrinic.net/docs/policies/drafts/afpol-glbipv6200508.htm This is a last call for comments from the entire community on these proposals. After 15 days, the proposed policies above will be forwarded to the AfriNIC Board for review. All your comments should be sent to policy-wg@afrinic.net This last call will expire 15 days from today. A summary of the face-to-face discussions for each of the above proposals during the AfriNIC-3 meeting is below: o Temporary Address Assignments / Assignments for Critical network/internet infrastructure http://www.afrinic.net/docs/policies/afpol-tmpal200504.htm - Concerns about 3.2 (Commercial Use Prohibited) : This would be difficult to justify by AfriNIC and may involve some legal issues. Suggestion was to delete the whole of 3.2 from the document. - Questions as to why a temporary assignment cannot be obtained from the upstream ISP? Answer was that some ISPs will argue not to have enough IPs to assign, and that its good practice for all temporary assignments to come from an RIR block reserved for this purpose. Other answers were that various upstreams reserve their prefixes for different products/services, and may not have a prefix ready for temporary use. It was agreed that policy be passed only if AfriNIC can reserve a large block for this purpose. - Temporary assignments are vulnerable to hi-jacking, especially when some one 'keeps an eye' on the temporary assignment and knows its not in use anymore, they will start using these IPs. Other comments: whole prefix would be listed as bogus, hence the need for the RIR to allot another prefix for temporary assignments. ** Concensus was realized (pending suggested edits) o Policy for PI/Direct Assignments to End-User Organisations http://www.afrinic.net/docs/policies/afpol-v4eu200504.htm - the minimum /24 assignments may have an impact on the global routing table. other comments; the routing table is already so saturated that such small assignmenst wouldnt have such a noticeable effect. - APNIC also stated that the minimum is /24 in their region. - Some people suggested a similar proposal for IPv6. - replace 5.0, ICANN-sanctioned root, gTLD, and ccTLD .. with specifics. TLDs were not deemed critical infrastructure by some, and only IXPs and root servers were proposed. ** Policy realized concensus. o Change to criteria for ASN assignments http://www.afrinic.net/docs/policies/drafts/afpol-chgasn200508.htm ** No discussion, policy realized concensus. o IPv6 IANA to RIR allocations http://www.afrinic.net/docs/policies/drafts/afpol-glbipv6200508.htm ** No discussion, policy realized concensus. Please send all your comments to policy-wg@afrinic.net within 15 days from the date of this last call. Kind regards, Ernest AfriNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : https://lists.afrinic.net/pipermail/policy-wg/attachments/20060209/197087c0/smime.bin From apb at cequrux.com Sat Feb 11 12:22:48 2006 From: apb at cequrux.com (Alan Barrett) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies In-Reply-To: <43EB0CB7.9080803@afrinic.net> References: <43EB0CB7.9080803@afrinic.net> Message-ID: <20060211102248.GN495@apb-laptoy.apb.alt.za> On Thu, 09 Feb 2006, Ernest, B.M (AfriNIC - ZA) wrote: > During the 3rd AfriNIC Public Policy Meeting in Cairo held from 12th > to 13th December 2005, the community consented and voted to forward > the following policy proposals to the AfriNIC Board of Directors for > approval: Actually, there was no vote, but there did appear to be consensus. --apb (Alan Barrett) From alan at futureperfect.co.za Mon Feb 13 08:21:03 2006 From: alan at futureperfect.co.za (Alan Levin) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies In-Reply-To: <20060211102248.GN495@apb-laptoy.apb.alt.za> References: <43EB0CB7.9080803@afrinic.net> <20060211102248.GN495@apb-laptoy.apb.alt.za> Message-ID: <376FCE7F-3C98-4FC0-BAD7-39D0FEB20962@futureperfect.co.za> On 11 Feb 2006, at 12:22 PM, Alan Barrett wrote: > On Thu, 09 Feb 2006, Ernest, B.M (AfriNIC - ZA) wrote: >> During the 3rd AfriNIC Public Policy Meeting in Cairo held from 12th >> to 13th December 2005, the community consented and voted to forward >> the following policy proposals to the AfriNIC Board of Directors for >> approval: > > Actually, there was no vote, but there did appear to be consensus. I think that there was a vote (before the discussions although I may be wrong), the problem was that there were only two voting members present. aL --------------------------------------------- Alan Levin Tel: +27 21 409-7997 From adiel at afrinic.net Mon Feb 13 09:07:04 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies Message-ID: <7.0.1.0.2.20060213110657.0ab660f0@afrinic.net> >On 11 Feb 2006, at 12:22 PM, Alan Barrett wrote: >>On Thu, 09 Feb 2006, Ernest, B.M (AfriNIC - ZA) wrote: >>>During the 3rd AfriNIC Public Policy Meeting in Cairo held from 12th >>>to 13th December 2005, the community consented and voted to forward >>>the following policy proposals to the AfriNIC Board of Directors for >>>approval: >> >>Actually, there was no vote, but there did appear to be consensus. > >I think that there was a vote (before the discussions although I may >be wrong), the problem was that there were only two voting members >present. No, there was no vote, and more importantly, policies are not a voting matter (ref to our policy development process). Policies are adopted based on consensus. I remember that in Cairo the principle has been clarified by the policy-wg members leading the discussions. See: http://www.afrinic.net/pdp.htm Rgrds. - a. >aL > > > > > >--------------------------------------------- >Alan Levin >Tel: +27 21 409-7997 > >_______________________________________________ >policy-wg mailing list >policy-wg@afrinic.net >http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg Adiel A. Akplogan CEO, AfriNIC www.afrinic.net From ernest at afrinic.net Tue Mar 7 12:58:11 2006 From: ernest at afrinic.net (Ernest, B.M (AfriNIC - ZA)) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies Message-ID: <440D6743.6040709@afrinic.net> Dear Colleagues, The last call for comments on the following policy proposals expired on 25/02/2005 at 1200H SAST: o Policy for PI/Direct Assignments to End-User Organisations http://www.afrinic.net/docs/policies/afpol-v4eu200504.htm o Temporary Address Assignments / Assignments for Critical network/internet infrastructure http://www.afrinic.net/docs/policies/afpol-tmpal200504.htm o Change to criteria for ASN assignments http://www.afrinic.net/docs/policies/drafts/afpol-chgasn200508.htm o IPv6 IANA to RIR allocations http://www.afrinic.net/docs/policies/drafts/afpol-glbipv6200508.htm The policy-working group will now forward the proposals to the AfriNIC Board of Directors for approval. Regards Ernest AfriNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : https://lists.afrinic.net/pipermail/policy-wg/attachments/20060307/5eb1bba9/smime.bin From sultane at yahoo.com Tue Mar 7 17:20:49 2006 From: sultane at yahoo.com (ari) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies In-Reply-To: <440D6743.6040709@afrinic.net> Message-ID: <20060307152049.1831.qmail@web52701.mail.yahoo.com> Ernest, Adiel, Hope all is well there; can you post these to the AISI lists or is it not ok to do it ? your call ... just a sign of Openness :-)) ar ----- Original Message ---- From: "Ernest, B.M (AfriNIC - ZA)" To: policy-wg@afrinic.net Sent: Tuesday, March 7, 2006 11:58:11 AM Subject: [policy-wg] Last call for comments on proposed policies Dear Colleagues, The last call for comments on the following policy proposals expired on 25/02/2005 at 1200H SAST: o Policy for PI/Direct Assignments to End-User Organisations http://www.afrinic.net/docs/policies/afpol-v4eu200504.htm o Temporary Address Assignments / Assignments for Critical network/internet infrastructure http://www.afrinic.net/docs/policies/afpol-tmpal200504.htm o Change to criteria for ASN assignments http://www.afrinic.net/docs/policies/drafts/afpol-chgasn200508.htm o IPv6 IANA to RIR allocations http://www.afrinic.net/docs/policies/drafts/afpol-glbipv6200508.htm The policy-working group will now forward the proposals to the AfriNIC Board of Directors for approval. Regards Ernest AfriNIC _______________________________________________ policy-wg mailing list policy-wg@afrinic.net http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.afrinic.net/pipermail/policy-wg/attachments/20060307/56eabb9f/attachment.htm From adiel at afrinic.net Wed Mar 8 10:46:07 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Last call for comments on proposed policies In-Reply-To: <20060307152049.1831.qmail@web52701.mail.yahoo.com> References: <440D6743.6040709@afrinic.net> <20060307152049.1831.qmail@web52701.mail.yahoo.com> Message-ID: <7.0.1.0.2.20060308124006.04eb5bd8@afrinic.net> Hello Rachel, of course you can forward the message to the AISI mailing list, If you think it is for interest. But then you must encourage those interested to subscribe to plicy-wg@afrinic.net, because debates on policy must happen only here, so everybody can follow and we can be able to properly summarize at the end. Regards. -- Adiel A. Akplogan CEO, AfriNIC www.afrinic.net ================ See you at AfriNIC-4 and AfNOG'07 Meeting Nairobi, Kenya 13-18 May 2006 www.afrinic.net/meeting/afrinic-4 >Ernest, Adiel, > >Hope all is well there; can you post these to the AISI lists or is >it not ok to do it ? your call ... just a sign of Openness :-)) >ar > >----- Original Message ---- >From: "Ernest, B.M (AfriNIC - ZA)" >To: policy-wg@afrinic.net >Sent: Tuesday, March 7, 2006 11:58:11 AM >Subject: [policy-wg] Last call for comments on proposed policies > >Dear Colleagues, > >The last call for comments on the following policy proposals >expired on 25/02/2005 at 1200H SAST: > >o Policy for PI/Direct Assignments to End-User Organisations > >http://www.afrinic.net/docs/policies/afpol-v4eu200504.htm > >o Temporary Address Assignments / Assignments for Critical > network/internet infrastructure > >http://www.afrinic.net/docs/policies/afpol-tmpal200504.htm > >o Change to criteria for ASN assignments > >http://www.afrinic.net/docs/policies/drafts/afpol-chgasn200508.htm > >o IPv6 IANA to RIR allocations >http://www.afrinic.net/docs/policies/drafts/afpol-glbipv6200508.htm > >The policy-working group will now forward the proposals to the AfriNIC >Board of Directors for approval. > >Regards > >Ernest >AfriNIC >_______________________________________________ >policy-wg mailing list >policy-wg@afrinic.net >http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >_______________________________________________ >policy-wg mailing list >policy-wg@afrinic.net >http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg From rtankeu at yahoo.fr Thu Mar 23 17:09:39 2006 From: rtankeu at yahoo.fr (Robertine TANKEU) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] WDR Correspondent for Africa In-Reply-To: <6.2.0.14.2.20051209155054.02b9d788@localhost> Message-ID: <20060323150939.34365.qmail@web25814.mail.ukl.yahoo.com> Hi everyone, This is to inform you that, I am the new WDR correspondent for Africa. The WDR ( World Dialogue on Regulation) on Network Economies is concerned with regulation and governance for network economies. Its mission is to facilitate an international dialogue that generates and disseminates new knowledge on frontier issues in regulation and governance to support the development of network economies. The dialogue theme for this research phase is: diversifying participation in network development. The research themes are: disasters, indicators, infopractices, new models and pro poor. As you can imagine, it?s quite a bit of work; so I will appreciate if you can collaborate with me by providing me with some sources of information on what is doing in the region in terms of researches, workshops related to WDR themes. I invite you to visit our website at: www. regulateonline.org Many regards Robertine Tankeu WDR correspondent for Africa Cameroon Tel: 237 789 21 13 ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international. T?l?chargez sur http://fr.messenger.yahoo.com From jordi.palet at consulintel.es Fri Apr 14 14:22:40 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Re: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: Message-ID: Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6@lists.apnic.net So, if you aren't subscribed in the global-v6@lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ > Responder a: > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops@ops.ietf.org" , "ppml@arin.net" > , "shim6@psg.com" > Conversaci?n: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong >> Responder a: >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: , "v6ops@ops.ietf.org" >> , >> "ppml@arin.net" , "shim6@psg.com" >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri Apr 14 14:08:05 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Re: [ppml] PI addressing in IPv6 advances in ARIN In-Reply-To: Message-ID: Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6@lists.apnic.net So, if you aren't subscribed in the global-v6@lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ > Responder a: > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops@ops.ietf.org" , "ppml@arin.net" > , "shim6@psg.com" > Conversaci?n: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong >> Responder a: >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: , "v6ops@ops.ietf.org" >> , >> "ppml@arin.net" , "shim6@psg.com" >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri Apr 14 17:01:03 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Global IPv6 PI policy proposal Message-ID: Please, use global-v6@lists.apnic.net for inputs to this draft policy proposal, in order to avoid threads being split across multiple mail exploders in different regions. 1. Number: (The RIPE NCC will assign this) 2. Policy Proposal Name: Provider-Independent (PI) IPv6 Assignments for End-User-Organizations Note: We can use ?Portable IPv6 Assignments for End-User-Organizations? if that helps some folks to buy-in the proposal. 3. Author: a. name: Jordi Palet Martinez b. e-mail: jordi.palet@consulintel.es c. organisation: Consulintel 4. Proposal Version: 1.1 5. Submission Date: 17/4/2006 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: a. new, modify, or delete. NEW 8. Policy term: a. temporary, permanent, or renewable. TEMPORARY 9. Summary of proposal: This policy is intended to provide a solution for organizations that have a need for provider independent assignments in IPv6. Typically those organizations will require the provider independent assignment in order to be able to become multihomed in a similar fashion as today is done for IPv4, but other reasons are also foreseen. For example some organizations aren?t multihomed, but still require being globally routable with stable addressing (avoiding renumbering if they change the upstream provider) and in those cases (reasons behind may be administrative, policy, security, etc.) it seems that no other solution than provider independence is feasible, at least by now. Considering the foreseen consequences in the medium/long-term of this policy in the routing tables, this policy proposes an expiry date of 3 years once a technically correct alternative valid and deployable solution becomes accepted by the community. After that sunset period, the assignments done for multihoming purposes should be reclaimed and this policy should be modified to still allow assignments that could be required for purposes different than multhoming. At the sunset, the organizations that want to avoid renumbering and qualify to become an LIR, will be able to opt for that solution and they will get allocated the same prefix. 10. Policy text: a. Current (if modify): b. New: Provider-Independent IPv6 assignment to End-User-Organizations Qualification for an IPv6 Provider-Independent assignment: To qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy. This is valid regardless of actually having being assigned or allocated such an IPv4 block. Provider-Independent IPv6 assignment size to End-User-Organizations: The minimum size of the assignment is /32. However a larger assignment can be provided if duly documented and justified. Subsequent assignment size to End-User-Organizations: Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified. Assignment super-block: Those assignments shall be allocated from a separate super-block to allow for LIRs to filter them if required. Expiry for those assignments: In the case of assignments done under this proposal in order to address the multihoming issue, they will need to return the block in a maximum period of 3 years after a technically correct alternative valid and deployable solution becomes accepted by the community. Alternatively, to avoid renumbering, some of the organizations affected by this, could become an LIR, if they qualify for it. 11. Rationale: a. Arguments supporting the proposal In IPv4 there are organizations that qualify for an allocation for being PI, or could opt to be an LIR, either because they need to be multihomed or have other administrative or technical reasons to require a portable addressing block. This is not the case today for IPv6 and it is perceived as a clear barrier for deployment of IPv6 in some organizations, and is being addressed by this proposal by means of providing a direct assignment from RIPE NCC. These organizations are not allowed to make further assignments to other external organizations, but instead only to assign subnets internally within their own facilities. Assigning /32 will make those blocks to behave as other regular LIR-allocated ones and follow the generally accepted routing filtering practices, but at the same time being identifiable belonging to a special super-block. Also, it allows becoming an LIR, if that?s the case, without requiring a renumbering. By setting up this policy, we avoid creating an unfairness situation among different regions and allow any organization that requires PI to access to it. All the organizations that opt for this PI, will be in the same fair situation once the technical solution is agreed and will have to either move to the new solution or become an LIR if they qualify. Newcomers will be in the same situation. Organizations that don?t opt to PI with this policy is because they don?t need it, so they aren?t put in an unfair situation. Those that don?t believe in possible alternative solutions and agree in going for a permanent PI policy instead, don?t have valid reasons to oppose to this proposal, as the sunset will only enter into effect once that solution is agreed, so this proposal is not against their view. Some organizations my qualify to become an LIR now and avoid using this temporary assignment, but if their only reason to become an LIR is to get the PI block, then it seems better, looking in the long-term routing table size conservation, to go for this choice, which is more fair for the overall community. The ?temporarily? of this assignment must be understood as a long-term one, as we may expect those alternative solutions to be available possible in 3-4 years, which means that with the ?transition? period of 3 years, asking for a change in 6-7 years must not be considered as a pain. b. Arguments opposing the proposal The possible effect of this proposal is the grow of the routing tables to figures which, together with the existing (and forecasted) IPv4 routing entries, could create an important trouble to operators before vendors provide products with implement technical solutions, or even if those technical solutions exists, have an important impact in the cost or/and depreciation period for the infrastructure investments. This is the reason why the proposal provides already a fix sunset, but relative to the date where an alternative and technically correct solution is available and accepted as deployable by the community. Regarding the size of the assignment (/32), being a temporal one, should not be considered as a space waste, and instead be seen as an advantage in the sense of not requiring new special filters. Acknowledgments: I will like to acknowledge the inputs received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From adiel at afrinic.net Sat May 13 20:37:14 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Re: Upcoming Cybercrime Capacity Building and Legislative Drafting Conference in Botswana - Sponsored by the U.S. Department of Justice for African Countries In-Reply-To: <601223F486171E40AC1FC82A9C0770610ECD47@CRM-EXC002.crm.doj. gov> References: <601223F486171E40AC1FC82A9C0770610ECD47@CRM-EXC002.crm.doj.gov> Message-ID: <7.0.1.0.2.20060513223442.04fd4128@afrinic.net> Dear Joel, Thanks you for the invitation, we will make sure to have somebody there to represent AfriNIC. Regards. - a. >Dear AfriNIC: > >My name is Joel Schwarz and I am an attorney >with the U.S. Department of Justice's Computer >Crime and Intellectual Property Section. > > > >I am currently in the planning stages of >organizing a workshop on cybercrime legislative >drafting and capacity building for the >Sub-Saharan African region. As I'm sure you >would agree, as African countries look to >E-Commerce as a way to develop their economies >it is important that the legal infrastructure >that allows for investigation and prosecution of >offenses related to the use of that technology >be concurrently developed. Moreover, while >technology has provided new and exciting >benefits to Africa, such as distance learning >for remote and distributed populations, and >wireless and satellite communications in regions >that lack investment in physical infrastructure, >there is the danger that this technology could >be misused by criminals as a staging ground for >attacks, or as a cybercrime haven. Similarly, >as technology continues to integrate itself into >our daily lives we are finding that electronic >evidence and investigative techniques are also >becoming more important in investigating, >solving and prosecuting physical-world crimes, >such as terrorism or kidnapping (which is now >being facilitated through E?mailed ransom notes). > > > >As such, our goals for the workshop are: 1) to >provide technical support to participants to >assist them in drafting adequate domestic cyber >crime legislation; and 2) to increase the >investigative capacity of the law enforcement >community in Africa in regard to cyber crime matters. > > > >Currently, our plan is to hold 2 back to back >workshops - June 12 - 16th and June 19 - 23rd - >at the ILEA Botswana facility in Gaborone, the >first workshop being in English only, and the >second in English with simultaneous French >translation. At present we are expecting 2 to 3 >delegates from each participating ILEA country >(participating member countries of ILEA are: >Botswana, Ethiopia, Kenya, Lesotho, Malawi, >Mauritius, Namibia, Nigeria, Seychelles, South >Africa, Swaziland, Tanzania, Uganda, Zambia, >Cameroon, Comoros, Congo, Djibouti, DRC, Gabon and Madagascar). > > > >In terms of the backgrounds of potential >workshop candidates, we are primarily seeking >legislators (and/or legislative staff), >policymakers (from the government, academia, >etc.), and senior law enforcement officials >responsible for drafting and amending cybercrime >statutes or for conducting cybercrime >investigations. Of course, I'm also interested >in inviting law enforcement individuals from >dedicated cybercrime investigative or >prosecutorial units, if they exist or, in the >alternative, individuals who have specialized in >cybercrime investigations or prosecutions within >one of the ILEA member countries referenced above. > > > >In order to provide training that will be both >helpful and productive, as well as in order to >tailor the training to the needs of the >individual delegates, I've drafted an agenda for >a comprehensive 4 day workshop (starting from >introduction to technology and moving attendees >through the problems and challenges raised, to >lessons on drafting cyber-legislation, to >building law enforcement capacity, etc) -- a >draft of which I will be sending out >shortly. In the interim, I am currently in the >process of locating speakers from both the >public and private sector to help supplement the >training we can offer from the governmental and >law enforcement perspective, and I am hoping >that AfriNIC might be able to assist us in such >a capacity. As such, I am writing to you to see >if someone from AfriNIC might be available to >participate as a speaker (or to recommend local >speakers in Africa) in either one, or both, of >the workshops (referenced above), during one or more of the following sessions: > > > >* The Risk of Cybercrime and Its Impact on the >African Region: A discussion of the importance >of Cybersecurity and of the scope of cybercrime >in the region and around the globe. > > > >* Unique Challenges in the Region in Combating >Cybercrime: Discussion of special circumstances >such as satellites from other countries, no >domestic ISPs subject to local law, porous borders, etc. > > > >* The Process of Developing and Enacting Cyber >Legislation: The process by which various >countries? computer crime statutes were drafted >and adopted (whether those attempts have >resulted din actual laws, or have yet to come to fruition). > > > >African State Cybercrime Laws or Proposed >Laws: Discussion by African countries of >cybercrime laws that they have enacted >domestically, or are in the process of drafting, >and their experiences in drafting/enacting them. > > > >* Discussion of Current International Efforts to >combat Phishing and ID Theft and How African Countries Can Get Involved > > > >* Fostering Cooperation Between ISPs, Industry, >and Law Enforcement: Perspective from private >industry regarding how they are affected by >cybercrime and how they can assist and provide >information to law enforcement for criminal investigations. > > > >* Training, Structuring, and Funding Cybercrime >Units: Panel discussion of how a cybercrime >unit can be effectively assembled to conduct >computer crime investigations and the means >through which countries can obtain funds to >create or augment their investigative cybercrime capabilities. > > > >* Wireless and Satellite Internet Access ? >Unique Challenges Raised: A discussion of the >unique law enforcement investigative and >international cooperation challenges raised by >these new means of gaining Internet access. > > > >* Finding In-Country/In-Region Support & Funding >for Law Enforcement CyberCrime Units: A >discussion of the challenges faced by others, >success stories in the region and ideas for >resources to consult and training options to tap into. > > > >Thank you in advance for considering this >request and for any help you may be able to >offer. And please feel free to contact me if >you have any questions or need additional information. Cheers. > > > >-Joel Schwarz > >Joel Schwarz > >Computer Crime & Intellectual Property Section > >U.S. Department of Justice > >Washington, D.C. 20005 > >Phone - (202) 353-4253 > >Fax - (202) 514-6113 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.afrinic.net/pipermail/policy-wg/attachments/20060513/05a4ba0f/attachment.htm From aa at tenet.ac.za Mon May 15 07:02:59 2006 From: aa at tenet.ac.za (Andrew Alston) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Global IPv6 PI policy proposal In-Reply-To: Message-ID: Hi All, I've given this policy a fair bit of thought. I am a major proponent of PI v6 space, however, I do not agree with the /32 allocation. Yes, while there is a LOT of IPv6 space, the use of /32s in the PI arena violates the (widely accepted?) recommendations in RFC 3177 and quite frankly is unnecessarily large in my opinion. It is also out of line with what I believe is ARIN's recently adopted stance when they approved the assignment of /48 P.I space. I have heard many arguments regarding the pro's and con's of P.I space, but the primary one I hear time and again revolves around the size of the routing table should /48s start appearing in the table due to P.I assignments. Quite frankly, to my knowledge, the routing table has *NEVER* kept up with moore's law, in v4 or v6, far far from it. But beyond the moore's law argument, as again, many people would say that is irrelevant, there are other things we can consider here. At current, if we look at the size of the routing table in the v4 world, yes, its large and its growing, but why is this the case? Current assignment policies with regards to v4 dictate that a company gets their space in relatively small blocks, and as the companies grow and mature, they require more and more v4 space. This means they apply for multiple blocks, and announce multiple blocks, which results in many companies announcing P.I space announcing multiple routes. In the case of IPv6 and /48 blocks, this should not happen. The /48 block contains a vast number of addresses, and is easily subnettable due to its size to allow for decent aggregation within most companies. I would say that in the case of very large organizations, there should be an option to apply for a bigger P.I block if the motivation exists, perhaps a /46 or a /47, purely on the basis that some organizations may need large blocks for internal aggregation due to number of sites or other such reasons. Other than that, I would support this policy and recommend it be passed, providing we can sort out the issues around the size of allocations. Many Thanks Andrew Alston TENET - Chief Technology Officer -----Original Message----- From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net]On Behalf Of JORDI PALET MARTINEZ Sent: 14 April 2006 17:01 To: global-v6@lists.apnic.net Subject: [policy-wg] Global IPv6 PI policy proposal Please, use global-v6@lists.apnic.net for inputs to this draft policy proposal, in order to avoid threads being split across multiple mail exploders in different regions. 1. Number: (The RIPE NCC will assign this) 2. Policy Proposal Name: Provider-Independent (PI) IPv6 Assignments for End-User-Organizations Note: We can use ?Portable IPv6 Assignments for End-User-Organizations? if that helps some folks to buy-in the proposal. 3. Author: a. name: Jordi Palet Martinez b. e-mail: jordi.palet@consulintel.es c. organisation: Consulintel 4. Proposal Version: 1.1 5. Submission Date: 17/4/2006 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: a. new, modify, or delete. NEW 8. Policy term: a. temporary, permanent, or renewable. TEMPORARY 9. Summary of proposal: This policy is intended to provide a solution for organizations that have a need for provider independent assignments in IPv6. Typically those organizations will require the provider independent assignment in order to be able to become multihomed in a similar fashion as today is done for IPv4, but other reasons are also foreseen. For example some organizations aren?t multihomed, but still require being globally routable with stable addressing (avoiding renumbering if they change the upstream provider) and in those cases (reasons behind may be administrative, policy, security, etc.) it seems that no other solution than provider independence is feasible, at least by now. Considering the foreseen consequences in the medium/long-term of this policy in the routing tables, this policy proposes an expiry date of 3 years once a technically correct alternative valid and deployable solution becomes accepted by the community. After that sunset period, the assignments done for multihoming purposes should be reclaimed and this policy should be modified to still allow assignments that could be required for purposes different than multhoming. At the sunset, the organizations that want to avoid renumbering and qualify to become an LIR, will be able to opt for that solution and they will get allocated the same prefix. 10. Policy text: a. Current (if modify): b. New: Provider-Independent IPv6 assignment to End-User-Organizations Qualification for an IPv6 Provider-Independent assignment: To qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy. This is valid regardless of actually having being assigned or allocated such an IPv4 block. Provider-Independent IPv6 assignment size to End-User-Organizations: The minimum size of the assignment is /32. However a larger assignment can be provided if duly documented and justified. Subsequent assignment size to End-User-Organizations: Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified. Assignment super-block: Those assignments shall be allocated from a separate super-block to allow for LIRs to filter them if required. Expiry for those assignments: In the case of assignments done under this proposal in order to address the multihoming issue, they will need to return the block in a maximum period of 3 years after a technically correct alternative valid and deployable solution becomes accepted by the community. Alternatively, to avoid renumbering, some of the organizations affected by this, could become an LIR, if they qualify for it. 11. Rationale: a. Arguments supporting the proposal In IPv4 there are organizations that qualify for an allocation for being PI, or could opt to be an LIR, either because they need to be multihomed or have other administrative or technical reasons to require a portable addressing block. This is not the case today for IPv6 and it is perceived as a clear barrier for deployment of IPv6 in some organizations, and is being addressed by this proposal by means of providing a direct assignment from RIPE NCC. These organizations are not allowed to make further assignments to other external organizations, but instead only to assign subnets internally within their own facilities. Assigning /32 will make those blocks to behave as other regular LIR-allocated ones and follow the generally accepted routing filtering practices, but at the same time being identifiable belonging to a special super-block. Also, it allows becoming an LIR, if that?s the case, without requiring a renumbering. By setting up this policy, we avoid creating an unfairness situation among different regions and allow any organization that requires PI to access to it. All the organizations that opt for this PI, will be in the same fair situation once the technical solution is agreed and will have to either move to the new solution or become an LIR if they qualify. Newcomers will be in the same situation. Organizations that don?t opt to PI with this policy is because they don?t need it, so they aren?t put in an unfair situation. Those that don?t believe in possible alternative solutions and agree in going for a permanent PI policy instead, don?t have valid reasons to oppose to this proposal, as the sunset will only enter into effect once that solution is agreed, so this proposal is not against their view. Some organizations my qualify to become an LIR now and avoid using this temporary assignment, but if their only reason to become an LIR is to get the PI block, then it seems better, looking in the long-term routing table size conservation, to go for this choice, which is more fair for the overall community. The ?temporarily? of this assignment must be understood as a long-term one, as we may expect those alternative solutions to be available possible in 3-4 years, which means that with the ?transition? period of 3 years, asking for a change in 6-7 years must not be considered as a pain. b. Arguments opposing the proposal The possible effect of this proposal is the grow of the routing tables to figures which, together with the existing (and forecasted) IPv4 routing entries, could create an important trouble to operators before vendors provide products with implement technical solutions, or even if those technical solutions exists, have an important impact in the cost or/and depreciation period for the infrastructure investments. This is the reason why the proposal provides already a fix sunset, but relative to the date where an alternative and technically correct solution is available and accepted as deployable by the community. Regarding the size of the assignment (/32), being a temporal one, should not be considered as a space waste, and instead be seen as an advantage in the sense of not requiring new special filters. Acknowledgments: I will like to acknowledge the inputs received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ policy-wg mailing list policy-wg@afrinic.net http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg From jordi.palet at consulintel.es Mon May 15 09:02:59 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Global IPv6 PI policy proposal In-Reply-To: Message-ID: Hi Andrew, See my response below in-line. Regards, Jordi > De: Andrew Alston > Responder a: AfriNIC Policy Working Group List > Fecha: Mon, 15 May 2006 07:02:59 +0200 > Para: AfriNIC Policy Working Group List > Asunto: RE: [policy-wg] Global IPv6 PI policy proposal > > Hi All, > > I've given this policy a fair bit of thought. I am a major proponent of PI v6 Let's start with something that may be shocking for some. I'm not in favor of PI. I'm in favor of keeping the maximum aggregation and having a contention in the routing tables (there are studies that show that we will pass over the million of entries in a few years, which is not good at all). However, I think is not good that a region has PI and not the rest, because the global cost of routing is shared by all the regions. This will be very unfair. I also understand at the same time those companies that are in need for a solution to PI (multihomed or not), and this is why I want to see this proposal adopted, or alternatively a way for any company which needs IPv6 space, to become an LIR and receive addressing space. This is not possible today because they not sub-assign the space to other entities, but only to their own ones. > space, however, I do not agree with the /32 allocation. Yes, while there is a > LOT of IPv6 space, the use of /32s in the PI arena violates the (widely > accepted?) recommendations in RFC 3177 and quite frankly is unnecessarily > large in my opinion. It is also out of line with what I believe is ARIN's > recently adopted stance when they approved the assignment of /48 P.I space. My understanding is that the ARIN decision is still on the hands of the Advisory Council, so the prefix length is not yet fixed as they can suggest modifications to the policy proposal. RFC3177 is not related at all to this case, in my opinion, as it clearly states that is only addressing the issues of the boundary between the public and private topology and the PI space is addressing the issue of making public some private topologies which are on the need for it. There is so much IPv6 space than if we agree with the HD-Ratio change which is actually being approved in most of the regions (I guess it will become in all of them), the expectative are for 480+ years of IPv6 addresses lifetime. In my opinion, the impact of a PI policy allocating /32, will be minimum on this and even if we only have IPv6 addresses for 100 years, I really think is more than enough. Actually I doubt that we will keep using IPv4/IPv6 at all in that time, even we may be still will call IP to the protocol that we use by then. But of course, this is just predictions and we can be, all, wrong. In my opinion the important cost here is keeping the routing table low and at the same time not putting the cost in human resources to configure allow-/48 filters in each router, everytime there is a new PI allocation. Comparing this with the cost of "investing" a few extra /32 is quite positive on this balance. > > I have heard many arguments regarding the pro's and con's of P.I space, but > the primary one I hear time and again revolves around the size of the routing > table should /48s start appearing in the table due to P.I assignments. Quite > frankly, to my knowledge, the routing table has *NEVER* kept up with moore's > law, in v4 or v6, far far from it. But beyond the moore's law argument, as > again, many people would say that is irrelevant, there are other things we can > consider here. You need to see the latest presentations from Jason Schiller and Geoff Houston ... > > At current, if we look at the size of the routing table in the v4 world, yes, > its large and its growing, but why is this the case? Current assignment > policies with regards to v4 dictate that a company gets their space in > relatively small blocks, and as the companies grow and mature, they require > more and more v4 space. This means they apply for multiple blocks, and > announce multiple blocks, which results in many companies announcing P.I space > announcing multiple routes. In the case of IPv6 and /48 blocks, this should > not happen. > > The /48 block contains a vast number of addresses, and is easily subnettable > due to its size to allow for decent aggregation within most companies. I > would say that in the case of very large organizations, there should be an > option to apply for a bigger P.I block if the motivation exists, perhaps a /46 > or a /47, purely on the basis that some organizations may need large blocks > for internal aggregation due to number of sites or other such reasons. > > Other than that, I would support this policy and recommend it be passed, > providing we can sort out the issues around the size of allocations. Take also in consideration that I'm still believing that we will have in a few years better technical solutions (and not just one) and considering that, /32 will not be a trouble, specially because is a temporary allocation and some of the entities needing it, may not need it forever. Last, but not least, consider that the alternative is to allow those entities to become an LIR, and in that case they will also get a /32. So what makes the difference ?. Also, note that I'm not proposing that those companies aren't charged for this. Actually I didn't say anything about the charging scheme because I understand that it falls in hands of the AfriNIC board. My view is that any entity receiving resources must share the cost in a similar fair way as the rest of the members. I will accept an exception for non-profit organizations and services if that's acceptable for the rest of the community. > > Many Thanks > > Andrew Alston > TENET - Chief Technology Officer > > -----Original Message----- > From: policy-wg-bounces@afrinic.net > [mailto:policy-wg-bounces@afrinic.net]On Behalf Of JORDI PALET MARTINEZ > Sent: 14 April 2006 17:01 > To: global-v6@lists.apnic.net > Subject: [policy-wg] Global IPv6 PI policy proposal > > > Please, use global-v6@lists.apnic.net for inputs to this draft policy > proposal, in order to avoid threads being split across multiple mail > exploders in different regions. > > > 1. Number: (The RIPE NCC will assign this) > > 2. Policy Proposal Name: > > Provider-Independent (PI) IPv6 Assignments for End-User-Organizations > > Note: We can use ?Portable IPv6 Assignments for End-User-Organizations? if > that helps some folks to buy-in the proposal. > > 3. Author: > a. name: Jordi Palet Martinez > b. e-mail: jordi.palet@consulintel.es > c. organisation: Consulintel > > 4. Proposal Version: 1.1 > > 5. Submission Date: 17/4/2006 > > 6. Suggested RIPE Working Group for discussion and publication: > > Address Policy > > 7. Proposal type: > a. new, modify, or delete. > > NEW > > 8. Policy term: > a. temporary, permanent, or renewable. > > TEMPORARY > > 9. Summary of proposal: > > This policy is intended to provide a solution for organizations that have a > need for provider independent assignments in IPv6. > > Typically those organizations will require the provider independent > assignment in order to be able to become multihomed in a similar fashion as > today is done for IPv4, but other reasons are also foreseen. For example > some organizations aren?t multihomed, but still require being globally > routable with stable addressing (avoiding renumbering if they change the > upstream provider) and in those cases (reasons behind may be administrative, > policy, security, etc.) it seems that no other solution than provider > independence is feasible, at least by now. > > Considering the foreseen consequences in the medium/long-term of this policy > in the routing tables, this policy proposes an expiry date of 3 years once a > technically correct alternative valid and deployable solution becomes > accepted by the community. After that sunset period, the assignments done > for multihoming purposes should be reclaimed and this policy should be > modified to still allow assignments that could be required for purposes > different than multhoming. > > At the sunset, the organizations that want to avoid renumbering and qualify > to become an LIR, will be able to opt for that solution and they will get > allocated the same prefix. > > 10. Policy text: > a. Current (if modify): > b. New: > > Provider-Independent IPv6 assignment to End-User-Organizations > Qualification for an IPv6 Provider-Independent assignment: To qualify for a > direct assignment, the organization must not be an IPv6 LIR and must qualify > for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 > policy. This is valid regardless of actually having being assigned or > allocated such an IPv4 block. > > Provider-Independent IPv6 assignment size to End-User-Organizations: The > minimum size of the assignment is /32. However a larger assignment can be > provided if duly documented and justified. > > Subsequent assignment size to End-User-Organizations: Whenever possible, > further assignments will be made from adjacent address blocks, but only if > duly documented and justified. > > Assignment super-block: Those assignments shall be allocated from a separate > super-block to allow for LIRs to filter them if required. > > Expiry for those assignments: In the case of assignments done under this > proposal in order to address the multihoming issue, they will need to return > the block in a maximum period of 3 years after a technically correct > alternative valid and deployable solution becomes accepted by the community. > Alternatively, to avoid renumbering, some of the organizations affected by > this, could become an LIR, if they qualify for it. > > 11. Rationale: > a. Arguments supporting the proposal > > In IPv4 there are organizations that qualify for an allocation for being PI, > or could opt to be an LIR, either because they need to be multihomed or have > other administrative or technical reasons to require a portable addressing > block. > > This is not the case today for IPv6 and it is perceived as a clear barrier > for deployment of IPv6 in some organizations, and is being addressed by this > proposal by means of providing a direct assignment from RIPE NCC. > > These organizations are not allowed to make further assignments to other > external organizations, but instead only to assign subnets internally within > their own facilities. > > Assigning /32 will make those blocks to behave as other regular > LIR-allocated ones and follow the generally accepted routing filtering > practices, but at the same time being identifiable belonging to a special > super-block. Also, it allows becoming an LIR, if that?s the case, without > requiring a renumbering. > > By setting up this policy, we avoid creating an unfairness situation among > different regions and allow any organization that requires PI to access to > it. All the organizations that opt for this PI, will be in the same fair > situation once the technical solution is agreed and will have to either move > to the new solution or become an LIR if they qualify. Newcomers will be in > the same situation. Organizations that don?t opt to PI with this policy is > because they don?t need it, so they aren?t put in an unfair situation. > > Those that don?t believe in possible alternative solutions and agree in > going for a permanent PI policy instead, don?t have valid reasons to oppose > to this proposal, as the sunset will only enter into effect once that > solution is agreed, so this proposal is not against their view. > > Some organizations my qualify to become an LIR now and avoid using this > temporary assignment, but if their only reason to become an LIR is to get > the PI block, then it seems better, looking in the long-term routing table > size conservation, to go for this choice, which is more fair for the overall > community. > > The ?temporarily? of this assignment must be understood as a long-term one, > as we may expect those alternative solutions to be available possible in 3-4 > years, which means that with the ?transition? period of 3 years, asking for > a change in 6-7 years must not be considered as a pain. > > b. Arguments opposing the proposal > > The possible effect of this proposal is the grow of the routing tables to > figures which, together with the existing (and forecasted) IPv4 routing > entries, could create an important trouble to operators before vendors > provide products with implement technical solutions, or even if those > technical solutions exists, have an important impact in the cost or/and > depreciation period for the infrastructure investments. > > This is the reason why the proposal provides already a fix sunset, but > relative to the date where an alternative and technically correct solution > is available and accepted as deployable by the community. > > Regarding the size of the assignment (/32), being a temporal one, should not > be considered as a space waste, and instead be seen as an advantage in the > sense of not requiring new special filters. > > > > Acknowledgments: I will like to acknowledge the inputs received for the > first version of this proposal from Marcelo Bagnulo and Lea Roberts. > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From frank at afrinic.net Mon May 15 09:13:55 2006 From: frank at afrinic.net (frank@afrinic.net) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Deprecation of ip6.int scheduled for 1 June 2006 Message-ID: <200605150713.k4F7Dsp4012797@ns1.afrinic.net> In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', which advises the community that the use of "ip6.int" for IPv6 reverse address mapping should be deprecated and ip6.arpa used instead. In adopting the RFC's recommendations, the Regional Internet Registries (RIRs) have jointly agreed to cease support of "ip6.int" delegations as of 1 June 2006. Frank Nnebe AfriNIC Ltd. From adiel at afrinic.net Mon May 15 12:02:51 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Fwd: Streaming - AfNOG Meetings Message-ID: <7.0.1.0.2.20060515135347.047f17f0@afrinic.org> Dear Colleagues, The AfNOG, AfriNIC and INET'Africa meetings being held this week in Nairobi can be followed online at: http://tinder.uoregon.edu:8000. If you have live comments, you can send them to meeting@afrinic.net Thanks to the University of Oregon and KeNIC for their support towards realising this. Kind regards. -- Adiel. AfriNIC-4 and AfNOG'07 Meeting Nairobi, Kenya 13-18 May 2006 www.afrinic.net/meeting/afrinic-4 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.afrinic.net/pipermail/policy-wg/attachments/20060515/6f3f4114/attachment.htm From alan at futureperfect.co.za Mon May 15 13:35:49 2006 From: alan at futureperfect.co.za (Alan Levin) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] Re: [afrinic-discuss] Fwd: Streaming - AfNOG Meetings In-Reply-To: <7.0.1.0.2.20060515135347.047f17f0@afrinic.org> References: <7.0.1.0.2.20060515135347.047f17f0@afrinic.org> Message-ID: <3678E461-3969-49AE-BB91-9A5EC65B6923@futureperfect.co.za> Hi Adiel, On 15 May 2006, at 1:02 PM, Adiel A. Akplogan wrote: > The AfNOG, AfriNIC and INET'Africa meetings being held this week in > Nairobi can be followed online at: http://tinder.uoregon.edu:8000. > If you have live comments, you can send them to meeting@afrinic.net Thanks for this announcement. After Randy mentioned this was happening I found out about it and a few people have asked if we could put the presentations up so as to assist remote participation. regards, Alan --------------------------------------------- Alan Levin Tel: +27 21 409-7997 From geier-lists-afrinic-policywg at tih.co.tz Thu May 18 08:00:26 2006 From: geier-lists-afrinic-policywg at tih.co.tz (Frank Habicht) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] IPv6 PI policy Message-ID: <446C0D7A.3060901@tih.co.tz> Hi all, sorry I didn't speak up in the meeting. Regarding Jordi's IPv6 PI policy proposal afpol-v60604. I was in the third group who didn't want to reject/defer/stall the policy but also not accept as it was. The only problem in my opinion is the question of size of the assigned blocks. Main concern of contributors like Uniforum was that the assigned PI blocks be routable in practise (which AfriNIC won't guarantee, but might "influence"). I trust that operators of ipv6 routers will make the necessary exception for the supernet from with PI blocks are assigned. That other RIRs do same supports this expectation but if possible I'd like to hear from the router operators. I would like to see a change to a smaller default assignment size to conserve address space. I would like to maintain the provision to use bigger blocks when justified. /48 as default should be fine. If filters of <48 are expected rather than <=48, then /44 might be a good option. Since a rapid uptake of PI usage would or could increase the routing table size, and since I assume the fees attached to PI assignments will influence the number, those can be part of the discussion. I suggest fees should _not_ be waived. I would like to see the proposal succeed even if the above is not agreeable. As the numbers of hands in the meeting indicated, it is important to have this policy with or without change of assignment size. I hope we can use the 15 days last call period to find the best solution to the mentioned details. Regards, Frank From jordi.palet at consulintel.es Fri May 19 00:49:51 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] IPv6 PI policy In-Reply-To: <446C0D7A.3060901@tih.co.tz> Message-ID: Hi Frank, all, See my reply below, in-line. Regards, Jordi > De: Frank Habicht > Responder a: AfriNIC Policy Working Group List > Fecha: Thu, 18 May 2006 09:00:26 +0300 > Para: > Asunto: [policy-wg] IPv6 PI policy > > Hi all, > > sorry I didn't speak up in the meeting. > Regarding Jordi's IPv6 PI policy proposal afpol-v60604. > > I was in the third group who didn't want to reject/defer/stall the > policy but also not accept as it was. > The only problem in my opinion is the question of size of the assigned > blocks. > > Main concern of contributors like Uniforum was that the assigned PI > blocks be routable in practise (which AfriNIC won't guarantee, but might > "influence"). I trust that operators of ipv6 routers will make the > necessary exception for the supernet from with PI blocks are assigned. > That other RIRs do same supports this expectation but if possible I'd > like to hear from the router operators. > > I would like to see a change to a smaller default assignment size to > conserve address space. I would like to maintain the provision to use > bigger blocks when justified. /48 as default should be fine. If filters > of <48 are expected rather than <=48, then /44 might be a good option. The actual practice is to filter <=32, so even /44 will not work. An alternative solution could be to understand that if we use /48 from a special /32 block, then they may not be filtered (hopefully), but this only works if an "allow" filter is placed on the complete /32. The disadvantage of that, is the malicious usage of other /48 within that /32 which are still not allocated. This already happens with non-allocated IPv4 space, for example being used for spam. I think this is bad in general, so a good reason for avoiding it. Another disadvantage is that using a /32 allows a non-issue transition (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously this is a very important advantage. May be I didn't stressed it enough during the meeting. I really think the advantages of the /32 versus the "perceived" waste are of a much much much heavy way in the balance. Remember after all that this is a temporary policy, so we are not wasting space forever. As said in the meeting, the alternative will be to modify the existing PA allocation to allow organizations to receive a PA prefix even if they don't subassign to *other* organizations. In this case, is clear that they will also get a /32. So what makes the difference ?. > > Since a rapid uptake of PI usage would or could increase the routing > table size, and since I assume the fees attached to PI assignments will > influence the number, those can be part of the discussion. I suggest > fees should _not_ be waived. I'm of the opinion that the fees should be waived only when the PA fees are waived, but this may imply that there is some type of charge for having a contractual relationship/membership with AfriNIC. I mean, right now LIRs that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is also true if a new LIR only needs IPv6 ? > > I would like to see the proposal succeed even if the above is not > agreeable. As the numbers of hands in the meeting indicated, it is > important to have this policy with or without change of assignment size. > I hope we can use the 15 days last call period to find the best solution > to the mentioned details. > > Regards, > Frank > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From aa at tenet.ac.za Fri May 19 10:45:59 2006 From: aa at tenet.ac.za (Andrew Alston) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] IPv6 PI policy In-Reply-To: References: Message-ID: <446D85C7.5070403@tenet.ac.za> Hi Jordi/Frank I've been looking at this, and Jordi states that the current policy is to filter <= /32, I actually disagree with this. I've been looking around at various route servers, and checking various networks, as well as speaking to a *LOT* of network admins, currently the actual ACTIVE practice is to filter <= /48, I have yet to actually find anyone who is filtering on a <= /32 basis. While I'm sure they may exist, if they do they are in my opinion probably the vast minority. Again I reiterate, P.I space of /48 with an option for /44 upon serious motivation. Other than that, I support the policy Thanks Andrew Alston TENET - Chief Technical Officer JORDI PALET MARTINEZ wrote: > Hi Frank, all, > > See my reply below, in-line. > > Regards, > Jordi > > > > > >> De: Frank Habicht >> Responder a: AfriNIC Policy Working Group List >> Fecha: Thu, 18 May 2006 09:00:26 +0300 >> Para: >> Asunto: [policy-wg] IPv6 PI policy >> >> Hi all, >> >> sorry I didn't speak up in the meeting. >> Regarding Jordi's IPv6 PI policy proposal afpol-v60604. >> >> I was in the third group who didn't want to reject/defer/stall the >> policy but also not accept as it was. >> The only problem in my opinion is the question of size of the assigned >> blocks. >> >> Main concern of contributors like Uniforum was that the assigned PI >> blocks be routable in practise (which AfriNIC won't guarantee, but might >> "influence"). I trust that operators of ipv6 routers will make the >> necessary exception for the supernet from with PI blocks are assigned. >> That other RIRs do same supports this expectation but if possible I'd >> like to hear from the router operators. >> >> I would like to see a change to a smaller default assignment size to >> conserve address space. I would like to maintain the provision to use >> bigger blocks when justified. /48 as default should be fine. If filters >> of <48 are expected rather than <=48, then /44 might be a good option. >> > > The actual practice is to filter <=32, so even /44 will not work. > > An alternative solution could be to understand that if we use /48 from a > special /32 block, then they may not be filtered (hopefully), but this only > works if an "allow" filter is placed on the complete /32. > > The disadvantage of that, is the malicious usage of other /48 within that > /32 which are still not allocated. This already happens with non-allocated > IPv4 space, for example being used for spam. I think this is bad in general, > so a good reason for avoiding it. > > Another disadvantage is that using a /32 allows a non-issue transition > (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously > this is a very important advantage. May be I didn't stressed it enough > during the meeting. > > I really think the advantages of the /32 versus the "perceived" waste are of > a much much much heavy way in the balance. Remember after all that this is a > temporary policy, so we are not wasting space forever. > > As said in the meeting, the alternative will be to modify the existing PA > allocation to allow organizations to receive a PA prefix even if they don't > subassign to *other* organizations. In this case, is clear that they will > also get a /32. So what makes the difference ?. > > >> Since a rapid uptake of PI usage would or could increase the routing >> table size, and since I assume the fees attached to PI assignments will >> influence the number, those can be part of the discussion. I suggest >> fees should _not_ be waived. >> > > I'm of the opinion that the fees should be waived only when the PA fees are > waived, but this may imply that there is some type of charge for having a > contractual relationship/membership with AfriNIC. I mean, right now LIRs > that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is > also true if a new LIR only needs IPv6 ? > > >> I would like to see the proposal succeed even if the above is not >> agreeable. As the numbers of hands in the meeting indicated, it is >> important to have this policy with or without change of assignment size. >> I hope we can use the 15 days last call period to find the best solution >> to the mentioned details. >> >> Regards, >> Frank >> >> >> _______________________________________________ >> policy-wg mailing list >> policy-wg@afrinic.net >> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >> > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg > From jordi.palet at consulintel.es Fri May 19 11:03:24 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:10 2006 Subject: [policy-wg] IPv6 PI policy In-Reply-To: <446D85C7.5070403@tenet.ac.za> Message-ID: Hi Andrew, I disagree, anyway, is something that its up to each operator, and what is sure is that they don't filter anything shorter than 32 ... Let me put an example that shows and <=32 works, others not. APNIC has its own infrastructure in two locations, and they decided to split the /32 in 2x/33. From time to time, they become not reachable from different locations. Some operators only accept the /32. How do you feel about that ? Let me insist that /32 is not a waste under the consideration of: 1) is an alternative to allow the current allocation policy to be modified for those that may sub-assign to the same organization (instead to others); 2) is temporary. However the cost for a different prefix is very unpredictable in terms of asking everyone to make a specific filter for each /48 (or /44) and consequently is not a good solution because is going to be against the proposal of the policy itself (becoming a barrier to the existing barrier !). Regards, Jordi > De: Andrew Alston > Responder a: > Fecha: Fri, 19 May 2006 10:45:59 +0200 > Para: , AfriNIC Policy Working Group List > > Asunto: Re: [policy-wg] IPv6 PI policy > > Hi Jordi/Frank > > I've been looking at this, and Jordi states that the current policy is > to filter <= /32, I actually disagree with this. > > I've been looking around at various route servers, and checking various > networks, as well as speaking to a *LOT* of network admins, currently > the actual ACTIVE practice is to filter <= /48, I have yet to actually > find anyone who is filtering on a <= /32 basis. While I'm sure they may > exist, if they do they are in my opinion probably the vast minority. > > Again I reiterate, P.I space of /48 with an option for /44 upon serious > motivation. > > Other than that, I support the policy > > Thanks > > Andrew Alston > TENET - Chief Technical Officer > > > JORDI PALET MARTINEZ wrote: >> Hi Frank, all, >> >> See my reply below, in-line. >> >> Regards, >> Jordi >> >> >> >> >> >>> De: Frank Habicht >>> Responder a: AfriNIC Policy Working Group List >>> Fecha: Thu, 18 May 2006 09:00:26 +0300 >>> Para: >>> Asunto: [policy-wg] IPv6 PI policy >>> >>> Hi all, >>> >>> sorry I didn't speak up in the meeting. >>> Regarding Jordi's IPv6 PI policy proposal afpol-v60604. >>> >>> I was in the third group who didn't want to reject/defer/stall the >>> policy but also not accept as it was. >>> The only problem in my opinion is the question of size of the assigned >>> blocks. >>> >>> Main concern of contributors like Uniforum was that the assigned PI >>> blocks be routable in practise (which AfriNIC won't guarantee, but might >>> "influence"). I trust that operators of ipv6 routers will make the >>> necessary exception for the supernet from with PI blocks are assigned. >>> That other RIRs do same supports this expectation but if possible I'd >>> like to hear from the router operators. >>> >>> I would like to see a change to a smaller default assignment size to >>> conserve address space. I would like to maintain the provision to use >>> bigger blocks when justified. /48 as default should be fine. If filters >>> of <48 are expected rather than <=48, then /44 might be a good option. >>> >> >> The actual practice is to filter <=32, so even /44 will not work. >> >> An alternative solution could be to understand that if we use /48 from a >> special /32 block, then they may not be filtered (hopefully), but this only >> works if an "allow" filter is placed on the complete /32. >> >> The disadvantage of that, is the malicious usage of other /48 within that >> /32 which are still not allocated. This already happens with non-allocated >> IPv4 space, for example being used for spam. I think this is bad in general, >> so a good reason for avoiding it. >> >> Another disadvantage is that using a /32 allows a non-issue transition >> (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously >> this is a very important advantage. May be I didn't stressed it enough >> during the meeting. >> >> I really think the advantages of the /32 versus the "perceived" waste are of >> a much much much heavy way in the balance. Remember after all that this is a >> temporary policy, so we are not wasting space forever. >> >> As said in the meeting, the alternative will be to modify the existing PA >> allocation to allow organizations to receive a PA prefix even if they don't >> subassign to *other* organizations. In this case, is clear that they will >> also get a /32. So what makes the difference ?. >> >> >>> Since a rapid uptake of PI usage would or could increase the routing >>> table size, and since I assume the fees attached to PI assignments will >>> influence the number, those can be part of the discussion. I suggest >>> fees should _not_ be waived. >>> >> >> I'm of the opinion that the fees should be waived only when the PA fees are >> waived, but this may imply that there is some type of charge for having a >> contractual relationship/membership with AfriNIC. I mean, right now LIRs >> that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is >> also true if a new LIR only needs IPv6 ? >> >> >>> I would like to see the proposal succeed even if the above is not >>> agreeable. As the numbers of hands in the meeting indicated, it is >>> important to have this policy with or without change of assignment size. >>> I hope we can use the 15 days last call period to find the best solution >>> to the mentioned details. >>> >>> Regards, >>> Frank >>> >>> >>> _______________________________________________ >>> policy-wg mailing list >>> policy-wg@afrinic.net >>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> _______________________________________________ >> policy-wg mailing list >> policy-wg@afrinic.net >> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >> ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From aa at tenet.ac.za Fri May 19 11:28:28 2006 From: aa at tenet.ac.za (Andrew Alston) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] IPv6 PI policy In-Reply-To: References: Message-ID: <446D8FBC.7030503@tenet.ac.za> Hi Jordi, I am not asking for a specific filter for each /48, I am suggesting that if the P.I space comes out of a single superblock (/30, /31, whatever the size of the superblock is that afrinic decides to allocate the P.I out of), that an exception be made singularly for the superblock to allow /48 routes from that superblock. Andrew JORDI PALET MARTINEZ wrote: > Hi Andrew, > > I disagree, anyway, is something that its up to each operator, and what is > sure is that they don't filter anything shorter than 32 ... > > Let me put an example that shows and <=32 works, others not. > > APNIC has its own infrastructure in two locations, and they decided to split > the /32 in 2x/33. From time to time, they become not reachable from > different locations. Some operators only accept the /32. > > How do you feel about that ? > > Let me insist that /32 is not a waste under the consideration of: 1) is an > alternative to allow the current allocation policy to be modified for those > that may sub-assign to the same organization (instead to others); 2) is > temporary. However the cost for a different prefix is very unpredictable in > terms of asking everyone to make a specific filter for each /48 (or /44) and > consequently is not a good solution because is going to be against the > proposal of the policy itself (becoming a barrier to the existing barrier > !). > > Regards, > Jordi > > > > > >> De: Andrew Alston >> Responder a: >> Fecha: Fri, 19 May 2006 10:45:59 +0200 >> Para: , AfriNIC Policy Working Group List >> >> Asunto: Re: [policy-wg] IPv6 PI policy >> >> Hi Jordi/Frank >> >> I've been looking at this, and Jordi states that the current policy is >> to filter <= /32, I actually disagree with this. >> >> I've been looking around at various route servers, and checking various >> networks, as well as speaking to a *LOT* of network admins, currently >> the actual ACTIVE practice is to filter <= /48, I have yet to actually >> find anyone who is filtering on a <= /32 basis. While I'm sure they may >> exist, if they do they are in my opinion probably the vast minority. >> >> Again I reiterate, P.I space of /48 with an option for /44 upon serious >> motivation. >> >> Other than that, I support the policy >> >> Thanks >> >> Andrew Alston >> TENET - Chief Technical Officer >> >> >> JORDI PALET MARTINEZ wrote: >> >>> Hi Frank, all, >>> >>> See my reply below, in-line. >>> >>> Regards, >>> Jordi >>> >>> >>> >>> >>> >>> >>>> De: Frank Habicht >>>> Responder a: AfriNIC Policy Working Group List >>>> Fecha: Thu, 18 May 2006 09:00:26 +0300 >>>> Para: >>>> Asunto: [policy-wg] IPv6 PI policy >>>> >>>> Hi all, >>>> >>>> sorry I didn't speak up in the meeting. >>>> Regarding Jordi's IPv6 PI policy proposal afpol-v60604. >>>> >>>> I was in the third group who didn't want to reject/defer/stall the >>>> policy but also not accept as it was. >>>> The only problem in my opinion is the question of size of the assigned >>>> blocks. >>>> >>>> Main concern of contributors like Uniforum was that the assigned PI >>>> blocks be routable in practise (which AfriNIC won't guarantee, but might >>>> "influence"). I trust that operators of ipv6 routers will make the >>>> necessary exception for the supernet from with PI blocks are assigned. >>>> That other RIRs do same supports this expectation but if possible I'd >>>> like to hear from the router operators. >>>> >>>> I would like to see a change to a smaller default assignment size to >>>> conserve address space. I would like to maintain the provision to use >>>> bigger blocks when justified. /48 as default should be fine. If filters >>>> of <48 are expected rather than <=48, then /44 might be a good option. >>>> >>>> >>> The actual practice is to filter <=32, so even /44 will not work. >>> >>> An alternative solution could be to understand that if we use /48 from a >>> special /32 block, then they may not be filtered (hopefully), but this only >>> works if an "allow" filter is placed on the complete /32. >>> >>> The disadvantage of that, is the malicious usage of other /48 within that >>> /32 which are still not allocated. This already happens with non-allocated >>> IPv4 space, for example being used for spam. I think this is bad in general, >>> so a good reason for avoiding it. >>> >>> Another disadvantage is that using a /32 allows a non-issue transition >>> (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously >>> this is a very important advantage. May be I didn't stressed it enough >>> during the meeting. >>> >>> I really think the advantages of the /32 versus the "perceived" waste are of >>> a much much much heavy way in the balance. Remember after all that this is a >>> temporary policy, so we are not wasting space forever. >>> >>> As said in the meeting, the alternative will be to modify the existing PA >>> allocation to allow organizations to receive a PA prefix even if they don't >>> subassign to *other* organizations. In this case, is clear that they will >>> also get a /32. So what makes the difference ?. >>> >>> >>> >>>> Since a rapid uptake of PI usage would or could increase the routing >>>> table size, and since I assume the fees attached to PI assignments will >>>> influence the number, those can be part of the discussion. I suggest >>>> fees should _not_ be waived. >>>> >>>> >>> I'm of the opinion that the fees should be waived only when the PA fees are >>> waived, but this may imply that there is some type of charge for having a >>> contractual relationship/membership with AfriNIC. I mean, right now LIRs >>> that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is >>> also true if a new LIR only needs IPv6 ? >>> >>> >>> >>>> I would like to see the proposal succeed even if the above is not >>>> agreeable. As the numbers of hands in the meeting indicated, it is >>>> important to have this policy with or without change of assignment size. >>>> I hope we can use the 15 days last call period to find the best solution >>>> to the mentioned details. >>>> >>>> Regards, >>>> Frank >>>> >>>> >>>> _______________________________________________ >>>> policy-wg mailing list >>>> policy-wg@afrinic.net >>>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>>> >>>> >>> >>> >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>> >>> Barcelona 2005 Global IPv6 Summit >>> Slides available at: >>> http://www.ipv6-es.com >>> >>> This electronic message contains information which may be privileged or >>> confidential. The information is intended to be for the use of the >>> individual(s) named above. If you are not the intended recipient be aware >>> that any disclosure, copying, distribution or use of the contents of this >>> information, including attached files, is prohibited. >>> >>> >>> >>> _______________________________________________ >>> policy-wg mailing list >>> policy-wg@afrinic.net >>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>> >>> > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg > From jordi.palet at consulintel.es Sat May 20 20:29:56 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] IPv6 PI policy In-Reply-To: <446D8FBC.7030503@tenet.ac.za> Message-ID: Hi Andrew, Yes, I got that already, but in general people don't necessarily setup a single filter for all the prefix. Doing so, still allows, for example, spammers to use pieces of the superblock (i.e., /44 or /48). At the end, unfortunately, there is not a clear set of strict rules for routing/filtering, so whatever we decide may or may not work. However, as the general accepted practice is for <=/32, this ensures a higher level of general "routability". Regards, Jordi > De: Andrew Alston > Responder a: > Fecha: Fri, 19 May 2006 11:28:28 +0200 > Para: , AfriNIC Policy Working Group List > > Asunto: Re: [policy-wg] IPv6 PI policy > > Hi Jordi, > > I am not asking for a specific filter for each /48, I am suggesting that > if the P.I space comes out of a single superblock (/30, /31, whatever > the size of the superblock is that afrinic decides to allocate the P.I > out of), that an exception be made singularly for the superblock to > allow /48 routes from that superblock. > > Andrew > > > JORDI PALET MARTINEZ wrote: >> Hi Andrew, >> >> I disagree, anyway, is something that its up to each operator, and what is >> sure is that they don't filter anything shorter than 32 ... >> >> Let me put an example that shows and <=32 works, others not. >> >> APNIC has its own infrastructure in two locations, and they decided to split >> the /32 in 2x/33. From time to time, they become not reachable from >> different locations. Some operators only accept the /32. >> >> How do you feel about that ? >> >> Let me insist that /32 is not a waste under the consideration of: 1) is an >> alternative to allow the current allocation policy to be modified for those >> that may sub-assign to the same organization (instead to others); 2) is >> temporary. However the cost for a different prefix is very unpredictable in >> terms of asking everyone to make a specific filter for each /48 (or /44) and >> consequently is not a good solution because is going to be against the >> proposal of the policy itself (becoming a barrier to the existing barrier >> !). >> >> Regards, >> Jordi >> >> >> >> >> >>> De: Andrew Alston >>> Responder a: >>> Fecha: Fri, 19 May 2006 10:45:59 +0200 >>> Para: , AfriNIC Policy Working Group List >>> >>> Asunto: Re: [policy-wg] IPv6 PI policy >>> >>> Hi Jordi/Frank >>> >>> I've been looking at this, and Jordi states that the current policy is >>> to filter <= /32, I actually disagree with this. >>> >>> I've been looking around at various route servers, and checking various >>> networks, as well as speaking to a *LOT* of network admins, currently >>> the actual ACTIVE practice is to filter <= /48, I have yet to actually >>> find anyone who is filtering on a <= /32 basis. While I'm sure they may >>> exist, if they do they are in my opinion probably the vast minority. >>> >>> Again I reiterate, P.I space of /48 with an option for /44 upon serious >>> motivation. >>> >>> Other than that, I support the policy >>> >>> Thanks >>> >>> Andrew Alston >>> TENET - Chief Technical Officer >>> >>> >>> JORDI PALET MARTINEZ wrote: >>> >>>> Hi Frank, all, >>>> >>>> See my reply below, in-line. >>>> >>>> Regards, >>>> Jordi >>>> >>>> >>>> >>>> >>>> >>>> >>>>> De: Frank Habicht >>>>> Responder a: AfriNIC Policy Working Group List >>>>> Fecha: Thu, 18 May 2006 09:00:26 +0300 >>>>> Para: >>>>> Asunto: [policy-wg] IPv6 PI policy >>>>> >>>>> Hi all, >>>>> >>>>> sorry I didn't speak up in the meeting. >>>>> Regarding Jordi's IPv6 PI policy proposal afpol-v60604. >>>>> >>>>> I was in the third group who didn't want to reject/defer/stall the >>>>> policy but also not accept as it was. >>>>> The only problem in my opinion is the question of size of the assigned >>>>> blocks. >>>>> >>>>> Main concern of contributors like Uniforum was that the assigned PI >>>>> blocks be routable in practise (which AfriNIC won't guarantee, but might >>>>> "influence"). I trust that operators of ipv6 routers will make the >>>>> necessary exception for the supernet from with PI blocks are assigned. >>>>> That other RIRs do same supports this expectation but if possible I'd >>>>> like to hear from the router operators. >>>>> >>>>> I would like to see a change to a smaller default assignment size to >>>>> conserve address space. I would like to maintain the provision to use >>>>> bigger blocks when justified. /48 as default should be fine. If filters >>>>> of <48 are expected rather than <=48, then /44 might be a good option. >>>>> >>>>> >>>> The actual practice is to filter <=32, so even /44 will not work. >>>> >>>> An alternative solution could be to understand that if we use /48 from a >>>> special /32 block, then they may not be filtered (hopefully), but this only >>>> works if an "allow" filter is placed on the complete /32. >>>> >>>> The disadvantage of that, is the malicious usage of other /48 within that >>>> /32 which are still not allocated. This already happens with non-allocated >>>> IPv4 space, for example being used for spam. I think this is bad in >>>> general, >>>> so a good reason for avoiding it. >>>> >>>> Another disadvantage is that using a /32 allows a non-issue transition >>>> (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously >>>> this is a very important advantage. May be I didn't stressed it enough >>>> during the meeting. >>>> >>>> I really think the advantages of the /32 versus the "perceived" waste are >>>> of >>>> a much much much heavy way in the balance. Remember after all that this is >>>> a >>>> temporary policy, so we are not wasting space forever. >>>> >>>> As said in the meeting, the alternative will be to modify the existing PA >>>> allocation to allow organizations to receive a PA prefix even if they don't >>>> subassign to *other* organizations. In this case, is clear that they will >>>> also get a /32. So what makes the difference ?. >>>> >>>> >>>> >>>>> Since a rapid uptake of PI usage would or could increase the routing >>>>> table size, and since I assume the fees attached to PI assignments will >>>>> influence the number, those can be part of the discussion. I suggest >>>>> fees should _not_ be waived. >>>>> >>>>> >>>> I'm of the opinion that the fees should be waived only when the PA fees are >>>> waived, but this may imply that there is some type of charge for having a >>>> contractual relationship/membership with AfriNIC. I mean, right now LIRs >>>> that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is >>>> also true if a new LIR only needs IPv6 ? >>>> >>>> >>>> >>>>> I would like to see the proposal succeed even if the above is not >>>>> agreeable. As the numbers of hands in the meeting indicated, it is >>>>> important to have this policy with or without change of assignment size. >>>>> I hope we can use the 15 days last call period to find the best solution >>>>> to the mentioned details. >>>>> >>>>> Regards, >>>>> Frank >>>>> >>>>> >>>>> _______________________________________________ >>>>> policy-wg mailing list >>>>> policy-wg@afrinic.net >>>>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>>>> >>>>> >>>> >>>> >>>> ********************************************** >>>> The IPv6 Portal: http://www.ipv6tf.org >>>> >>>> Barcelona 2005 Global IPv6 Summit >>>> Slides available at: >>>> http://www.ipv6-es.com >>>> >>>> This electronic message contains information which may be privileged or >>>> confidential. The information is intended to be for the use of the >>>> individual(s) named above. If you are not the intended recipient be aware >>>> that any disclosure, copying, distribution or use of the contents of this >>>> information, including attached files, is prohibited. >>>> >>>> >>>> >>>> _______________________________________________ >>>> policy-wg mailing list >>>> policy-wg@afrinic.net >>>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>>> >>>> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> _______________________________________________ >> policy-wg mailing list >> policy-wg@afrinic.net >> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >> ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From mje at posix.co.za Mon May 22 18:38:18 2006 From: mje at posix.co.za (Mark J Elkins) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] IPv6 PI policy In-Reply-To: References: Message-ID: <4471E8FA.7020508@posix.co.za> JORDI PALET MARTINEZ wrote: > Hi Andrew, > > Yes, I got that already, but in general people don't necessarily setup a > single filter for all the prefix. Doing so, still allows, for example, > spammers to use pieces of the superblock (i.e., /44 or /48). > > At the end, unfortunately, there is not a clear set of strict rules for > routing/filtering, so whatever we decide may or may not work. However, as > the general accepted practice is for <=/32, this ensures a higher level of > general "routability". > > Regards, > Jordi > I?m not really sure how many people are going to acquire PI space anyway. I was the only person at the meeting asking for it. I?d probably end up asking for two blocks - one for UniForum SA (The co.za administrators) and one for myself (Posix Systems). I just think it makes sense for UniForum SA to have a block. I know its not essential in order to stick IPV6 addresses into the co.za zone file - but I think its appropriate to offer IPV6 connectivity if we also have IPV6 addresses in the registry (Who knows what glorious checks we can devise (tounge-in-cheek)). Disclaimer - None of this implies that IPV6 in the co.za zone is in any form of planning - or indeed will ever happen. For myself... (Posix - an ISP) I have historical IPV4 address space - so to go and get an IPV4 address so I can get a (for now) free IPV6 seems stupid.. so some PI IPV6 for now seems sensible - and the allocated size is just right... and can one day become PA. I have some IPV6 - this machine shows... eth0 Link encap:Ethernet HWaddr 00:0E:0C:3E:99:CA inet addr:160.124.48.1 Bcast:160.124.48.255 Mask:255.255.255.0 inet6 addr: 3ffe:b00:4016:aaef:20e:cff:fe3e:99ca/64 Scope:Global inet6 addr: fe80::20e:cff:fe3e:99ca/64 Scope:Link ...but this is test space and about to become non-routable... so I need the replacement :-) (OK - purely selfish reasoning) ... but would help me get CO.ZA up and running... when I can bend the arms of some of the other directors. Speaking only for myself. (Try ping6 me !) > > > >> De: Andrew Alston >> Responder a: >> Fecha: Fri, 19 May 2006 11:28:28 +0200 >> Para: , AfriNIC Policy Working Group List >> >> Asunto: Re: [policy-wg] IPv6 PI policy >> >> Hi Jordi, >> >> I am not asking for a specific filter for each /48, I am suggesting that >> if the P.I space comes out of a single superblock (/30, /31, whatever >> the size of the superblock is that afrinic decides to allocate the P.I >> out of), that an exception be made singularly for the superblock to >> allow /48 routes from that superblock. >> >> Andrew >> >> >> JORDI PALET MARTINEZ wrote: >> >>> Hi Andrew, >>> >>> I disagree, anyway, is something that its up to each operator, and what is >>> sure is that they don't filter anything shorter than 32 ... >>> >>> Let me put an example that shows and <=32 works, others not. >>> >>> APNIC has its own infrastructure in two locations, and they decided to split >>> the /32 in 2x/33. From time to time, they become not reachable from >>> different locations. Some operators only accept the /32. >>> >>> How do you feel about that ? >>> >>> Let me insist that /32 is not a waste under the consideration of: 1) is an >>> alternative to allow the current allocation policy to be modified for those >>> that may sub-assign to the same organization (instead to others); 2) is >>> temporary. However the cost for a different prefix is very unpredictable in >>> terms of asking everyone to make a specific filter for each /48 (or /44) and >>> consequently is not a good solution because is going to be against the >>> proposal of the policy itself (becoming a barrier to the existing barrier >>> !). >>> >>> Regards, >>> Jordi >>> >>> >>> >>> >>> >>> >>>> De: Andrew Alston >>>> Responder a: >>>> Fecha: Fri, 19 May 2006 10:45:59 +0200 >>>> Para: , AfriNIC Policy Working Group List >>>> >>>> Asunto: Re: [policy-wg] IPv6 PI policy >>>> >>>> Hi Jordi/Frank >>>> >>>> I've been looking at this, and Jordi states that the current policy is >>>> to filter <= /32, I actually disagree with this. >>>> >>>> I've been looking around at various route servers, and checking various >>>> networks, as well as speaking to a *LOT* of network admins, currently >>>> the actual ACTIVE practice is to filter <= /48, I have yet to actually >>>> find anyone who is filtering on a <= /32 basis. While I'm sure they may >>>> exist, if they do they are in my opinion probably the vast minority. >>>> >>>> Again I reiterate, P.I space of /48 with an option for /44 upon serious >>>> motivation. >>>> >>>> Other than that, I support the policy >>>> >>>> Thanks >>>> >>>> Andrew Alston >>>> TENET - Chief Technical Officer >>>> >>>> >>>> JORDI PALET MARTINEZ wrote: >>>> >>>> >>>>> Hi Frank, all, >>>>> >>>>> See my reply below, in-line. >>>>> >>>>> Regards, >>>>> Jordi >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> De: Frank Habicht >>>>>> Responder a: AfriNIC Policy Working Group List >>>>>> Fecha: Thu, 18 May 2006 09:00:26 +0300 >>>>>> Para: >>>>>> Asunto: [policy-wg] IPv6 PI policy >>>>>> >>>>>> Hi all, >>>>>> >>>>>> sorry I didn't speak up in the meeting. >>>>>> Regarding Jordi's IPv6 PI policy proposal afpol-v60604. >>>>>> >>>>>> I was in the third group who didn't want to reject/defer/stall the >>>>>> policy but also not accept as it was. >>>>>> The only problem in my opinion is the question of size of the assigned >>>>>> blocks. >>>>>> >>>>>> Main concern of contributors like Uniforum was that the assigned PI >>>>>> blocks be routable in practise (which AfriNIC won't guarantee, but might >>>>>> "influence"). I trust that operators of ipv6 routers will make the >>>>>> necessary exception for the supernet from with PI blocks are assigned. >>>>>> That other RIRs do same supports this expectation but if possible I'd >>>>>> like to hear from the router operators. >>>>>> >>>>>> I would like to see a change to a smaller default assignment size to >>>>>> conserve address space. I would like to maintain the provision to use >>>>>> bigger blocks when justified. /48 as default should be fine. If filters >>>>>> of <48 are expected rather than <=48, then /44 might be a good option. >>>>>> >>>>>> >>>>>> >>>>> The actual practice is to filter <=32, so even /44 will not work. >>>>> >>>>> An alternative solution could be to understand that if we use /48 from a >>>>> special /32 block, then they may not be filtered (hopefully), but this only >>>>> works if an "allow" filter is placed on the complete /32. >>>>> >>>>> The disadvantage of that, is the malicious usage of other /48 within that >>>>> /32 which are still not allocated. This already happens with non-allocated >>>>> IPv4 space, for example being used for spam. I think this is bad in >>>>> general, >>>>> so a good reason for avoiding it. >>>>> >>>>> Another disadvantage is that using a /32 allows a non-issue transition >>>>> (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously >>>>> this is a very important advantage. May be I didn't stressed it enough >>>>> during the meeting. >>>>> >>>>> I really think the advantages of the /32 versus the "perceived" waste are >>>>> of >>>>> a much much much heavy way in the balance. Remember after all that this is >>>>> a >>>>> temporary policy, so we are not wasting space forever. >>>>> >>>>> As said in the meeting, the alternative will be to modify the existing PA >>>>> allocation to allow organizations to receive a PA prefix even if they don't >>>>> subassign to *other* organizations. In this case, is clear that they will >>>>> also get a /32. So what makes the difference ?. >>>>> >>>>> >>>>> >>>>> >>>>>> Since a rapid uptake of PI usage would or could increase the routing >>>>>> table size, and since I assume the fees attached to PI assignments will >>>>>> influence the number, those can be part of the discussion. I suggest >>>>>> fees should _not_ be waived. >>>>>> >>>>>> >>>>>> >>>>> I'm of the opinion that the fees should be waived only when the PA fees are >>>>> waived, but this may imply that there is some type of charge for having a >>>>> contractual relationship/membership with AfriNIC. I mean, right now LIRs >>>>> that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is >>>>> also true if a new LIR only needs IPv6 ? >>>>> >>>>> >>>>> >>>>> >>>>>> I would like to see the proposal succeed even if the above is not >>>>>> agreeable. As the numbers of hands in the meeting indicated, it is >>>>>> important to have this policy with or without change of assignment size. >>>>>> I hope we can use the 15 days last call period to find the best solution >>>>>> to the mentioned details. >>>>>> >>>>>> Regards, >>>>>> Frank >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> policy-wg mailing list >>>>>> policy-wg@afrinic.net >>>>>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>>>>> >>>>>> >>>>>> >>>>> ********************************************** >>>>> The IPv6 Portal: http://www.ipv6tf.org >>>>> >>>>> Barcelona 2005 Global IPv6 Summit >>>>> Slides available at: >>>>> http://www.ipv6-es.com >>>>> >>>>> This electronic message contains information which may be privileged or >>>>> confidential. The information is intended to be for the use of the >>>>> individual(s) named above. If you are not the intended recipient be aware >>>>> that any disclosure, copying, distribution or use of the contents of this >>>>> information, including attached files, is prohibited. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> policy-wg mailing list >>>>> policy-wg@afrinic.net >>>>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>>>> >>>>> >>>>> >>> >>> >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>> >>> Barcelona 2005 Global IPv6 Summit >>> Slides available at: >>> http://www.ipv6-es.com >>> >>> This electronic message contains information which may be privileged or >>> confidential. The information is intended to be for the use of the >>> individual(s) named above. If you are not the intended recipient be aware >>> that any disclosure, copying, distribution or use of the contents of this >>> information, including attached files, is prohibited. >>> >>> >>> >>> _______________________________________________ >>> policy-wg mailing list >>> policy-wg@afrinic.net >>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg >>> >>> > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg > -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 From geier-lists-afrinic-policywg at tih.co.tz Fri Jun 2 12:06:26 2006 From: geier-lists-afrinic-policywg at tih.co.tz (Frank Habicht) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure Message-ID: <44800DA2.6070505@tih.co.tz> Your Name: Frank Habicht Your Organisation: TIX / TZ ISP association (ORG-TISP1-AFRINIC) Policy Affected: afpol-v6200407-000 and/or afpol-v60604 Date: 02 / June / 2006 Proposal: IPv6 assignments for critical infrastructure Incentive: No IPv6 assignments for critical infrastructure specified yet. Can be incorporated in afpol-v6. Proposed policy for PI assignments of IPv6 address space does not cater for special case of critical infrastructure. 1.0 Definitions: Critical infrastructure includes Internet Exchange Points, ccTLD DNS servers and root DNS servers. The addition of more global root DNS servers is unlikely and all present servers are operated by entities from outside the AfriNIC area. For the purpose of this policy is is proposed to not distinguish between Root and ccTLD DNS servers. It is suggested that on request popular SLD operations can also qualify for critical infrastructur assignments. 2.0 Proposed policy: On request AfriNIC assigns IPv6 address ressource to [operators of] critical infrastructure. Internet Exchange Points, DNS root server operations, DNS ccTLD operations, and popular SLD DNS operations upon justification are considered critical infrastructure. The default assignment size for an Internet Exchange Point shall be a /48. Assignments can be larger blocks on request with justification. For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS with justification ) default assignment size is equal to the default assignment size for PI assignments of IPv6 address space to End Users [as defined in separate policy]. Operators of critical infrastructure can obtain ASN assignments from AfriNIC. They must be multihomed to do so. 3.0 Remarks IPv6 PI policy proposal (afpol-v60604) specifies temporary assignments and no special cases for critical infrastructure. From jordi.palet at consulintel.es Sun Jun 4 22:37:35 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] New policy proposal (modification to IPv6 Allocation Policy) Message-ID: Hi all, See below the proposed text, which has been sent also to other RIRs. Regards, Jordi AfriNIC Policy Proposal Policy Proposal Name: IPv6 Address Allocation and Assignment Policy Author: Jordi Palet Martinez - Consulintel Proposal Type: Modification Policy Term: Permanent Policy Document to be Affected: afpol-v6200407-000 Summary of Proposal: This policy modification is intended to provide a solution for the lengthy discussions that have taken place in the different regions regarding existing IPv6 Policies. It also takes account of the changes that have already taken place in other Regional Internet Registry (RIR) service regions. It is an alternative solution to the existing proposals around IPv6 Provider Independent (PI) assignments. Often, some organizations need to make internal assignments. Their networks may be made up of a number of sites that each has their own L2 infrastructure. In some cases, organisations may have a small number of sites, but still need their own block so that they can avoid future renumbering, if they change their upstream provider or identify a need to become Multihomed. One example might be a large university that has several campuses and faculties, each requiring IPv6 addresses. It may have one or several upstream providers. The university will most likely need to be able to assign IPv6 addresses from the same block to its sites and, at the same time, be able to use one or several upstreams. The university network behaves like an internal university ISP to each of the End Sites. Draft Policy Text: Existing section 5.1.1. (afpol-v6200407-000) 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an end site; c) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region. d) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months. Proposed replacement text: 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region. The organizations may be other organizations, but also own/related departments/entities/sites; c) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months. Other text to be deleted from afpol-v6200407-000: 5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having AfriNIC review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. Rationale: a. Arguments Supporting the Proposal There have been already clear examples and discussions in different regions about the need for this modification. The difficulty encountered in receiving IPv6 address space by some big entities that have a need to use IPv6 is a clear barrier for its deployment. b. Arguments Opposing the Proposal One possible effect of this proposal would be a growth of global routing tables. This is only to be expected when new allocations are made possible under this proposal. Acknowledgments: I would like to acknowledge all those who have contributed during many years, to the discussion of the modifications to the existing policy suggested by this proposal. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Sun Jun 4 22:55:48 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <44800DA2.6070505@tih.co.tz> Message-ID: Hi Frank, I just submitted a new proposal, which will avoid requiring neither this one or the PI one that I submitted previously. The main point is the inexistence of a definition for an end site in the region under the current IPv6 allocation policy, which is different that what we have in the rest of the regions. So what I'm proposing is to allow organizations that are "end-sites", but need to delegate to their own infrastructure or entities, to become an LIR and receive a /32. As the policies need to be approved in a face-to-face meeting, there is not any harm done having several proposals "competing" for the same goals being discussed, but I think we should reach a consensus in the list before next meeting about which one we want to support. By the way, I will also propose that we remove the requirement to wait for a face-to-face meeting for moving ahead with a policy if consensus is reached in the list. Nevertheless, I will support your policy if needed, but some modifications are suggested below. Regards, Jordi > De: Frank Habicht > Responder a: AfriNIC Policy Working Group List > Fecha: Fri, 02 Jun 2006 13:06:26 +0300 > Para: > Asunto: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure > > Your Name: Frank Habicht > Your Organisation: TIX / TZ ISP association (ORG-TISP1-AFRINIC) > Policy Affected: afpol-v6200407-000 and/or afpol-v60604 > Date: 02 / June / 2006 > > Proposal: IPv6 assignments for critical infrastructure > > Incentive: > No IPv6 assignments for critical infrastructure specified yet. Can be > incorporated in afpol-v6. > > Proposed policy for PI assignments of IPv6 address space does not cater > for special case of critical infrastructure. > > 1.0 Definitions: > > Critical infrastructure includes Internet Exchange Points, ccTLD DNS > servers and root DNS servers. The addition of more global root DNS > servers is unlikely and all present servers are operated by entities > from outside the AfriNIC area. For the purpose of this policy is is > proposed to not distinguish between Root and ccTLD DNS servers. It is > suggested that on request popular SLD operations can also qualify for > critical infrastructur assignments. You need to consider that sooner or later, you will get some root server mirrors deployed in the region, hopefully. Actually I will talk about root and TLDs in general. > > > 2.0 Proposed policy: > > On request AfriNIC assigns IPv6 address ressource to [operators of] > critical infrastructure. Internet Exchange Points, DNS root server > operations, DNS ccTLD operations, and popular SLD DNS operations upon > justification are considered critical infrastructure. Remove "popular ...", just say "DNS TLDs" of any kind. > > The default assignment size for an Internet Exchange Point shall be a > /48. Assignments can be larger blocks on request with justification. For > critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS with > justification ) default assignment size is equal to the default > assignment size for PI assignments of IPv6 address space to End Users > [as defined in separate policy]. I will suggest not relating both proposals, and instead using /32 by default. This is the case for critical infrastructures in APNIC and LACNIC (in LACNIC there is a small difference for IX with usually get allocated a /48, but they aren't routed, I think that's wrong and we should not go that way here). RIPE NCC also uses /32 for root servers, but /64 or /48 for IX (again, assuming they aren't announced). ARIN uses /48 for micro-allocations. > > Operators of critical infrastructure can obtain ASN assignments from > AfriNIC. They must be multihomed to do so. I don't think asking to be multihomed is a good thing in the region. Cost is high, and may be the SLA allows them to have a single ISP with a sufficient enough reliability level vs. cost. > > > 3.0 Remarks > > IPv6 PI policy proposal (afpol-v60604) specifies temporary assignments > and no special cases for critical infrastructure. > > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From meeting at afrinic.net Thu Jun 15 09:49:17 2006 From: meeting at afrinic.net (AfriNIC Meeting team) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Outcome of AfriNIC-4 meeting Message-ID: <7.0.1.0.2.20060615114152.05166bb8@afrinic.net> Dear Colleagues, AfriNIC had its 4th Open Policy Meeting and the 3rd Annual General Member meeting from 16th to 17th May 2006. The report of both events is now available on the AfriNIC web site at: http://www.afrinic.net/meeting/afrinic-4/afrinic-4-minutes.htm The adopted budget for 2006 and the annual activity report approved during the AGM are also respectively available at: http://www.afrinic.net/corporate/Budget-2006.htm http://www.afrinic.net/corporate/2005_Report.pdf The next open policy and Member Meeting is scheduled from November 27th to December 1st in Mauritius. During the event, you will have the opportunity to visit the AfriNIC Headquarter Offices located in the Cybercity. Hope to see you all Mauritius for AfriNIC-5. Sincerely. Adiel A. Akplogan CEO AfriNIC Ltd. From frank at afrinic.net Wed Jun 28 15:27:49 2006 From: frank at afrinic.net (Frank) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Changes to the AfriNIC WHOIS Server Message-ID: <000601c69ab6$a6dc5220$0503d8c4@fnnebenb1> Changes to AfriNIC WHOIS Server 1) Email Filtering By default the AfriNIC WHOIS Server filters out attributes that contain email addresses to limit abuse. To get the original output, users can turn this off by using the -B flag when querying for an object. This is done for you automatically when querying the WHOIS server from our web client (http://whois.afrinic.net) 2) Deprecated "Trouble" Attribute The trouble attribute in the role object has been deprecated. Please use the remarks attribute for providing information on "trouble" issues. Thanks. Frank Nnebe AfriNIC Ltd. Phone: +27 012 841 4468 Email: frank@afrinic.net From bortzmeyer at nic.fr Wed Jun 28 16:49:04 2006 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Re: Changes to the AfriNIC WHOIS Server In-Reply-To: <000601c69ab6$a6dc5220$0503d8c4@fnnebenb1> References: <000601c69ab6$a6dc5220$0503d8c4@fnnebenb1> Message-ID: <20060628144904.GA2575@nic.fr> On Wed, Jun 28, 2006 at 03:27:49PM +0200, Frank wrote a message of 34 lines which said: > By default the AfriNIC WHOIS Server filters out attributes that > contain email addresses to limit abuse. Starting from when? % whois -h whois.afrinic.net 213.136.106.214 % This is the AfriNIC Whois server. % Note: this output has been filtered. % Information related to '213.136.106.0 - 213.136.106.255' inetnum: 213.136.106.0 - 213.136.106.255 ... person: CHRISTOPHE JELEN address: CI2M address: Avenue Houdaille address: Bp 310 cedex 01 Abidjan address: Ivoiry Coast phone: +225 20 30 09 71 e-mail: cjelen@aviso.ci From frank at afrinic.net Thu Jun 29 09:58:26 2006 From: frank at afrinic.net (Frank) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] RE: Changes to the AfriNIC WHOIS Server In-Reply-To: <20060628144904.GA2575@nic.fr> Message-ID: <000601c69b51$cda92b30$0503d8c4@fnnebenb1> Hi Stephen, It does not filter out the e-mail attribute but any other attributes that contain e-mail attributes such as changed lines. For example using the object you queried: FILTERED OUTPUT: inetnum: 213.136.106.0 - 213.136.106.255 netname: AVISONET descr: ISP Cote d'Ivoire country: CI admin-c: CJ1-AFRINIC tech-c: AE496-AFRINIC status: ASSIGNED PA mnt-by: CIT-DT mnt-lower: CIT-DT source: AFRINIC # Filtered parent: 213.136.96.0 - 213.136.127.255 NOT FILTERED OUTPUT: inetnum: 213.136.106.0 - 213.136.106.255 netname: AVISONET descr: ISP Cote d'Ivoire country: CI admin-c: CJ1-AFRINIC tech-c: AE496-AFRINIC status: ASSIGNED PA notify: eambeu@citelecom.ci mnt-by: CIT-DT mnt-lower: CIT-DT changed: manouan.aka@citelecom.ci 20060626 source: AFRINIC parent: 213.136.96.0 - 213.136.127.255 Hope this helps. Thanks. Frank. -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Wednesday, June 28, 2006 04:49 PM To: frank@afrinic.net; AfriNIC Policy Working Group List Cc: afrinic-discuss@afrinic.net Subject: Re: Changes to the AfriNIC WHOIS Server On Wed, Jun 28, 2006 at 03:27:49PM +0200, Frank wrote a message of 34 lines which said: > By default the AfriNIC WHOIS Server filters out attributes that > contain email addresses to limit abuse. Starting from when? % whois -h whois.afrinic.net 213.136.106.214 % This is the AfriNIC Whois server. % Note: this output has been filtered. % Information related to '213.136.106.0 - 213.136.106.255' inetnum: 213.136.106.0 - 213.136.106.255 ... person: CHRISTOPHE JELEN address: CI2M address: Avenue Houdaille address: Bp 310 cedex 01 Abidjan address: Ivoiry Coast phone: +225 20 30 09 71 e-mail: cjelen@aviso.ci From aalain at trstech.net Tue Jul 11 16:32:06 2006 From: aalain at trstech.net (AINA ALAIN PATRICK(TRS)) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] IPv6 PI policy proposal Message-ID: <200607111432.06737.aalain@trstech.net> hi, Can someone (jordi or others) explains to me what why should RIPE NCC actual IPV4 policy applied for AfriNIC region in the IPv6 IP assignement ? "to qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy" --alain From jordi.palet at consulintel.es Tue Jul 11 16:44:12 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] IPv6 PI policy proposal In-Reply-To: <200607111432.06737.aalain@trstech.net> Message-ID: Hi Alain, Is a typo, replace RIPE NCC with AfriNIC and you're done. This happened in the policy because the text was taken from my proposal to RIPE NCC and we didn't reviewed accurately all the text. Regards, Jordi > De: "AINA ALAIN PATRICK(TRS)" > Organizaci?n: www.trstech.net > Responder a: , AfriNIC Policy Working Group List > > Fecha: Tue, 11 Jul 2006 14:32:06 +0000 > Para: > Asunto: [policy-wg] IPv6 PI policy proposal > > hi, > > Can someone (jordi or others) explains to me what why should RIPE NCC actual > IPV4 policy applied for AfriNIC region in the IPv6 IP assignement ? > > > "to qualify for a direct assignment, the organization must not be an IPv6 LIR > and must qualify for an IPv4 assignment or allocation from RIPE NCC under the > actual IPv4 policy" > > > > --alain > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From frank at afrinic.net Wed Jul 19 11:58:30 2006 From: frank at afrinic.net (Frank) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] MyAfriNIC Demo Message-ID: <009401c6ab19$e3d29a40$0503d8c4@fnnebenb1> MyAfriNIC is a new web-based user-friendly portal AfriNIC is developing to provide all members with the ability to manage your membership information, your billing history, view and request new IPv4, IPv6 and AS resources, as well as track the status of your requests for AfriNIC support. We have set up a demo of the MyAfriNIC portal at: http://my.afrinic.net for your feedback. You can sign into it as follows: E-mail: demo@afrinic.net Password: demouser Please send us your comments, suggestions at: myafrinic-comments@afrinic.net Thanks. Frank Nnebe AfriNIC Ltd. Email:frank@afrinic.net From eric at afrispa.org Wed Jul 19 10:55:26 2006 From: eric at afrispa.org (Eric Osiakwan) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Re: [afrinic-discuss] MyAfriNIC Demo In-Reply-To: <009401c6ab19$e3d29a40$0503d8c4@fnnebenb1> References: <009401c6ab19$e3d29a40$0503d8c4@fnnebenb1> Message-ID: Thanks Frank and congratulations to AfriNIC Eric here On 19 Jul 2006, at 12:58, Frank wrote: > > MyAfriNIC is a new web-based user-friendly portal AfriNIC is > developing to > provide all members with the ability to manage your membership > information, > your billing history, view and request new IPv4, IPv6 and AS > resources, as > well as track the status of your requests for AfriNIC support. > > We have set up a demo of the MyAfriNIC portal at: http:// > my.afrinic.net for > your feedback. > > You can sign into it as follows: > > E-mail: demo@afrinic.net > Password: demouser > > Please send us your comments, suggestions at: myafrinic- > comments@afrinic.net > > Thanks. > > Frank Nnebe > AfriNIC Ltd. > Email:frank@afrinic.net > > _______________________________________________ > afrinic-discuss mailing list > afrinic-discuss@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/afrinic-discuss > Eric M.K Osiakwan Executive Secretary AfrISPA (www.afrispa.org) Tel: + 233.21.258800 Fax: + 233.21.258811 Cell: + 233.244.386792 Handle: eosiakwan Snail Mail: Pmb 208, Accra-North Office: BusyInternet - 42 Ring Road Central, Accra-North Blog: http://afrispa.skybuilders.com/users/Eric/blog.html Slang: "Tomorrow Now" From aalain at trstech.net Wed Jul 19 15:41:26 2006 From: aalain at trstech.net (AINA ALAIN PATRICK(TRS)) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Re: [afripv6-discuss] MyAfriNIC Demo In-Reply-To: <009401c6ab19$e3d29a40$0503d8c4@fnnebenb1> References: <009401c6ab19$e3d29a40$0503d8c4@fnnebenb1> Message-ID: <200607191341.27118.aalain@trstech.net> > MyAfriNIC is a new web-based user-friendly portal AfriNIC is developing to > provide all members with the ability to manage your membership information, > your billing history, view and request new IPv4, IPv6 and AS resources, as > well as track the status of your requests for AfriNIC support. congrats frank. just one public question. On MyAfriNIC i see the following Upcoming Events AfriNIC-5 23 - 27 Oct, 2006 Grand Baie, Mauritius is there a change on afrinic-5 dates ? --alain From ibyaruhanga at nssfug.org Fri Jul 21 11:11:39 2006 From: ibyaruhanga at nssfug.org (Immy Byaruhanga) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Mwirima, Oragambaki Message-ID: <6ADE7B2FDDD08E4C8637A0C68F1E477803CD4D@dc3.nssfug.org> Hi, Mwana wa tata Oragamabaki ? This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify National Social Security Fund (NSSF) Information Systems Department on the email administrator@nssfug.org. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.afrinic.net/pipermail/policy-wg/attachments/20060721/9e509b76/attachment.htm From adiel at afrinic.net Tue Aug 8 08:32:15 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] IGF registration is open Message-ID: <7.0.1.0.2.20060808102955.0287d6f0@afrinic.net> Dear colleagues, The online registration for the Internet Governance Forum (IGF) in Athens is now open at http://www.intgovforum.org/register/index.php. The meeting is open to any interested party and there is no special accreditation to participate to the meeting. Note that you need to register first in order to benefit from the preferential hotel rates offered to the IGF Meeting participants (you will need your registration code in order to complete your Hotel booking process). Hotel bookings must be made directly from the event local web site: https://www.igfgreece2006.gr As you can also see in the meeting Programme outline (http://www.intgovforum.org/athens_outline.htm), there will be workshops focused on specific issues relevant to the Athens meeting themes as well as other topics of relevance to Internet Governance. The form for workshop proposals is also online and the deadline for submissions is 24th August 2006. If you are interested in organizing one of these specific workshops, go to http://www.intgovforum.org/workshops/instructions.php Kind regards. Adiel A. Akplogan CEO, AfriNIC www.afrinic.net =============== See you at AfriNIC-5 in Mauritius 27 November - 01 December From adiel at afrinic.net Tue Sep 12 09:22:10 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] ICANN Announcement: Global IPv6 policy Message-ID: <7.0.1.0.2.20060912104644.05fd0480@afrinic.net> FYI ICANN ratifies Global Policy for Allocation of IPv6 addressees: http://www.icann.org/announcements/announcement-11sep06.htm _______________________________________________________________________ Adiel A. AKPLOGAN Tel. +230 466 66 16 CEO, AfriNIC Ltd. Fax: +230 466 67 58 adiel@afrinic.net www.afrinic.net From meeting at afrinic.net Tue Sep 12 17:37:37 2006 From: meeting at afrinic.net (AfriNIC - http://www.afrinic.net) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC-5: Call for Presentations and Tutorials Message-ID: <4506D441.1000309@afrinic.net> - apologies for cross-posting - Dear Colleagues, The next AfriNIC Public Policy Meeting will be held in Mauritius from 02 - 03 December 2006. It is an open forum to discuss issues related to internet number resource management within the AfriNIC service region. This meeting will also host a regional IPv6 conference where network operators will share their experiences on IPv6 deployment. We are looking for presentations and tutorials of relevance from anyone. Tutorials are usually 2 to 4 hour workshops, while presentations may last between 10 and 30 minutes. Presentations / Tutorials may cover the following topics: - IPv6 deployment - Routing Best Practice/Address Space Prefix Filtering - Reverse DNS implemenation - DNSec - Fighting Spam We would like to have as many practical, hands-on presentations as possible and they do not have to be long. Policy proposals are also usually discussed at the meeting, but must pass through the appropriate phases of the Policy Development Process (please see http://www.afrinic.net/pdp.htm). If you would like to make a presentation or tutorial, please send your proposal to meeting@afrinic.net Your proposal should contain the following information: - Full Name - Email Address - Affiliation - Short biography - Title of Talk - A detailed abstract or outline describing the presentation - Draft slides for the presentation (if ready/available) - Length of talk (minutes/hours/days) - Need (or not) for sponsorship or assistance to attend the meeting (travel and/or accommodation, etc) The audience at AfriNIC meetings is mainly composed of technical network operators and engineers with a wide range of experience levels from beginners to several years of experience. Presentations that contain any sort of marketing and commercial content are usually not encouraged at such meetings. Kind regards, AfriNIC www.afrinic.net From meeting at afrinic.net Thu Sep 14 10:26:00 2006 From: meeting at afrinic.net (AfriNIC - http://www.afrinic.net) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Re: [afrinic-discuss] AfriNIC-5: Call for Presentations and Tutorials In-Reply-To: <4506D441.1000309@afrinic.net> References: <4506D441.1000309@afrinic.net> Message-ID: <45091218.5060105@afrinic.net> Dear Colleagues, Please take note of the following correction: The next AfriNIC Public Policy Meeting will be held in Mauritius from 27th November - 01st December 2006. ( *not* 02-03 Dec 2006) regards, Ernest, AfriNIC. AfriNIC - http://www.afrinic.net wrote the following on 09/12/2006 05:37 PM: > - apologies for cross-posting - > > > Dear Colleagues, > > The next AfriNIC Public Policy Meeting will be held in Mauritius from > 02 - 03 December 2006. It is an open forum to discuss issues related > to internet number resource management within the AfriNIC service > region. This meeting will also host a regional IPv6 conference where > network operators will share their experiences on IPv6 deployment. > > We are looking for presentations and tutorials of relevance from > anyone. Tutorials are usually 2 to 4 hour workshops, while > presentations may > last between 10 and 30 minutes. > > Presentations / Tutorials may cover the following topics: > > - IPv6 deployment > - Routing Best Practice/Address Space Prefix Filtering > - Reverse DNS implemenation > - DNSec > - Fighting Spam > > We would like to have as many practical, hands-on presentations > as possible and they do not have to be long. > > Policy proposals are also usually discussed at the meeting, > but must pass through the appropriate phases of the Policy Development > Process (please see http://www.afrinic.net/pdp.htm). > > If you would like to make a presentation or tutorial, please send your > proposal to meeting@afrinic.net > > Your proposal should contain the following information: > > - Full Name > - Email Address > - Affiliation > - Short biography > - Title of Talk > - A detailed abstract or outline describing the presentation > - Draft slides for the presentation (if ready/available) > - Length of talk (minutes/hours/days) > - Need (or not) for sponsorship or assistance to attend the > meeting (travel and/or accommodation, etc) > > The audience at AfriNIC meetings is mainly composed of technical > network operators and engineers with a wide range of experience levels > from beginners to several years of experience. > > Presentations that contain any sort of marketing and commercial > content are usually not encouraged at such meetings. > > Kind regards, > > AfriNIC > www.afrinic.net > _______________________________________________ > afrinic-discuss mailing list > afrinic-discuss@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/afrinic-discuss From vincent at kenic.or.ke Thu Sep 28 10:37:01 2006 From: vincent at kenic.or.ke (Vincent Ngundi) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure Message-ID: <200609281137.04843.vincent@kenic.or.ke> Hi All, * I agree with Jordi, exceptions should be made to organisations that run critical services like TLD root servers (ccTLD managers for instance). These organisations require a PI address space as this will enable them to have more control over the address space they use. * Policy ratification should be done online. A system of determining whether a majority of the community is in agreement should be established. Face-to-face ratification has it's own drawbacks. For instance, if current policy bars an organisation from getting Internet resources to perform certain crucial tests and/or tasks or to provide critical Internet services, then that organisation deserves to have a mechanism at their disposal through which they can propose policies that can be ratfied within a reasonable period (reasonable in that the period can even be included in a Project Plan if need be). * The idea is NOT to ease the process of assigning Internet resources, but to reduce the effort in implementing Internet services and technologies. Rigid policy formulation structures may contribute to the slow implementation/deployment of new Internet technologies. * I also propose that these prefixes be assigned on a temporary basis (with a defined testing period) but with the option of retaining them based on some defined RIR criteria. Regards, Vincent Ngundi KeNIC (.KE Registry) - (ORG-KNIC1-AFRINIC) -- $ whois -h whois.afrinic.net VIN1-AfriNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 479 bytes Desc: not available Url : https://lists.afrinic.net/pipermail/policy-wg/attachments/20060928/59fb49d4/attachment.bin From aalain at trstech.net Tue Oct 3 11:31:31 2006 From: aalain at trstech.net (AINA ALAIN PATRICK(TRS)) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <200609281137.04843.vincent@kenic.or.ke> References: <200609281137.04843.vincent@kenic.or.ke> Message-ID: <200610030931.32100.aalain@trstech.net> > * Policy ratification should be done online. A system of determining > whether a majority of the community is in agreement should be established. > Face-to-face ratification has it's own drawbacks. online too has. According to the curent PDP: online, face-to-face and online discussions are used to get the needed consensus before getting a policy ractified by the board. > For instance, if current > policy bars an organisation from getting Internet resources to perform > certain crucial tests and/or tasks or to provide critical Internet > services, then that organisation deserves to have a mechanism at their > disposal through which they can propose policies that can be ratfied within > a reasonable period (reasonable in that the period can even be included in > a Project Plan if need be). Are you concerned about the delay due to obtain a public meeting ? or calling for a PDP for emergency ? --alain From vincent at kenic.or.ke Tue Oct 3 15:35:49 2006 From: vincent at kenic.or.ke (Vincent Ngundi) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <200610030931.32100.aalain@trstech.net> References: <200609281137.04843.vincent@kenic.or.ke> <200610030931.32100.aalain@trstech.net> Message-ID: <200610031635.52877.vincent@kenic.or.ke> On Tue October 3 2006 12:31, AINA ALAIN PATRICK(TRS) wrote: > According to the curent PDP: online, face-to-face and online discussions > are used to get the needed consensus before getting a policy ractified by > the board. > I agree, but the actual ratification or adoption of the policy must be done during a face-to-face board meeting.....can't this be done online? Am I wrong about the actual ratification process? > > Are you concerned about the delay due to obtain a public meeting ? or > calling for a PDP for emergency ? > I'm concerned about the delay due to convening a public meeting. Regards, -Vincent -- $ whois -h whois.afrinic.net VIN1-AfriNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 479 bytes Desc: not available Url : https://lists.afrinic.net/pipermail/policy-wg/attachments/20061003/f4326f94/attachment.bin From michuki at swiftkenya.com Tue Oct 3 15:57:27 2006 From: michuki at swiftkenya.com (Michuki Mwangi) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <200610031635.52877.vincent@kenic.or.ke> References: <200609281137.04843.vincent@kenic.or.ke> <200610030931.32100.aalain@trstech.net> <200610031635.52877.vincent@kenic.or.ke> Message-ID: <45226C47.8010401@swiftkenya.com> Vincent Ngundi wrote: >> Are you concerned about the delay due to obtain a public meeting ? or >> calling for a PDP for emergency ? >> > > I'm concerned about the delay due to convening a public meeting. Probably worth finding out is how often the board meets. From adiel at akplogan.com Wed Oct 4 12:04:12 2006 From: adiel at akplogan.com (Adiel A. Akplogan) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <200610031635.52877.vincent@kenic.or.ke> References: <200609281137.04843.vincent@kenic.or.ke> <200610030931.32100.aalain@trstech.net> <200610031635.52877.vincent@kenic.or.ke> Message-ID: <7.0.1.0.2.20061004134929.03ccefd8@akplogan.com> Hello, >On Tue October 3 2006 12:31, AINA ALAIN PATRICK(TRS) wrote: > > According to the curent PDP: online, face-to-face and online discussions > > are used to get the needed consensus before getting a policy ractified by > > the board. > > > >I agree, but the actual ratification or adoption of the policy must be done >during a face-to-face board meeting.....can't this be done online? > >Am I wrong about the actual ratification process? Just a clarification here: The board ratify policy only after consensus is reached not only during the face 2 face meeting but also in online discussions. To precisely answer your question/concern, the board ratify a policy during its meeting, not only face to face one but also during teleconferences. So no need to wait next meeting for the board to meet to get a policy ratified if consensus is reached. > > Are you concerned about the delay due to obtain a public meeting ? or > > calling for a PDP for emergency ? > > > >I'm concerned about the delay due to convening a public meeting. We will be happy to have input from the community here, but if we take in account the very low participation to policy discussions online ... it may not be a good idea to only make decision based on online discussions. People seems to be more open to speak at a meeting than writing an e-mail. Thanks. Adiel. From adiel at afrinic.net Wed Oct 4 12:20:58 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure Message-ID: <7.0.1.0.2.20061004142053.03e63a30@akplogan.com> Hello, >On Tue October 3 2006 12:31, AINA ALAIN PATRICK(TRS) wrote: > > According to the curent PDP: online, face-to-face and online discussions > > are used to get the needed consensus before getting a policy ractified by > > the board. > > > >I agree, but the actual ratification or adoption of the policy must be done >during a face-to-face board meeting.....can't this be done online? > >Am I wrong about the actual ratification process? Just a clarification here: The board ratify policy only after consensus is reached not only during the face 2 face meeting but also in online discussions. To precisely answer your question/concern, the board ratify a policy during its meeting, not only face to face one but also during teleconferences. So no need to wait next meeting for the board to meet to get a policy ratified if consensus is reached. > > Are you concerned about the delay due to obtain a public meeting ? or > > calling for a PDP for emergency ? > > > >I'm concerned about the delay due to convening a public meeting. We will be happy to have input from the community here, but if we take in account the very low participation to policy discussions online ... it may not be a good idea to only make decision based on online discussions. People seems to be more open to speak at a meeting than writing an e-mail. Thanks. Adiel. From vincent at kenic.or.ke Wed Oct 4 12:47:07 2006 From: vincent at kenic.or.ke (Vincent Ngundi) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <7.0.1.0.2.20061004134929.03ccefd8@akplogan.com> References: <200609281137.04843.vincent@kenic.or.ke> <200610031635.52877.vincent@kenic.or.ke> <7.0.1.0.2.20061004134929.03ccefd8@akplogan.com> Message-ID: <200610041347.12264.vincent@kenic.or.ke> Hi Adiel, > To precisely answer your question/concern, the board ratify a > policy during its meeting, not only face to face one but also > during teleconferences. So no need to wait next meeting for > the board to meet to get a policy ratified if consensus is > reached. > Thanks for the clarification on this. > We will be happy to have input from the community here, but if > we take in account the very low participation to policy discussions > online ... it may not be a good idea to only make decision based on > online discussions. People seems to be more open to speak at a meeting > than writing an e-mail. > My initial suggestion was that if a majority of the community was in agreement with the proposal (via online discussions if I may add), then the board should go ahead and ratify it. IMHO, it's a possible scenario. Regards, -Vincent -- $ whois -h whois.afrinic.net VIN1-AfriNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 479 bytes Desc: not available Url : https://lists.afrinic.net/pipermail/policy-wg/attachments/20061004/7329bbcf/attachment.bin From aalain at trstech.net Fri Oct 6 12:36:11 2006 From: aalain at trstech.net (AINA ALAIN PATRICK(TRS)) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <7.0.1.0.2.20061004134929.03ccefd8@akplogan.com> References: <200609281137.04843.vincent@kenic.or.ke> <200610031635.52877.vincent@kenic.or.ke> <7.0.1.0.2.20061004134929.03ccefd8@akplogan.com> Message-ID: <200610061036.12009.aalain@trstech.net> > >I'm concerned about the delay due to convening a public meeting. > > We will be happy to have input from the community here, but if > we take in account the very low participation to policy discussions > online ... it may not be a good idea to only make decision based on > online discussions. People seems to be more open to speak at a meeting > than writing an e-mail. Taking that we have only two meetings a year, the max latency to a public face-to-face meeting after the 30 days of online discussions is 7 months. To this we have to add one month (15 days for the last call) and 15 days to get it ractified (my estimation). So in the worse case, we have 8 months to get a new policy. And yes, this may seem high in case of new technologies like IPv6. -alain -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.afrinic.net/pipermail/policy-wg/attachments/20061006/da229075/attachment.htm From mje at posix.co.za Mon Oct 9 17:32:34 2006 From: mje at posix.co.za (Mark J Elkins) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <200609281137.04843.vincent@kenic.or.ke> References: <200609281137.04843.vincent@kenic.or.ke> Message-ID: <452A6B92.4030804@posix.co.za> Vincent Ngundi wrote: > Hi All, > > * I agree with Jordi, exceptions should be made to organisations that run > critical services like TLD root servers (ccTLD managers for instance). These > organisations require a PI address space as this will enable them to have > more control over the address space they use. > > * Policy ratification should be done online. A system of determining whether a > majority of the community is in agreement should be established. Face-to-face > ratification has it's own drawbacks. For instance, if current policy bars an > organisation from getting Internet resources to perform certain crucial tests > and/or tasks or to provide critical Internet services, then that organisation > deserves to have a mechanism at their disposal through which they can propose > policies that can be ratfied within a reasonable period (reasonable in that > the period can even be included in a Project Plan if need be). > > * The idea is NOT to ease the process of assigning Internet resources, but to > reduce the effort in implementing Internet services and technologies. Rigid > policy formulation structures may contribute to the slow > implementation/deployment of new Internet technologies. > > * I also propose that these prefixes be assigned on a temporary basis (with a > defined testing period) but with the option of retaining them based on some > defined RIR criteria. > Do we have consensus about providing PI to critical infrastructure yet? I'll be at the meeting in Mauritius. That meeting seems to have great focus on IPV6. (Which is Great!!!) I want to potentially apply for some private IPV6 numbering for UniForum S.A. - the "co.za" registry system. The COZA system peers with multiple ISP's at JINX and uses multiple people for Transit - so can not afford to be locked to a single provider and would prefer to have its own allocation. Its the largest domain registry in the AfriNIC region (almost 270000 domains). Part of the validation for a new domain is that each nameserver is queried to check that all nameservers are authoritative - so until there is native IPV6 - we can't register any domain that contains a nameserver that maps to an IPV6 address. UniForum SA currently has 206.223.136/24 - which was allocated out of a pool for critical resources. We now directly pay AfriNIC yearly for this address space. -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 From jordi.palet at consulintel.es Mon Oct 9 18:44:34 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <452A6B92.4030804@posix.co.za> Message-ID: Hi all, Talking about the policy development process in the region in general, as I feel that we should try to be *ALL* more "visible" if we want the thing moving on. I think that it will be useful to hear many more people in the list telling "yes I like (or I don't like) this or that policy". Even if you don't have a clear view about a given policy, but you don't oppose to it, saying so will help. This is a must for the open policy development process. The participation in meetings is important, but never a must. The policy chair and board should judge the consensus based on *MANY* folks in the list, not just a dozen of us. Regards, Jordi > De: Mark J Elkins > Organizaci?n: Posix Systems > Responder a: AfriNIC Policy Working Group List > Fecha: Mon, 09 Oct 2006 17:32:34 +0200 > Para: AfriNIC Policy Working Group List > Asunto: Re: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure > > Vincent Ngundi wrote: >> Hi All, >> >> * I agree with Jordi, exceptions should be made to organisations that run >> critical services like TLD root servers (ccTLD managers for instance). These >> organisations require a PI address space as this will enable them to have >> more control over the address space they use. >> >> * Policy ratification should be done online. A system of determining whether >> a >> majority of the community is in agreement should be established. Face-to-face >> ratification has it's own drawbacks. For instance, if current policy bars an >> organisation from getting Internet resources to perform certain crucial tests >> and/or tasks or to provide critical Internet services, then that organisation >> deserves to have a mechanism at their disposal through which they can propose >> policies that can be ratfied within a reasonable period (reasonable in that >> the period can even be included in a Project Plan if need be). >> >> * The idea is NOT to ease the process of assigning Internet resources, but to >> reduce the effort in implementing Internet services and technologies. Rigid >> policy formulation structures may contribute to the slow >> implementation/deployment of new Internet technologies. >> >> * I also propose that these prefixes be assigned on a temporary basis (with a >> defined testing period) but with the option of retaining them based on some >> defined RIR criteria. >> > Do we have consensus about providing PI to critical infrastructure yet? > I'll be at the meeting in Mauritius. That meeting seems to have great > focus on IPV6. > (Which is Great!!!) > > I want to potentially apply for some private IPV6 numbering for UniForum > S.A. - the "co.za" registry system. The COZA system peers with multiple > ISP's at JINX and uses multiple people for Transit - so can not afford > to be locked to a single provider and would prefer to have its own > allocation. Its the largest domain registry in the AfriNIC region > (almost 270000 domains). Part of the validation for a new domain is that > each nameserver is queried to check that all nameservers are > authoritative - so until there is native IPV6 - we can't register any > domain that contains a nameserver that maps to an IPV6 address. > > UniForum SA currently has 206.223.136/24 - which was allocated out of a > pool for critical resources. We now directly pay AfriNIC yearly for this > address space. > > -- > . . ___. .__ Posix Systems - Sth Africa > /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO ACE, Cisco > CCIE > / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From alan at futureperfect.co.za Mon Oct 9 19:55:41 2006 From: alan at futureperfect.co.za (Alan Levin) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: References: Message-ID: <039E04AE-EC20-47A4-9DC0-F31A63111129@futureperfect.co.za> Hi, On 09 Oct 2006, at 6:44 PM, JORDI PALET MARTINEZ wrote: > I think that it will be useful to hear many more people in the list > telling > "yes I like (or I don't like) this or that policy". Even if you > don't have a > clear view about a given policy, but you don't oppose to it, saying > so will > help. Yes, I like :) Sorry I will not see you in Mauritius, amongst other things I have another young one on the way. warm regards, Alan > > >> De: Mark J Elkins >> Organizaci?n: Posix Systems >> Responder a: AfriNIC Policy Working Group List > wg@afrinic.net> >> Fecha: Mon, 09 Oct 2006 17:32:34 +0200 >> Para: AfriNIC Policy Working Group List >> Asunto: Re: [policy-wg] AfriNIC policy: IPv6 for critical >> infrastructure >> >> Vincent Ngundi wrote: >>> Hi All, >>> >>> * I agree with Jordi, exceptions should be made to organisations >>> that run >>> critical services like TLD root servers (ccTLD managers for >>> instance). These >>> organisations require a PI address space as this will enable them >>> to have >>> more control over the address space they use. >>> >>> * Policy ratification should be done online. A system of >>> determining whether >>> a >>> majority of the community is in agreement should be established. >>> Face-to-face >>> ratification has it's own drawbacks. For instance, if current >>> policy bars an >>> organisation from getting Internet resources to perform certain >>> crucial tests >>> and/or tasks or to provide critical Internet services, then that >>> organisation >>> deserves to have a mechanism at their disposal through which they >>> can propose >>> policies that can be ratfied within a reasonable period >>> (reasonable in that >>> the period can even be included in a Project Plan if need be). >>> >>> * The idea is NOT to ease the process of assigning Internet >>> resources, but to >>> reduce the effort in implementing Internet services and >>> technologies. Rigid >>> policy formulation structures may contribute to the slow >>> implementation/deployment of new Internet technologies. >>> >>> * I also propose that these prefixes be assigned on a temporary >>> basis (with a >>> defined testing period) but with the option of retaining them >>> based on some >>> defined RIR criteria. >>> >> Do we have consensus about providing PI to critical infrastructure >> yet? >> I'll be at the meeting in Mauritius. That meeting seems to have great >> focus on IPV6. >> (Which is Great!!!) >> >> I want to potentially apply for some private IPV6 numbering for >> UniForum >> S.A. - the "co.za" registry system. The COZA system peers with >> multiple >> ISP's at JINX and uses multiple people for Transit - so can not >> afford >> to be locked to a single provider and would prefer to have its own >> allocation. Its the largest domain registry in the AfriNIC region >> (almost 270000 domains). Part of the validation for a new domain >> is that >> each nameserver is queried to check that all nameservers are >> authoritative - so until there is native IPV6 - we can't register any >> domain that contains a nameserver that maps to an IPV6 address. >> >> UniForum SA currently has 206.223.136/24 - which was allocated out >> of a >> pool for critical resources. We now directly pay AfriNIC yearly >> for this >> address space. >> >> -- >> . . ___. .__ Posix Systems - Sth Africa >> /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO >> ACE, Cisco >> CCIE >> / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 >> >> _______________________________________________ >> policy-wg mailing list >> policy-wg@afrinic.net >> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the use of the individual(s) named above. If you are not the > intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, including > attached files, is prohibited. > > > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg > --------------------------------------------- Alan Levin Tel: +27 21 409-7997 From apb at cequrux.com Sat Oct 14 15:53:20 2006 From: apb at cequrux.com (Alan Barrett) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: References: <452A6B92.4030804@posix.co.za> Message-ID: <20061014135320.GD6888@apb-laptoy.apb.alt.za> On Mon, 09 Oct 2006, JORDI PALET MARTINEZ wrote: > I think that it will be useful to hear many more people in the list > telling "yes I like (or I don't like) this or that policy". Even if > you don't have a clear view about a given policy, but you don't oppose > to it, saying so will help. I like the policy except for one thing: I think that a /32 is outrageously larger than people seeking space under this proposal are likely to need, and I would like to see it changed to a /48 from a reserved /40 block, to allow easy growth if it turns out to be necessary, and to allow reclamation of the unused parts of the /40 block in future if that turns out to be desirable. --apb (Alan Barrett) From geier-lists-afrinic-policywg at tih.co.tz Sun Oct 15 08:50:04 2006 From: geier-lists-afrinic-policywg at tih.co.tz (Frank Habicht) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <20061014135320.GD6888@apb-laptoy.apb.alt.za> References: <452A6B92.4030804@posix.co.za> <20061014135320.GD6888@apb-laptoy.apb.alt.za> Message-ID: <4531DA1C.4060908@tih.co.tz> On 10/14/2006 4:53 PM, Alan Barrett wrote: > On Mon, 09 Oct 2006, JORDI PALET MARTINEZ wrote: > >> I think that it will be useful to hear many more people in the list >> telling "yes I like (or I don't like) this or that policy". Even if >> you don't have a clear view about a given policy, but you don't oppose >> to it, saying so will help. >> > > I like the policy except for one thing: I think that a /32 is > outrageously larger than people seeking space under this proposal > are likely to need, and I would like to see it changed to a /48 from > a reserved /40 block, to allow easy growth if it turns out to be > necessary, and to allow reclamation of the unused parts of the /40 block > in future if that turns out to be desirable. > > --apb (Alan Barrett) > > I agree. With all points. [/44 reserved as in ARIN, instead of /40 should also be fine] And I believe routability (though AfriNIC is officially not concerned) is not a problem. http://www.ripe.net/ripe/meetings/ripe-53/presentations/ipv6_routing_table.pdf (pg 13: "global" ipv6 routing table is 734 routes and 86 of them are /48) btw: this is still about my critical infrastructure proposal, right? or Jordi's PI ? They seem to overlap a bit and we might confuse them in this discussion. Especially since the one entity apparently immediately ready to go for it (Uniforum SA) would be eligible under both proposed policies. Should I specify my proposal then to include assignment sizes? I would replace this sentence: For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS with justification ) default assignment size is equal to the default assignment size for PI assignments of IPv6 address space to End Users [as defined in separate policy]. With this one: For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS with justification ) default assignment size is one /48 from a reserved /40. (as mentioned no problem to change /40 to /44) (the reference in the original version isn't good as such - done because I wanted to hit just the right size for "routability") Comments? Question, including to AfriNIC staff: "On request AfriNIC assigns IPv6 address ressource to [operators of] critical infrastructure." What is preferred, with or without the "operators of" ? I meant to have the final version without the brackets, with "operators of" either included or not. Does AfriNIC assign to net work operators or to infrastructure? (I lean towards operators, and to include the 2 words) Frank From jordi.palet at consulintel.es Sun Oct 15 12:22:28 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <4531DA1C.4060908@tih.co.tz> Message-ID: Hi Frank, My email was not referring to any specific proposal, just trying to get more people voicing opinions about all those under discussion. Regarding the prefix size, the point is still the same. The RIRs doesn't warrantee routability, but I think it will be a bit silly to set a policy that uses a prefix size that can't be viewed from everywhere, especially for critical infrastructures. I've seen this with several critical infrastructures in other regions, where the /48 was not reachable some times. How much "good" is that for a "critical infrastructure" ? For me the answer is clear ... The only "disadvantage" of a /32 is that some people could consider it as a waste. But let's be realistic, even if the predictions can always fail, which current policies the life of IPv6 will be around 480 years. Do you really believe we are "wasting" addressing space ? Let me give you a very simple example of the routability problem. APNIC has a /32 for their own use. However, they announce two separate /33 blocks, because they have two data centers. Some days I can't reach their web site, because some ISPs don't like the /33. Do you still think a /32 is bad and a /48 will make it ? Regards, Jordi > De: Frank Habicht > Responder a: AfriNIC Policy Working Group List > Fecha: Sun, 15 Oct 2006 09:50:04 +0300 > Para: AfriNIC Policy Working Group List > Asunto: Re: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure > > On 10/14/2006 4:53 PM, Alan Barrett wrote: >> On Mon, 09 Oct 2006, JORDI PALET MARTINEZ wrote: >> >>> I think that it will be useful to hear many more people in the list >>> telling "yes I like (or I don't like) this or that policy". Even if >>> you don't have a clear view about a given policy, but you don't oppose >>> to it, saying so will help. >>> >> >> I like the policy except for one thing: I think that a /32 is >> outrageously larger than people seeking space under this proposal >> are likely to need, and I would like to see it changed to a /48 from >> a reserved /40 block, to allow easy growth if it turns out to be >> necessary, and to allow reclamation of the unused parts of the /40 block >> in future if that turns out to be desirable. >> >> --apb (Alan Barrett) >> >> > > > I agree. With all points. [/44 reserved as in ARIN, instead of /40 > should also be fine] > And I believe routability (though AfriNIC is officially not concerned) > is not a problem. > > http://www.ripe.net/ripe/meetings/ripe-53/presentations/ipv6_routing_table.pdf > (pg 13: "global" ipv6 routing table is 734 routes and 86 of them are /48) > > > btw: this is still about my critical infrastructure proposal, right? or > Jordi's PI ? > They seem to overlap a bit and we might confuse them in this discussion. > Especially since the one entity apparently immediately ready to go for it > (Uniforum SA) would be eligible under both proposed policies. > > > Should I specify my proposal then to include assignment sizes? > > I would replace this sentence: > For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS > with justification ) default assignment size is equal to the default > assignment size for PI assignments of IPv6 address space to End Users > [as defined in separate policy]. > > With this one: > For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS > with justification ) default assignment size is one /48 from a reserved /40. > > > (as mentioned no problem to change /40 to /44) > (the reference in the original version isn't good as such - done because > I wanted to hit just the right size for "routability") > Comments? > > Question, including to AfriNIC staff: > "On request AfriNIC assigns IPv6 address ressource to [operators of] > critical infrastructure." > What is preferred, with or without the "operators of" ? I meant to have > the final version without the brackets, with "operators of" either > included or not. > Does AfriNIC assign to net work operators or to infrastructure? (I lean > towards operators, and to include the 2 words) > > Frank > > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Sun Oct 15 12:37:09 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <20061014135320.GD6888@apb-laptoy.apb.alt.za> Message-ID: Hi Alan, The most important thing in my opinion is that we approve a critical infrastructure policy in the next meeting. Some folks in the region are already "in halt" with IPv6 because the lack of this, which is really a terrible problem. I see several possibilities here, but I don't know how to proceed, if we need different policy proposals (for each choice), or if the board can approve a policy which text is "fixed" depending on the consensus during the meeting. I think this is done in other regions. I hope you understand what I mean. For example, it could happen that even the proposed PI talks about /32, if the meeting reach consensus on that policy but using a /48 ? Or we need to submit another version with the /48 ? Depending on your answer, I can suggest several alternatives for the prefix size in PI: 1) Use something such as what LACNIC uses for critical infrastructures regarding the prefix size is something like: "prefixes from /48 to /32". This gives the freedom to AfriNIC to implement a /48 if it is considered enough, or a /32 if the requester justify the need (or whatever in the middle). I understand that LACNIC decided this path to avoid a *long* discussion about the prefix size when that policy was approved. 2) We can build a text that defines a /44 for the PI prefix size, such as in ARIN, but reserve the /32, and give AfriNIC the freedom to allocate whatever is justified by each requester. 3) Keep the existing text for /32. 4) May be somebody else has other possible suggestions about this specific point ? The other decision is if the community want a temporary PI policy, such as the actual text, or a permanent one. By the way, I understand that if the PI policy is approved, then there is no need for the critical infrastructures one ? Regards, Jordi > De: Alan Barrett > Responder a: AfriNIC Policy Working Group List > Fecha: Sat, 14 Oct 2006 15:53:20 +0200 > Para: AfriNIC Policy Working Group List > Asunto: Re: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure > > On Mon, 09 Oct 2006, JORDI PALET MARTINEZ wrote: >> I think that it will be useful to hear many more people in the list >> telling "yes I like (or I don't like) this or that policy". Even if >> you don't have a clear view about a given policy, but you don't oppose >> to it, saying so will help. > > I like the policy except for one thing: I think that a /32 is > outrageously larger than people seeking space under this proposal > are likely to need, and I would like to see it changed to a /48 from > a reserved /40 block, to allow easy growth if it turns out to be > necessary, and to allow reclamation of the unused parts of the /40 block > in future if that turns out to be desirable. > > --apb (Alan Barrett) > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From apb at cequrux.com Sun Oct 15 10:15:27 2006 From: apb at cequrux.com (Alan Barrett) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: <4531DA1C.4060908@tih.co.tz> References: <452A6B92.4030804@posix.co.za> <20061014135320.GD6888@apb-laptoy.apb.alt.za> <4531DA1C.4060908@tih.co.tz> Message-ID: <20061015081527.GH6888@apb-laptoy.apb.alt.za> On Sun, 15 Oct 2006, Frank Habicht wrote: > On 10/14/2006 4:53 PM, Alan Barrett wrote: > > I like the policy except for one thing: I think that a /32 is > > outrageously larger than people seeking space under this proposal > > are likely to need, and I would like to see it changed to a /48 from > > a reserved /40 block, to allow easy growth if it turns out to be > > necessary, and to allow reclamation of the unused parts of the /40 > > block in future if that turns out to be desirable. > > btw: this is still about my critical infrastructure proposal, > right? or Jordi's PI ? I have the same size concerns about both proposals. > I would replace this sentence: > For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS > with justification ) default assignment size is equal to the default > assignment size for PI assignments of IPv6 address space to End Users > [as defined in separate policy]. > > With this one: > For critical DNS server operations ( root DNS, ccTLD DNS, and SLD DNS > with justification ) default assignment size is one /48 from a reserved /40. > > (as mentioned no problem to change /40 to /44) /48 from a reserved /44 is fine for me. For both the PI proposal and the critical infrastructure proposal. > (the reference in the original version isn't good as such - done because > I wanted to hit just the right size for "routability") > Comments? Routability is not an issue of size. Routability is an issue of configuration. I think it's safe to assume: (a) AfriNIC will use different super blocks for different purposes; (b) AfriNIC will publish which super blocks will be used for which purposes, and the smallest allocation size in each super block; (c) People who filter based on prefix length will adjust their filters according to the policies published in (b) above; (d) People who announce address space in units equal to the units allocated to them will not have routability problems caused by the filters mentioned in (c) above; (e) People who announce address space in more-specific units smaller than the units allocated to them might have routability problems. It might be a good idea to explicitly mention (a) and (b) in the policy proposal. AfriNIC has no control over (c), (d) or (e). > Question, including to AfriNIC staff: > "On request AfriNIC assigns IPv6 address ressource to [operators of] > critical infrastructure." > What is preferred, with or without the "operators of" ? I meant to have > the final version without the brackets, with "operators of" either > included or not. > Does AfriNIC assign to net work operators or to infrastructure? (I lean > towards operators, and to include the 2 words) The space would be assigned *to* the operator, *for* the facility. There should be a way of reclaiming the space if the facility ceases to function or ceases to need the space, regardless of whether or not the operator stays in business. -apb (Alan Barrett) From apb at cequrux.com Sun Oct 15 16:11:42 2006 From: apb at cequrux.com (Alan Barrett) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] AfriNIC policy: IPv6 for critical infrastructure In-Reply-To: References: <4531DA1C.4060908@tih.co.tz> Message-ID: <20061015141142.GI6888@apb-laptoy.apb.alt.za> On Sun, 15 Oct 2006, JORDI PALET MARTINEZ wrote: > The only "disadvantage" of a /32 is that some people could consider > it as a waste. But let's be realistic, even if the predictions can > always fail, which current policies the life of IPv6 will be around > 480 years. Do you really believe we are "wasting" addressing space ? Yes, I believe that /32 is a waste. I don't believe the predictions about 480 years; I expect the rate of use to change before the end of the 480 years. > Let me give you a very simple example of the routability > problem. APNIC has a /32 for their own use. However, they announce two > separate /33 blocks, because they have two data centers. Some days I > can't reach their web site, because some ISPs don't like the /33. I submit that the reachability problems are not because "/33 is too long to get through filters"; but rather because "this particular /33 is more specific than what was allocated". If what is allocated is a /48, then filters will be designed to take that into account. I envisage filters that allow /32s but block /33s in parts of the address space where operators know that the smallest allocation is a /32s; and that allow /48s but block /49s in parts of the address space where operators know that the smallest allocation is a /48. > Do you still think a /32 is bad and a /48 will make it ? Yes. --apb (Alan Barrett) From adiel at afrinic.net Sat Oct 21 10:12:36 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] Call for Comments on IPv6 Multi-homing Solutions Message-ID: <7.0.1.0.2.20061021115955.04803da8@afrinic.net> You may be interested by this call for comment on the some possible IPv6 Multi-Homing solutions. http://www.nro.net/documents/nro42.html - Adiel From meeting at afrinic.net Mon Oct 30 09:59:38 2006 From: meeting at afrinic.net (AfriNIC - http://www.afrinic.net) Date: Wed Nov 8 07:57:11 2006 Subject: [policy-wg] [Fwd: AfriNIC-5: Call for Presentations and Tutorials] Message-ID: <4545B0EA.1050904@afrinic.net> - apologies for cross-posting - Dear Colleagues, This is a reminder about the call for presentations and tutorials for the AfriNIC-5 meeting. The next AfriNIC Public Policy Meeting will be held in Mauritius from 27 Nov - 01 Dec 2006. It is an open forum to discuss issues related to internet number resource management within the AfriNIC service region. This meeting will also host a regional IPv6 conference where network operators will share their experiences on IPv6 deployment. We are looking for presentations and tutorials of relevance from anyone. Tutorials are usually 2 to 4 hour workshops, while presentations may last between 10 and 30 minutes. Presentations / Tutorials may cover the following topics: - IPv6 deployment - Routing Best Practice/Address Space Prefix Filtering - Reverse DNS implemenation - DNSec - Fighting Spam We would like to have as many practical, hands-on presentations as possible and they do not have to be long. Policy proposals are also usually discussed at the meeting, but must pass through the appropriate phases of the Policy Development Process (please see http://www.afrinic.net/pdp.htm). If you would like to make a presentation or tutorial, please send your proposal to meeting@afrinic.net Your proposal should contain the following information: - Full Name - Email Address - Affiliation - Short biography - Title of Talk - A detailed abstract or outline describing the presentation - Draft slides for the presentation (if ready/available) - Length of talk (minutes/hours/days) - Need (or not) for sponsorship or assistance to attend the meeting (travel and/or accommodation, etc) The audience at AfriNIC meetings is mainly composed of technical network operators and engineers with a wide range of experience levels from beginners to several years of experience. Presentations that contain any sort of marketing and commercial content are usually not encouraged at such meetings. Kind regards, AfriNIC www.afrinic.net From hisham at afrinic.net Mon Nov 13 16:10:00 2006 From: hisham at afrinic.net (Hisham R Rojoa) Date: Mon Nov 13 16:10:53 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 Message-ID: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> Dear Colleagues, We had consensus on the policy bellow during the AfriNIC-4 meeting. This a final call before it get ratified by the board. If you have any additional comments it is now the time for it. Regards. ========================= 1. Author: Geoff Huston 2. Organization: APNIC 3. Policy Affected: afpol-as200407-000 - ASN Allocation Policy 4. Date: 9 December 2005 Proposal: 4-Byte AS Number Policy Proposal Author: Geoff Huston, gih@apnic.net, APNIC Proposal Version: 1.0 Proposal Type: New Policy Term: Temporary (1 January 2007 ? 1 January 2010) Policy Statement: This policy proposal nominates 3 dates for changes to the current AS Number allocation policy for the registry: On 1 January 2007 the registry will process applications that specifically request 4-byte only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 4-byte only AS Number, a 2-byte only AS Number will be allocated by the registry. On 1 January 2009 the registry will process applications that specifically request 2-byte only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 2-byte only AS Number, a 4-byte only AS Number will be allocated by the registry. On 1 January 2010 the registry will cease to make any distinction between 2-byte only AS Numbers and 4-byte only AS Numbers, and will operate AS number allocations from an undifferentiated 4-byte AS Number allocation pool. Nomenclature It is proposed to identify 4-byte AS Numbers using a syntax of :. Accordingly, a 4-byte AS number of value 65546 (decimal) would be identified as "1:10". Terminology "2-byte only AS Numbers" refers to AS numbers in the range 0 ?65535 "4-byte only AS Numbers" refers to AS Numbers in the range 1:0 65535:65535 (decimal range 65,536 - 4,294,967,295) "4-byte AS Numbers" refers to AS Numbers in the range 0:0 ? 65535:65535 (decimal range 0 ? 4,294,967,295) Rationale: Recent studies of AS number consumption rates indicate that the existing 2-byte pool of unallocated AS Numbers will be exhausted sometime in the period between 2010 and 2016, absent of any concerted efforts of recovery of already-allocated AS Numbers [1] [2]. Standardization work in the IETF has produced a document that is currently being submitted as a Proposed Standard that will expand the AS Number space to a 4-byte field [3]. It is noted that some advance period may be required by network operators to undertake the appropriate procedures relating to support of 4-byte AS numbers, and while no flag day is required in the transition to the longer AS Number field, it is recognised that a prudent course of action is to allow for allocation of these extended AS numbers well in advance of an anticipated 2-byte AS Number exhaustion date. This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 4-byte AS Number space. The essential attributes of this policy proposal are to facilitate the ease of transitional arrangements by equipment vendors, network managers and network operations staff, to provide the industry with some predictability in terms of dates and associated actions with respect to registry operational procedures for AS Number allocations. References [1] Daily AS Number Report, http://www.potaroo.net/tools/asns [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, http://www.nanog.org/mtg-0510/wilhelm.html [3] BGP Support for Four-octet AS Number Space, draft-ietf-idr-as4bytes-12.txt Timetable for implementation: Procedures to support this proposal need to be implemented by 1 January 2007 From geier-lists-afrinic-policywg at tih.co.tz Tue Nov 14 06:08:23 2006 From: geier-lists-afrinic-policywg at tih.co.tz (Frank Habicht) Date: Tue Nov 14 06:08:47 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 In-Reply-To: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> References: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> Message-ID: <45594137.7010604@tih.co.tz> Hello, I'm supporting this proposal. It should be ratified. seeing that the first date is not far from now, maybe (all) RIRs can start asking IANA for some first small 4-byte ASN allocations...? Frank On 11/13/2006 5:10 PM, Hisham R Rojoa wrote: > Dear Colleagues, > > We had consensus on the policy bellow during the AfriNIC-4 meeting. > This a final call before it get ratified by the board. If you have any > additional comments it is now the time for it. > > Regards. > > ========================= > 1. Author: Geoff Huston > 2. Organization: APNIC > 3. Policy Affected: afpol-as200407-000 - ASN Allocation Policy > > 4. Date: 9 December 2005 > > Proposal: 4-Byte AS Number Policy Proposal From ernest at afrinic.net Tue Nov 14 08:44:14 2006 From: ernest at afrinic.net (Ernest Byaruhanga (AfriNIC)) Date: Tue Nov 14 08:44:24 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 In-Reply-To: <45594137.7010604@tih.co.tz> References: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> <45594137.7010604@tih.co.tz> Message-ID: <455965BE.70400@afrinic.net> Frank Habicht wrote the following on 11/14/2006 06:08 AM: > Hello, > > I'm supporting this proposal. It should be ratified. seeing that > the first date is not far from now, maybe (all) RIRs can start > asking IANA for some first small 4-byte ASN allocations...? The IESG are still doing the RFC that specifies the format, etc for 32-bit ASNs. Until this is done, we cant request for a 32-bit ASN block just yet. Rgds, Ernest. From gih at apnic.net Wed Nov 15 01:35:33 2006 From: gih at apnic.net (Geoff Huston) Date: Wed Nov 15 01:35:56 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 In-Reply-To: <455965BE.70400@afrinic.net> References: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> <45594137.7010604@tih.co.tz> <455965BE.70400@afrinic.net> Message-ID: <7.0.0.16.2.20061115103126.0140c620@apnic.net> At 05:44 PM 14/11/2006, Ernest Byaruhanga (AfriNIC) wrote: >Frank Habicht wrote the following on 11/14/2006 06:08 AM: > > Hello, > > > > I'm supporting this proposal. It should be ratified. seeing that > > the first date is not far from now, maybe (all) RIRs can start > > asking IANA for some first small 4-byte ASN allocations...? > >The IESG are still doing the RFC that specifies the format, etc for >32-bit ASNs. Until this is done, we cant request for a 32-bit ASN >block just yet. At this stage the IESG has approved an IANA Early Allocation of the extended AS number space, and the ticket to create the expanded AS Number registry at the IANA is now with IANA. Once this ticket is processed, which I assume will be in days rather than weeks or months, then the IANA will be in a position to process requests from the RIRs for these AS number blocks with non-zero high order 16 bits. So the bottom line is that if the AfriNIC community chose to adopt this policy we appear to be on track to be able to meet the dates, and, in particular, we are still confident that we would be ready by 1 January 2007. regards, Geoff Huston APNIC From ernest at afrinic.net Wed Nov 15 09:25:15 2006 From: ernest at afrinic.net (Ernest Byaruhanga (AfriNIC)) Date: Wed Nov 15 09:25:19 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 In-Reply-To: <7.0.0.16.2.20061115103126.0140c620@apnic.net> References: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> <45594137.7010604@tih.co.tz> <455965BE.70400@afrinic.net> <7.0.0.16.2.20061115103126.0140c620@apnic.net> Message-ID: <455AC0DB.60609@afrinic.net> Geoff Huston wrote the following on 11/15/2006 01:35 AM: > At 05:44 PM 14/11/2006, Ernest Byaruhanga (AfriNIC) wrote: >> Frank Habicht wrote the following on 11/14/2006 06:08 AM: >>> Hello, >>> >>> I'm supporting this proposal. It should be ratified. seeing >>> that the first date is not far from now, maybe (all) RIRs can >>> start asking IANA for some first small 4-byte ASN >>> allocations...? >> >> The IESG are still doing the RFC that specifies the format, etc >> for 32-bit ASNs. Until this is done, we cant request for a 32-bit >> ASN block just yet. > > At this stage the IESG has approved an IANA Early Allocation of the > extended AS number space, and the ticket to create the expanded AS > Number registry at the IANA is now with IANA. Once this ticket is > processed, which I assume will be in days rather than weeks or > months, then the IANA will be in a position to process requests > from the RIRs for these AS number blocks with non-zero high order > 16 bits. Thanks for the update Geoff. Rgds, Ernest. From aalain at trstech.net Tue Nov 14 16:45:43 2006 From: aalain at trstech.net (Alain Patrick AINA) Date: Wed Nov 15 10:41:29 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 In-Reply-To: <455965BE.70400@afrinic.net> References: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> <45594137.7010604@tih.co.tz> <455965BE.70400@afrinic.net> Message-ID: <200611141445.43633.aalain@trstech.net> > The IESG are still doing the RFC that specifies the format, etc for > 32-bit ASNs. you meant IETF ? ...and yes "draft-ietf-idr-as4bytes from" IETF working group IDR is being evaluated by IESG. Its IANA considerations below will enable the four-octet ASN registry at IANA. --alain _______ 7. IANA Considerations This document makes the four-octet, unsigned integers larger than 65535 available for allocation as AS numbers. These AS numbers need to be managed by the IANA "Autonomous System Numbers" registry. From ernest at afrinic.net Wed Nov 15 11:45:22 2006 From: ernest at afrinic.net (Ernest Byaruhanga (AfriNIC)) Date: Wed Nov 15 11:45:26 2006 Subject: [policy-wg] Last Call for policy afpol-as200407-000 In-Reply-To: <200611141445.43633.aalain@trstech.net> References: <038a01c7072d$86401d60$0903d8c4@DDVHC72J> <45594137.7010604@tih.co.tz> <455965BE.70400@afrinic.net> <200611141445.43633.aalain@trstech.net> Message-ID: <455AE1B2.3090603@afrinic.net> Alain Patrick AINA wrote the following on 11/14/2006 04:45 PM: >> The IESG are still doing the RFC that specifies the format, etc for >> 32-bit ASNs. > > you meant IETF ? Same thing. The IESG is a committee at the IETF. rgds ernest From hisham at afrinic.net Wed Nov 15 15:32:10 2006 From: hisham at afrinic.net (Hisham R Rojoa) Date: Wed Nov 15 15:32:16 2006 Subject: [policy-wg] Policy for Discussion at AfriNIC-5 Message-ID: <001a01c708ba$76c10910$0903d8c4@DDVHC72J> Dear Colleagues Please find below the open policies which will be discussed at AfriNIC-5: (1) Global IPv6 PI policy proposal, JORDI PALET MARTINEZ jordi.palet@consulintel.es Fri Apr 14 17:01:03 SAST 2006 (2) IPv6 PI address space for critical infrastructure Frank Habicht geier-lists-afrinic-policywg@tih.co.tz Fri Jun 2 12:06:26 SAST 2006 (3) Modification to current IPv6 Allocation Policy JORDI PALET MARTINEZ jordi.palet@consulintel.es Sun Jun 4 22:37:35 SAST 2006 These can be viewed at http://www.afrinic.net/policy.htm Best Regards Hisham R. Rojoa Membership Liaison and Communication Officer From adiel at afrinic.net Wed Nov 22 14:17:03 2006 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Wed Nov 22 14:48:01 2006 Subject: [policy-wg] Proposed Change for allocation period Message-ID: <7.0.1.0.2.20061122152736.045bbeb8@afrinic.net> Name: Adiel A. Akplogan Organisation: AfriNIC Policy/Documents Affected: afpol-v4200407-000, affrm-v4fst200501, Date: November 2006 Proposal: Proposal to change the allocation and assignment period to 12 months: Incentive: In the very changing environment of the Internet and related services it is generally difficult to precisely plan IP addresses usage two years ahead. Further to that AfriNIC members may at the moment appear to have an unfair advantage over those in other regions. This will mean that all LIRs will plan their address space needs within the same time frames. Introduction: ------------- This proposal suggests that AfriNIC should start allocating/assigning enough IPv4 and IPv6 address space to last a member's 1 year addressing needs (as opposed to currently ? 2, as is the practice). Abstract: --------- Current IPv4/v6 policy does not explicitly mention a timeframe that AfriNIC requires its members to plan for when requesting IP address space. The practice however is to allocate/assign enough IP address space to satisfy a member's two year requirements. This period is shorter in most of the other regions: LACNIC: 3 months ARIN: 6 months APNIC: 12 months RIPE: 24 months Motivation: ----------- Fairness: Having a different allocation/assignment period could be seen as offering advantages to LIRs in one region over those in another. With a shorter allocation/assignment period, a member can only plan for the short term, whereas others will have more flexibility in terms of their planning. AfriNIC members may at the moment appear to have an unfair advantage over those in other regions. This will mean that all LIRs will plan their address space needs within the same time frames in all regions. More accurate allocation based on real needs: With evaluation based on one year needs, it will be easy for LIR to precise in their needs statement. It will also contribute to speed up the evaluation process by AfriNIC's IP analysts as they won't have to assess too much new services which are not yet implemented but only planed (in two years period time) by the requester. Currently there are similar proposals in the LACNIC and RIPE regions to change this period to one year. ARIN has also adopted a similar policy. Summary: -------- In view of the above criteria, AfriNIC should allocate/assign enough IPv4 and IPv6 address space to last a member's 1 year addressing needs. --------------------- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.12/545 - Release Date: 21/11/2006 From geier-lists-afrinic-policywg at tih.co.tz Fri Dec 1 11:25:49 2006 From: geier-lists-afrinic-policywg at tih.co.tz (Frank Habicht) Date: Fri Dec 1 11:26:25 2006 Subject: [policy-wg] afpol-v60606 Message-ID: <456FF51D.7030604@tih.co.tz> Hi, I listened to the discussion and would like to point out: the policy proposal is meant to create same or very similar conditions as in other Regions. not sure if the lest 2 slides were shown this proposal about critical infrastructure can be incorporated in the general v6 policy text. other RIRs: http://www.nro.net/documents/nro38.html#3-3-1 Thanks, Frank From mje at posix.co.za Thu Dec 14 14:40:57 2006 From: mje at posix.co.za (Mark J Elkins) Date: Thu Dec 14 14:39:11 2006 Subject: [policy-wg] IPV6 PI space Message-ID: <45814659.6000806@posix.co.za> Firstly - the training and knowledge received in Mauritius was great with respect to IPV6. This has allowed me to better understand the needs and concerns of others. However - I am by no means the expert and expected to be corrected when incorrect. I believe there needs to be some sort of PI policy. I do not believe that is is very healthy for Exchange Points (IXP's) to use the address space of a particular ISP. I also believe that its unhealthy for some organisations (eg - CCTLD's) that currently have IPV4 PI space and who are Multi-Homed to also have space from any particular ISP. I believe that AfriNIC needs two different PI allocation policies for these two different areas: For Exchange Points --------------------------- These need a small, non-wasteful, low maintenance allocation - for example, an allocation of a /44 would allow for 16 "networks" (each of /48) to be established. A /48 is more than suitable for a single (even geographically dispersed) IXP, thus a /44 should be sufficient for a country or a countries ISPA. (By this - I'm thinking of South Africa with currently only one active peering point, but with potential expansion to a total of three points - but all managed by a single ISPA type organisation). I'd like to see AfriNIC allocate these /44's out of a single /32, which means there are 4096 of these allocations available. These should be only used for IXP's and should (I'd like to suggest) have no re-occurring charge associated with them. The allocation could be made to the ISPA type organisation - so that there is no need for ongoing maintenance of the allocation (or at least greatly reduce the maintenance burden on AfriNIC). I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) within the AfriNIC region. By allocating a /44, the Reverse DNS responsibilities (and hence - usage of AfriNIC resources) is minimalised and filtering could also be done on /44's. The allocations should be made on /40 boundaries so when there is a need to allocate a particular country (or ISPA) with additional space, to do so from the same /40. This allows for 256 different "countries". Technically - IXP allocations do not need to be globally route-able - so this type of allocation should be fine. The other assumption here is that the IXP (or ISPA - whatever) is a non-commercial (non-profit) organisation - in order to be exempt from re-occurring fees. (By extension, maybe even allocate a /32 to AfrISPA - and let them delegate onwards? - but I'm trying to not have options) For other existing holders of IPV4 PI Space --------------------------------------------------------- For all organisations that currently have IPV4 PI space within the AfriNIC region, they should be allowed to obtain full /32's of IPV6 space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or proof that it has been requested and is impending. (kiss - Keeping It Simple) No policy is exempt from changes in the future. The above policy suggestions are to tackle todays requirements whilst keeping them flexible enough that they may serve the AfriNIC regions needs for the next few years. -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 From aa at tenet.ac.za Thu Dec 14 15:34:55 2006 From: aa at tenet.ac.za (Andrew Alston) Date: Thu Dec 14 15:35:26 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <45814659.6000806@posix.co.za> References: <45814659.6000806@posix.co.za> Message-ID: <000601c71f84$aaca7e90$005f7bb0$@ac.za> Hi There, Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due to other commitments, however, having been involved in the P.I debate for a while and having kept a close watch on the developments in this regard around the world, I tend to take a different view on this. I firmly believe that with regards P.I space, a /48 allocation is enough. Firstly, for IXP space, there is a trend to move towards /126 networks on point to point allocations (do not use /127's, there are a variety of reasons for this), therefore, IXP's could operate off a single /48, utilizing /64's per IXP, and utilizing /126 networks for the actual peering requirements. Secondly, with regards to end user networks, for AfriNIC to allocate /32's in P.I space would again run contrary to what the global trends are, ARIN has agreed to /48 P.I space, and (someone correct me if I 'm wrong here), APNIC is about to ratify their /48 P.I policy. Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an end point network, a /48 should be more than sufficient for P.I allocations to individual companies. ISP's should qualify for /32s and become LIR's if they want the /32s and are allocating onwards. I would prefer therefore that as per global trends, AfriNIC allocates a set block out of which to assign /48 P.I prefix's (possibly a /30 or a /31), and assigns the /48s outta that prefix for all P.I space. That block can then be made public, so that those of us that update filters to filter /48 deaggregated announcements can add exceptions for the specified prefix. I would say that where companies have more than one physical location there could potentially be an exception to this policy, so that a company that has multiple physically diverse branches, might for example qualify for multiple /48s, purely for the purpose of better routing aggregation, but again, these /48s out of the same block referred to earlier. The above would be more in line with what is done globally, and would avoid the complications of BGP filters that were different for different regions! Thanks Andrew Alston TENET - Chief Technology Officer -----Original Message----- From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net] On Behalf Of Mark J Elkins Sent: Thursday, December 14, 2006 2:41 PM To: AfriNIC Policy Working Group List Subject: [policy-wg] IPV6 PI space Firstly - the training and knowledge received in Mauritius was great with respect to IPV6. This has allowed me to better understand the needs and concerns of others. However - I am by no means the expert and expected to be corrected when incorrect. I believe there needs to be some sort of PI policy. I do not believe that is is very healthy for Exchange Points (IXP's) to use the address space of a particular ISP. I also believe that its unhealthy for some organisations (eg - CCTLD's) that currently have IPV4 PI space and who are Multi-Homed to also have space from any particular ISP. I believe that AfriNIC needs two different PI allocation policies for these two different areas: For Exchange Points --------------------------- These need a small, non-wasteful, low maintenance allocation - for example, an allocation of a /44 would allow for 16 "networks" (each of /48) to be established. A /48 is more than suitable for a single (even geographically dispersed) IXP, thus a /44 should be sufficient for a country or a countries ISPA. (By this - I'm thinking of South Africa with currently only one active peering point, but with potential expansion to a total of three points - but all managed by a single ISPA type organisation). I'd like to see AfriNIC allocate these /44's out of a single /32, which means there are 4096 of these allocations available. These should be only used for IXP's and should (I'd like to suggest) have no re-occurring charge associated with them. The allocation could be made to the ISPA type organisation - so that there is no need for ongoing maintenance of the allocation (or at least greatly reduce the maintenance burden on AfriNIC). I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) within the AfriNIC region. By allocating a /44, the Reverse DNS responsibilities (and hence - usage of AfriNIC resources) is minimalised and filtering could also be done on /44's. The allocations should be made on /40 boundaries so when there is a need to allocate a particular country (or ISPA) with additional space, to do so from the same /40. This allows for 256 different "countries". Technically - IXP allocations do not need to be globally route-able - so this type of allocation should be fine. The other assumption here is that the IXP (or ISPA - whatever) is a non-commercial (non-profit) organisation - in order to be exempt from re-occurring fees. (By extension, maybe even allocate a /32 to AfrISPA - and let them delegate onwards? - but I'm trying to not have options) For other existing holders of IPV4 PI Space --------------------------------------------------------- For all organisations that currently have IPV4 PI space within the AfriNIC region, they should be allowed to obtain full /32's of IPV6 space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or proof that it has been requested and is impending. (kiss - Keeping It Simple) No policy is exempt from changes in the future. The above policy suggestions are to tackle todays requirements whilst keeping them flexible enough that they may serve the AfriNIC regions needs for the next few years. -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 _______________________________________________ policy-wg mailing list policy-wg@afrinic.net https://lists.afrinic.net/mailman/listinfo.cgi/policy-wg From mje at posix.co.za Thu Dec 14 16:48:22 2006 From: mje at posix.co.za (Mark J Elkins) Date: Thu Dec 14 16:46:23 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <000601c71f84$aaca7e90$005f7bb0$@ac.za> References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> Message-ID: <45816436.30002@posix.co.za> Andrew Alston wrote: > Hi There, > > Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due to > other commitments, however, having been involved in the P.I debate for a > while and having kept a close watch on the developments in this regard > around the world, I tend to take a different view on this. > Yup - we missed you :-) Was a lovely location. > I firmly believe that with regards P.I space, a /48 allocation is enough. > Firstly, for IXP space, there is a trend to move towards /126 networks on > point to point allocations (do not use /127's, there are a variety of > reasons for this), therefore, IXP's could operate off a single /48, > utilizing /64's per IXP, and utilizing /126 networks for the actual peering > requirements. > Our teachers in Mauritius (Jordi and Phillip Smith) seemed to suggest that a point-to-point connection should use a /126 but for almost every other case, use a /64 - ie - for individual machines on a LAN (including Routers). Regardless - a /48 make perfect sense for an IXP. What I am suggesting is rather issue a /44 to the local industry body that is managing the infrastructure to reduce the work-load of AfriNIC. Either way - the extra number of routes in global routing tables will be the same - which should be zero - excepting for access to local IXP's. This is meant to be a Policy for African IXP's. I really don't see more than 4000 ISPA type organisations in Africa. > Secondly, with regards to end user networks, for AfriNIC to allocate /32's > in P.I space would again run contrary to what the global trends are, ARIN > has agreed to /48 P.I space, and (someone correct me if I 'm wrong here), > APNIC is about to ratify their /48 P.I policy. > > Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an > end point network, a /48 should be more than sufficient for P.I allocations > to individual companies. ISP's should qualify for /32s and become LIR's if > they want the /32s and are allocating onwards. > > I would prefer therefore that as per global trends, AfriNIC allocates a set > block out of which to assign /48 P.I prefix's (possibly a /30 or a /31), and > assigns the /48s outta that prefix for all P.I space. That block can then > be made public, so that those of us that update filters to filter /48 > deaggregated announcements can add exceptions for the specified prefix. > > I would say that where companies have more than one physical location there > could potentially be an exception to this policy, so that a company that has > multiple physically diverse branches, might for example qualify for multiple > /48s, purely for the purpose of better routing aggregation, but again, these > /48s out of the same block referred to earlier. > > The above would be more in line with what is done globally, and would avoid > the complications of BGP filters that were different for different regions! > Whether a /32 or a /48 is allocated for PI should make little difference to International Routing Tables, in fact allocating a /32 would potentially reduce the number of entries - where an organisation finds a /48 "too small" (again - we were sort of taught that a /48 should be allocated per business location). By allocating a /32, you'll empower that organisation to become an LIR without any renumbering inconvenience - and have the simplicity that all allocations are then the same size - except for Exchange Points. I guess I'm more concerned with Router memory than attempting to waste IPV6 space? I'm also more for separating those that will never need more space (IXP's) from those that probably will need more space (organisations with existing IPV4 PI space). Allocating /32's has zero impact on different filters for different regions :-) I'm all for the same size filters though (ie either /32's or /48's) ... I just think that if you are too big for a /48 - then you should go straight to a /32. > Thanks > > Andrew Alston > TENET - Chief Technology Officer > > -----Original Message----- > From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net] > On Behalf Of Mark J Elkins > Sent: Thursday, December 14, 2006 2:41 PM > To: AfriNIC Policy Working Group List > Subject: [policy-wg] IPV6 PI space > > Firstly - the training and knowledge received in Mauritius was great > with respect to IPV6. This has allowed me to better understand the needs > and concerns of others. However - I am by no means the expert and > expected to be corrected when incorrect. > > I believe there needs to be some sort of PI policy. I do not believe > that is is very healthy for Exchange Points (IXP's) to use the address > space of a particular ISP. I also believe that its unhealthy for some > organisations (eg - CCTLD's) that currently have IPV4 PI space and who > are Multi-Homed to also have space from any particular ISP. > > I believe that AfriNIC needs two different PI allocation policies for > these two different areas: > > For Exchange Points > --------------------------- > > These need a small, non-wasteful, low maintenance allocation - for > example, an allocation of a /44 would allow for 16 "networks" (each of > /48) to be established. A /48 is more than suitable for a single (even > geographically dispersed) IXP, thus a /44 should be sufficient for a > country or a countries ISPA. (By this - I'm thinking of South Africa > with currently only one active peering point, but with potential > expansion to a total of three points - but all managed by a single ISPA > type organisation). > I'd like to see AfriNIC allocate these /44's out of a single /32, which > means there are 4096 of these allocations available. These should be > only used for IXP's and should (I'd like to suggest) have no > re-occurring charge associated with them. > The allocation could be made to the ISPA type organisation - so that > there is no need for ongoing maintenance of the allocation (or at least > greatly reduce the maintenance burden on AfriNIC). > I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) > within the AfriNIC region. > By allocating a /44, the Reverse DNS responsibilities (and hence - usage > of AfriNIC resources) is minimalised and filtering could also be done on > /44's. The allocations should be made on /40 boundaries so when there is > a need to allocate a particular country (or ISPA) with additional space, > to do so from the same /40. This allows for 256 different "countries". > Technically - IXP allocations do not need to be globally route-able - so > this type of allocation should be fine. > The other assumption here is that the IXP (or ISPA - whatever) is a > non-commercial (non-profit) organisation - in order to be exempt from > re-occurring fees. > (By extension, maybe even allocate a /32 to AfrISPA - and let them > delegate onwards? - but I'm trying to not have options) > > For other existing holders of IPV4 PI Space > --------------------------------------------------------- > > For all organisations that currently have IPV4 PI space within the > AfriNIC region, they should be allowed to obtain full /32's of IPV6 > space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an > AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or > proof that it has been requested and is impending. > (kiss - Keeping It Simple) > > > > No policy is exempt from changes in the future. The above policy > suggestions are to tackle todays requirements whilst keeping them > flexible enough that they may serve the AfriNIC regions needs for the > next few years. > > -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 From vincent at kenic.or.ke Thu Dec 14 17:25:07 2006 From: vincent at kenic.or.ke (Vincent Ngundi) Date: Thu Dec 14 17:26:04 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <000601c71f84$aaca7e90$005f7bb0$@ac.za> References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> Message-ID: <200612141825.08332.vincent@kenic.or.ke> How about we assign a _minumum of a /48 (those who need more will have to justify that to AfriNIC) to end users and critical infrastructure providers and reserve a /32 for each assigned /48? Regards, -Vincent On Thu December 14 2006 16:34, Andrew Alston wrote: > Hi There, > > Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due > to other commitments, however, having been involved in the P.I debate for a > while and having kept a close watch on the developments in this regard > around the world, I tend to take a different view on this. > > I firmly believe that with regards P.I space, a /48 allocation is enough. > Firstly, for IXP space, there is a trend to move towards /126 networks on > point to point allocations (do not use /127's, there are a variety of > reasons for this), therefore, IXP's could operate off a single /48, > utilizing /64's per IXP, and utilizing /126 networks for the actual peering > requirements. > > Secondly, with regards to end user networks, for AfriNIC to allocate /32's > in P.I space would again run contrary to what the global trends are, ARIN > has agreed to /48 P.I space, and (someone correct me if I 'm wrong here), > APNIC is about to ratify their /48 P.I policy. > > Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an > end point network, a /48 should be more than sufficient for P.I allocations > to individual companies. ISP's should qualify for /32s and become LIR's if > they want the /32s and are allocating onwards. > > I would prefer therefore that as per global trends, AfriNIC allocates a set > block out of which to assign /48 P.I prefix's (possibly a /30 or a /31), > and assigns the /48s outta that prefix for all P.I space. That block can > then be made public, so that those of us that update filters to filter /48 > deaggregated announcements can add exceptions for the specified prefix. > > I would say that where companies have more than one physical location there > could potentially be an exception to this policy, so that a company that > has multiple physically diverse branches, might for example qualify for > multiple /48s, purely for the purpose of better routing aggregation, but > again, these /48s out of the same block referred to earlier. > > The above would be more in line with what is done globally, and would avoid > the complications of BGP filters that were different for different regions! > > Thanks > > Andrew Alston > TENET - Chief Technology Officer > > -----Original Message----- > From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net] > On Behalf Of Mark J Elkins > Sent: Thursday, December 14, 2006 2:41 PM > To: AfriNIC Policy Working Group List > Subject: [policy-wg] IPV6 PI space > > Firstly - the training and knowledge received in Mauritius was great > with respect to IPV6. This has allowed me to better understand the needs > and concerns of others. However - I am by no means the expert and > expected to be corrected when incorrect. > > I believe there needs to be some sort of PI policy. I do not believe > that is is very healthy for Exchange Points (IXP's) to use the address > space of a particular ISP. I also believe that its unhealthy for some > organisations (eg - CCTLD's) that currently have IPV4 PI space and who > are Multi-Homed to also have space from any particular ISP. > > I believe that AfriNIC needs two different PI allocation policies for > these two different areas: > > For Exchange Points > --------------------------- > > These need a small, non-wasteful, low maintenance allocation - for > example, an allocation of a /44 would allow for 16 "networks" (each of > /48) to be established. A /48 is more than suitable for a single (even > geographically dispersed) IXP, thus a /44 should be sufficient for a > country or a countries ISPA. (By this - I'm thinking of South Africa > with currently only one active peering point, but with potential > expansion to a total of three points - but all managed by a single ISPA > type organisation). > I'd like to see AfriNIC allocate these /44's out of a single /32, which > means there are 4096 of these allocations available. These should be > only used for IXP's and should (I'd like to suggest) have no > re-occurring charge associated with them. > The allocation could be made to the ISPA type organisation - so that > there is no need for ongoing maintenance of the allocation (or at least > greatly reduce the maintenance burden on AfriNIC). > I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) > within the AfriNIC region. > By allocating a /44, the Reverse DNS responsibilities (and hence - usage > of AfriNIC resources) is minimalised and filtering could also be done on > /44's. The allocations should be made on /40 boundaries so when there is > a need to allocate a particular country (or ISPA) with additional space, > to do so from the same /40. This allows for 256 different "countries". > Technically - IXP allocations do not need to be globally route-able - so > this type of allocation should be fine. > The other assumption here is that the IXP (or ISPA - whatever) is a > non-commercial (non-profit) organisation - in order to be exempt from > re-occurring fees. > (By extension, maybe even allocate a /32 to AfrISPA - and let them > delegate onwards? - but I'm trying to not have options) > > For other existing holders of IPV4 PI Space > --------------------------------------------------------- > > For all organisations that currently have IPV4 PI space within the > AfriNIC region, they should be allowed to obtain full /32's of IPV6 > space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an > AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or > proof that it has been requested and is impending. > (kiss - Keeping It Simple) > > > > No policy is exempt from changes in the future. The above policy > suggestions are to tackle todays requirements whilst keeping them > flexible enough that they may serve the AfriNIC regions needs for the > next few years. -- $ whois -h whois.afrinic.net VIN1-AfriNIC From aa at tenet.ac.za Thu Dec 14 18:06:46 2006 From: aa at tenet.ac.za (Andrew Alston) Date: Thu Dec 14 18:08:06 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <200612141825.08332.vincent@kenic.or.ke> References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> <200612141825.08332.vincent@kenic.or.ke> Message-ID: <000001c71f99$e24e5430$a6eafc90$@ac.za> This is possible, but at the same time it has a huge drawback. If you reserve a /32 for each block you have to drastically increase the size of the base block the allocations are coming from in order for people to do filter adjustments to allow the /48s through from a specific prefix range. (For example, if you were doing /48s outta a /30 prefix you could have a single filter for the /30, in the scenario suggested below you would need a block of /16 in order to assign 65536 blocks of PI space, and considering that each RIR is allocated v6 blocks from ICANN in blocks of /12 (as far as I know, I'm open to correction on this), that's 1/16th of the total space in reserve to allocate /48s, with the potential to expand) At the same time, maybe a /16 reservation with /48s on /32 boundaries is a good idea, because it does allow for increases in P.I space within the same block that are contiguous, meaning that the routing tables wouldn't grow upon the allocation of more space, the size of the announcements would just grow. I guess it depends, would AfriNIC be prepared to allocate a /16 of their assigned /12 to this purpose? Thanks Andrew Alston TENET - Chief Technology Officer -----Original Message----- From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net] On Behalf Of Vincent Ngundi Sent: Thursday, December 14, 2006 5:25 PM To: AfriNIC Policy Working Group List Subject: Re: [policy-wg] IPV6 PI space How about we assign a _minumum of a /48 (those who need more will have to justify that to AfriNIC) to end users and critical infrastructure providers and reserve a /32 for each assigned /48? Regards, -Vincent On Thu December 14 2006 16:34, Andrew Alston wrote: > Hi There, > > Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due > to other commitments, however, having been involved in the P.I debate for a > while and having kept a close watch on the developments in this regard > around the world, I tend to take a different view on this. > > I firmly believe that with regards P.I space, a /48 allocation is enough. > Firstly, for IXP space, there is a trend to move towards /126 networks on > point to point allocations (do not use /127's, there are a variety of > reasons for this), therefore, IXP's could operate off a single /48, > utilizing /64's per IXP, and utilizing /126 networks for the actual peering > requirements. > > Secondly, with regards to end user networks, for AfriNIC to allocate /32's > in P.I space would again run contrary to what the global trends are, ARIN > has agreed to /48 P.I space, and (someone correct me if I 'm wrong here), > APNIC is about to ratify their /48 P.I policy. > > Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an > end point network, a /48 should be more than sufficient for P.I allocations > to individual companies. ISP's should qualify for /32s and become LIR's if > they want the /32s and are allocating onwards. > > I would prefer therefore that as per global trends, AfriNIC allocates a set > block out of which to assign /48 P.I prefix's (possibly a /30 or a /31), > and assigns the /48s outta that prefix for all P.I space. That block can > then be made public, so that those of us that update filters to filter /48 > deaggregated announcements can add exceptions for the specified prefix. > > I would say that where companies have more than one physical location there > could potentially be an exception to this policy, so that a company that > has multiple physically diverse branches, might for example qualify for > multiple /48s, purely for the purpose of better routing aggregation, but > again, these /48s out of the same block referred to earlier. > > The above would be more in line with what is done globally, and would avoid > the complications of BGP filters that were different for different regions! > > Thanks > > Andrew Alston > TENET - Chief Technology Officer > > -----Original Message----- > From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net] > On Behalf Of Mark J Elkins > Sent: Thursday, December 14, 2006 2:41 PM > To: AfriNIC Policy Working Group List > Subject: [policy-wg] IPV6 PI space > > Firstly - the training and knowledge received in Mauritius was great > with respect to IPV6. This has allowed me to better understand the needs > and concerns of others. However - I am by no means the expert and > expected to be corrected when incorrect. > > I believe there needs to be some sort of PI policy. I do not believe > that is is very healthy for Exchange Points (IXP's) to use the address > space of a particular ISP. I also believe that its unhealthy for some > organisations (eg - CCTLD's) that currently have IPV4 PI space and who > are Multi-Homed to also have space from any particular ISP. > > I believe that AfriNIC needs two different PI allocation policies for > these two different areas: > > For Exchange Points > --------------------------- > > These need a small, non-wasteful, low maintenance allocation - for > example, an allocation of a /44 would allow for 16 "networks" (each of > /48) to be established. A /48 is more than suitable for a single (even > geographically dispersed) IXP, thus a /44 should be sufficient for a > country or a countries ISPA. (By this - I'm thinking of South Africa > with currently only one active peering point, but with potential > expansion to a total of three points - but all managed by a single ISPA > type organisation). > I'd like to see AfriNIC allocate these /44's out of a single /32, which > means there are 4096 of these allocations available. These should be > only used for IXP's and should (I'd like to suggest) have no > re-occurring charge associated with them. > The allocation could be made to the ISPA type organisation - so that > there is no need for ongoing maintenance of the allocation (or at least > greatly reduce the maintenance burden on AfriNIC). > I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) > within the AfriNIC region. > By allocating a /44, the Reverse DNS responsibilities (and hence - usage > of AfriNIC resources) is minimalised and filtering could also be done on > /44's. The allocations should be made on /40 boundaries so when there is > a need to allocate a particular country (or ISPA) with additional space, > to do so from the same /40. This allows for 256 different "countries". > Technically - IXP allocations do not need to be globally route-able - so > this type of allocation should be fine. > The other assumption here is that the IXP (or ISPA - whatever) is a > non-commercial (non-profit) organisation - in order to be exempt from > re-occurring fees. > (By extension, maybe even allocate a /32 to AfrISPA - and let them > delegate onwards? - but I'm trying to not have options) > > For other existing holders of IPV4 PI Space > --------------------------------------------------------- > > For all organisations that currently have IPV4 PI space within the > AfriNIC region, they should be allowed to obtain full /32's of IPV6 > space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an > AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or > proof that it has been requested and is impending. > (kiss - Keeping It Simple) > > > > No policy is exempt from changes in the future. The above policy > suggestions are to tackle todays requirements whilst keeping them > flexible enough that they may serve the AfriNIC regions needs for the > next few years. -- $ whois -h whois.afrinic.net VIN1-AfriNIC _______________________________________________ policy-wg mailing list policy-wg@afrinic.net https://lists.afrinic.net/mailman/listinfo.cgi/policy-wg From k13 at nikhef.nl Thu Dec 14 19:03:53 2006 From: k13 at nikhef.nl (Rob Blokzijl) Date: Thu Dec 14 19:04:09 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <000601c71f84$aaca7e90$005f7bb0$@ac.za> References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> Message-ID: Hi there too :-) , it seems to me that your arguments all boil down to 'address conservation'. However as far as I understand in IPv6 conservation is not the most important driver for address allocation policy. It is route conservation. So, arguments like /nnn should be enough address space for a specific purpose is far less important then the aggregation and routing aspects. I think, but then I may be wrong of course :-) Greetings, Rob On Thu, 14 Dec 2006, Andrew Alston wrote: > Hi There, > > Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due to > other commitments, however, having been involved in the P.I debate for a > while and having kept a close watch on the developments in this regard > around the world, I tend to take a different view on this. > > I firmly believe that with regards P.I space, a /48 allocation is enough. > Firstly, for IXP space, there is a trend to move towards /126 networks on > point to point allocations (do not use /127's, there are a variety of > reasons for this), therefore, IXP's could operate off a single /48, > utilizing /64's per IXP, and utilizing /126 networks for the actual peering > requirements. > > Secondly, with regards to end user networks, for AfriNIC to allocate /32's > in P.I space would again run contrary to what the global trends are, ARIN > has agreed to /48 P.I space, and (someone correct me if I 'm wrong here), > APNIC is about to ratify their /48 P.I policy. > > Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an > end point network, a /48 should be more than sufficient for P.I allocations > to individual companies. ISP's should qualify for /32s and become LIR's if > they want the /32s and are allocating onwards. > > I would prefer therefore that as per global trends, AfriNIC allocates a set > block out of which to assign /48 P.I prefix's (possibly a /30 or a /31), and > assigns the /48s outta that prefix for all P.I space. That block can then > be made public, so that those of us that update filters to filter /48 > deaggregated announcements can add exceptions for the specified prefix. > > I would say that where companies have more than one physical location there > could potentially be an exception to this policy, so that a company that has > multiple physically diverse branches, might for example qualify for multiple > /48s, purely for the purpose of better routing aggregation, but again, these > /48s out of the same block referred to earlier. > > The above would be more in line with what is done globally, and would avoid > the complications of BGP filters that were different for different regions! > > Thanks > > Andrew Alston > TENET - Chief Technology Officer > > -----Original Message----- > From: policy-wg-bounces@afrinic.net [mailto:policy-wg-bounces@afrinic.net] > On Behalf Of Mark J Elkins > Sent: Thursday, December 14, 2006 2:41 PM > To: AfriNIC Policy Working Group List > Subject: [policy-wg] IPV6 PI space > > Firstly - the training and knowledge received in Mauritius was great > with respect to IPV6. This has allowed me to better understand the needs > and concerns of others. However - I am by no means the expert and > expected to be corrected when incorrect. > > I believe there needs to be some sort of PI policy. I do not believe > that is is very healthy for Exchange Points (IXP's) to use the address > space of a particular ISP. I also believe that its unhealthy for some > organisations (eg - CCTLD's) that currently have IPV4 PI space and who > are Multi-Homed to also have space from any particular ISP. > > I believe that AfriNIC needs two different PI allocation policies for > these two different areas: > > For Exchange Points > --------------------------- > > These need a small, non-wasteful, low maintenance allocation - for > example, an allocation of a /44 would allow for 16 "networks" (each of > /48) to be established. A /48 is more than suitable for a single (even > geographically dispersed) IXP, thus a /44 should be sufficient for a > country or a countries ISPA. (By this - I'm thinking of South Africa > with currently only one active peering point, but with potential > expansion to a total of three points - but all managed by a single ISPA > type organisation). > I'd like to see AfriNIC allocate these /44's out of a single /32, which > means there are 4096 of these allocations available. These should be > only used for IXP's and should (I'd like to suggest) have no > re-occurring charge associated with them. > The allocation could be made to the ISPA type organisation - so that > there is no need for ongoing maintenance of the allocation (or at least > greatly reduce the maintenance burden on AfriNIC). > I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) > within the AfriNIC region. > By allocating a /44, the Reverse DNS responsibilities (and hence - usage > of AfriNIC resources) is minimalised and filtering could also be done on > /44's. The allocations should be made on /40 boundaries so when there is > a need to allocate a particular country (or ISPA) with additional space, > to do so from the same /40. This allows for 256 different "countries". > Technically - IXP allocations do not need to be globally route-able - so > this type of allocation should be fine. > The other assumption here is that the IXP (or ISPA - whatever) is a > non-commercial (non-profit) organisation - in order to be exempt from > re-occurring fees. > (By extension, maybe even allocate a /32 to AfrISPA - and let them > delegate onwards? - but I'm trying to not have options) > > For other existing holders of IPV4 PI Space > --------------------------------------------------------- > > For all organisations that currently have IPV4 PI space within the > AfriNIC region, they should be allowed to obtain full /32's of IPV6 > space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an > AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or > proof that it has been requested and is impending. > (kiss - Keeping It Simple) > > > > No policy is exempt from changes in the future. The above policy > suggestions are to tackle todays requirements whilst keeping them > flexible enough that they may serve the AfriNIC regions needs for the > next few years. > > From woody at pch.net Thu Dec 14 21:52:32 2006 From: woody at pch.net (Bill Woodcock) Date: Thu Dec 14 21:52:51 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <000601c71f84$aaca7e90$005f7bb0$@ac.za> References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> Message-ID: On Thu, 14 Dec 2006, Andrew Alston wrote: > I firmly believe that with regards P.I space, a /48 allocation is enough. > Firstly, for IXP space, there is a trend to move towards /126 networks on > point to point allocations (do not use /127's, there are a variety of > reasons for this), therefore, IXP's could operate off a single /48, > utilizing /64's per IXP, and utilizing /126 networks for the actual peering > requirements. While the peering would be directly across the /48 or /64, rather than across a bunch of point-to-points (which, if needed, would be supplied by the peers, rather than the IXP, if done following the practices used in the rest of the world), I can verify Andrew's assertion that a /64 is what an IXP needs. A /48 is, therefore, also sufficient. And for the sake of simplicity, I'd strongly recommend just making all v6 PI allocations be /48s, period. > Secondly, with regards to end user networks, for AfriNIC to allocate /32's > in P.I space would again run contrary to what the global trends are, ARIN > has agreed to /48 P.I space, and (someone correct me if I 'm wrong here), > APNIC is about to ratify their /48 P.I policy. Yes, that's correct. > These need a small, non-wasteful, low maintenance allocation - for > example, an allocation of a /44 would allow for 16 "networks" (each of > /48) to be established. This is incorrect. An IXP, by definition, is a single subnet, across which all participants can reach each other. Therefore, it need never be more than a single /64. A /44 is wasteful, since only 1/2^20 of it, or 0.00009% could ever be assigned. And bear in mind that even then, the largest exchange points the world has ever known have had fewer than 500 participants, so in terms of actual IP addresses used, as opposed to subnets assigned, at _best_, that would be 0.00000000000000000000005% utilization. Again, not very efficient. I don't think you need to be worrying about giving IXPs room to grow. They have plenty. > A /48 is more than suitable for a single (even geographically > dispersed) IXP There's no such thing, again by definition. > a /44 should be sufficient for a country or a countries ISPA. Since no routing aggregation is possible, there's no benefit to assigning IXP subnets for a country in a nominally-aggregatable manner, and this is a false economy, resulting in additional wasted space. And there's no inherent connection between IXPs and ISPAs; in fact, exactly the opposite. The connection in South Africa is a fluke which the market hasn't yet corrected because there aren't sufficient market forces at work there. So, briefly, what you could do, which is what's working elsewhere, is to stick to the basis of what Andrew is suggesting: make all PI allocations /48s, and leave it at that. Nice and simple. -Bill From vincent at kenic.or.ke Fri Dec 15 13:41:28 2006 From: vincent at kenic.or.ke (Vincent Ngundi) Date: Fri Dec 15 13:42:24 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> Message-ID: <200612151441.29916.vincent@kenic.or.ke> On Thu December 14 2006 22:52, Bill Woodcock wrote: > On Thu, 14 Dec 2006, Andrew Alston wrote: > > I firmly believe that with regards P.I space, a /48 allocation is > > enough. Firstly, for IXP space, there is a trend to move towards /126 > > networks on point to point allocations (do not use /127's, there are > > a variety of reasons for this), therefore, IXP's could operate off a > > single /48, utilizing /64's per IXP, and utilizing /126 networks for > > the actual peering requirements. > > While the peering would be directly across the /48 or /64, rather than > across a bunch of point-to-points (which, if needed, would be supplied by > the peers, rather than the IXP, if done following the practices used in > the rest of the world), I can verify Andrew's assertion that a /64 is > what an IXP needs. A /48 is, therefore, also sufficient. And for the > sake of simplicity, I'd strongly recommend just making all v6 PI > allocations be /48s, period. > I agree though we should also consider the need for additional assignments (within the same block) thus the need to reserve a /32. > > Secondly, with regards to end user networks, for AfriNIC to allocate > > /32's in P.I space would again run contrary to what the global trends > > are, ARIN has agreed to /48 P.I space, and (someone correct me if I > > 'm wrong here), APNIC is about to ratify their /48 P.I policy. > > Yes, that's correct. > Which approach are we taking here while coming up with a solution: Is it: (a) looking at what other RIR's are doing (b) considering the needs of the AfriNIC community (c) both Regards, -V > > These need a small, non-wasteful, low maintenance allocation - for > > example, an allocation of a /44 would allow for 16 "networks" (each > > of /48) to be established. > > This is incorrect. An IXP, by definition, is a single subnet, across > which all participants can reach each other. Therefore, it need never be > more than a single /64. A /44 is wasteful, since only 1/2^20 of it, or > 0.00009% could ever be assigned. And bear in mind that even then, the > largest exchange points the world has ever known have had fewer than 500 > participants, so in terms of actual IP addresses used, as opposed to > subnets assigned, at _best_, that would be 0.00000000000000000000005% > utilization. Again, not very efficient. I don't think you need to be > worrying about giving IXPs room to grow. They have plenty. > > > A /48 is more than suitable for a single (even geographically > > dispersed) IXP > > There's no such thing, again by definition. > > > a /44 should be sufficient for a country or a countries ISPA. > > Since no routing aggregation is possible, there's no benefit to assigning > IXP subnets for a country in a nominally-aggregatable manner, and this is > a false economy, resulting in additional wasted space. And there's no > inherent connection between IXPs and ISPAs; in fact, exactly the opposite. > The connection in South Africa is a fluke which the market hasn't yet > corrected because there aren't sufficient market forces at work there. > > So, briefly, what you could do, which is what's working elsewhere, is to > stick to the basis of what Andrew is suggesting: make all PI allocations > /48s, and leave it at that. Nice and simple. > > -Bill > > _______________________________________________ > policy-wg mailing list > policy-wg@afrinic.net > https://lists.afrinic.net/mailman/listinfo.cgi/policy-wg -- $ whois -h whois.afrinic.net VIN1-AfriNIC From aa at tenet.ac.za Fri Dec 15 15:32:40 2006 From: aa at tenet.ac.za (Andrew Alston) Date: Fri Dec 15 15:33:01 2006 Subject: [policy-wg] IPV6 PI space In-Reply-To: <200612151441.29916.vincent@kenic.or.ke> References: <45814659.6000806@posix.co.za> <000601c71f84$aaca7e90$005f7bb0$@ac.za> <200612151441.29916.vincent@kenic.or.ke> Message-ID: <000301c7204d$846ff990$8d4fecb0$@ac.za> > Which approach are we taking here while coming up with a solution: > > Is it: > (a) looking at what other RIR's are doing > (b) considering the needs of the AfriNIC community > (c) both I definitely think we need to take option (c) on this one. It is imperative that we remember that how allocations are done impacts how future routing is done, and since BGP and the BGP tables have global reach, and it is not only the AfriNIC community that is affected by this. The impact I refer to relate specifically to filtering of /48s versus /32s, having specific blocks out of which /48s and more specifics are permitted and other such things. Just my 2c Andrew Alston TENET - Chief Technology Officer