Subject: (IPng 6474) nit-picky error conditions

From: Richard Draves <[email-masked]>
Date: Tue, 15 Sep 1998 22:57:00 -0700

I want to check my understanding of how some exceptional conditions should
be handled by receivers. Perhaps there is some implementation leeway in
these situations, in which case I'm interested in hearing what other
implementations do.

In the ICMP spec section 3.4, I read "If an IPv6 node processing a packet
finds a problem with a field in the IPv6 header or extension headers such
that it cannot complete processing the packet, it MUST discard the packet
and SHOULD send an ICMPv6 Parameter Problem message to the packet's source,
indicating the type and location of the problem."

So my general rule should be to send an icmp error unless some spec
specifically says not to, right?

For some cases, like bad version number in the header, or link-layer framing
says the packet is not big enough to contain a full IPv6 header, it would
seem prudent to drop the packet without an attempt to send an ICMP error?

If I receive a packet with a hop limit of zero, should I drop the packet
silently or send an ICMP error hop-limit exceeded? The IPv6 spec section 3
says "The packet is discarded if Hop Limit is decremented to zero" which
doesn't really address the question of receiving with the hop limit already
zero. The ICMPv6 spec section 3.3 says "If a router receives a packet with a
Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it
MUST discard the packet and send an ICMPv6 Time Exceeded message with Code 0
to the source fo the packet." So this doesn't say what a host should do. By
implication one might assume that a host should not check the hop limit at
all, but that doesn't seem right.

If I find the payload length (either in the header or from a jumbo payload
length option) is bigger than the link-layer framing's length would
indicate, I should send an parameter problem code 0 pointing at the payload
length?

If I'm a host and I receive a packet which is not sent to one of my
addresses, should I silently ignore it or send an ICMP error of some type?
The general rule says to send an error, but that seems wrong in this
situation.

If I find that there's not room left in the packet for an extension header
(payload length is too small/extension header is too big), then I should
send parameter problem code 0 pointing at the payload length? A clue here is
the jumbo payload length option spec, which has an example like this
"according to the IPv6 specification", although I can't find a discussion of
the situation in the IPv6 specification.

By analogy, if I find that there's not room left in a hop-by-hop/destination
option for an option (header is too small/option is too big), then I should
send parameter problem code 0 pointing at the extension header length byte?

If I find an option in the wrong kind of extension header (for example, if I
find a router-alert option in a destination options header), should I a)
pretend I do not recognize the option and use the high bits of the option
type to govern my behavior, or b) send parameter problem code 0 pointing at
the option type byte?

If I find an option twice, for example two jumbo payload length options,
should I use the later value? Or is it an error? The jumbo payload length
spec doesn't mention this case. But the router alert spec does, saying it's
an error ("MUST only be one option of this type, regardless of value, per
Hop-by-Hop header"), but doesn't say how receivers should handle the error.
Code 0 pointing at the option type byte of the second option?

If I receive an option that I recognize, but its size is wrong, I should
send parameter problem code 0 pointing at the option length byte?

If I receive an option that I recognize and its alignment is wrong, should I
process the option anyway? Am I allowed to send an ICMP error?

Thanks,
Rich
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 16 Sep 1998 08:41:16 -0500

> By implication one might assume that a host should not check the
> hop limit at all, but that doesn't seem right.

Except for ND packets, why should the host ever check the hop limit?
The network did the work to get a packet to the host, why waste it?
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------