objects.Network_Packet_Object.xsd Maven / Gradle / Ivy
The newest version!
This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org.
Network_Packet_Object
2.1
01/22/2014
The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML.
Copyright (c) 2012-2014, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included.
The Network_Packet object provides the definition of a network packet based on the TCP/IP model/Internet protocol suite. In the TCP/IP stack, "packet" is generally defined as IP header plus payload, but we also include the LinkLayer from the OSI model, which defines the physical network interfaces and routing protocols. The application layer has not yet been defined.
The NetworkPacketObjectType's definition of a network packet is based on the TCP/IP model/Internet protocol suite. In the TCP/IP stack, "packet" is generally defined as IP header plus payload, but we also include the LinkLayer from the OSI model, which defines the physical network interfaces and routing protocols. Protocol fields are provided but requirements are not enforced/captured; all fields are optional.
The Link Layer is the lowest layer of the TCP/IP network stack and is comprised of physical and logical protocols that operate between adjacent nodes of a network segment or a WAN connection.
Internet layer characterizes information about the network layer of this Network Packet. The network layer is one layer from the 7-layer OSI Model.
Transport layer characterizes information about the transport layer of this Network Packet. The transport layer is one layer from the 7-layer OSI Model.
A link layer protocol is a hardware interface protocol, such as Ethernet, or a logical link routing protocol, such as ARP.
Physical Interface characterizes one hardware interface of a link layer connection.
Logical Protocols characterizes the logical protocol of a link layer connection. One example of a logical protocol is ARP.
Multiple interface types exist - only most common (Ethernet) included now. Others will be added later as needed.
Ethernet sends network packets from the sending host to one or more receiving hosts. (REF: IEEE 802.3; http://wiki.wireshark.org/Ethernet).
Logical Protocols characterizes the logical protocol of a link layer connection. One example of a logical protocol is ARP.
ARP is a logical protocol used for resolution of network layer addresses (e.g., IP addresses) into link layer addresses (e.g., MAC addresses). RARP is a logical protocol used by a host computer to request its network layer address when it has its link layer address.
Neighbor Discovery Protocol (NDP) is used with IPv6 to determine the link-layer addresses for neighbors. Corresponds to combination of IPv4 protocols: ARP, ICMP Router Discovery, and ICMP Redirect.
Ethernet sends network packets from the sending host to one or more receiving hosts. (REF: IEEE 802.3; http://wiki.wireshark.org/Ethernet).
The ethernet header includes information such as source MAC address, destination MAC address, and more.
Ethernet header characterizes and ethernet header and includes information such as source MAC address, destination MAC address, and more.
Destination MAC Addr characterizes the destination MAC Address of the ethernet frame.
Source MAC Addr characterizes the source MAC Address of the ethernet frame.
Type or Length characterizes either the length of the ethernet frame or the protocol type of the network layer.
Checksum characterizes the Frame Check sequence of an ethernet frame.
0-1500 then it is a length field. Otherwise, it defines the protocol type of the Internet layer.
Length characterizes the length of the ethernet frame.
two-octet field in an Ethernet frame. specifies protocol encapsulated in the payload of ethernet frame.
The Address Resolution Protocol is a request and reply protocol that runs encapsulated by the line protocol. It is communicated within the boundaries of a single network, never routed across internetwork nodes. This property places ARP into the Link Layer. It is encapsulated. REF: http://www.comptechdoc.org/independent/networking/guide/netarp.html.
Characterizes the type of hardware address specified in an ARP message.
ProtoAddrType characterizes the type of protocol address being mapped. For IPv4 addresses, value = 0x0800.
Harware_Addr_Size represents the byte size of the hardware address. For Ethernet or other IEEE 802 MAC addresses, the value is 6.
Proto_Addr_Size represents the byte size of the protocol address. IPv4 addresses = 4.
Op_Type characterizes the type of operation. 1 = ARP request, 2=ARP reply, 3=RARP request, 4=RARP reply.
Sender_Hardware_Addr characterizes the sender's hardware address (e.g., MAC address).
Sender_Protocol_Addr characterizes the sender's IP address.
Recip_Sender_Hardware Addr characterizes the recipients' hardware address (e.g., MAC address).
Recip Protocol Addr characterizes the recipient's IP address.
ARPOpType specifies types of ARP operations, via a union of the ARPOpTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
ARPOpTypeEnum contains the various ARP Operation Types.
Indicates the ARP request operation, or value 1 in the OPER field of an ARP packet.
Indicates the ARP reply operation, or value 2 in the OPER field of an ARP packet.
Indicates the RARP request operation, or value 3 in the OPER field of an ARP packet.
Indicates the RARP reply operation, or value 4 in the OPER field of an ARP packet.
NDP Type characterizes NDP (Neighbor Discover Protocol) IPv6 packets. NDP defines five ICMPv6 packet types. RFC 2461: http://tools.ietf.org/html/rfc4861.
ICMPv6 Header characterizes an ICMPv6 header.
Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly (type=133; code=0).
Routers send out Router Advertisement messages periodically, or in response to Router Solicitations (type=134; code=0).
Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor (type=135; code=0).
A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly (type=136; code=0).
Routers send Redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by setting the ICMP Target Address equal to the ICMP Destination Address (type=137; code=0).
Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly.(type=133; code=0).
Router Solicitation messages include zero or more options, some of which may appear multiple times in the same message.
Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message.
Src Link Addr characterizes the Source Link-Layer Address option.
Routers send out Router Advertisement messages periodically, or in response to Router Solicitations. (type=134; code=0).
8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router).
16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds.
32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm. A value of zero means unspecified (by this router).
32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm. A value of zero means unspecified (by this router).
Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message.
1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.
1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network.
Router Advertisement messages include zero or more options, some of which may appear multiple times in the same message.
Src Link Addr characterizes the Source Link-Layer Address option.
32-bit unsigned integer. The recommended MTU for the link.
Prefix Info characterizes Prefix Information for Router Advertisement Options.
Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor. (type=135; code=0).
The IP address of the target of the solicitation.
Neighbor Solicitation messages include zero or more options, some of which may appear multiple times in the same message.
Neighbor Solicitation messages include zero or more options, some of which may appear multiple times in the same message.
Src Link Addr characterizes the Source Link-Layer Address option.
A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly. (type=136; code=0).
The IP address of the target of the advertisement.
Neighbor Advertisement messages include zero or more options, some of which may appear multiple times in the same message.
Router flag. When set, the R-bit indicates that the sender is a router. The R-bit is used by Neighbor Unreachability Detection to detect a router that changes to a host.
Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection.
Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address.
Neighbor Advertisement messages include zero or more options, some of which may appear multiple times in the same message.
Target Link Addr characterizes the Target Link-Layer Address option.
Routers send Redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by setting the ICMP Target Address equal to the ICMP Destination Address. (type=137; code=0).
An IP address that is a better first hop to use for the ICMP Destination Address.
The IP address of the destination that is redirected to the target.
Redirect messages include zero or more options, some of which may appear multiple times in the same message.
Redirect messages include zero or more options, some of which may appear multiple times in the same message.
The link-layer address for the target.
As much as possible of the IP packet that triggered the sending of the Redirect message without making the redirect packet exceed the minimum MTU specified in the IPv6 protocol.
NDPLinkAddrType characterizes the Link-Layer Address option.
The length of the option (including the type and length fields) in units of 8 octets.
The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers.
Prefix Info characterizes Prefix Information for Router Advertisement Options. It provides hosts with on-link prefixes and prefixes for Address Autoconfiguration. (type=3). RFC 4861.
Length characterizes the length of the option (the number of valid leading bits in the prefix), and is represented as a 32-bit integer.
8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on-link determination (when combined with the L flag in the prefix information option).
32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity.
32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred.
The Prefix is an IP address or a prefix of an IP address.
1-bit on-link flag. When set, indicates that this prefix can be used for on-link determintation. When not set the advertisement makes no statement about on-link or off-link properties of the prefix.
1-bit autonomous address-configuration flag. When set indicates that this prefix can be usd for stateless address configuration.
The redirected header option is used in redirect messages and contains all or part of the packet that is being redirected. (type=4).
The length of the option (including the type and length fields) in units of 8 octets.
As much as possible of the IP packet that triggered the sending of the redirect without making redirect packet larger than MTU.
The MTU option is used in Router Advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known. (type=5).
The length of the MTU option type: length=1.
The recommended MTU for the link. 32-bit unsigned integer.
The Internet layer is the group of methods, protocols, and specifications that are used to transport packets from the originating host across network boundaries. Not all protocols are currently defined, just those most commonly used: IPv4, ICMPv4, IPv6, ICMPv6. Other protocols will be added as needed. (http://en.wikipedia.org/wiki/Internet_layer).
Internet Protocol version 4 (IPv4) is a connectionless protocol for use on packet-switched link layer networks (e.g., Ethernet).
ICMP is chiefly used the operating systems of networked computers to send error messages indicating, for example, that a requested service is not available or that a host or router could not be reached (http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol; REF: http://www.networksorcery.com/enp/protocol/icmp.htm).
Internet Protocol version 6 (IPv6) is intended to succeed IPv4, and like IPv4 it is a connectionless protocol for use on packet-switched link layer networks.
ICMPv6 is the implementation of the ICMP for IPv6. ICMPv6 performs error reporting and diagnostic functions.
Internet Protocol version 4 (IPv4) is a connectionless protocol for use on packet-switched link layer networks (e.g., Ethernet). REF: RFC 791; http://en.wikipedia.org/wiki/IPv4.
The IPv4 header provides addressing, and internet modules use fields in the header to fragment and reassemble internet datagrams when necessary for transmission through small packet networks.
The data portion of an IP packet is interpreted based on the value of the Protocol header field. Actual field values will probably be specified in the elements of the different network layers, but we provide a field here to capture any data as necessary.
The IPv4 header provides addressing, and internet modules use fields in the header to fragment and reassemble internet datagrams when necessary for transmission through small packet networks. REF: RFC 791.
The version field indicates the format of the internet header. For IP v4, the version is 4.
The Internet Header Length specifies the length of IP packet header in 32 bit words. Min value = 5.
Originally defined as the Type of Service field, the Differentiated Services Code Point (DSCP) field is now defined by RFC 2474 for Differentiated services (DiffServ). New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP (VoIP), which is used for interactive data voice exchange (http://en.wikipedia.org/wiki/IPv4).
Explicit Congestion Notification: This field is defined in RFC 3168 and allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is only effective when supported by the underlying network. (http://en.wikipedia.org/wiki/IPv4).
This 16-bit field defines the entire datagram size, including header and data, in bytes.
The Identification field is primarily used for uniquely identifying fragments of an original IP datagram. (http://en.wikipedia.org/wiki/IPv4).
This is a three-bit field used to control or identify fragments. An field has been defined for each bit with associated enumerated types.
The fragment offset field is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. http://en.wikipedia.org/wiki/IPv4.
This 8-bit field helps prevent datagrams from persisting on an internet (it limits a datagram's lifetime).
This field defines the protocol used in the data portion of the IP datagram. The type of this field is an enumerated list of IP protocol numbers as maintained by the Internet Assigned Numbers Authority.
This field is a 16-bit checksum used for error-checking of the header.
This field is the IPv4 address of the sender of the packet.
This field is the IPv4 address of the receiver of the packet.
The IPv4 option field is variable in length with zero or more options. It is not often used. http://en.wikipedia.org/wiki/IPv4.
These flag types are used to control or identify fragments in an IP packet. It is a three-bit field, each of the three bits are defined by a field with a string value that indicates the meaning of whether or not the bit is set.
Bit 0: This bit value (0) is reserved and must be zero.
Bit 1: This is the "don't fragment" bit. Values are specified in the DoNotFragmentType.
Bit 2: This is the "more fragments" bit. Values are specified in the MoreFragmentsType.
DoNotFragmentType specifies fragmenting options, via a union of the DoNotFragmentTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
This type enumerates the meaning of the Do Not Fragment bit used in IPv4 flags.
Indicates that the router or other device should fragment the packet if necessary, especially if the packet size is bigger than the MTU of an outgoing interface.
Indicates that the router or other device should NOT fragment the packet in any circumstance.
MoreFragmentsType specifies whether there are more fragments, via a union of the MoreFragmentsTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
This type enumerates the meaning of the More Fragments bit used in IPv4 flags.
Indicates that the last fragment has been received. In other words, the "more fragments" flag is set to 0.
Indicates that more fragments need to be received. In other words, the "more fragments" flag is set.
The IPv4 option field is variable in length with zero or more options.
The copied flag indicates that this option is copied into all fragments on fragmentation. 1 bit. They are represented in this field by a string which specifies their value.
The option class is represented by 2 bits where 0 = control; 1 = reserved for future use; 2 = debugging and measurement; 3 = reserved for future use. These enumerated values are defined for this field.
The Internet Protocol has provision for optional header fields identified by an option type. These types are enumerated in the IPv4OptionsType.
IPv4CopyFlagType specifies value of IPv4 copy flag, via a union of the IPv4CopyFlagTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
The copy flag indicates whether the option is copied into all fragments on fragmentation (0=not copied; 1=copied). This information is also captured in the IPv4OptionsTypeEnum which lists all options, which incorporates copy and class numbers.
Indicates that the options need NOT be copied into all fragments of a fragmented packet.
Indicates that the options need to be copied into all fragments of a fragmented packet.
IPv4ClassType specifies IPv4 class type, via a union of the IPv4ClassTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
The option class is represented by 2 bits. The explicit meanings are captured here in an enumerated list. This information is also captured in the IPv4OptionsTypeEnum which lists all options, which incorporates copy and class numbers.
Indicates the "control" options.
Indicates a reserved value.
Indicates the debugging and measurement options.
Indicates a reserved value.
IPv4OptionsType specifies IPv4 options, via a union of the IPv4OptionsTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
The Internet Protocol (IP) has provision for optional header fields identified by an option type field. Options 0 and 1 are exactly one octet which is their type field. All other options have their one octet type field, followed by a one octet length field, followed by length-2 octets of option data. The option type field is sub-divided into a one bit copied flag, a two bit class field, and a five bit option number. These taken together form an eight bit value for the option type field. IP options are commonly referred to by this value. The IPv4OptionsEnum enumerates the options numbers that can be applied in IP. See http://www.iana.org/assignments/ip-parameters for more information.
Indicates the End of Options List option, or EOOL.
Indicates the No Operation option, or NOP.
Indicates the Security option, or SEC.
Indicates the Loose Source Route option, or LSR.
Indicates the Time Stamp option, or TS.
Indicates the Extended Security option, or E-SEC.
Indicates the Commercial Security option, or CIPSO.
Indicates the Record Route option, or RR.
Indicates the Stream ID option, or SID.
Indicates the Strict Source Route option, or SSR.
Indicates the Experimental Measurement option, or ZSU.
Indicates the MTU probe option, or MTUP.
Indicates the MTU reply option, or MTUR.
Indicates the Experimental Flow Control option, or FINN.
Indicates the Experimental Access Control option, or FINN.
Indicates the IMI Traffic Descriptor option, or IMITD.
Indicates the Extended Internet Protocol option, or EIP.
Indicates the Trace Route option, or TR.
Indicates the Address Extension option, or ADDEXT.
Indicates a Router Alert option, or RTRALT.
Indicates a Selective Directed Broadcast option, or SDB.
Indicates the Dynamic Packet State option, or DPS.
Indicates the Upstream Multicast Packet option, or UMP.
Indicates the Quick-Start option, or QS.
Indicates the RFC3692-style Experiment option, or EXP.
Internet Protocol version 6 (IPv6) is intended to succeed IPv4, and like IPv4 it is a connectionless protocol for use on packet-switched link layer networks. RFC 3513, RFC 2460, http://en.wikipedia.org/wiki/IPv6.
IPv6 headers is a simplification of the IPv4 header.
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. http://tools.ietf.org/html/rfc2460.
The data portion of an IP packet. Actual field values will probably be specified in the elements of the different network layers, but we provide a field here to capture any data as necessary.
The IPv6 header is a simplification of the IPv4 header.
4-bit Internet Protocol version number =6.
8-bit traffic class field. Available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. http://tools.ietf.org/html/rfc2460#section-7.
20-bit flow label. Used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service. http://tools.ietf.org/html/rfc2460#section-6.
16-bit unsigned integer. Length of the IPv6 payload (the rest of the packet following the IPv6 header) in octets. Any extension headers are considered part of the payload.
8-bit selector. Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 protocol field.
TTL/hop limit specifies how many times a packet can be forwarded. 8-bit unsigned integer.
128-bit address of the originator of the packet.
128-bit address of the intended recipient of the packet.
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. An IPv6 packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header. http://tools.ietf.org/html/rfc2460.
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. It carries a variable number of type-length-value (TLV) encoded options.
The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. http://tools.ietf.org/html/rfc2460.
The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU. A fragment packet begins with an unfragmentable part consisting of the IPv6 header plus all extension headers up to and including the routing header. We don't include it for this field because the data is already stored in other elements. We provide the elements necessary for the Fragmentable Part. http://tools.ietf.org/html/rfc2460.
The Destination Options header is used to carry optional information that needs to be examined only by a packet's destination node(s).
Follows RFC2402. The IP Authentication Header is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays. http://www.ietf.org/rfc/rfc2402.txt.
Follows RFC2406. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.
IPv6DoNotRecogActionType specifies possible actions when option is not recognized, via a union of the IPv6DoNotRecogActionTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
Enumerates possible actions when an option is not recognized.
Indicates that the option should be skipped and the header should continue to be processed. See RFC 2460.
Indicates that the packet should be discarded. See RFC 2460.
Indicates that the packet should be discarded 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. See RFC 2460.
Indicates that the packet should be discarded 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. See RFC 2460.
IPV6PacketChangeType specifies whether a packet has changed, via a union of the IPv6PacketChangeTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
Enumerated list that specifies whether or not the Option Data of an option can change en-route to the packet's final destination.
Indicates that the packet does not change en-route. See RFC 2460.
Indicates that the packet may change en-route. See RFC 2460.
Specifies the meaning of each bit of the 8-bit IPv6OptionType type.
Action to be taken if the processing IPv6 nodes does not recognize the Option Type. This information is internally encoded in the Option Type identifier (highest-order two bits) 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. These possible actions are enumerated via IPv6DoNotRecogActionType.
The third highest order bit of the Option Data specifies whether or not the Option Data of that option can change en-route to the packet's final destination.
This field may be used to specify the actual Option Type byte, with no explicit meaning attached. Meaning/interpretation provided by the Do_Not_Recogn_Action and Packet_Change fields.
IPVersionType specifies IP versions, via a union of the IPVersionTypeEnum type and the atomic xs:string type. See http://www.iana.org/assignments/version-numbers/version-numbers.xml for a complete list. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
Enumerates the different Internet Protocol versions. IPv4(4) and IPv6(6) are the most common.
Indicates IP Version 4.
Indicates the IP version designating ST Datagram Mode.
Indicates IP Version 6.
Indicates the IP version designating TP/IX: The Next Internet.
Indicates the IP version designating PIP: The P Internet Protocol.
Indicates the IP version designating TUBA (TCP and UDP with Bigger Addresses, i.e. RFC 1347).
only UDP and TCP defined to begin. Other protocols will be defined as necessary.
TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. http://en.wikipedia.org/wiki/User_Datagram_Protocol.
TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
The TCP header contains 10 mandatory fields and an optional extension field. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). This field will be further defined when required.
The Data field specifies the data payload of the TCP packet.
UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. http://en.wikipedia.org/wiki/User_Datagram_Protocol.
The UDP header consists of four fields, which are defined here.
The Data field specifies the data payload of the UDP packet.
The TCP header contains 10 mandatory fields and an optional extension field. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
Identifies the sending port.
Identifies the receiving port.
The Sequence number (32-bits) has a dual role: If the SYN flag is set, then this is the initial sequence numbers. If the SYN flag is clear (see Control Bits element), then this is the accumulated sequence number of the first data byte of this packet for the current session. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
If the ACK flag (see Control Bits element) is set then the value of this field is the next sequence number that the receiver is expecting.
Specifies the size of the TCP header in 32-bit words.
these 3 bits are reserved for future use and should be set to zero.
The TCP header contains 9 flags (aka Control Bits).
The size of the receive window, which specifies the number of bytes (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
The 16-bit checksum field is used for error-checking of the header and data. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
Defines the 9 different flags in the TCP header.
ECN-nonce concealment protection.
Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
ECN-Echo indicates: if the SYN flag is set, that the TCP peer is ECN capable; if the SYN flag is clear, that a packet with Congestion Experienced flag in IP header set is received during normal transmission. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
Indicates that the Urgent point field is significant.
indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
Push functions. asks to push the buffered dtata to the receiving application. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
Reset the connection.
Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
If this flag is set, it means there is no more data from sender.
The UDP header type defines the four fields in the UDP header.
Identifies the sender's port.
Identifies the receiver's port.
Specifies the length in bytes of the entire datagram (header and data).
The checksum is used for error-checking of the header and data.
IANAHardwareType specifies the type of hardware, via a union of the IANAHardwareTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
This enumerated type specifies Address Resolution Protocol (ARP) parameters. http://www.iana.org/assignments/arp-parameters/arp-parameters.xml.
Indicates Ethernet hardware.
Indicates IEEE 802 compliant hardware for networks carrying variable-size packets.
Indicates the ARCNET LAN protocol.
Indicates the Frame Relay WAN technology.
Indicates the ATM (Asynchronous Transfer Mode) networking standard.
Indicates the HDLC (High-Level Data Link Control) protocol.
Indicates the FibreChannel technology.
Indicates the ATM (Asynchronous Transfer Mode) networking standard.
Indicates the Serial Line protocol, or SLIP.
EtherObjectType specifies "type" field of Ethernets, via a union of the IANAEtherTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
http://cavebear.com/archive/cavebear/Ethernet/type.html http://www.iana.org/assignments/ethernet-numbers http://standards.ieee.org/develop/regauth/ethertype/eth.txt http://en.wikipedia.org/wiki/EtherType.
Indicates the IPv4 Ethernet type is specified.
Indicates the ARP Ethernet type is specified.
Indicates the RARP Ethernet type is specified.
Indicates the IPX Ethernet type is specified.
Indicates the SNMP Ethernet type is specified.
Indicates the IPv6 Ethernet type is specified.
IANAAssignedIPNumbersType specifies Internet Protocol numbers, via a union of the IANAAssignedIPNumbersTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
Assigned Internet Protocol Numbers http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml List of protocol numbers used in the Protocol fields of the IPv4 header and the Next Header of the IPv6 header.
Indicates the IPv6 Hop-By-Hop option protocol (HOPOPT).
Indicates the Internet Control Message protocol (HOPOPT).
Indicates the Internet Control Message protocol (HOPOPT).
Indicates the Gateway-to-Gateway protocol (HOPOPT).
Indicates the IPv4 Encapsulation protocol (IPv4).
Indicates the Stream protocol (HOPOPT).
Indicates the TCP protocol.
Indicates the EGP (Exterior Gateway) protocol.
Indicates the IGP/IGRP (Cisco) protocol.
Indicates the Network-Voice protocol.
Indicates the PUP protocol.
Indicates the ARGUS protocol.
Indicates the EMCON protocol.
Indicates the Cross Net Debugger protocol.
Indicates the UDP protocol.
Indicates the IPv6 protocol.
Indicates the Source Demand Routing protocol.
Indicates the routing header for IPv6.
Indicates the fragment header for IPv6.
Indicates the Reservation Protocol.
Indicates the General Routing Encapsulation protocol number.
Indicates the Encapsulated Security Payload protocol number.
Indicates the Authentication Header protocol number.
Indicates the ICMP for v6 protocol number.
Indicates the No Next Header for IPv6 protocol number.
Indicates the Destination Options for IPv6 protocol number.
Indicates the Mobility Header protocol number.
IANAPortNumberRegistryType specifies port numbers, via a union of the IANAPortNumberRegistryTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml.
Indicates the port for ftpdata.
Indicates the port for ftp.
Indicates the port for ssh.
Indicates the port for telnet.
Indicates the port for smtp.
Indicates the domain port.
Indicates the port for tftp.
Indicates the port for http.
Indicates the port for ldap.
Indicates the port for https.
ICMP is used to send error messages (e.g., a datagram cannot reach its destination), informational messages ( e.g., timestamp information), or a traceroute message. REF: http://www.networksorcery.com/enp/protocol/icmp.htm.
Actual header bytes are captured here. The message content of each type/code pair is also defined as part of the larger, complex "ICMPv4PacketType" type as either an error message, an informational message, or a traceroute message. The meaning of the type and code bytes is made explicit in the elements corresponding to each message type.
For ICMP error messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here.
For ICMP informational messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here.
For ICMP traceroute messages (type = 30), specifies related fields and ICMP code value. A boolean value is used to explicitly interpret the code byte appearing in the ICMP header. Additional fields and message content are also defined here.
Actual ICMP header bytes are defined, corresponding to the ICMP type, ICMP code, and to the checksum.
ICMP Type byte specifies the format of the ICMP message.
ICMP Code byte further qualifies the ICMP message.
ICMP Checksum (16 bits) covers the ICMP message.
ICMP error messages include destination unreachable messages, source quench messages, redirect messages, and time exceeded messages.
A destination unreachable message is an ICMP message which is generated by the host or its inbound gateway to inform the client that the destination is unreachable for some reason (http://en.wikipedia.org/wiki/ICMP_Destination_Unreachable).
A source quench message is an ICMP message that requests that the sender decrease the rate of messages sent to a router or host. This message may be generated if a router or host does not have sufficient buffer space to process the request or may occur if the router or host buffer is approaching its limit (http://en.wikipedia.org/wiki/ICMP_Source_Quench).
A redirect message is used to send data packets on an alternative route. This ICMP redirect message informs a host to update its routing information.
An ICMP time exceeded message is generated by a gateway to inform the source of a datagram that the datagram has been discarded due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit (http://en.wikipedia.org/wiki/ICMP_Time_Exceeded).
Message content common to all ICMP error messages are defined here. Fields that are specific to individual messages are defined separately under each message type.
Elements associated with ICMPv4 error messages (as opposed to ICMP informational messages or ICMP traceroute message).
IP header from the original datagram.
First 8 bytes of the original datagram's data.
ICMP informational messages include echo request/reply, timestamp request/reply, and address mask request/reply.
Echo reply/request messages are also known as "ping". The Info_Message_Content field contains an identifier and sequence number which together form the "quench" for echo reply and echo request. Fields specific to an echo reply message are given as elements to this echo reply field (type=0).
Echo reply/request messages are also known as "ping". The Info_Message_Content field contains an identifier and sequence number which together form the "quench" for echo reply and echo request. Fields specific to an echo request message are given as elements to this echo request field (type=8).
A timestamp request is an ICMP informational message used for time synchronization.
A timestamp reply is an informational ICMP message which replies to a timestamp request message.
An address mask request is an ICMP informational message (query message) normally sent by a host to a router in order to obtain an appropriate subnet mask (type=17).
An address mask reply is an ICMP informational message, used to reply to an address mask request message with an appropriate subnet mask (type=18).
Fields that are common to all ICMP informational messages are defined here. Fields that are specific to individual messages are defined separately under each message type.
Elements associated with ICMPv4 informational messages (as opposed to ICMP error messages or ICMP traceroute message).
16-bit identifier. Combined with the sequence number, called the "quench" for echo reply and echo request.
16-bit sequence number. The identifier and sequence number can be used by the client to match the reply with the request that caused the reply.
Elements associated with ICMPv4 traceroute message (as opposed to ICMP error messages or ICMP informational messages); corresponds to ICMP type =30. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm).
One of two possible subtypes for an ICMP traceroute message. This subtype means that the outbound packet was successfully forwarded (code=0).
One of two possible subtypes for an ICMP traceroute message. This one means that there is no route for the outbound packet and the packet was discarded (code=1).
16 bits. The ID number as copied from the ICMP traceroute option of the packet which caused this traceroute message to be sent (not related to the ID number in the IP header). (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm).
16 bits. Outbound hop count as copied from the IP traceroute option of the packet which caused this traceroute message to be sent (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm).
16 bits. Return hop count as copied from the IP traceroute options of the packet which caused this traceroute message to be sent. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm).
32 bits. The speed in bytes per second of the link over which the Outbound/Return Packet will be sent. If this value cannot be determined, the field should be set to zero. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm).
32 bits. The MTU in bytes of the link over which the Outbound/Return Packet will be sent. MTU refers to the data portion (includes IP header; excludes datalink header/trailer) of the packet. If this value cannot be determined, this field should be set to zero. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm).
ICMP is used to send error messages (e.g., a datagram cannot reach its destination), informational messages ( e.g., ping). Only the message types defined in RFC 4443 (ICMP v6) are included; additional message types will be defined as needed. REF: http://tools.ietf.org/html/rfc4443 and http://www.networksorcery.com/enp/protocol/icmpv6.htm and http://en.wikipedia.org/wiki/ICMPv6.
Actual ICMP v6 header bytes are defined, corresponding to the ICMP type, ICMP code, and to the checksum.
For ICMP v6 error messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here. The type value indicates whether an ICMP message is an error message (type is 0 to 127) or an information message (type is 128 to 255).
For ICMP v6 informational messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here. The type value indicates whether an ICMP message is an error message (type is 0 to 127) or an information message (type is 128 to 255).
Actual ICMP header bytes are defined, corresponding to the ICMP type, ICMP code, and to the checksum. Translation of each type and code byte are defined in text by using boolean values associated with corresponding elements in the informational and error message type elements.
The ICMP v6 type byte specifies the type of the message. Values range from 0 to 127 (high order bit is 0) indicate an error messages; values from 128 to 255 (high order bit is 1) indicate an informational message.
The code byte value depends on the message type and provides an additional level of message granularity.
Checksum characterizes the checksum information of an ICMPv6 header.
ICMP v6 error messages include destination unreachable messages, packet too big messages, and time exceeded messages, and parameter problem messages, as defined in RFC 2463. Type values of ICMP v6 error messages range from 1 to 127.
A destination unreachable message should be generated by a router, or by the IPv6 later in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (http://tools.ietf.org/html/rfc4443).
A packet too big message must be sent by a router in response to a packet that it cannot forward because the packet is larger than the MTU of the outgoing link.
A time exceeded message is send if either the hop limit is exceeded (hop limit = 0) or if fragment reassembly has timed out.
If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers and it cannot complete processing of the packet, it should send an ICMPv6 Parameter Problem message to the packet's source (http://tools.ietf.org/html/rfc4443).
as much of invoking packet as possible without the ICMPv6 packet exceeding the minimum IPc6 MTU.
ICMP v6 informational messages include echo request/reply; other informational message types will be added in the future as they are more commonly used (only echo request/reply are defined in RFC 4443).
Echo request and reply messages are used for diagnostic purposes.
Echo request and reply messages are used for diagnostic purposes.
Fields that are common to all ICMP v6 informational messages are defined here. Fields that are specific to individual messages are defined separately under each message type.
Elements associated with ICMPv6 informational messages (as opposed to ICMP v6 error messages).
16-bit identifier. Combined with the sequence number, called the "quench" for echo reply and echo request.
16-bit sequence number. The identifier and sequence number can be used by the client to match the reply with the request that caused the reply.
Echo reply v4 informational message (used to ping); ICMP type=0.
Echo reply is the only subtype (code=0).
This data is optional and is used for the different kind of answers given with an ICMP Echo Reply message. Can be arbitrary length (but less than the MTU of the network).
Destination Unreachable error message; ICMP type=3.
One of 16 different subtypes of a destination unreachable ICMP message; destination network unreachable (code=0).
One of 16 different subtypes of a destination unreachable ICMP message; destination host unreachable (code=1).
One of 16 different subtypes of a destination unreachable ICMP message; destination protocol unreachable (code=2).
One of 16 different subtypes of a destination unreachable ICMP message; destination port unreachable (code=3).
One of 16 different subtypes of a destination unreachable ICMP message; fragmentation required (code=4). This field has an additional field (Next-Hop MTU), as well as a boolean value indicating this subtype.
One of 16 different subtypes of a destination unreachable ICMP message; source route failed (code=5).
One of 16 different subtypes of a destination unreachable ICMP message; destination network unknown (code=6).
One of 16 different subtypes of a destination unreachable ICMP message; destination host unknown (code=7).
One of 16 different subtypes of a destination unreachable ICMP message; source host isolated (code=8).
One of 16 different subtypes of a destination unreachable ICMP message; host administratively prohibited (code=9).
One of 16 different subtypes of a destination unreachable ICMP message; host administratively prohibited (code=10).
One of 16 different subtypes of a destination unreachable ICMP message; network unreachable for TOS (code=11).
One of 16 different subtypes of a destination unreachable ICMP message; host unreachable for TOS (code=12).
One of 16 different subtypes of a destination unreachable ICMP message; communication administratively prohibited (code=13).
One of 16 different subtypes of a destination unreachable ICMP message; host precedence violation (code=14).
One of 16 different subtypes of a destination unreachable ICMP message; precedence cutoff in effect (code=15).
This further specifies an ICMP destination unreachable (type=3) message of code=4 (fragmentation required) message by providing a Next-Hop MTU field.
Indicates that the subtype of the destination unreachable ICMP message is "fragmentation required".
The Next-Hop MTU field contains the MTU of the next-hop network is a code 4 error (fragmentation required) occurs.
Source Quench (congestion control) error message; ICMP type=4.
Source quench is the only subtype (code=0).
Redirect Message error message; ICMP type=5.
One of 4 different subtypes of a redirect ICMP message; redirect datagram for the network (code=0).
One of 4 different subtypes of a redirect ICMP message; redirect datagram for the host (code=1).
One of 4 different subtypes of a redirect ICMP message; redirect datagram for the TOS and network (code=2).
One of 4 different subtypes of a redirect ICMP message; redirect datagram for the TOS and host (code=3).
The IP address is the 32-bit address of the gateway to which the redirection should be sent.
Echo Request informational message (used to ping); ICMP type=8.
Echo request is the only subtype (code=0).
This data is optional and is used for the different kind of answers given with an ICMP Echo Request message. Can be arbitrary length (but less than the MTU of the network).
Time Exceeded error message; ICMP type=11.
specifies that the time-to-live was exceeded in transit (code=0).
specifies that the fragment reassembly time was exceeded (code=1).
Time Stamp Request informational message; ICMP type=13.
This is the only subtype of a timestamp request message (code=0).
32-bits; number of ms since midnight UT. The originate timestamp is the time the sender last touched the message before sending it. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.
Time Stamp Reply informational message; ICMP type=14.
This is the only subtype of a timestamp reply message (code=0).
The originate timestamp is the time the sender last touched the message before sending it. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.
The receive timestamp is the time the echoer first touched the message on receipt. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.
The transmit timestamp is the time the echoer last touched the message on sending it. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.
Address Mask Request informational message; ICMP type=17.
This is the only possible subtype of an address mask request message (code=0).
The address mask can be set to 0 in an address mask request message (as opposed to an address mask reply message, in which case it should be set to the subnet mask).
Address Mask informational message; ICMP type=18.
This is the only possible subtype of an address mask reply message (code=0).
This address mask field should be set to the subnet mask.
Destination unreachable error message; ICMP v6 type=1.
No route to destination (ICMP v6 code=0).
Communication with destination administratively prohibited (ICMP v6 code=1).
Beyond scope of source address (ICMP v6 code =2).
Address is unreachable (ICMP v6 code=3).
Port is unreachable (ICMP v6 code=4).
Source address failed ingress/egress policy (ICMP v6 code=5).
Reject route to destination (ICMP v6 code=6).
Packet too big error message; ICMP v6 type=2.
Only one code value is defined and is set to 0 (zero) by the originator and ignored by the receiver.
Maximum Transmission Unit describes the size limit for any given physical network.
Time exceeded error message; ICMP v6 type=3.
Hop limit exceeded in transit (ICMP v6 code=0).
Fragment reassembly time exceeded (ICMP v6 code=1).
Parameter problem error message; ICMP v6 type=4.
Erroneous header field encountered (ICMP v6 code=0).
Unrecognized next header type encountered (ICMP v6 code=1).
Unrecognized IP v6 option encountered (ICMP v6 code=2).
identifies octet offset within invoking packet where error was detected.
Echo request informational ICMP v6 message; type=128.
Every node must implement an ICMP v6 Echo responder function that receives Echo Requests (ICMP v6 code=0).
Zero or more octets of arbitrary data.
Echo reply informational ICMP v6 message; type=129.
Every node must implement an ICMP v6 Echo responder function that originates corresponding Echo Replies(ICMP v6 code=0).
This is the data from the invoking echo request message.
Provides an IP address or a prefix of an IP address for NDP for IPv6.
IPv6 address.
The initial bits of an IPv6 address (these are identical for all hosts in a network) form the network's prefix. http://ipv6.com/articles/general/IPv6-Addressing.htm.
Defines fields for the IPv6 Hop-by-Hop Options header which is used to carry optional information that must be examined by every node along a packet's delivery path.
Identifies the type of header immediately following the Hop-by-Hop Options header. Uses the same values as the IPv4 Protocol field.
Length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets.
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 type-length-value (TLV)-encoded options.
Defines the variable-length fields associated with IPv6 extension headers (the Hop-by-Hop Options header and the Destination Options header). Contains one or more type-length-value (TLV)-encoded options.
Identifies the type of option. This 8-bit Option Type identifier is internally encoded such that different bits have different meanings. These meanings are further specified in the IPv6OptionType type.
Length of the Option Data field of this option, in octets.
The Pad1 option is used to insert one octet of padding into the Options area of a header. The Pad1 option does not have length and value fields.
The PadN option is used to insert two or more octets of paddings into the Options area of a header.
Specifies the fields of the Routing header, which is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. http://tools.ietf.org/html/rfc2460.
Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field.
length of the Routing header in 8-octet units, not including the first 8 octets.
8-bit identifiers of a particular Routing header variant. Further definition will be added as required.
Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. http://tools.ietf.org/html/rfc2460.
Variable length field, of format determined by the Routing Type.
Specifies the fields of the Fragment header, which is used by an IPv6 source to send a packet larger than would fit in the path MTU. http://tools.ietf.org/html/rfc2460.
Each fragment has a header containing next header information, the offset of the fragment, an M flag specifying whether or not it is the last fragment, and an identification value.
The fragment of the packet that corresponds to the fragment header. The length of the fragment must fit with the MTU of the path to the packets' destination.
Defines fields for the IPv6 Destination Options header which is used to carry optional information that needs to be examined only by a packet's destination node(s).
Identifies the type of header immediately following the Destination_Options options header. Uses the same values as the IPv4 Protocol field.
Length of the Destination Options header in 8-octet units, not including the first 8 octets.
Variable-length field, of length such that the complete Destinations Options header is an integer multiple of 8 octets long. Contains one or more type-length-value (TLV)-encoded options.
The IP Authentication Header is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays. http://www.ietf.org/rfc/rfc2402.txt.
Identifies the type of header immediately following the Authentication header. Uses the same values as the IPv4 Protocol field.
An 8-bit field specifying the length of the AH in 32-bit words.
The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. http://www.ietf.org/rfc/rfc2402.txt.
This unsigned 32-bit field contains a monotonically increasing counter value (sequence number).
This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integer multiple of 32 bits in length.
ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. http://www.ietf.org/rfc/rfc2406.txt.
The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. http://www.ietf.org/rfc/rfc2406.txt.
This unsigned 32-bit field contains a monotonically increasing counter value (sequence number).
Payload Data is a variable-length field containing data described by the Next Header field.
The padding field can be used for various reasons, such as to fill in the plaintext as required by an encryption algorithm or to conceal the actual length of the payload.
The pad length indicates the number of pad bytes immediately preceding it. Range is 0-255, where a value of zero indicates that no padding bytes are present. http://www.ietf.org/rfc/rfc2406.txt.
Identifies the type data contained in the payload data field. Uses the same values as the IPv4 Protocol field.
The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. http://www.ietf.org/rfc/rfc2406.txt.
The Pad1 type specifies how one octet of padding is inserted into the Options area of a header. The Pad1 option type does not have length and value fields.
The fixed 00 value specifies that the Pad1 option is used and also serves as the single octet of padding.
The PadN type specifies how two or more octets of padding are inserted into the Options area of a header.
Specifies the PandN option.
Length of the padding. For N octets of padding, the Option_Data_Length fields contains the value N-2.
Actual padding; consists of N-2 zero-valued octets.
Each fragment has a header containing next header information, the offset of the fragment, an M flag specifying whether or not it is the last fragment, and an identification value.
Identifies the type of header immediately following the Fragment header. Uses the same values as the IPv4 Protocol field.
13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part or the original packet.
Indicates whether this is the last fragment or whether there are more fragments.
For every packet that is to be fragmented, the source node generates a 32-bit Identification value.
MFlagType specifies whether there are more fragments, via a union of the MFlagTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications.
This attribute is optional and specifies the expected type for the value of the specified property.
Used by the IPv6 Fragment Header to indicate whether or not there are more fragments.
Fragment is the last fragment.
There are more fragments (current is not the last).