AfriNIC has implemented a PIv6 space policy[0]. part of it states: "* The 'end-site' must show a plan to use and announce the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AfriNIC."
the policy document[0] itself says "Open for Discussion" but: http://www.afrinic.net/policy.htm#policies afpol-v6200701 IPv6 Provider Independent (PI) Assignment for End-Sites 13.06.2007 Implemented ... lists it as implemented. those in the AfriNIC region who want globally unique, registered space but do not plan to "announce the IPv6 PI address space" have no method of getting any such space. if anyone reads this differently than i do, please educate me. i don't think they mean 'announce' to partner(s) or within intra-AS boundaries, but admittedly i haven't read their mail archives to see if this angle was ever brought up. this leaves a few options like getting PA space from an LIR or becoming a LIR(?!) as an option of getting space for the purpose of unique local addressing, but the downside(s) to that seem too obvious to mention. you could also announce the PI or LIR block and just null route it on your edge, but i don't think that's the spirit of the policy and is a slap in the face to those trying to keep the IPv6 global routing tables tight & clean. so in the AfriNIC region, "why not just get PI space for what you want ULA-C for" isn't an option and the alternatives and workarounds aren't that clean. in that region there is a separate ULA-C policy[1] 'under discussion' (and others[2] submitted by the same person), but i think there's been general consensus on RIR lists and history on policies with global implications that says the outcome of an IETF decision one way or another on the fate of ULA-C (or another I-D that addresses similar needs perhaps out of a different prefix than ULA-*) is more desirable than individual RIRs acting prematurely or making policy based on proposed I-Ds. nothing prevents other RIRs from changing their policies later to have similar requirements. also, nothing indicates other RIRs are considering changing their policies in this direction now or in the future. in no way is this post an endorsement of the I-D as-is nor a move to rush to move this document forward, just to point out a current event with relevancy to the discussion. as a result of AfriNIC's policy and the discussions here, i believe there can to be some common ground found: (*) there is a desire for organizations to acquire globally unique network assignments for prefixes that SHALL NOT appear in the DFZ routing tables and addresses from these prefixes SHALL NOT appear as src/dst in traffic on the forwarding plane, outside of intra-AS or private inter-AS arrangements (VPNs, private interconnect, etc). (*) acquiring PI space from RIRs for this purpose is not an option for everyone right now. that may change in either direction at any point in the future. AfriNIC may amend to accommodate this usage. other RIRs might consider similar restrictions on PIv6 space or want to allocate 'unannounced' space out of different IANA allocations causing inconsistencies amongst the RIRs. the IETF has the ability to reduce region-by-region difference by producing a document to unify the approach to assigning this class of network prefixes. (*) since these prefixes can and will appear in other inter-networks (but not the Big One), a recognized delegation from IETF to IANA for registry maintenance (and hopefully further down) adds confidence. confidence in avoiding collisions (intentional or accidental), confidence in confirming entries of route6 objects into routing registries (private or public), and confidence in the legitimate entry of those prefixes into other tools to build the proper perimeter between network edges that make network operators life easier. thanks for reading this far & sorry for the wordiness, -- bill 0. http://www.afrinic.net/docs/policies/afpol-v6200701.htm 1. http://www.afrinic.net/docs/policies/afpol-v6ula200704.htm 2. http://www.ripe.net/ripe/policies/proposals/2007-05.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------