HH_Type10toMC - check Hop-by-Hop Options Header (Type 10) to Multicast Address
Host and Router
HH_Type10toMC.seq [-tooloption ...] -pkt HH_Type10toMC.def
-tooloption : v6eval tool option
See also HH.def
None
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 = 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 = 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}
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)
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
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