Fred, See below... On 10/10/2013 06:42, Templin, Fred L wrote: > Hi Ole, > >> -----Original Message----- >> From: Ole Troan [mailto:otroan@xxxxxxxxxxxxx] >> Sent: Wednesday, October 09, 2013 10:31 AM >> To: Templin, Fred L >> Cc: Ronald Bonica; ipv6@xxxxxxxx; ietf@xxxxxxxx >> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> >> (Implications of Oversized IPv6 Header Chains) to Proposed Standard >> >> Fred, >> >>>>>> -----Original Message----- >>>>>> From: Ronald Bonica [mailto:rbonica@xxxxxxxxxxx] >>>>>> Sent: Tuesday, October 08, 2013 5:46 PM >>>>>> To: Ole Troan; Templin, Fred L >>>>>> Cc: ipv6@xxxxxxxx; ietf@xxxxxxxx >>>>>> Subject: RE: Last Call: <draft-ietf-6man-oversized-header-chain- >>>> 08.txt> >>>>>> (Implications of Oversized IPv6 Header Chains) to Proposed >> Standard >>>>>> I agree with Ole. >>>>> How so? A tunnel that crosses a 1280 MTU link MUST fragment >>>>> in order to satisfy the IPv6 minMTU. If it must fragment, then >>>>> an MTU-length IPv6 header chain would not fit within the first >>>>> fragment, and we have opened an attack vector against tunnels. >>>>> This is not a matter to be agreed or disagreed with - it is >>>>> a simple fact. >>>> right, and RFC2460 has this to say about it: >>>> >>>> IPv6 requires that every link in the internet have an MTU of 1280 >>>> octets or greater. On any link that cannot convey a 1280-octet >>>> packet in one piece, link-specific fragmentation and reassembly >> must >>>> be provided at a layer below IPv6. >>> Very true. In this case, the "link" is the tunnel and the "link- >> specific >>> fragmentation" is IPv6 fragmentation. Which places the first part of >> an >>> MTU-length IPv6 header chain in the first fragment and the remainder >> of >>> the header chain in the second fragment. >> indeed. which would violate the MUST in oversized-header-chain. >> >> what do we do? >> a) ignore this particular corner case >> b) suggest the tunnel head end to drop the packet >> c) develop a new tunnel segmentations scheme that doesn't depend on >> IPv6 fragmentation. :-) > > You know I have an interest in alternative c), but that does not > address the issue of splitting the header chain across multiple > fragments. So, my choice is: > > d) limit the size of the IPv6 header chain so that the chain will > fit within the first fragment by having the host limit the chain > to the MTU size minus 256 bytes. > > Actually, I would be even happier if we just asked the host to limit > the size of the header chain to 1024 bytes regardless of the path MTU. Since the problem recurses as we tunnel tunnels, I don't see how any finite limit can solve the problem. 1280 itself is a pragmatic choice of "a bit shorter than 1500". The problem is that you are asserting that middleboxes that a tunnel passes through are expected to examine the complete header chain of the encapsulated packet even if the encapsulated packet is a fragment. I think that's an unreasonable expectation. A reasonable expectation is that middleboxes should identify the encapsulated packet as a payload that they cannot analyse, and let it go (unless they have a policy setting to drop tunnelled packets, which is a different discussion). I understood that to be the basis on which the WG reached consensus. Brian