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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Templin, Fred L wrote:

> This means that stateless firewalls are being directed to discontinue
> extension header parsing when a first encapsulated IPv6 header is
> encountered - even though there may be many more parsable (inner)
> headers that follow.

Even without tunnels, firewalls MUST be able to parse ICMPv6 error
messages generated behind it, even though ICMPv6 is explicitly
allowed to have its own lengthy header chain:

   Every ICMPv6 message is preceded by an IPv6 header and zero or more
   IPv6 extension headers. [rfc2463]

Even without firewalls, ICMPv6 still causes a problem because:

           As much of invoking packet
       as will fit without the ICMPv6 packet
       exceeding the minimum IPv6 MTU [IPv6] [rfc2463]

a host sending the original packet can not identify which packet
sent by it caused the error, if tail part of header-chain of
inner packet is omitted.

						Masataka Ohta





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]