#!/usr/bin/perl
#
# $Name: V6LC_4_0_5 $
#
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
# Yokogawa Electric Corporation.
# All rights reserved.
# 
# Redistribution and use of this software in source and binary
# forms, with or without modification, are permitted provided that
# the following conditions and disclaimer are agreed and accepted
# by the user:
# 
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in
#    the documentation and/or other materials provided with
#    the distribution.
# 
# 3. Neither the names of the copyrighters, the name of the project
#    which is related to this software (hereinafter referred to as
#    "project") nor the names of the contributors may be used to
#    endorse or promote products derived from this software without
#    specific prior written permission.
# 
# 4. No merchantable use may be permitted without prior written
#    notification to the copyrighters.
# 
# 5. The copyrighters, the project and the contributors may prohibit
#    the use of this software at any time.
# 
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHTERS, THE PROJECT AND
# CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING
# BUT NOT LIMITED THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE, ARE DISCLAIMED.  IN NO EVENT SHALL THE
# COPYRIGHTERS, THE PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
# INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
# IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
# $Id: DO_MSB11.seq,v 1.8 2008/07/31 02:40:31 hide Exp $
#
######################################################################
BEGIN {
	$V6evalTool::TestVersion = '$Name: V6LC_4_0_5 $';
}

use V6evalTool;
use CommonSPEC;

$pktdesc{'echo_request_ex'}	= 'Send Echo Request (Unrecognized Option:Type 11)';
$pktdesc{'icmperr'}		= 'Recv ICMP Error (Parameter Problem, unrecognized IPv6 option encountered)';
$pktdesc{'echo_reply'}		= 'Recv Echo Reply';

$endStatus = $V6evalTool::exitPass;

######################################################################

$IF = 'Link0';

vCapture($IF);

#----- test
vSend($IF, 'echo_request_ex');
%ret = nd_vRecv_EN($IF, $CommonSPEC::wait_reply, 0, 0, 'icmperr', 'echo_reply');

if ($ret{'status'} == 0) {
	if ($ret{'recvFrame'} eq 'icmperr') {
		vLogHTML('OK<BR>');
	} elsif ($ret{'recvFrame'} eq 'echo_reply') {
		vLogHTML('Receive unexpected Echo Reply<BR>');
		vLogHTML('<FONT COLOR="#FF0000">NG</FONT><BR>');
		$endStatus = $V6evalTool::exitFail;
	}
} else {
	vLogHTML('Cannot receive ICMP Error message<BR>');
	vLogHTML('<FONT COLOR="#FF0000">NG</FONT><BR>');
	$endStatus = $V6evalTool::exitFail;
}
#----- end test

$ret = cleanup($IF);
vStop($IF);
if ($ret == $CommonSPEC::Success) {
	exit($endStatus);
} else {
	exit($V6evalTool::exitFatal);
}


######################################################################
__END__

=head1 NAME

  DO_MSB11 - Options Processing, Destination Options Header (Most Significant Bits 11, unicast destination)

=head1 TARGET

  Host and Router

=head1 SYNOPSIS

=begin html
<PRE>
  <A HREF="./DO_MSB11.seq">DO_MSB11.seq</A> [-tooloption ...] -pkt <A HREF="./DO_MSB11.def">DO_MSB11.def</A>
    -tooloption : v6eval tool option
</PRE>

=end html

=head1 INITIALIZATION

  None

=head1 TEST PROCEDURE

Verify that a node properly processes bot known and unknown options, and acts in accordance with the highest order two bits of the option.

   TN                          NUT
    |                           |
    |-------------------------->|
    |   Echo Request            |
    |                           |
    |                           |
    |<--------------------------|
    |   ICMP Error              |
    |                           |
    |                           |
    v                           v

  1. TN transmits an Echo Request that has a Destination Options header with an unknown Option Type of 199.
  2. Observe the packets transmitted by the NUT.

  Echo Request Data is:

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

        Destination Options Header
            NextHeader         = 58 (ICMPv6)
            HeaderExtLength    = 0
            OptionType         = 0xc7 (unknown, msb: 11)
            OptDataLength      = 4
            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}


=head1 JUDGEMENT

  PASS: The NUT must send an ICMPv6 Parameter Problem message to TN.
        The Code field must be 2(unrecognized IPv6 Option encoumtered).
        The Pointer field must be 0x2A(offset of the option field of Destination Options header).
        The NUT must discard the Echo Request and not send a Reply.
        The invoking Echo Request packet included in the Error Message must not exceed minimum IPv6 MTU.

            The Source Address of the Parameter Problem Message must be 
            the same as the Destination Address in TN's Echo Request Packet.
            The Destination Address should be the same as the Source Address 
            in TN's Echo Reuest Packet.

        IPv6 Header
            Version             = 6
            Traffic Class       = 0
            FlowLabel           = 0
            PayloadLength       = 16
            NextHeader          = 58 (ICMPv6)
            SourceAddress       = NUT Link Local Address
            Destination Address = TN Link Local Address

        ICMP Error
            Type           = 4 (Parameter Problem)
            Code           = 2 (unrecognized IPv6 option encountered)
            Checksum       = (auto)
            Pointer        = 42 (Offset to Option field of Destination Options Header)
            PayloadData    = (Sent Packet)

=head1 CLEANUP

Common Test Cleanup

=cut

# =head1 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.
# 
# =begin html
# <PRE>
#       <B>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.</B>
# </PRE>
# 
# =end html
# 
#    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.
# 
# =begin html
# <PRE>
#       o  <B>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).</B>
# </PRE>
# 
# =end html
# 

=pod

=head1 REFERENCE

=begin html
<BLOCKQUOTE>
<PRE>
RFC 2460 - IPv6 Specification
</PRE>
</BLOCKQUOTE>

=end html

=head1 SEE ALSO

  perldoc V6evalTool

=cut