On Jan 4, 2012, at 12:27 AM, Dan Wing wrote: >> -----Original Message----- >> From: Jared Mauch [mailto:[email protected]] >> Sent: Tuesday, January 03, 2012 6:15 PM >> To: Dan Wing >> Cc: Eric Vyncke (evyncke); [email protected] >> Subject: Re: Fragmentation-related security issues >> >> Broken and misconfigured network elements will always exist. We needn't >> create solutions for everyone's problems that should be addressed >> otherwise. > > Ok. So what of the IPv6/IPv4 translators which are placed in front > of existing, operational IPv4 networks.
If the translator can't talk at some larger MSS, it can reduce that, one does this on cisco with 'ip tcp adjust-mss' on the interface for TCP. I assume nobody forgot to create a comparable command for ipv6 :) For UDP, there are silent drops/blackholes today. Translation technologies are a bandaid and expected to have tradeoffs. This will be one of them that may make going native more attractive. Expecting the ICMP messages that may be dropped already to be propagated and translated properly isn't ideal, but this is something that doesn't need lots of attention. - Jared > > -d > > >> Jared Mauch >> >> On Jan 3, 2012, at 8:23 PM, "Dan Wing" <[email protected]> wrote: >> >>>> -----Original Message----- >>>> From: Eric Vyncke (evyncke) [mailto:[email protected]] >>>> Sent: Tuesday, January 03, 2012 1:53 PM >>>> To: Dan Wing (dwing) >>>> Cc: [email protected] >>>> Subject: RE: Fragmentation-related security issues >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On >> Behalf >>>> Of Dan >>>>> Wing (dwing) >>>> >>>>> So, I don't think we can just wish away packet-too-big < 1280. >>>> >>>> Rather than dropping those ICMP PTB, let's accept them but let the >> OS >>>> decide which is the minimum size path MTU that it can >>>> accept/tolerate... >>>> - For a server, this min path MTU should be large (to avoid DoS) >>>> - For a host, this min path MTU could be small >>>> >>>> Of course, if the path is symmetric, the path MTU will be the same >> on >>>> both direction (assuming everything is well configured). >>>> >>>> OTOH, as written by Jared, let's fail it hard so it is noticeable by >>>> the user is another technique... but with a dual-stack and happy >> eye- >>>> ball, the end-user will notice nothing and will stay happy with >> IPv4. >>> >>> Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, >>> and I think also as implemented by Apple, will _not_ fail nicely >>> on Path MTU Discovery problems. It will only fail nicely if >>> connectivity fails (that is, unable to establish the TCP >>> connection). >>> >>> -d >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [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 --------------------------------------------------------------------
