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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
