This is not correct. PI is not available from 2 RIRs, and there is not a clear view of when it will become available. In one of them, because the timing of the Policy Development Process, it will take at least 15 months to get it implemented and this in the case it is approved in the next meeting in almost one year from now.
In the other one, even PA is not available unless you have 200 customers (this is the same in other RIRs that already have PI). I'm not saying that this is related to ULA-C, I still believe it should be kept separated, and ULA-C is NOT to be used as a replacement of PA/PI, and indeed, I'm convinced it will not happen because if you try that you can never be sure that your ULA-C is globally routed and consequently is 100% reachable. Anyway, I though it is important to clarify what I have explained above. Regards, Jordi > De: Brian E Carpenter <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Mon, 09 Jul 2007 10:05:21 +0200 > Para: <[EMAIL PROTECTED]> > CC: Stephen Sprunk <[EMAIL PROTECTED]>, <[email protected]> > Asunto: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt > > On 2007-07-09 06:52, [EMAIL PROTECTED] wrote: >> I think we should avoid any "straw man" arguments, as those tend not to >> actually help advance the subject matter. >> >> Just because one way of accomplishing a particular networking objective, >> involves particularly unpleasant choices, does not mean that the technology >> involved is at fault. It is also possible that the design choice was a case >> of not using the right tool for the right job. >> >>> Thus spake "Brian E Carpenter" <[EMAIL PROTECTED]> >>>> On 2007-07-06 02:59, Stephen Sprunk wrote: >>>>> Why would you ever change PI space? The issue is changing PA >>>>> space, and that's something that may need to be done every few >>>>> weeks as upstream links go up and down. >>>> Absolutely not. If you have 3 ISPs you run 3 PA prefixes all the time. >>>> If you drop or add an ISP you drop or add a prefix in a planned manner. >>>> RFC 4192. >> >> I beg to differ. >> >> PI space is available, from most if not all RIRs. >> The criteria for obtaining such is reasonable, and having multiple >> ISPs, i.e. being multihomed, generally accomplishes this. > > That's unfortunately true, but since it doesn't scale to the ten > million or so networks we expect to desire multihoming, it will > only work for a few years. That's why we need other solutions. > > Brian > >> >> ISPs are expected to have PA space available to assign to their customers. >> This does not mean that every customer can only ever use PA space from >> their ISP. It only means that customers who do not have their own PI space, >> will be able to get PA space from their ISP. >> >> If you are multihomed, the community generally expects you to use PI space. >> And that community includes your ISPs. >> >> If we did not need to have PI space being announced from anyone other than >> the core of the DFZ (those entities which are generally considered "tier 1" >> for lack of a better description), then we would only have AS paths of >> length 1, and we would be able to run EGP (the predecessor of BGP). >> >> And clearly the collection of RFCs describing IPv6 numbering schemes are >> robust enough, and the routing protocols inclusive enough, that PI space >> can be announced via ISPs, in addition to their own PA aggregates. >> >>> When my link to one of those three ISPs goes down, I have a 1/3 chance of >>> each outbound connection failing because the return path is broken (or my >>> other two upstreams do uRPF). I also have a 1/3 chance of each inbound >>> connection failing until I update DNS to remove the relevant AAAA records; >>> smarter clients will try multiple addresses for inbound connections, but >>> there'll be a delay and not all clients are that smart. >>> >>> The alternative is to renumber the entire network every time a link goes >>> up >>> or down. >> >> You should, in this case, have a PI block, not be using anyone's PA block, >> let along 3 x PA blocks. If you are using PI, you are running BGP, and >> single link failures are the kind of thing that are relatively minor events >> for any multi-connected entity, such as your network. No renumbering is >> needed. >> >>>>> Compare to the cost of a NAT box and the choice is easy. >>>> That's true if you don't put the indirect operational and user >>>> costs of NAT, plus the opportunity cost of innovation blocked >>>> by NAT, into the equation. >>> Most of the operational and innovation costs of NAT are also present with >>> a >>> stateful firewall, which any sane organization will be using, because it's >>> really the stateful inspection that burns you. >>> >>>> It *is* hard to get this into the budget unless you think strategically, >>>> and factor in the way IPv6 is designed to handle multiple PA prefixes >>>> simultaneously. >>> When presented with the choice between a paradigm shift and continuing >>> along >>> the present path, most people will pick the latter. In this case, that >>> means moving either from NAT+RFC1918 to NAT+RFC4193 or from PIv4 to PIv6. >> >> Our collective job is to ensure that scalable solutions are disseminated, >> not only in the RFCs, but in the actual implementations that customers use. >> >> This may mean some small amount of customer education. Everyone wins when >> the end customers (no matter whose customers they are) make a choice which >> is not only right for them, but good for the community as a whole. >> >> If anyone is multihomed currently, and using NAT+RFC1918, then having the >> option to go to PIv6 will likely make their life much easier. The fact >> that they would never need to renumber, is just a bonus. >> (They will have to renumber, in moving to IPv6 in any flavour, remember.) >> >>>>>> If your choices are PI vs PA then yeah NAT does look very attractive, >>>>>> but if you can have PA and "private"-PI (aka ULA) then things look a >>>>>> lot >>>>>> less blurred (IMHO). >>>>> IMHO, you underestimate how much IT folks hate renumbering. >>>> They hate renumbering IPv4 networks. I do too, having managed such an >>>> operation a couple of times. It's as a result of that hatred that >>>> IPv6 came out as it is, making RFC 4192 possible. >>> Again, RFC 4192 ignores all of the non-technical aspects of renumbering. >>> That's probably appropriate, given the IETF's domain, but it's only a tiny >>> part of what must be done. Changing the address on an interface takes a >>> few >>> seconds; the change control processes leading up to it can burn months of >>> manpower. >>> >>> You might convince me that if you do it frequently enough, the cost will >>> be >>> low, but I don't want to work anywhere that renumbers often enough to be >>> good at it. That reminds me of a scene in _Broken Arrow_ where a >>> character >>> comments he doesn't know whether to be more scared that they lost a >>> nuclear >>> weapon or that it happens often enough the military has a name for it. >>> >>>> This is *not* to say that anyone will renumber weekly, and big networks >>>> will avoid it (and are therefore candidates for PI). But for smaller >>>> networks, the hatred should be substantially less, and balance the >>>> hatred >>>> of NAT. >>> It's the smaller folks that can't get PI that hate NAT the least, because >>> they tend to have less-educated staff (or rely on consultants/vendors) and >>> may even see NAT as a good thing ("it makes me secure!"), not the evil >>> that >>> it really is. >>> >>> S >>> >>> Stephen Sprunk "Those people who think they know everything >>> CCIE #3723 are a great annoyance to those of us who do." >>> K5SSS --Isaac Asimov >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
