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

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

Reply via email to