ietf
[Top] [All Lists]

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

2013-10-09 12:21:41
Hi Ole,

-----Original Message-----
From: Ole Troan [mailto:otroan(_at_)employees(_dot_)org]
Sent: Wednesday, October 09, 2013 9:54 AM
To: Templin, Fred L
Cc: Ronald Bonica; ipv6(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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(_at_)juniper(_dot_)net]
Sent: Tuesday, October 08, 2013 5:46 PM
To: Ole Troan; Templin, Fred L
Cc: ipv6(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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.

Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

cheers,
Ole

<Prev in Thread] Current Thread [Next in Thread>