In many RIRs the existing policies for IPv6 PA also state somehow that the prefix need to be announced (AND aggregated) in a specific time (1 or 2 years), so this is not something new. I'm not saying it is good or bad, I agree or disagree, just as an info.
Regards, Jordi > De: bill fumerola <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Mon, 9 Jul 2007 16:44:18 -0700 > Para: Stephen Sprunk <[EMAIL PROTECTED]> > CC: <[email protected]> > Asunto: Re: draft-ietf-ipv6-ula-central-02.txt > > On Mon, Jul 09, 2007 at 09:48:12AM -0500, Stephen Sprunk wrote: >> Good grief. The RIRs today cannot guarantee ULA-C addresses _won't_ be >> routed any more than they can guarantee PI/PA addresses _will_ be routed. >> You seem to be proposing a shift in RIR policy where anyone who doesn't >> play ball with arbitrary IETF rules get their allocations/assignments >> revoked... Sorry, but I'm not signing that contract, nor is anyone else. >> It'd never pass community consensus. >> >> RIRs have no power to do that today. Routability of prefixes is solely in >> the hands of ISPs that accept (or not) those routes. And we do _not_ want >> a world where some group of ivory tower academics and vendors tell >> operators what they _must_ do on their own networks. The Internet is >> successful due to cooperation inspired by enlightened self-interest, not >> central control. > > AfriNIC apparently has decided they can get into the routability business > by stipulating that PIv6 space allocated must be 'announced' within a > year or it will be taken back. the first time they use that clause to > take back space, they'll have solidified that ability in their region. > > power assumed is power allowed is power granted. > > i agree that the routability verbiage in the AfriNIC PIv6 policy is bad > policy. i agree that each standards body and community service provider > has their place in making the the bits spin around the world properly. > i dispute that the IETF is powerless to give IANA and operators more > optionality (that they may choose to use or not use) simply because there > exists one other cat-skinning technique (depending where the cat currently > resides). > > will ULA-* packets escape networks? yes. bogus packets leak out of > networks all the time. there's every reason to block packets from ULA-* > prefixes not in use by you everywhere possible as it applies to your > network. private agreements to exchange ULA-[CG] routes between partner > companies notwithstanding. > > will ULA-* routes leak? yes, but plenty of bogus routes leak now. RFC1918 > prefixes, prefixes that aren't allocated, prefixes that people know "it's > ok to steal from those for internal use, since my customers will never > need routability to those prefixes", prefixes leaked out of just plain > stupidity. stopping ULA-[CG] will have zero impact on bogus routes in > the table: other efforts are addressing that, hopefully with success. > > wouldn't it be nice if we could attach a contact to those leaked routes > and/or packets? it may not always be accurate, but it'd give a better > starting point than figuring out where that packet sourced 10.5.15.5 > came from. i'm not saying depend on it, just that more accountability > cannot be a bad thing. > > wouldn't it be nice to discuss what value ULA-[CG] prefixes could add, > instead of bringing up every possible way network addressing can be > abused. this is the wrong forum to discuss well known abusive/bogus/broken > engineering. that can be applied to any address class. > > i don't expect to change any opinions on this very religious topic. i > just hope that this doesn't get reduced to being passed back and forth > as Not Our Problem between RIRs and this WG. i hope bad RIR policies & > proposals aren't being used as examples of why this something the IETF > should stay out of. > > should the I-D become standard: i hope people violently opposed to > ULA-[CG] don't use it, don't route it, don't announce it, and don't > accept announcements of it. that is the benefit of autonomous systems. > i hope people in favor of it are able to use the space in ways that help > them build the networks they want with all the possible tools and methods > available to them. used incorrectly, those operators will face all the > usual consequences of those who operate poorly run networks. > > > -- bill (who will stop leaking packets on the topic) > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
