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

RFC2460 problem - error processing of Routing Header



Hi, all.

I found a problem in RFC2460, about error processing of Routing Header.
It does not define the behavior of End Node when the End Node received
the packet which has odd Hdr.Ext.Len.


(Section 4.4)
>    A Routing header is not examined or processed until it reaches the
>    node identified in the Destination Address field of the IPv6 header.
>    In that node, dispatching on the Next Header field of the immediately
>    preceding header causes the Routing header module to be invoked,
>    which, in the case of Routing Type 0, performs the following
>    algorithm:
> 
>    if Segments Left = 0 {
>       proceed to process the next header in the packet, whose type is
>       identified by the Next Header field in the Routing header
>    }
>    else if Hdr Ext Len is odd {
>          send an ICMP Parameter Problem, Code 0, message to the Source
>          Address, pointing to the Hdr Ext Len field, and discard the
>          packet
>    }
<<< snip >>>


When the IPv6 packet with the Routing Header is as follows (example):

   [IPv6 Header]
      Source Address: host-0
      Destination Address: host-4
      Next Header: Routing Header
   [Routing Header]
      Next Header: ICMPv6
      Hdr.Ext.Len: 5
      Routing Type: 0
      Segment Left: 0
      Address: router-1
      Address: router-2
      Address: router-3
   [ICMPv6]
      ICMPv6 Echo Request


The Routing Header in this packet has Hdr.Ext.Len with invalid odd number
and Segment Left with 0.

RFC says that the End Node (host-4) will process the Next Header (ICMPv6),
but Hdr.Ext.Len has inaccurate value, so Host-4 does not have the way
to get the correct starting point of the Next Header.


   [Routing Header processing]
      Segment Left == 0
          -> goes to Next Header

   [Between the Routing Header and the Next Header (not defined)]
      Header Ext. Length == 5 (odd)
          -> discards the packet and transmits ICMP Parameter Problem?
          -> or seeks 5*8 = 40 octets without considering HdrExtLen is odd?
             (There is not the starting point of the Next Header.
              There is the middle of Address[3] in Routing Header.)

   [Next Header processing]
      (What will happen?)


I think that End Node should also check like Intermediate Node
that the Hdr.Ext.Len is not odd number, because Hdr.Ext.Len is
used by not only Intermediate Node but End Node.

So I propose to replace the first two items of the algorithm.


>    if Hdr Ext Len is odd {
>          send an ICMP Parameter Problem, Code 0, message to the Source
>          Address, pointing to the Hdr Ext Len field, and discard the
>          packet
>    }
>    else if Segments Left = 0 {
>       proceed to process the next header in the packet, whose type is
>       identified by the Next Header field in the Routing header
>    }


Thank you.


-- 
OOTOMO Hiroyuki <Hiroyuki.Ootomo@jp.yokogawa.com>
Gr. 1, Engeneering department 1, Development center, ATE headquarters
Yokogawa Electric Corporation
URL: http://www.yokogawa.com/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------