Grigory
Grigory Kljuchnikov wrote:
>
> 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?
What do you do for IPv4? Do the same for consisency. Most implementations
increment an error counter and drop the packet.
>
> 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?
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.
>
> 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?
Our implementation sends a ICMPv6 Parameter Problem code 0 message
(ICMP6_PARAMPROB_HEADER)
for non-multicast packets.
>
> 4. Jumbo Payload options errors.
> 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
> hop-by-options header?
>
Good question. I would guess it's an error...?
> 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.
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.
> 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?
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
>
> 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 PROTECTED]
> --------------------------------------------------------------------
--
++++++++++++++++++++++++++++++++++++++++++++++++++++
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 PROTECTED]
--------------------------------------------------------------------
