Hi Brian, Though there are no requirements as you said about TCP header being seen, we know of issues that have happened in IPv4. By leaving the same in IPv6 we could very easily be inviting further simpler attacks.
By not seeing the TCP field, the level of granularity considerably reduces for "firewalling" and other application level tweaks that are now done over the internet. Is there a reason we should not specify such a limit? Backward compatibility, etc? Thanks, Vishwas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter Sent: Friday, November 25, 2005 4:25 PM To: Stig Venaas Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments Stig Venaas wrote: > On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: > >>Hi Janos, >> >>I think that is the minimum Link MTU and not the smallest size non-last >>fragment. >> >>Can you point me to the RFC/ draft which says what you stated? > > > Yes, I believe that is the minimum link MTU. So, obviously one fragment > might be smaller. I haven't seen anything say which fragment (reasonable > that it is the last, but haven't seen anything saying it must be), and > nothing prohibiting leaving several fragments smaller. > > Also, there is sadly nothing saying overlapping fragments are not > allowed. I suppose people writing code are assumed to exercise common sense, e.g. make the first fragment as large as possible and don't overlap fragments. But neither is required to make reassembly work. (Nor is in-order reception of fragments required.) It isn't a requirement in the Internet that intermediate systems can see the transport header, so none of this seems to me to be a bug in RFC 2460. The Unfragmentable Part definition there seems correct to me. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
