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:43:29
Hi Ole,

-----Original Message-----
From: Ole Troan [mailto:otroan(_at_)employees(_dot_)org]
Sent: Wednesday, October 09, 2013 10:31 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.

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.

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

cheers,
Ole


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