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. :-) cheers, Ole
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail