HH_Type11toMC - check Hop-by-Hop Options Header (Type 11) to Multicast Address
Host and Router
HH_Type11toMC.seq [-tooloption ...] -pkt HH_Type11toMC.def
-tooloption : v6eval tool option
See also HH.def
1. Ping to Target (for checking Target is alive)
Tester Target
| |
|-------------------------->|
| Echo Request |
| |
| |
| (<----------------------) |
| No Packet |
| |
| |
v v
1. Send Echo Request 2. No packet from Target
Echo Request Data is:
IPv6 Header
Version = 6
Traffic Class = 0
FlowLabel = 0
PayloadLength = 16
NextHeader = 0 (Hop-by-Hop Options Header)
SourceAddress = Tester Link Local Address
DestinationAddress = Link Local Multicast Address
Hop-by-Hop Options Header
NextHeader = 58 (ICMP)
HeaderExtLength = 0
OptionType = 0xe2 (Unrecognized Option, Type 11)
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}
PASS: No packets from Target
Sent packet is discarded
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.3 Hop-by-Hop Options Header
The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 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 Hop-by-Hop 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 Hop-by-
Hop Options header in 8-octet units, not
including the first 8 octets.
Options Variable-length field, of length such that the
complete Hop-by-Hop 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 hop-by-hop options defined in this document are the Pad1 and PadN options specified in section 4.2.
perldoc V6evalTool