> Date: Fri, 29 Jun 2007 15:57:29 +0000 > From: Paul Vixie <[EMAIL PROTECTED]> > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > >> So, IMHO it would be premature to turn over address >> delegation authority at this time. > > then let's keep going.
My apologies for joining the discussion a bit late, but I hadn't been aware of the issue until recently (the issue of ULA, let alone ULA-C draft(s)). I'm coming to this from the perspective of someone with an operational slant, albeit with an interest in keeping IPv6 from suffering some of the avoidable problems in IPv4 that originated in "historical" use and our collective lack of adequate experience suffering the pain that making these errors caused. Not the pain of a body blow, but of a thousand (or 270K) paper cuts. I think that UCA and UCA-C is a clever technical solution to a problem that exists primarily in the political/financial area, and which does not even have a good reason for existing. I'll summarize what I think the issues are, how I think they should best be addressed, and what the ideal-world order of events would be, and even what ultimately should happen regarding ULA and ULA-C. I think that ULA has come about as an answer to the need for IPv6 space, which does not have procedural overhead or cost (both of which occur when requesting space from RIRs). Additionally, I believe that there exist RIR policies which are resulting in some pressure towards implementing ULA/ULA-C -- policies which can and should be modified by the membership constituency of the RIRs. ULA-C is an interesting middle ground, but the mere existence of ULA-C as a concept, and as a draft that we're discussing, is a strong indicator that these RIR policies are a problem. And moreover, as a compromise, ULA-C is causing more harm than good. The requirements that I see ULA/ULA-C addressing are: - need for IPv6 space - need for this space to be globally unique - need for this space to be easily acquired - need for this space to be acquired for no cost - need for the status of this space to be easily identifyable (DFZ or not) All but the last issue, are trivially manageable by relaxing the existing requirements in place at the RIRs, for acquiring space. The basic policy requirements for space should be relaxed considerably, insofar as IPv6 blocks being globally announced, justified, and paid for. The argument about space exhaustion is trivially countered by making changes to the smallest block of PI space that is directly allocated by RIRs - e.g. to a minimum of /64, or even /56. The last item is IMHO, something that can be managed by a relatively small change to places where allocations/assignments are handled, e.g. whois or RADB type places -- support the addition of a "Local" flag, something which is entirely voluntary, and whose use for filtering is similarly voluntary. I submit the following as being valid assertions: (A) If enough members push for these changes in their RIRs, the changes will happen (B) If the changes happen, the specific and explicit need for ULA/ULA-C goes away (C) Depracating ULA/ULA-C would then be the most appropriate next step (D) Elimination of most of the major (and to some degree, "alien") elements of IPv6 will go a long, long way towards getting IPv6 deployed, including: (1) vendor support (2) scalable hardware support for IPv6 mandatory elements (3) network operator deployment (4) Host O/S and infrastructure deployment (e.g. DNS) Oddly enough, what I recommend for now is - put ULA-C on the back burner. Make travel plans to attend the next IANA meeting, and in the meantime, join the IANA mailing lists. Voice your concern over PI space issues, and the making available of small PI blocks to all comers. What I advocate in the IANA world is, of course, that everyone who has a reason to have a routing policy that differs from their upstream, be allowed to get one PI block for every place that they are unable to aggregate within a larger block (i.e. where topology requires that they announce different prefixes). And, additionally, that as many PI blocks for "ULA" use as an organization wants, be allocated. Making PI blocks move from "ULA" to "DFZ" status, is strictly something that the RIRs need to address from a membership and fee perspective, as well as policy basis. I would encourage that policies be adopted where only failure to renumber and aggregate, where such renumbering and aggregation would not impose harm, have any cost penalty associated with them. "Harm" here would be: a requirement to then deaggregate. I.e. where the result of topological merger means that the resulting network naturally would have been able to be implemented with a single prefix. Basically, if you take two networks, each with its own PI block, one of which was not previously in the DFZ, and merge them and announce both blocks, you should not be penalized if they are fundamentally not able to be aggregated by any means of renumbering (such as not being contiguous). And on the other hand, if you *could* aggregate by renumbering, that you be given a disincentive to not renumber. Keep in mind, folks, that renumbering no longer has to be an atomic event, in any sense of the word. Even at the host and interface level, IPv6 expects there to be multiple IPv6 addresses, including link-local. So, having yet another address does not seriously constitute a major PITA, and renumbering can be done by anyone on any timeframe they like. Globally unique PI blocks - one to an ASN, please; no deaggregation, please; use them however you want, just tell others if you intend them to be in the DFZ or not. Is this not a reasonable and modest proposition? Brian Dickson -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
