Just to remind people, RIR policy is community driven. If the operations people feel they need a policy for IPv6 allocations and assignments which takes accounts of semantic bits, they can derive consensus driven policies to do it. Its not done in the IETF. There might be an issue with how it squares against IETF goals of conservation, but thats part of the discussion in RIR policy space maybe.
I think there is a touch of catch-22 here: there isn't a clear sense this is an industry wide practice demanding that policy initiative (I do not preclude it: I just observe, it hasn't happened yet) and there is an absence of a well understood methodology of using it and applying it which differs radically in outcome from ACL based methods. If there was an IETF standard I am sure somebody could propose an allocations model which reflected it, but who knows if that would get traction. I notice that there are large providers who feel semantic bit flagging works for them. So, I do not say "nobody is doing it" as much as "nobody has said they want an RIR allocations policy which reflects it, yet" The first time this came up, I think I said to mike that I could understand ISPs wanting to say "this is a mechanism we use inside our locus of control, to flag behaviours of packets" -ie that it was unlikely there was a model for this to be meaningful between providers, but inside a single autonomous region, sure: why not. (the formalism that you didn't get the /32 under a model of consumption which assumed this kind of usage of the bits is really not a big deal for me personally, although I am sure it would upset some people) -G PS I am an RIR employee. I do not speak to policy in any formal sense. I work in research. On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <[email protected]>wrote: > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > > ===== > Mistyped and autocorrected on a clunky virtual keyboard > > On 4. jun. 2013, at 01:08, joel jaeggli <[email protected]> wrote: > > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > >> That's completely true; many switch chips cannot route on longer than > /64 prefixes, so attempting to do so starts to either heat up the software > slow path, or consume ACL entries, or is simply not supported at all. While > this is arguably a bug, it is also pretty much ubiquitous in the current > generation of ethernet switches, which are the basis for the majority of > routers. > > please cite specifics. I have no devices in the field that have such a > limitation. > > > > joel > >> > >> > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < > [email protected] <mailto:[email protected]>> wrote: > >> > >> On 04/06/2013 03:44, manning bill wrote: > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > >> > > >> >> On 03/06/2013 11:06, manning bill wrote: > >> >>> /48's are a horrible policy - one should only advertise what > >> one is actually using. > >> >> Now *that* would cause a nice fragmented DFZ... > >> >> Sander > >> >> > >> > > >> > > >> > I'm going to inject a route. One route. why do you care if its a > >> /9, a /28, a /47, or a /121? > >> > >> I've heard tell that there are routers that are designed to handle > >> prefixes up to /64 efficiently but have a much harder time with > >> prefixes longer than that, as a reasonable engineering trade-off. > >> Not being a router designer, I don't know how true this is. > >> > >> Brian > >> > >> Its -one- route. > >> > That one route covers everything I'm going to use… and nothing > >> I'm not. > >> > > >> > Is there a credible reason you want to be the vector of DDoS > >> attacks, by announcing dark space (by proxy aggregation)? > >> > Is that an operational liability you are willing to assume, just > >> so you can have "unfragmented" DFZ space? > >> > > >> > > >> > /bill > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] <mailto:[email protected]> > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > _______________________________________________ > > v6ops mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
