Subject: How to handle some errors in IPv6 packets?

From: Grigory Kljuchnikov <[email-masked]>
Date: Tue, 9 Oct 2001 11:02:35 +0400 (MSK)

Hello,

I have several questions about handling exceptional situations
in IPv6 packets:

1. How to process packets that have incorrect version number?
Should we discard it or send an ICMPv6 error message?
Ethernet header has an identifier of the included ip-level protocol
packet.  Suppose that it identifies the  IPv6 packet but the Version
fields of the IPv6 header is not 6. What to do in this case?
Send an error, discard the packet or something else?

2. How to process packets that have incorrect payload length field?
Should we discard it or send an ICMPv6 error message?
IP receives from LAN an array of octets as well as it's length.
If payload length field contains correct value then that length is
equal to the payload length plus 40 (the length of the header).
What to do if the payload length does not match the length of
the octets array received from the LAN level?  Should we send
an ICMP error message or silently discard the message?

3.  What to do when the total size of options does not match the size
of the header (Hop-by-hop and Destination options headers)?
Each TLV options contains it's data size. What implementations are
supposed to do if the total length of options (calculated from their
Option Data length fields) does not match the length of the header?

4.  Jumbo Payload options errors.
What to do if Jumbo Payload option length is not equal to 4?
What to do if there are several Jumbo Payload options in
hop-by-options header?

5.  What to do with malformed fragments sequences?
There several possible exceptional situations not covered by
RFC 2460 Section 4.5 such as:
5.1  Fragments overlap.
5.2  Suppose we have received a fragment with M flag set to 0
("rightmost" fragment).  Then an exception is a fragment with M flag
set to 1 offset greater than the offset of the "rightmost" fragment.
How implementations are supposed to handle these cases?

Grigory Klyuchnikov, System Engineer,
Institute for System Programming
Russian Academy of Sciences

--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Tue, 9 Oct 2001 10:32:49 +0300

Just one implementors choices on these...

> From: Grigory Kljuchnikov <[email-masked]>

> Should we discard it or send an ICMPv6 error message?

I don't care what the original Ethernet framing was. I only check the
version field from IP header, and process the packet accordingly. If
it was not 4 or 6, packet is silently dropped.

> 2. How to process packets that have incorrect payload length field?

If the packet is shorter than the length indicated by the length field
of the IP header, the packet is silently dropped. If actual length is
longer, the extra octets are silently ignored and packet is processed
normally.

> Option Data length fields) does not match the length of the header?

Packet is silently dropped (while processing options, when it bumps
against the end of the option header).

> 4.  Jumbo Payload options errors.

I don't do jumbo.

> RFC 2460 Section 4.5 such as:

Hmm. currently just last received overlapped octets will end up the
final content of the packet. No error generated.

> How implementations are supposed to handle these cases?

Another hmm.. I would need to check my source :-). But, depends on
when the fragment with M=0 arrives.

- If by that time, all the preceding fragments are available, the
  packet is declared as complete. The later arriving M=1 will start a
  new assembly (which will probably time out, if nothing else
  arrives).

- If at point of M=1, I still have the assembly and M=0 has been
  received. Need to check this, probably drop the new fragment.

-- 
Markku Savela <[email-masked]>

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 09 Oct 2001 10:23:43 -0400

Grigory

> Send an error, discard the packet or something else?

What do you do for IPv4?  Do the same for consisency.  Most implementations
increment an error counter and drop the packet.

> an ICMP error message or silently discard the message?

If the payload is bigger then the actual packet, we updated error counters and
drop.  Otherwise, you have all the necessary data, so you can process the
packet.

> Option Data length fields) does not match the length of the header?

Our implementation sends a ICMPv6 Parameter Problem code 0 message
(ICMP6_PARAMPROB_HEADER)
for non-multicast packets.

> What to do if Jumbo Payload option length is not equal to 4?

We send ICMPV6 Parementer Problem code 0 message for non-multicast.

> What to do if there are several Jumbo Payload options in

Good question.  I would guess it's an error...?

> RFC 2460 Section 4.5 such as:

If you don't handle overlaping fragments, the easiest thing to do
is just drop it.  We provide an admin knob for handling overlaping
fragments.

> How implementations are supposed to handle these cases?

I am assuming in your example that you recived fragment with M=0 before
the fragment with M=1.

If the fragment with M=0 completed your fragment chain, you'll end up 
delivering the packet.  The fragment with M=1 will start a new chain.

If the fragment with M=0 did not complete your chain (i.e. you have holes),
then you can just drop the fragment with M=1 and wait for the chain to
complete.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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]
--------------------------------------------------------------------