In message <6fae3df4-b5b4-4f21-9098-761523745...@kumari.net>, Warren Kumari writes: > > On Jun 12, 2013, at 2:44 PM, Robert Elz <k...@munnari.oz.au> wrote: > > > Date: Wed, 12 Jun 2013 19:49:08 +0200 > > From: Gert Doering <g...@space.net> > > Message-ID: <20130612174908.gt2...@space.net> > > = > > > | Loop back to about 50 messages earlier in this thread, > > = > > > I don't generally read this list (any more) - just happened to see the > > past hour's worth of messages, so I have no idea what was 50 messages > > earlier, but ... > > = > > > | We're not talking ivory tower theoretical routers. We're talking about > > | devices that can stand the heat out there, like "be able to apply diffe= > rent > > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > > | ICMP packets from the world". This MUST be done by the hardware, and it > > | MUST be able to look at *Layer 4* information. > > = > > > If that's the issue, then the routers should just be treating any packet = > with > > a frag header like dirt. = > > > You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 ? > > Seeing as I filter on routers (which don't do reassembly) and I want to kno= > w what's actually in the packets I let into my network, they just get dropp= > ed on the floor. > Ain't nobody noticed, so, if it ain't broke=85 > > W
Don't take lack of complaints as "nobody noticed". If you want complaints then nameserver vendors can remove the code which tries you handle your broken routers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
