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 --------------------------------------------------------------------
