#!/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_MSB11mc.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_mc'} = 'Send Echo Request (Unrecognized Option:Type 11, Multicast)'; $pktdesc{'icmperr_mc'} = '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_mc'); # timeout %ret = nd_vRecv_EN($IF, $CommonSPEC::wait_reply, 0, 0, 'icmperr_mc', 'echo_reply'); if ($ret{'status'} == 0) { if ($ret{'recvFrame'} eq 'icmperr_mc') { vLogHTML('Received unexpected ICMP Error message
'); } elsif ($ret{'recvFrame'} eq 'echo_reply') { vLogHTML('Received unexpected Echo Reply
'); } vLogHTML('NG
'); $endStatus = $V6evalTool::exitFail; } else { vLogHTML('OK
'); } #----- end test $ret = cleanup($IF); vStop($IF); if ($ret == $CommonSPEC::Success) { exit($endStatus); } else { exit($V6evalTool::exitFatal); } ###################################################################### __END__ =head1 NAME DO_MSB11mc - Options Processing, Destination Options Header (Most Significant Bits 11, multicast destination) =head1 TARGET Host and Router =head1 SYNOPSIS =begin html
  DO_MSB11mc.seq [-tooloption ...] -pkt DO_MSB11mc.def
    -tooloption : v6eval tool option
=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 | | | | | | (<----------------------) | | No Packet | | | | | v v 1. TN transmits an Echo Request that has a Destination Options header with an unknown Option Type of of 199. 2. Observe 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 = Link-local Multicast Address Destination Options Header NextHeader = 58 (ICMPv6) HeaderExtLength = 0 OptionType = 0xe2 (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 not generate any packets sent to TN. The Echo Request is discarded, as the destination address is multicast. The NUT must not send an ICMPv6 Parameter Problem message. =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 #
#       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.
# 
# # =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 #
#       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).
# 
# # =end html # =pod =head1 REFERENCE =begin html
RFC 2460 - IPv6 Specification
=end html =head1 SEE ALSO perldoc V6evalTool =cut