At 1:04 PM +0300 6/6/00, Markku Savela wrote:
>The RFC-2460 in chapter 4 explains that one should return a "Parameter
>Problem" ICMP for unrecognized extension header. This has an offset
>pointing to the "next header field".
>
>Question: What is the value of this offset, if the problematic "next
>header" was uncovered by ESP processing?
It should be the offset of the byte containing the unrecognized or
unsupported Next header value, counting from the beginning of the packet.
>Admittedly, ESP is a bad example, because one probably should not be
>sending the ICMP in this case. But, there might be other future funny
>extension headers that produce the next header value in strange
>ways?
Every extension header has a Next Header field somewhere, and that
field has some offset from the start of the packet, so what's the
problem?
>[Just asking before changing our implementation, which incorrectly(?)
>returns ICMP Unreachable (type=1, code=4) for any protocol that
>nobody listens.
That is indeed incorrect. That error message should only be used for
protocols that:
- you *do* recognize
- are known to have ports
- have no process listening on the destination port
- have no protocol-specific method to report the error (such as
TCP reset).
In practice, this means destination unreachable - port unreachable is only
intended for UDP. (It's a little layer violation that it exists.)
> Unknown extension header is just a protocol that has
>no handler installed or activated].
That's fine. Such cases should be reported as parameter error - unrecognized
next header.
Steve
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
