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:31:43
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.

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

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