NAME

  DH_Type10toMC - check Destination Options Header (Type 10) to Multicast Address


TARGET

  Host and Router


SYNOPSIS

  DH_Type10toMC.seq [-tooloption ...] -pkt DH_Type10toMC.def
    -tooloption : v6eval tool option
  See also DH.def


INITIALIZATION

  None


TEST PROCEDURE

  Tester                      Target
    |                           |
    |-------------------------->|
    |   Echo Request            |
    |                           |
    |                           |
    |<--------------------------|
    |   Neighbor Solicitation   |
    |                           |
    |                           |
    |-------------------------->|
    |   Neighbor Advertisement  |
    |                           |
    |                           | 
    |<--------------------------|
    |   ICMP Error              |
    |                           |
    |                           |
    v                           v

  1. Send Echo Request
  2. Wait ICMP Error or NS
  3. If NS received then send NA, and wait ICMP Error again
  4. Receive ICMP Error

  Echo Request Data is:

        IPv6 Header
            Version            = 6
            Traffic Class      = 0
            FlowLabel          = 0
            PayloadLength      = 16
            NextHeader         = 60 (Destination Options Header)
            SourceAddress      = Tester Link Local Address
            DestinationAddress = Link Local Multicast Address

        Destination Options Header
            NextHeader         = 58 (ICMP)
            HeaderExtLength    = 0
            OptionType         = 0x82 (Unrecognized Option, Type 10)
            OptDataLength      = 4 (for 8 octets alignment)
            data               = {0,0,0,0}

        ICMP Echo Request
            Type           = 128 (Echo Request)
            Code           = 0
            Checksum       = (auto)
            Identifier     = 0xffff
            SequenceNumber = 1
            PayloadData    = {1,2,3,4,5,6,7,8}


JUDGMENT

  PASS: ICMP Error Received

        IPv6 Header
            Version             = 6
            Traffic Class       = 0
            FlowLabel           = 0
            PayloadLength       = 16
            NextHeader          = 58 (ICMP)
            SourceAddress       = Target Link Local Address
            Destination Address = Tester Link Local Address

        ICMP Error
            Type           = 4 (Parameter Problem)
            Code           = 2 (unrecognized IPv6 option encountered)
            Checksum       = (auto)
            Pointer        = 42 (Offset to unrecognized option)
            PayloadData    = (Echo Request)


REFERENCE

RFC2460

4.2 Options

   Two of the currently-defined extension headers -- the Hop-by-Hop
   Options header and the Destination Options header -- carry a variable
   number of type-length-value (TLV) encoded "options", of the following
   format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      Option Type          8-bit identifier of the type of option.

      Opt Data Len         8-bit unsigned integer.  Length of the Option
                           Data field of this option, in octets.

      Option Data          Variable-length field.  Option-Type-specific
                           data.

   The sequence of options within a header must be processed strictly in
   the order they appear in the header; a receiver must not, for
   example, scan through the header looking for a particular kind of
   option and process that option prior to processing all preceding
   ones.

   The Option Type identifiers are internally encoded such that their
   highest-order two bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.
      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

   The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en-route to the
   packet's final destination.  When an Authentication header is present
   in the packet, for any option whose data may change en-route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

      0 - Option Data does not change en-route

      1 - Option Data may change en-route

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type.

   The same Option Type numbering space is used for both the Hop-by-Hop
   Options header and the Destination Options header.  However, the
   specification of a particular option may restrict its use to only one
   of those two headers.

   Individual options may have specific alignment requirements, to
   ensure that multi-octet values within Option Data fields fall on
   natural boundaries.  The alignment requirement of an option is
   specified using the notation xn+y, meaning the Option Type must
   appear at an integer multiple of x octets from the start of the
   header, plus y octets.  For example:

      2n    means any 2-octet offset from the start of the header.
      8n+2  means any 8-octet offset from the start of the header,
            plus 2 octets.

4.6 Destination Options Header

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s).  The
   Destination Options header is identified by a Next Header value of 60
   in the immediately preceding header, and has the following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header          8-bit selector.  Identifies the type of header
                        immediately following the Destination Options
                        header.  Uses the same values as the IPv4
                        Protocol field [RFC-1700 et seq.].

   Hdr Ext Len          8-bit unsigned integer.  Length of the
                        Destination Options header in 8-octet units, not
                        including the first 8 octets.

   Options              Variable-length field, of length such that the
                        complete Destination Options header is an
                        integer multiple of 8 octets long.  Contains one
                        or  more TLV-encoded options, as described in
                        section 4.2.

   The only destination options defined in this document are the Pad1
   and PadN options specified in section 4.2.

   Note that there are two possible ways to encode optional destination
   information in an IPv6 packet: either as an option in the Destination
   Options header, or as a separate extension header.  The Fragment
   header and the Authentication header are examples of the latter
   approach.  Which approach can be used depends on what action is
   desired of a destination node that does not understand the optional
   information:

      o  If the desired action is for the destination node to discard
         the packet and, only if the packet's Destination Address is not
         a multicast address, send an ICMP Unrecognized Type message to
         the packet's Source Address, then the information may be
         encoded either as a separate header or as an option in the
         Destination Options header whose Option Type has the value 11
         in its highest-order two bits.  The choice may depend on such
         factors as which takes fewer octets, or which yields better
         alignment or more efficient parsing.
      o  If any other action is desired, the information must be encoded
         as an option in the Destination Options header whose Option
         Type has the value 00, 01, or 10 in its highest-order two bits,
         specifying the desired action (see section 4.2).


SEE ALSO

  perldoc V6evalTool