[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    AfriNIC, ULA-C, & "why not just get PI space"
From:       bill fumerola <billf () mu ! org>
Date:       2007-06-27 20:48:14
Message-ID: 20070627204814.GR31273 () elvis ! mu ! org
[Download RAW message or body]

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
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]