Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

[Ole Troan <[e-mail]>]

Fred,

>>>> -----Original Message-----
>>>> From: Ronald Bonica [mailto:[e-mail]]
>>>> Sent: Tuesday, October 08, 2013 5:46 PM
>>>> To: Ole Troan; Templin, Fred L
>>>> Cc: [e-mail]; [e-mail]
>>>> 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