PcapDotNet.Packets

Base class for different IPv4 options.

The option concerete type.

A generic Options class. Represents a list of options (either IPv4 options, IPv6 options or TCP options).

The Option type this collection contains.

Two options are equal iff they have the exact same options.

The hash code is the xor of the following hash codes: number of bytes the options take and all the options.

Returns an enumerator that iterates through the collection.

A that can be used to iterate through the collection. 1

Returns an enumerator that iterates through a collection.

An object that can be used to iterate through the collection. 2

A string of all the option type names.

Returns the collection of options.

Returns the number of options.

Returns the option in the given index.

The zero based index of the option. The option in the given index.

The number of bytes the options take.

Whether or not the options parsed ok.

TCP Alternate Checksum Data Option (RFC 1146). The format of the TCP Alternate Checksum Data Option is:

            +-----+--------+
            | Bit | 0-7    |
            +-----+--------+
            | 0   | Kind   |
            +-----+--------+
            | 8   | Length |
            +-----+--------+
            | 16  | Data   |
            | ... |        |
            +-----+--------+

This field is used only when the alternate checksum that is negotiated is longer than 16 bits. These checksums will not fit in the checksum field of the TCP header and thus at least part of them must be put in an option. Whether the checksum is split between the checksum field in the TCP header and the option or the entire checksum is placed in the option is determined on a checksum by checksum basis. The length of this option will depend on the choice of alternate checksum algorithm for this connection. While computing the alternate checksum, the TCP checksum field and the data portion TCP Alternate Checksum Data Option are replaced with zeros.

Represents a complex TCP option. Complex option means that it contains data and not just the type.

Represents a TCP option according to rfc 793.

Either an IPv4 option or a TCP option.

A generic option (for IPv4, IPv6 and TCP). The option is read from buffer and can be of different length.

Returns true iff the given object is an equivalent option.

Returns true iff the given option is an equivalent option.

Returns a hash code for the option.

The number of bytes this option will take.

Checks whether two options have equivalent type. Useful to check if an option that must appear at most once appears in the list.

True iff this option may appear at most once in a datagram.

Checks whether two options have equivalent type. Useful to check if an option that must appear at most once appears in the list.

Checks if the two options are exactly the same - including type and value.

The hash code for a tcp option is the hash code for the option type. This should be overridden by tcp options with data.

The string that represents the option type.

Initializes the option type.

This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset field. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the TCP header.

This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary.

The type of the TCP option.

The number of bytes this option header take.

Creates a complex option using the given option type.

This interface is used to create all complex options. Every complex option should implement such a factory to create itself from a buffer.

Tries to read the option from a buffer starting from the option value (after the type and length).

The buffer to read the option from. The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. The number of bytes the option value should take according to the length field that was already read. On success - the complex option read. On failure - null.

The minimum number of bytes this option take.

The minimum number of bytes this option's value take.

Creates the option using the given data.

the default option data is no data.

Tries to read the option from a buffer starting from the option value (after the type and length).

The alternate checksum data.

The number of bytes this option will take.

True iff this option may appear at most once in a datagram.

This class is used to build different packets. Packets are built from layers. This class can be used using static Build methods by giving the Packet's timestamp and layers. This class can be instantiated with different layers and then use the Build method by only giving the Packet's timestamp. If a layer that an instance of this class holds is modified, the PacketBuilder instance will create different packets. This sample shows how to create ICMP Echo Request packets to different servers with different IP ID and ICMP sequence numbers and identifiers.


               EthernetLayer ethernetLayer = new EthernetLayer
                                                 {
                                                     Source = new MacAddress("00:01:02:03:04:05"),
                                                     Destination = new MacAddress("A0:A1:A2:A3:A4:A5")
                                                 };
            
               IpV4Layer ipV4Layer = new IpV4Layer
                                         {
                                             Source = new IpV4Address("1.2.3.4"),
                                             Ttl = 128,
                                         };
            
               IcmpEchoLayer icmpLayer = new IcmpEchoLayer();
            
               PacketBuilder builder = new PacketBuilder(ethernetLayer, ipV4Layer, icmpLayer);
            
               List<Packet> packets = new List<Packet>();
            
               for (int i = 0; i != 100; ++i)
               {
                   ipV4Layer.Destination = new IpV4Address("2.3.4." + i);
                   ipV4Layer.Identification = (ushort)i;
                   icmpLayer.SequenceNumber = (ushort)i;
                   icmpLayer.Identifier = (ushort)i;
            
                   packets.Add(builder.Build(DateTime.Now));
               }

Builds a single packet using the given layers with the given timestamp.

The packet's timestamp. The layers to build the packet accordingly and by their order. A packet built from the given layers with the given timestamp.

Builds a single packet using the given layers with the given timestamp.

The packet's timestamp. The layers to build the packet accordingly and by their order. A packet built from the given layers with the given timestamp.

Creates a PacketBuilder that can build packets according to the given layers and with different timestamps. The layers' properties can be modified after the builder is built and this will affect the packets built.

The layers to build the packet accordingly and by their order.

Builds a single packet using the builder's layers with the given timestamp.

The packet's timestamp. A packet built from the builder's layers with the given timestamp.

The option-type octet is viewed as having 3 fields: Bits Description 1 bit Copied flag. The copied flag indicates that this option is copied into all fragments on fragmentation. 0 = not copied. 1 = copied. 2 bits Option class. The option classes are: 0 = control. 1 = reserved for future use. 2 = debugging and measurement. 3 = reserved for future use. 5 bitsOption number.

DoD Extended Security Option (133), RFC 1108, is not supported because it only defines abstract option and no concrete option RFC is available. EIP: The Extended Internet Protocol, RFC 1385, is not supported because according iana.org its option type is 145 but according to the RFC its option type is 138 (0x8A).

End of Option list. This option occupies only 1 octet; it has no length octet.

No Operation. This option occupies only 1 octet; it has no length octet.

Record Route. Used to trace the route an internet datagram takes.

MTU Probe. RFCs 1063, 1191. Obsoleted.

Quick Start (QS). RFC 4782.

Internet Timestamp.

Traceroute Using an IP Option. RFC 1393.

DoD Basic Security: Used to carry the classification level and protection authority flags.

Loose Source Routing. Used to route the internet datagram based on information supplied by the source.

Strict Source Routing. Used to route the internet datagram based on information supplied by the source.

Stream ID. Used to carry the stream identifier.

Router Alert Option (RFC 2113).

Represents a timestamp IPv4 option with each timestamp preceded with internet address of the registering entity or the internet address fields are prespecified.

Internet Timestamp

            +--------+--------+--------+--------+
            |01000100| length | pointer|oflw|flg|
            +--------+--------+--------+--------+
            |         internet address          |
            +--------+--------+--------+--------+
            |             timestamp             |
            +--------+--------+--------+--------+
            |                 .                 |
                              .
                              .
             Type = 68

The Option Length is the number of octets in the option counting the type, length, pointer, and overflow/flag octets (maximum length 40). The Pointer is the number of octets from the beginning of this option to the end of timestamps plus one (i.e., it points to the octet beginning the space for next timestamp). The smallest legal value is 5. The timestamp area is full when the pointer is greater than the length. The Overflow (oflw) [4 bits] is the number of IP modules that cannot register timestamps due to lack of space. The Flag (flg) [4 bits] values are 0 - time stamps only, stored in consecutive 32-bit words. 1 - each timestamp is preceded with internet address of the registering entity. 3 - the internet address fields are prespecified. An IP module only registers its timestamp if it matches its own address with the next specified internet address. The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight UT. If the time is not available in milliseconds or cannot be provided with respect to midnight UT then any time may be inserted as a timestamp provided the high order bit of the timestamp field is set to one to indicate the use of a non-standard value. The originating host must compose this option with a large enough timestamp data area to hold all the timestamp information expected. The size of the option does not change due to adding timestamps. The intitial contents of the timestamp data area must be zero or internet address/zero pairs. If the timestamp data area is already full (the pointer exceeds the length) the datagram is forwarded without inserting the timestamp, but the overflow count is incremented by one. If there is some room but not enough room for a full timestamp to be inserted, or the overflow count itself overflows, the original datagram is considered to be in error and is discarded. In either case an ICMP parameter problem message may be sent to the source host. The timestamp option is not copied upon fragmentation. It is carried in the first fragment. Appears at most once in a datagram.

Represents a complex IPv4 option. Complex option means that it contains data and not just the type.

Represents an ip option according to rfc 791.

Checks whether two options have equivalent type. Useful to check if an option that must appear at most once appears in the list.

Checks if the two options are exactly the same - including type and value.

The hash code of the option is the hash code of the option type.

The string of the option is the string of the option type.

Constructs the option by type.

This option indicates the end of the option list.
This might not coincide with the end of the internet header according to the internet header length. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the internet header. May be copied, introduced, or deleted on fragmentation, or for any other reason.

This option may be used between options, for example, to align the beginning of a subsequent option on a 32 bit boundary. May be copied, introduced, or deleted on fragmentation, or for any other reason.

The type of the IP option.

The header length in bytes for the option (type and size).

Constructs the option by type.

The minimum length in bytes for the option (type, length, pointer, overflow and flags).

The minimum length in bytes of the option value.

The maximum value for the overflow field.

The maximum value for the pointed index field.

Two options are equal if they have the same value (timestamp, overflow, pointed equals, addresses and timestamps).

Two options are equal if they have the same value (timestamp, overflow, pointed equals and addresses).

Create the option by giving it all the data.

The timestamp option type. The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. The index in the timestamp to points to the octet beginning the space for next timestamp. The timestamp area is considered full when the index points beyond the timestamps.

True iff the options values is equal.

Writes the value of the option to the buffer.

The timestamp option type.

The number of IP modules that cannot register timestamps due to lack of space.

The index in the timestamp that points to the for next timestamp. The timestamp area is considered full when the index points beyond the timestamps.

The number of timestamps this option holds (or can hold).

The number of bytes this option will take.

True iff this option may appear at most once in a datagram.

The number of bytes the value of the option take.

Create the option by giving it all the data.

The timestamp option type. The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. The index in the timestamp that points to the for next timestamp. The pairs of addresses and timestamps where each timestamp time passed since midnight UT.

Create the option by giving it all the data.

True iff the options values is equal.

Writes the value of the option to the buffer.

The number of timestamps this option holds (or can hold).

The pairs of addresses and timestamps where each timestamp time passed since midnight UT.

The number of bytes the value of the option take.

Set of Mobility options for IPv6 Mobility Extension Header.

Base class for different IPv6 options types.

The option concrete type.

Creates options from a list of options.

The list of options.

Creates options from a list of options.

The list of options.

Creates options from a list of options.

The list of options.

No options instance.

RFC 5096.

            +-----+-------------+--------------+
            | Bit | 0-7         | 8-15         |
            +-----+-------------+--------------+
            | 0   | Option Type | Opt Data Len |
            +-----+-------------+--------------+
            | 16  | Data                       |
            | ... |                            |
            +-----+----------------------------+

            +-----+-------------+--------------+
            | Bit | 0-7         | 8-15         |
            +-----+-------------+--------------+
            | 0   | Option Type | Opt Data Len |
            +-----+-------------+--------------+
            | 16  | Value                      |
            | ... |                            |
            +-----+----------------------------+

RFC 6275.

            +-----+-------------+--------------+
            | Bit | 0-7         | 8-15         |
            +-----+-------------+--------------+
            | 0   | Option Type | Opt Data Len |
            +-----+-------------+--------------+
            | 16  | Option Data                |
            | ... |                            |
            +-----+----------------------------+

RFC 6275.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Option Type | Opt Data Len (optional) |
            +-----+-------------+-------------------------+
            | 16  | Option Data (optional)                |
            | ... |                                       |
            +-----+---------------------------------------+

Returns true iff the given option is an equivalent option.

Returns a hash code for the option.

The type of the IP option.

True iff parsing of this option didn't encounter issues.

The number of bytes the option takes.

Creates an option from the given data.

Data related to the experimental protocol extension.

RFC 5846.

            +-----+---+---+---+-----+-------------------------+
            | Bit | 0 | 1 | 2 | 3-7 | 8-15                    |
            +-----+---+---+---+-----+-------------------------+
            | 0   | Next Header     | Header Extension Length |
            +-----+-----------------+-------------------------+
            | 16  | MH Type         | Reserved                |
            +-----+-----------------+-------------------------+
            | 32  | Checksum                                  |
            +-----+-----------------+-------------------------+
            | 48  | B.R. Type       | R. Trigger              |
            +-----+-----------------+-------------------------+
            | 64  | Sequence #                                |
            +-----+---+---+---+-------------------------------+
            | 80  | P | V | G | Reserved                      |
            +-----+---+---+---+-------------------------------+
            | 96  | Mobility Options                          |
            | ... |                                           |
            +-----+-------------------------------------------+

RFC 5846.

            +-----+---+---+---+-----+-------------------------+
            | Bit | 0 | 1 | 2 | 3-7 | 8-15                    |
            +-----+---+---+---+-----+-------------------------+
            | 0   | Next Header     | Header Extension Length |
            +-----+-----------------+-------------------------+
            | 16  | MH Type         | Reserved                |
            +-----+-----------------+-------------------------+
            | 32  | Checksum                                  |
            +-----+-----------------+-------------------------+
            | 48  | B.R. Type       | R. Trigger or Status    |
            +-----+-----------------+-------------------------+
            | 64  | Sequence #                                |
            +-----+---+---+---+-------------------------------+
            | 80  | P | V | G | Reserved                      |
            +-----+---+---+---+-------------------------------+
            | 96  | Mobility Options                          |
            | ... |                                           |
            +-----+-------------------------------------------+

RFC 3775, 6275.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Next Header | Header Extension Length |
            +-----+-------------+-------------------------+
            | 16  | MH Type     | Reserved                |
            +-----+-------------+-------------------------+
            | 32  | Checksum                              |
            +-----+---------------------------------------+
            | 48  | Message Data                          |
            | ... | ends with Mobility Options            |
            +-----+---------------------------------------+

RFC 2460.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Next Header | Header Extension Length |
            +-----+-------------+-------------------------+
            | 16  | Data                                  |
            | ... |                                       |
            +-----+---------------------------------------+

RFC 2460.

True iff the given extension header is equal to this extension header.

Returns a hash code of the extension header.

Identifies the type of this extension header.

Identifies the type of header immediately following this extension header. If the extension header is constructed with null NextHeader, it would be auto calculated according to the next extension or next layer when writing the layer.

The number of bytes this extension header takes.

List of all extension header protocols.

True iff the extension header parsing didn't encounter an issue.

The minimum number of bytes the extension header takes.

True iff the given extension header is equal to this extension header.

Returns a hash code of the extension header.

The number of bytes this extension header takes.

The minimum number of bytes this extension header takes.

Identifies the type of this extension header.

True iff the extension header parsing didn't encounter an issue.

Identifies the particular mobility message in question. An unrecognized MH Type field causes an error indication to be sent.

Contains the checksum of the Mobility Header. The checksum is calculated from the octet string consisting of a "pseudo-header" followed by the entire Mobility Header starting with the Payload Proto field. The checksum is the 16-bit one's complement of the one's complement sum of this string. The pseudo-header contains IPv6 header fields. The Next Header value used in the pseudo-header is 135. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header. Note that the procedures of calculating upper-layer checksums while away from home apply even for the Mobility Header. If a mobility message has a Home Address destination option, then the checksum calculation uses the home address in this option as the value of the IPv6 Source Address field. The Mobility Header is considered as the upper-layer protocol for the purposes of calculating the pseudo-header. The Upper-Layer Packet Length field in the pseudo-header MUST be set to the total length of the Mobility Header. For computing the checksum, the checksum field is set to zero.

Zero or more TLV-encoded mobility options.

The minimum number of bytes the message data takes.

Identifies the particular mobility message in question. An unrecognized MH Type field causes an error indication to be sent.

Defines the type of the Binding Revocation Message.

In indication, used by the initiator to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. This sequence number could be a random number. At any time, implementations must ensure there is no collision between the sequence numbers of all outstanding Binding Revocation Indication Messages. In acknowledgement, copied from the Sequence Number field in the Binding Revocation Indication. It is used by the initiator, e.g., HA, LMA, MAG, in matching this Binding Revocation Acknowledgement with the outstanding Binding Revocation Indication.

In indication, set by the initiator to indicate that the revoked binding(s) is a PMIPv6 binding. In acknowledgement, set if set in the corresponding Binding Revocation Indication message.

In indication, Set by the initiator, home agent, or local mobility anchor to indicate to the receiving mobility entity the termination of the IPv4 Home Address binding only as in Home Agent Operation and Local Mobility Anchor Operation. In acknowledgement, set if the it is set in the corresponding Binding Revocation Indication message.

In indication, Set by the initiator, LMA or MAG, to indicate the termination of all Per-Peer mobility Bindings or Multiple Bindings that share a common identifier(s) and are served by the initiator and responder as in Local Mobility Anchor Operation and Mobile Access Gateway Operation. In acknowledgement, set if it is set in the corresponding Binding Revocation Indication message.

Creates an instance from next header, checksum, revocation trigger, sequence number, proxy binding, IPv4 home address binding only, global and options.

Defines the type of the Binding Revocation Message.

Indicating the event that triggered the initiator to send the BRI message.

RFC 6275.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Next Header | Header Extension Length |
            +-----+-------------+-------------------------+
            | 16  | MH Type     | Reserved                |
            +-----+-------------+-------------------------+
            | 32  | Checksum                              |
            +-----+-------------+-------------------------+
            | 48  | Status      | Reserved                |
            +-----+-------------+-------------------------+
            | 64  | Home Address                          |
            |     |                                       |
            |     |                                       |
            |     |                                       |
            |     |                                       |
            |     |                                       |
            |     |                                       |
            |     |                                       |
            +-----+---------------------------------------+
            | 192 | Mobility Options                      |
            | ... |                                       |
            +-----+---------------------------------------+

The minimum number of bytes the message data takes.

Creates an instance from next header, checksum, status, home address and options.

Identifies the particular mobility message in question. An unrecognized MH Type field causes an error indication to be sent.

Indicating the reason for this message.

The home address that was contained in the Home Address destination option. The mobile node uses this information to determine which binding does not exist, in cases where the mobile node has several home addresses.

Represents an ICMP layer with an unknown message type.

Represents an ICMP layer.

A simple layer is a layer that doesn't care what is the length of its payload, what layer comes after it and what layer comes before it.

The base class of a layer used to build a Packet. Each layer represents the part of the packet relevant to a specific protocol. A sequence of layers can represent a packet. A packet can be according to a sequence of layers.

The interface of a layer used to build a Packet. Each layer represents the part of the packet relevant to a specific protocol. A sequence of layers can represent a packet. A packet can be according to a sequence of layers.

Writes the layer to the buffer.

The buffer to write the layer to. The offset in the buffer to start writing the layer at. The length of the layer's payload (the number of bytes after the layer in the packet). The layer that comes before this layer. null if this is the first layer. The layer that comes after this layer. null if this is the last layer.

Finalizes the layer data in the buffer. Used for fields that must be calculated according to the layer's payload (like checksum).

The buffer to finalize the layer in. The offset in the buffer the layer starts. The length of the layer's payload (the number of bytes after the layer in the packet). The layer that comes after this layer. null if this is the last layer.

The number of bytes this layer will take.

The kind of the data link of the layer. Can be null if this is not the first layer in the packet.

Writes the layer to the buffer.

Finalizes the layer data in the buffer. Used for fields that must be calculated according to the layer's payload (like checksum).

True iff the two objects are equal Layers.

Returns a hash code for the layer. The hash code base is a XOR of the hash codes of the layer length and data link.

The number of bytes this layer will take.

The kind of the data link of the layer. Can be null if this is not the first layer in the packet.

Writes the layer to the buffer.

Writes the layer to the buffer. This method ignores the payload length, and the previous and next layers.

The buffer to write the layer to. The offset in the buffer to start writing the layer at.

A layer under an IP layer. Must provide the IPv4 Protocol.

The protocol that should be written in the previous (IPv4) layer.

Writes the layer to the buffer. This method ignores the payload length, and the previous and next layers.

The buffer to write the layer to. The offset in the buffer to start writing the layer at.

Writes the ICMP payload to the buffer. Doesn't include payload in the next layers.

The buffer to write the ICMP payload to. The offset in the buffer to start writing the payload at.

Finalizes the layer data in the buffer. Used for the ICMP checksum.

ICMP layers are equal if they have the same message type, code, checksum, variable and payload.

Returns a hash code for the layer. The hash code is a XOR of the layer length, data link, message type and code, checksum and variable.

Returns a string containing the message type, code and variable.

True iff the ICMP payload is equal to the other ICMP payload.

The value of this field determines the format of the remaining data.

A sub-type of the message. Specific method of this message type.

A combination of the ICMP Message Type and Code.

The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero. This checksum may be replaced in the future. null means that this checksum should be calculated to be correct.

A value that should be interpreted according to the specific message.

The number of bytes this layer will take.

The number of bytes the ICMP payload takes.

The protocol that should be written in the previous (IPv4) layer.

Writes the ICMP payload to the buffer. Doesn't include payload in the next layers.

The buffer to write the ICMP payload to. The offset in the buffer to start writing the payload at.

The value of this field determines the format of the remaining data.

A sub-type of the message. Specific method of this message type.

A value that should be interpreted according to the specific message.

The payload of the ICMP. All the data without the ICMP header.

The value of this field determines the format of the remaining data.

A sub-type of the message. Specific method of this message type.

The number of bytes the ICMP payload takes.

A value that should be interpreted according to the specific message.

Used to represent an ICMP datagram with an unknown message type.

Generic

            +-----+------+------+-----------+
            | Bit | 0-7  | 8-15 | 16-31     |
            +-----+------+------+-----------+
            | 0   | Type | Code | Checksum  |
            +-----+------+------+-----------+
            | 32  | Value according to Type |
            +-----+-------------------------+
            | 64  | Payload                 |
            | ... |                         |
            +-----+-------------------------+

Represents a packet datagram. A datagram is part of the packet bytes that can be treated as a specific protocol data (usually header + payload). Never copies the given buffer.

Represents segement of a byte array. Never copies the given buffer.

Take all the bytes as a segment.

The buffer to take as a segment.

Take only part of the bytes as a segment.

The bytes to take the segment from. The offset in the buffer to start taking the bytes from. The number of bytes to take.

Creates a subsegment starting from a given offset in the segment taking a given number of bytes.

The offset in the segment to start taking. The number of bytes to take from the segment. A new DataSegment that is part of the given DataSegment.

Returns the Segment's bytes as a read only MemoryStream with a non-public buffer.

A read only MemoryStream containing the bytes of the segment.

Iterate through all the bytes in the segment.

Two segments are equal if they have the same data.

The hash code of a segment is the hash code of its length xored with all its bytes (each byte is xored with the next byte in the integer).

Creates a string starting with the number of bytes the data segment contains and ending with the first 10 bytes of the data segment as hexadecimal digits.

A string starting with the number of bytes the data segment contains and ending with the first 10 bytes of the data segment as hexadecimal digits.

Converts the segment to a hexadecimal string representing every byte as two hexadecimal digits.

A hexadecimal string representing every byte as two hexadecimal digits.

Converts the segment to a string using the given encoding.

The encoding to use to convert the bytes sequence in the segment to a string. A string of the bytes in the segment converted using the given encoding.

Reads a requested number of bytes from a specific offset in the segment.

The offset in the segment to start reading. The number of bytes to read. The bytes read from the segment starting from the given offset and in the given length.

Reads 2 bytes from a specific offset in the segment as a ushort with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 3 bytes from a specific offset in the segment as a UInt24 with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 4 bytes from a specific offset in the segment as an int with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 4 bytes from a specific offset in the segment as a uint with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 6 bytes from a specific offset in the segment as a UInt48 with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 6 bytes from a specific offset in the segment as a MacAddress with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 4 bytes from a specific offset in the segment as an IpV4Address with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 4 bytes from a specific offset in the segment as an IpV4TimeOfDay with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 4 bytes from a specific offset in the segment as an IpV4Address with a given endianity.

The offset in the segment to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Converts the given 16 bits sum to a checksum. Sums the two 16 bits in the 32 bits value and if the result is bigger than a 16 bits value repeat. The result is one's complemented and the least significant 16 bits are taken.

Sums bytes in a buffer as 16 bits big endian values. If the number of bytes is odd then a 0x00 value is assumed after the last byte. Used to calculate checksum.

The buffer to take the bytes from. The offset in the buffer to start reading the bytes. The number of bytes to read. A value equals to the sum of all 16 bits big endian values of the given bytes.

The number of bytes in this segment.

The value of the byte in the given offset in the segment.

The offset in the segment to take the byte from.

Returns the last byte of the segment.

An empty DataSegment.

The original buffer that holds all the data for the segment.

The offset of the first byte of the segment in the buffer.

Take all the bytes as a datagram.

The buffer to take as a datagram.

Take only part of the bytes as a datagram.

The bytes to take the datagram from. The offset in the buffer to start taking the bytes from. The number of bytes to take.

Creates a Layer that represents the datagram to be used with PacketBuilder.

The default validity check always returns true.

An empty datagram. Useful for empty payloads.

A datagram is checked for validity according to the protocol.

The number of bytes the ICMP header takes.

Creates a Layer that represents the datagram to be used with PacketBuilder.

ICMP is valid if the datagram's length is OK, the checksum is correct and the code is in the expected range.

Creates an IcmpDatagram from a buffer according to the message type.

The buffer of the datagram. The offset where the datagram starts. The length of the datagram in the buffer. An IcmpDatagram according to the Icmp message type.

The value of this field determines the format of the remaining data.

A sub-type of the message. Specific method of this message type.

A combination of the ICMP Message Type and Code.

A value that should be interpreted according to the specific message.

True iff the checksum value is correct according to the datagram data.

The payload of the ICMP. All the data without the header.

The minimum valid ICMP code for this type of ICMP datagram.

The maximum valid ICMP code for this type of ICMP datagram.

Creates a Layer that represents the datagram to be used with PacketBuilder.

Unknown ICMP datagrams are always invalid.

Take only part of the bytes as a datagarm.

The bytes to take the datagram from. The offset in the buffer to start taking the bytes from. The number of bytes to take.

RFC 1393.

            +-----+------+-------------+------------------+
            | Bit | 0-7  | 8-15        | 16-31            |
            +-----+------+-------------+------------------+
            | 0   | Type | Code        | Checksum         |
            +-----+------+-------------+------------------+
            | 32  | ID Number          | unused           |
            +-----+--------------------+------------------+
            | 64  | Outbound Hop Count | Return Hop Count |
            +-----+--------------------+------------------+
            | 96  | Output Link Speed                     |
            +-----+---------------------------------------+
            | 128 | Output Link MTU                       |
            +-----+---------------------------------------+

The number of bytes this datagram should take.

The number of bytes this ICMP payload should take.

The value the Return Hop Count should be for an outbound ICMP packet.

Creates a Layer that represents the datagram to be used with PacketBuilder.

Valid if the datagram's length is OK, the checksum is correct and the code is in the expected range.

The ID Number as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. This is NOT related to the ID number in the IP header.

The Outbound Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent.

The Return Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent.

The speed, in OCTETS per second, of the link over which the Outbound/Return Packet will be sent. Since it will not be long before network speeds exceed 4.3Gb/s, and since some machines deal poorly with fields longer than 32 bits, octets per second was chosen over bits per second. If this value cannot be determined, the field should be set to zero.

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, the field should be set to zero.

Is the packet an Outbound packet. This is indicated by a value of 0xFFFF in the ReturnHopCount field.

The minimum valid ICMP code for this type of ICMP datagram.

The maximum valid ICMP code for this type of ICMP datagram.

RFC 1256.

            +-----+-----------+-----------------+----------+
            | Bit | 0-7       | 8-15            | 16-31    |
            +-----+-----------+-----------------+----------+
            | 0   | Type      | Code            | Checksum |
            +-----+-----------+-----------------+----------+
            | 32  | Num Addrs | Addr Entry Size | Lifetime |
            +-----+-----------+-----------------+----------+
            | 64  | Router Address[1]                      |
            +-----+----------------------------------------+
            | 96  | Preference Level[1]                    |
            +-----+----------------------------------------+
            | 128 | Router Address[2]                      |
            +-----+----------------------------------------+
            | 160 | Preference Level[2]                    |
            +-----+----------------------------------------+
            |  .  |                   .                    |
            |  .  |                   .                    |
            |  .  |                   .                    |

The default number of 32-bit words of information per each router address.

Creates a Layer that represents the datagram to be used with PacketBuilder.

Valid if the datagram's length is OK, the checksum is correct, the code is in the expected range and the address entry size is the default address entry size.

The number of router addresses advertised in this message.

The number of 32-bit words of information per each router address (2, in the version of the protocol described here).

The maximum number of seconds that the router addresses may be considered valid.

The maximum time that the router addresses may be considered valid.

The pairs of sending router's IP address(es) on the interface from which this message is sent and the preferability of each Router Address[i] as a default router address, relative to other router addresses on the same subnet. A signed, twos-complement value; higher values mean more preferable.

RFC 1256. An ICMP Router Advertisement layer.

Writes the ICMP payload to the buffer. Doesn't include payload in the next layers.

The buffer to write the ICMP payload to. The offset in the buffer to start writing the payload at.

True iff the Entries are equal to the other ICMP entries.

The maximum time that the router addresses may be considered valid.

The value of this field determines the format of the remaining data.

A value that should be interpreted according to the specific message.

The number of bytes the ICMP payload takes.

Represents an ICMP layer with an Identifier and a Sequence Number.

An identifier to aid in matching requests and replies, may be zero.

A sequence number to aid in matching requests and replies, may be zero.

A value that should be interpreted according to the specific message.

RFC 2616. The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.

An HTTP field with a name and value.

Creates a field according to the field name and value.

The name of the field to create. The bytes value of the field to create. The constructed HTTP field.

Creates a field according to the field name and encoded string value.

The name of the field to create. The value of the field to create encoded in the given encoding. The encoding that encodes the given field value. The constructed HTTP field.

Creates a field according to the field name and encoded string value.

The name of the field to create. The value of the field to create encoded in ISO-8859-1 encoding. The constructed HTTP field.

True iff the two HTTP fields are of equal value. Two fields are equal iff they have the same name (case insensitive) and the same bytes value.

Returns a hash code of this field according to the name and value.

A string representing the field similar to how it would like in the HTTP protocol.

The name of the field.

The Value of the field.

The Value of the field as a string using ISO-8859-1 encoding.

The number of bytes the field will take in the HTTP protocol.

The field name.

The field name in uppercase.

Creates a Content Length Field according to a given content length.

The size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.

A layer that contains an ARP layer. Must provide the ARP hardware type.

The ARP Hardware Type of the layer before the ARP layer.

Eastlake.

Undefined value.

The SNMP subset of ASN.1.

OSI ASN.1 1990 [ASN.1].

OSI ASN.1 1994.

Private abstract syntax notations. This coding value will not be assigned to a standard abstract syntax notation. An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.

DNS RRs. The data portion consists of DNS resource records as they would be transmitted in a DNS response section. The subcoding octet is the number of RRs in the data area as an unsigned integer. Domain names may be compressed via pointers as in DNS replies. The origin for the pointers is the beginning of the RDATA section of the SINK RR. Thus the SINK RR is safe to cache since only code that knows how to parse the data portion need know of and can expand these compressions.

MIME structured data [RFC 2045, 2046]. The data portion is a MIME structured message. The "MIME-Version:" header line may be omitted unless the version is other than "1.0". The top level Content-Transfer-Encoding may be encoded into the subcoding octet. Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.

Text tagged data. The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item is considered to be a tag labeling the immediately following text item. If there are an odd number of text items overall, then the last is considered to label a null text item. Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). Thus any organization with a domain name can assign tags without fear of conflict.

Private formats indicated by a URL. The format of the data portion is indicated by an initial URL [RFC 1738] which is terminated by a zero valued octet followed by the data with that format. The subcoding octet is available for whatever use the private formating wishes to make of it. The manner in which the URL specifies the format is not defined but presumably the retriever will recognize the URL or the data it points to.

Faltstrom.

            +-----+----------+--------+
            | bit | 0-15     | 16-31  |
            +-----+----------+--------+
            | 0   | Priority | Weight |
            +-----+----------+--------+
            | 32  | Target            |
            | ... |                   |
            +-----+-------------------+

A DNS resource record type that any domain name that it contains should not be compressed when written and cannot decompress them when reads them.

A DNS resource record type that any domain name that it contains should not be compressed when written.

RFC 1035. Represents a resource record data.

Returns the DnsResourceData concrete type that should be created for the given DnsType.

Constructs an instance out of the priority, weight and target fields.

The priority of the target URI in this RR. A client must attempt to contact the URI with the lowest-numbered priority it can reach; URIs with the same priority should be tried in the order defined by the weight field. A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights should be given a proportionately higher probability of being selected. The URI of the target. Resolution of the URI is according to the definitions for the Scheme of the URI.

Two DnsResourceDataUri are equal iff their priority, weight and target fields are equal.

A hash code of the combination of the priority, weight and target fields.

A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights should be given a proportionately higher probability of being selected.

The URI of the target. Resolution of the URI is according to the definitions for the Scheme of the URI.

Wijngaards.

            +----------------------+
            | Previous Domain Name |
            +----------------------+
            | Next Domain Name     |
            +----------------------+

Constructs the resource data from the previous and next fields.

The start, or previous name. End or next name in the list.

Two trust anchor link resource datas are equal iff their previous and next fields are equal.

The combined hash code of the previous and next fields.

The start, or previous name.

End or next name in the list.

RFC 1706.

            +-----+-----+----------------------+----------+-----------+
            | bit | 0-7 | 8-7+X                | 8+X-55+X | 56+X-63+X |
            +-----+-----+----------------------+----------+-----------+
            | 0   | AFI | Domain Specific Area | ID       | Sel       |
            +-----+-----+-----+----------------+----------+-----------+
            | 0   | AFI | IDI | HO-DSP         | ID       | Sel       |
            +-----+-----+-----+----------------+----------+-----------+
            | 0   | Area Address               | ID       | Sel       |
            +-----+-----------+----------------+----------+-----------+
            | 0   | IDP       | DSP                                   |
            +-----+-----------+---------------------------------------+

IDP is Initial Domain Part. DSP is Domain Specific Part. HO-DSP may use any format as defined by the authority identified by IDP.

Constructs an instance out of the area address, system identifier and selector fields.

The combination of [IDP, HO-DSP] identify both the routing domain and the area within the routing domain. Hence the combination [IDP, HO-DSP] is called the "Area Address". All nodes within the area must have same Area address. System Identifier. NSAP Selector.

Two DnsResourceDataNetworkServiceAccessPoint are iff their area address, system identifier and selector fields are equal.

A hash code of the combination of the area address, system identifier and selector fields.

Authority and Format Identifier.

System Identifier.

NSAP Selector.

RFC 1035.

            +-----+
            | CPU |
            +-----+ 
            | OS  |
            +-----+

Base class for any resource data that contains DNS strings. Each DNS string is a segment of up to 255 bytes. The format of each DNS string is one byte for the length of the string and then the specified number of bytes.

Two strings resources datas are equal if they are of the same concrete type and their strings are equal and in the same order.

A hash code based on the concrete type and the strings.

Constructs the resource data from the CPU and OS parameters.

A string which specifies the CPU type. A string which specifies the operating system type.

A string which specifies the CPU type.

A string which specifies the operating system type.

Identifies the public key's cryptographic algorithm and determines the format of the public key field.

Indicates that no key is present.

A DSA key is present, in the format defined in RFC 2536.

A RSA key is present, in the format defined in RFC 3110 with the following changes: The earlier definition of RSA/MD5 in RFC 2065 limited the exponent and modulus to 2552 bits in length. RFC 3110 extended that limit to 4096 bits for RSA/SHA1 keys The IPSECKEY RR imposes no length limit on RSA public keys, other than the 65535 octet limit imposed by the two-octet length encoding. This length extension is applicable only to IPSECKEY; it is not applicable to KEY RRs.

The type of digest that is used to create a digest value.

No definition for digest type. Should not be used.

RFC 3658. SHA-1.

RFC 4509. SHA-256.

RFC 5933. GOST R 34.11-94.

RFCs 2535, 2536, 2537, 2539, 3110, 3755, 4034, 5155, 5702, 5933. The key algorithm.

RFC 4034. Field is not used or indicates that the algorithm is unknown to a secure DNS, which may simply be the result of the algorithm not having been standardized for DNSSEC.

RFCs 2537, 4034. RSA/MD5. Deprecated.

RFC 2539. Diffie-Hellman. Implementation is optional, key only.

RFCs 2536, 3755. DSA - Digital Signature Algorithm. Implementation is mandatory.

Reserved for elliptic curve crypto.

RFCs 3110, 3755. RSA/SHA-1.

RFC 5155. DSA-NSEC3-SHA1.

RFC 5155. RSASHA1-NSEC3-SHA1.

RFC 5702. RSA/SHA-256.

RFC 5702. RSA/SHA-512.

RFC 5933. GOST R 34.10-2001.

RFC 4034. Reserved for Indirect Keys.

RFCs 2535, 3755. Private algorithms - domain name.

RFCs 2535, 3755. Private algorithms - OID.

IEEE P802.1p. Eight different classes of service are available as expressed through the 3-bit PCP field in an IEEE 802.1Q header added to the frame. The way traffic is treated when assigned to any particular class is undefined and left to the implementation.

BE. Best Effort.

BK. Background. Lowest.

EE. Excellent Effort.

CA. Critical Applications.

VI. Video Under 100 ms latency.

VO. Voice. Under 10 ms latency.

IC. Internetwork Control.

NC. Network Control. Highest.

RFC 768. This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol. This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP). Format

             0      7 8     15 16    23 24    31
            +--------+--------+--------+--------+
            |     Source      |   Destination   |
            |      Port       |      Port       |
            +--------+--------+--------+--------+
            |                 |                 |
            |     Length      |    Checksum     |
            +--------+--------+--------+--------+
            |
            |          data octets ...
            +---------------- ...

Contains the common part of UDP and TCP. Format:

            +-----+-------------+----------+-----+-----+-----+-----+-----+-----+------------------+
            | Bit | 0-4         | 4-9      | 10  | 11  | 12  | 13  | 14  | 15  | 16-31            |
            +-----+-------------+----------+-----+-----+-----+-----+-----+-----+------------------+
            | 0   | Source Port                                                | Destination Port |
            +-----+------------------------------------------------------------+------------------+
            | 32  | Sequence Number                                                               |
            +-----+-------------------------------------------------------------------------------+

Indicates the port of the sending process. In UDP, this field is optional and may only be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used in UDP, a value of zero is inserted.

Destination Port has a meaning within the context of a particular internet destination address.

Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the Transport header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.

True iff the checksum for the transport type is optional.

The payload of the transport datagram.

The number of bytes the datagram header takes.

Creates a Layer that represents the datagram to be used with PacketBuilder.

A udp datagram is valid if it has a full header.

The length in octets of this user datagram including this header and the data. (This means the minimum value of the length is eight.)

Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.

True iff the checksum for the transport type is optional.

The payload of the UDP datagram.

The payload of the datagram as a DNS datagram.

A Transport layer under an IP layer. Must supply information about the Transport layer checksum.

Whether the checksum should be calculated. Can be false in UDP because the checksum is optional. false means that the checksum will be left zero.

The offset in the layer where the checksum should be written.

Whether the checksum is optional in the layer.

RFC 2711.

            +-----+-------------+--------+
            | Bit | 0-7         | 8-15   |
            +-----+-------------+--------+
            | 0   | Option Type | 2      |
            +-----+-------------+--------+
            | 16  | Router Alert Type    |
            +-----+----------------------+

RFC 2460.

            +-----+-------------+--------------+
            | Bit | 0-7         | 8-15         |
            +-----+-------------+--------------+
            | 0   | Option Type | Opt Data Len |
            +-----+-------------+--------------+
            | 16  | Option Data                |
            | ... |                            |
            +-----+----------------------------+

RFC 2460.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Option Type | Opt Data Len (optional) |
            +-----+-------------+-------------------------+
            | 16  | Option Data (optional)                |
            | ... |                                       |
            +-----+---------------------------------------+

True iff the option type and data are equal.

Returns a hash code for the option.

The type of the IP option.

The number of bytes the option takes.

Parses an option from the given data.

The data to parse. The option if parsing was successful, null otherwise.

The number of bytes the option data takes.

Creates an instance according to the given router alert type.

Type of router alert.

Parses the given data to create a router alert IPv6 option.

The data to parse to create the option. Router alert IPv6 option according to the data parsed.

Type of router alert.

Type of an IPv6 Mobility option.

RFC 6275.

RFC 6275. Alternate Care-of Address.

RFC 6275.

RFC 3963. Mobile Network Prefix Option.

RFC 5568. Mobility Header Link-Layer Address option.

RFC 4283. MN-ID-OPTION-TYPE.

RFC 4285. AUTH-OPTION-TYPE.

RFC 4285. MESG-ID-OPTION-TYPE

RFC 4866. CGA Parameters Request.

RFC 4866. CGA Parameters.

RFC 4866.

RFC 4866. Care-of Test Init

RFC 4866. Care-of Test.

RFC 5026. DNS-UPDATE-TYPE.

RFC 5096. Experimental Mobility Option.

RFC 5094. Vendor Specific Mobility Option.

RFC 5149.

RFC 5568. Binding Authorization Data for FMIPv6 (BADF).

RFC 5213.

RFC 5213. Mobile Node Link-layer Identifier Option

RFC 5213. Link-local Address Option.

RFC 5213.

RFC 5847.

RFC 5555. IPv4 Home Address.

RFC 5555. IPv4 Address Acknowledgement.

RFC 5555. NAT Detection.

RFC 5555. IPv4 Care-of Address.

RFC 5845. GRE Key Option.

RFC 5568. Mobility Header IPv6 Address/Prefix.

RFC 5648.

RFC5844. IPv4 Home Address Request.

RFC 5844. IPv4 Home Address Reply.

RFC 5844. IPv4 Default-Router Address.

RFC 5844. IPv4 DHCP Support Mode.

RFC 5949.

RFC 5949. Mobile Node Link-local Address Interface Identifier Option.

RFC 6058.

RFC 6089

RFC 6089.

RFC 6463. Redirect-Capability Mobility Option.

RFC 6463.

RFC 6463. Alternate IPv4 Care-of Address.

RFC 6602.

RFC 6705. MAG IPv6 Address.

RFC 6757.

RFC 6275.

            +-----+--------------+
            | Bit | 0-7          |
            +-----+--------------+
            | 0   | Option Type  |
            +-----+--------------+
            | 8   | Opt Data Len |
            +-----+--------------+
            | 16  | 0            |
            | ... |              |
            +-----+--------------+

Creates an instance from padding data length.

The number of bytes the option data takes.

RFC 5568.

            +-----+-------------+--------------+
            | Bit | 0-7         | 8-15         |
            +-----+-------------+--------------+
            | 0   | Option Type | Opt Data Len |
            +-----+-------------+--------------+
            | 16  | SPI                        |
            |     |                            |
            +-----+----------------------------+
            | 48  | Authenticator              |
            | ... |                            |
            +-----+----------------------------+

The minimum number of bytes this option data takes.

Creates an instance from security parameter index and authenticator.

SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys. Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. Rules for calculating this value depends on the used authorization procedure.

SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys.

Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. Rules for calculating this value depends on the used authorization procedure. For the return routability procedure, this option can appear in the Binding Update and Binding Acknowledgements. Rules for calculating the Authenticator value are the following: Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) Where | denotes concatenation. "Care-of address" is the care-of address that will be registered for the mobile node if the Binding Update succeeds, or the home address of the mobile node if this option is used in de-registration. Note also that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. The "correspondent" is the IPv6 address of the Previous Access Router (PAR). Note that, if the message is sent to a destination that is itself mobile, the "correspondent" address may not be the address found in the Destination Address field of the IPv6 header; instead, the home address from the type 2 Routing header should be used. "MH Data" is the content of the Mobility Header, excluding the Authenticator field itself. The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. The Checksum in the transmitted packet is still calculated in the usual manner, with the calculated Authenticator being a part of the packet protected by the Checksum. Kbm is a shared key between the MN and the PAR. Note that while the contents of a potential Home Address destination option are not covered in this formula, the rules for the calculation of the Kbm do take the home address in account. This ensures that the MAC will be different for different home addresses. The first 96 bits from the MAC result are used as the Authenticator field.

RFC 2460.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Next Header | Header Extension Length |
            +-----+-------------+-------------------------+
            | 32  | Options                               |
            | ... |                                       |
            +-----+---------------------------------------+

RFC 2460.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Next Header | Header Extension Length |
            +-----+-------------+-------------------------+
            | 16  | Options                               |
            | ... |                                       |
            +-----+---------------------------------------+

Extension header options.

True iff the extension header parsing didn't encounter an issue.

Creates an instance from next header and options.

Identifies the type of header immediately following this extension header. Extension header options.

Identifies the type of this extension header.

RFC 5213.

Reserved.

Virtual. Logical Network Interface.

Point-to-Point Protocol.

IEEE 802.3. Ethernet.

IEEE 802.11a/b/g. Wireless LAN.

IEEE 802.16e. WIMAX.

RFC 5568.

            +-----+---+---+----------+-------------------------+
            | Bit | 0 | 1 | 2-7      | 8-15                    |
            +-----+---+---+----------+-------------------------+
            | 0   | Next Header      | Header Extension Length |
            +-----+------------------+-------------------------+
            | 16  | MH Type          | Reserved                |
            +-----+------------------+-------------------------+
            | 32  | Checksum                                   |
            +-----+--------------------------------------------+
            | 48  | Sequence #                                 |
            +-----+---+---+----------+-------------------------+
            | 64  | S | U | Reserved | Code                    |
            +-----+---+---+----------+-------------------------+
            | 96  | Mobility Options                           |
            | ... |                                            |
            +-----+--------------------------------------------+

The minimum number of bytes the message data takes.

Creates an instance from next header, checksum, sequence number, assigned address configuration, buffer, code and options.

Identifies the particular mobility message in question. An unrecognized MH Type field causes an error indication to be sent.

Must be set by the sender so replies can be matched to this message.

Assigned address configuration flag. When set to true, this message requests a new CoA to be returned by the destination. May be set when Code = 0. Must be false when Code = 1.

When set, the destination should buffer any packets toward the node indicated in the options of this message. Used when Code = 0, should be set to false when Code = 1.

Describes whether the source ip address is a previous care of address.

Represents an IGMP group record with all the relevant fields. Used to build an IGMP report of version 3.

Create the record according to all the fields.

The type of group record included in the report message. The Multicast Address field contains the IP multicast address to which this Group Record pertains. The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in this record's Number of Sources (N) field. The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. The protocol specified in this document, IGMPv3, does not define any auxiliary data. Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, and MUST ignore any auxiliary data present in any received Group Record. The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field.

Create the record according to all the fields.

A string containing the record type, multicast address, source addresses and the number of bytes in teh auxiliary data.

Two records are equal if the record type, multicast address, source addresses and auxiliary data are equal.

The hash code of a record is the xor of the hash code of the record type, multicast address, source addresses and auxiliary data.

The type of group record included in the report message.

The Multicast Address field contains the IP multicast address to which this Group Record pertains.

The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in this record's Number of Sources (N) field.

The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. The protocol specified in this document, IGMPv3, does not define any auxiliary data. Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, and MUST ignore any auxiliary data present in any received Group Record. The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field.

RFC 2236.

RFC 2236. Represents a generic IGMP version 2 datagram.

Represents a Simple IGMP layer. A simple layer only has the 8 bytes header without additional fields.

The base of all IGMP layers.

IGMP layers are equal if they have the same message type, query version, similar max response time and the same specific type fields.

Xor of the hash codes of the layer length, datalink, message type and query version.

true iff the fields that are not mutual to all IGMP layers are equal.

The type of the IGMP message of concern to the host-router interaction.

The IGMP version of a Membership Query message. If the type is not a query, None will be returned.

The actual time allowed, called the Max Resp Time.

The protocol that should be written in the previous (IPv4) layer.

Represents an IGMP layer that contains a Group Address.

The Group Address field is set to zero when sending a General Query, and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query. In a Membership Report of version 1 or 2 or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left. In a Membership Report of version 3 this field is meaningless.

Writes the layer to the buffer. This method ignores the payload length, and the previous and next layers.

The buffer to write the layer to. The offset in the buffer to start writing the layer at.

Xor of the hash codes of the layer length, datalink, message type, query version and group address.

true iff the the group address is equal.

The number of bytes this layer will take.

The actual time allowed, called the Max Resp Time.

The type of the IGMP message of concern to the host-router interaction.

RFC 3376. Represents an IGMP Query version 3 layer.

Creates an instance of an IGMP Query Version 3 layer. Default SourceAddresses is no addresses.

Writes the layer to the buffer. This method ignores the payload length, and the previous and next layers.

The buffer to write the layer to. The offset in the buffer to start writing the layer at.

Xor of the combination of the IsSuppressRouterSideProcessing and QueryRobustnessVariable fields with the hash codes of the layer length, datalink, message type, query version, group address and all the source addresses.

true iff the GroupAddress, IsSuppressRouterSideProcessing, QueryRobustnessVariable and SourceAddresses fields are equal and the QueryInterval is similar.

The actual time allowed, called the Max Resp Time.

When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. It does not, however, suppress the querier election or the normal "host-side" processing of a Query that a router may be required to perform as a consequence of itself being a group member.

If non-zero, the QRV field contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. If the querier's [Robustness Variable] exceeds 7, the maximum value of the QRV field, the QRV is set to zero. Routers adopt the QRV value from the most recently received Query as their own [Robustness Variable] value, unless that most recently received QRV was zero, in which case the receivers use the default [Robustness Variable] value or a statically configured value.

The actual interval, called the Querier's Query Interval (QQI).

The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in the Number of Sources (N) field.

The number of bytes this layer will take.

The type of the IGMP message of concern to the host-router interaction.

The IGMP version of a Membership Query message. If the type is not a query, None will be returned.

The actual time allowed, called the Max Resp Time.

RFC 792.

            +-----+------+------+-----------------+
            | Bit | 0-7  | 8-15 | 16-31           |
            +-----+------+------+-----------------+
            | 0   | Type | Code | Checksum        |
            +-----+------+------+-----------------+
            | 32  | Identifier  | Sequence Number |
            +-----+-------------+-----------------+

RFC 792.

            +-----+------+------+-----------------+
            | Bit | 0-7  | 8-15 | 16-31           |
            +-----+------+------+-----------------+
            | 0   | Type | Code | Checksum        |
            +-----+------+------+-----------------+
            | 32  | Identifier  | Sequence Number |
            +-----+-------------+-----------------+

An identifier to aid in matching requests and replies, may be zero.

A sequence number to aid in matching requests and replies, may be zero.

Creates a Layer that represents the datagram to be used with PacketBuilder.

RFC 2616. The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the transfer-coding is a property of the message, not of the entity.

            Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding

Example:

            Transfer-Encoding: chunked

If multiple encodings have been applied to an entity, the transfer-codings MUST be listed in the order in which they were applied. Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.

The field name.

The field name in uppercase.

Creates an HTTP transfer encoding field from a set of transfer codings.

True iff the two HTTP transfer encoding fields are of equal value. Two HTTP transfer encoding fields are equal iff they have the same transfer codings.

Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.

            transfer-coding         = "chunked" | transfer-extension
            transfer-extension      = token *( ";" parameter )

Parameters are in the form of attribute/value pairs.

            parameter               = attribute "=" value
            attribute               = token
            value                   = token | quoted-string

All transfer-coding values are case-insensitive. Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message.

RFC 1702. Represents a source route entry consisting of a list of Autonomous System numbers and indicates an AS source route.

RFC 1701. SRE.

            +-----+----------------+------------+------------+
            | Bit | 0-15           | 16-23      | 24-31      |
            +-----+----------------+------------+------------+
            | 0   | Address Family | SRE Offset | SRE Length |
            +-----+----------------+------------+------------+
            | 32  | Routing Information ...                  |
            +-----+------------------------------------------+

The number of bytes the entry header takes.

Two entries are equal iff they have the same address family, length, payload offset and payload.

The hash code of an entry is a xor of the hash code of the address family, length, payload offset and payload.

True iff the payloads a are equal.

Writes the payload to the given buffer in the given offset.

The buffer to write the payload to. The offset in the buffer to start writing.

The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field.

The number of bytes the entry takes.

The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined.

The SRE Length field contains the number of octets in the SRE.

The hash code of the payload.

Initializes using the given AS numbers and the next as number index.

Autonomous System numbers of the source route. The next AS number index in the source route.

True iff the AS numbers are equal.

Writes the payload to the given buffer in the given offset.

The buffer to write the payload to. The offset in the buffer to start writing.

The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field.

The SRE Length field contains the number of octets in the SRE.

The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined.

The xor of the hash code of the AS numbers.

Autonomous System numbers of the source route.

The next AS number index in the source route.

The next AS number.

Represents a GRE layer.

A base class for Ethernet like layers. Contains an Ethernet type that can be calculated according to the previous layer and defines that if the next layer is an ARP layer, the hardware type should be Ethernet.

Creates an instance with zero values.

Ethernet type (next protocol).

The ARP Hardware Type of the layer before the ARP layer.

Sets the key according to the payload length and call id.

(High 2 octets of Key) Size of the payload, not including the GRE header. (Low 2 octets of Key) Contains the Peer's Call ID for the session to which this packet belongs.

Writes the layer to the buffer.

Finalizes the layer data in the buffer. Used for fields that must be calculated according to the layer's payload (like checksum).

True iff the two objects are equal Layers.

The GRE Version Number.

The Protocol Type field contains the protocol type of the payload packet. These Protocol Types are defined in [RFC1700] as "ETHER TYPES" and in [ETYPES]. An implementation receiving a packet containing a Protocol Type which is not listed in [RFC1700] or [ETYPES] SHOULD discard the packet.

Recursion control contains a three bit unsigned integer which contains the number of additional encapsulations which are permissible. This SHOULD default to zero.

Must be set to zero (0).

If the Checksum Present bit is set to 1, then the Checksum field is present and contains valid information. If either the Checksum Present bit or the Routing Present bit are set, BOTH the Checksum and Offset fields are present in the GRE packet.

The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit words in the GRE header and the payload packet. For purposes of computing the checksum, the value of the checksum field is zero. This field is present only if the Checksum Present bit is set to one. In order to calculate the Checksum automatically, leave null in this field and set the ChecksumPresent field to true.

The Key field contains a four octet number which was inserted by the encapsulator. It may be used by the receiver to authenticate the source of the packet. The Key field is only present if the Key Present field is set to 1. null iff the Key isn't present.

(High 2 octets of Key) Size of the payload, not including the GRE header.

(Low 2 octets of Key) Contains the Peer's Call ID for the session to which this packet belongs.

The Sequence Number field contains an unsigned 32 bit integer which is inserted by the encapsulator. It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. null off the sequence number present bit is 0.

Contains the sequence number of the highest numbered GRE packet received by the sending peer for this user session. Present if A bit (Bit 8) is one (1). null iff not present.

The offset field indicates the octet offset from the start of the Routing field to the first octet of the active Source Route Entry to be examined. This field is present if the Routing Present or the Checksum Present bit is set to 1, and contains valid information only if the Routing Present bit is set to 1. Should be null iff the Routing is null (routing is not present).

The Routing field is optional and is present only if the Routing Present bit is set to 1. The Routing field is a list of Source Route Entries (SREs). null iff the routing isn't present.

If the source route is incomplete, then the Strict Source Route bit is checked. If the source route is a strict source route and the next IP destination or autonomous system is NOT an adjacent system, the packet MUST be dropped.

The number of bytes this layer will take.

The protocol that should be written in the previous (IPv4) layer. This is GRE.

Reid.

            +---------------------+
            | One ore more strings|
            +---------------------+

Constructs the resource data from strings.

A descriptive text in one or more strings.

Constructs the resource data from strings.

A descriptive text in one or more strings.

RFC 1035.

            +---------+
            | RMAILBX |
            +---------+
            | EMAILBX |
            +---------+

A resource record data that contains exactly 2 domain names.

A base class for resource record datas that contain DNS domain names.

Two domain names resource data are equal if they are of the same type and contain the same domain names in the same order.

The hash code of the resource data is based on the concrete type and domain names.

Constructs a mailing list info resource data from mailing list and error mailbox.

Specifies a mailbox which is responsible for the mailing list or mailbox. If this domain name names the root, the owner of the MINFO RR is responsible for itself. Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g., Msgroup-request for Msgroup. This field provides a more general mechanism. Specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR (similar to the ERRORS-TO: field which has been proposed). If this domain name names the root, errors should be returned to the sender of the message.

Specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR (similar to the ERRORS-TO: field which has been proposed). If this domain name names the root, errors should be returned to the sender of the message.

RFC 1876.

            +-----+---------+------+-----------+----------+
            | bit | 0-7     | 8-15 | 16-23     | 24-31    |
            +-----+---------+------+-----------+----------+
            | 0   | VERSION | SIZE | HORIZ PRE | VERT PRE |
            +-----+---------+------+-----------+----------+
            | 32  | LATITUDE                              |
            +-----+---------------------------------------+
            | 64  | LONGITUDE                             |
            +-----+---------------------------------------+
            | 96  | ALTITUDE                              |
            +-----+---------------------------------------+

The maximum value for the size field.

The number of bytes this resource data takes.

Constructs an instance from the version, size, horizontal precision, vertical precision, latitude, longitude and altitude fields.

Version number of the representation. This must be zero. Implementations are required to check this field and make no assumptions about the format of unrecognized versions. The diameter of a sphere enclosing the described entity, in centimeters. Only numbers of the form decimal digit times 10 in the power of a decimal digit are allowed since it is expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to 9e9(90,000km) to be expressed. This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5. Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), it is therefore suitable for use as a "worldwide" size. The horizontal precision of the data, in centimeters, expressed using the same representation as Size. This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. (This was chosen to match the interpretation of Size; to get a "plus or minus" value, divide by 2.) The vertical precision of the data, in centimeters, expressed using the sane representation as for Size. This is the total potential vertical error, rather than a "plus or minus" value. (This was chosen to match the interpretation of SIize; to get a "plus or minus" value, divide by 2.) Note that if altitude above or below sea level is used as an approximation for altitude relative to the ellipsoid, the precision value should be adjusted. The latitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude. The longitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude. The altitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563). Altitude above (or below) sea level may be used as an approximation of altitude relative to the the spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the spheroid. Adjustments to Altitude and/or VerticalPrecision will be necessary in most cases. The Defense Mapping Agency publishes geoid height values relative to the ellipsoid.

Two DnsResourceDataLocationInformation are equal iff their version, size, horizontal precision, vertical precision, latitude, longitude and altitude fields are equal.

A hash code based on the version, size, horizontal precision, vertical precision, latitude, longitude and altitude fields

Version number of the representation. This must be zero. Implementations are required to check this field and make no assumptions about the format of unrecognized versions.

The diameter of a sphere enclosing the described entity, in centimeters. Only numbers of the form decimal digit times 10 in the power of a decimal digit are allowed since it is expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to 9e9(90,000km) to be expressed. This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5. Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), it is therefore suitable for use as a "worldwide" size.

The horizontal precision of the data, in centimeters, expressed using the same representation as Size. This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. (This was chosen to match the interpretation of Size; to get a "plus or minus" value, divide by 2.)

The vertical precision of the data, in centimeters, expressed using the sane representation as for Size. This is the total potential vertical error, rather than a "plus or minus" value. (This was chosen to match the interpretation of SIize; to get a "plus or minus" value, divide by 2.) Note that if altitude above or below sea level is used as an approximation for altitude relative to the ellipsoid, the precision value should be adjusted.

The latitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude.

The longitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude.

The altitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563). Altitude above (or below) sea level may be used as an approximation of altitude relative to the the spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences. (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the spheroid. Adjustments to Altitude and/or VerticalPrecision will be necessary in most cases. The Defense Mapping Agency publishes geoid height values relative to the ellipsoid.

RFC 2137.

The general update signatory field bit has no special meaning. If the other three bits are all zero, it must be one so that the field is non-zero to designate that the key is an update key. The meaning of all values of the signatory field with the general bit and one or more other signatory field bits on is reserved.

If non-zero, this key is authorized to add and update RRs for only a single owner name. If there already exist RRs with one or more names signed by this key, they may be updated but no new name created until the number of existing names is reduced to zero. This bit is meaningful only for mode A dynamic zones and is ignored in mode B dynamic zones. This bit is meaningful only if the owner name is a wildcard. (Any dynamic update KEY with a non-wildcard name is, in effect, a unique name update key.)

If non-zero, this key is authorized to add and delete RRs even if there are other RRs with the same owner name and class that are authenticated by a SIG signed with a different dynamic update KEY. If zero, the key can only authorize updates where any existing RRs of the same owner and class are authenticated by a SIG using the same key. This bit is meaningful only for type A dynamic zones and is ignored in type B dynamic zones. Keeping this bit zero on multiple KEY RRs with the same or nested wild card owner names permits multiple entities to exist that can create and delete names but can not effect RRs with different owner names from any they created. In effect, this creates two levels of dynamic update key, strong and weak, where weak keys are limited in interfering with each other but a strong key can interfere with any weak keys or other strong keys.

If nonzero, this key is authorized to attach, detach, and move zones by creating and deleting NS, glue A, and zone KEY RR(s). If zero, the key can not authorize any update that would effect such RRs. This bit is meaningful for both type A and type B dynamic secure zones. NOTE: do not confuse the "zone" signatory field bit with the "zone" key type bit.

Represents a gateway to which an IPsec tunnel may be created in order to reach the entity named by an IPsec resource record.

Two gateway representations are equal if they are of the same type and the value is the same.

Serves as a hash function for a particular type.

A hash code for the current gateway represnetation.

An instance that represents that no gateway exists.

The gateway represnetation type.

The number of bytes the gateway represnetation takes.

RFC 2671.

            +------+----------------+----------+
            | bit  | 0-7            | 8-15     |
            +------+----------------+----------+
            | 0    | Name                      |
            | ...  |                           |
            +------+---------------------------+
            |      | Type = OPT                |
            +------+---------------------------+
            |      | Sender's UDP payload size |
            +------+----------------+----------+
            |      | EXTENDED-RCODE | VERSION  |
            +------+----------------+----------+
            |      | Flags                     |
            +------+---------------------------+
            |      | Resource Data Length      |
            +------+---------------------------+
            |      | Resource Data             |
            | ...  |                           |
            +------+---------------------------+

RFC 1035. A resource record with data. Used for the answers, authorities and additionals sections. For OPT resource records, DnsOptResourceRecord should be used.

            +------+-------------------------------------------------+
            | byte | 0-1                                             |
            +------+-------------------------------------------------+
            | 0    | Name                                            |
            | ...  |                                                 |
            +------+-------------------------------------------------+
            |      | Type                                            |
            +------+-------------------------------------------------+
            |      | Class                                           |
            +------+-------------------------------------------------+
            |      | TTL                                             |
            |      |                                                 |
            +------+-------------------------------------------------+
            |      | Resource Data Length                            |
            +------+-------------------------------------------------+
            |      | Resource Data                                   |
            | ...  |                                                 |
            +------+-------------------------------------------------+

RFC 1035. All RRs have the same top level format shown below:

            +------+-------------------------------------------------+
            | byte | 0-1                                             |
            +------+-------------------------------------------------+
            | 0    | Name                                            |
            | ...  |                                                 |
            +------+-------------------------------------------------+
            |      | Type                                            |
            +------+-------------------------------------------------+
            |      | Class                                           |
            +------+-------------------------------------------------+
            |      | TTL (not available in queries)                  |
            |      |                                                 |
            +------+-------------------------------------------------+
            |      | Resource Data Length (not available in queries) |
            +------+-------------------------------------------------+
            |      | Resource Data (not available in queries)        |
            | ...  |                                                 |
            +------+-------------------------------------------------+

A string representing the resource record by concatenating its different parts.

An owner name, i.e., the name of the node to which this resource record pertains.

Two octets containing one of the RR TYPE codes.

Two octets containing one of the RR CLASS codes.

A 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. Not available in queries.

A variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address. Not available in queries.

Creates a resource record from domain name, type, class, ttl and data.

An owner name, i.e., the name of the node to which this resource record pertains. Two octets containing one of the RR TYPE codes. Two octets containing one of the RR CLASS codes. A 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. A variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address.

A string representing the resource record by concatenating its different parts.

Two DnsDataResourceRecord are equal iff their domain name, dns type, dns class, ttl and data fields are equal.

A hash code of the combination of the domain name, dns type, dns class, ttl and data fields.

Constructs an instance out of the domain name, senders UDP payload size, extended return code, version, flags and data fields.

An owner name, i.e., the name of the node to which this resource record pertains. The number of octets of the largest UDP payload that can be reassembled and delivered in the sender's network stack. Note that path MTU, with or without fragmentation, may be smaller than this. Forms upper 8 bits of extended 12-bit RCODE. Note that EXTENDED-RCODE value "0" indicates that an unextended RCODE is in use (values "0" through "15"). Indicates the implementation level of whoever sets it. Full conformance with this specification is indicated by version "0". Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, to minimize the responder and network load of discovering the greatest common implementation level between requestor and responder. A requestor's version numbering strategy should ideally be a run time configuration option. OPT flags. An OPT resource record data

A string representing the resource record by concatenating its different parts.

The number of octets of the largest UDP payload that can be reassembled and delivered in the sender's network stack. Note that path MTU, with or without fragmentation, may be smaller than this.

Forms upper 8 bits of extended 12-bit RCODE. Note that EXTENDED-RCODE value "0" indicates that an unextended RCODE is in use (values "0" through "15").

Indicates the implementation level of whoever sets it. Full conformance with this specification is indicated by version "0". Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, to minimize the responder and network load of discovering the greatest common implementation level between requestor and responder. A requestor's version numbering strategy should ideally be a run time configuration option.

OPT flags.

Represents a DNS layer.

Writes the layer to the buffer.

The buffer to write the layer to. The offset in the buffer to start writing the layer at.

Finalizes the layer data in the buffer. Used for fields that must be calculated according to the layer's payload (like checksum).

True iff the two objects are equal Layers.

A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied the corresponding reply and can be used by the requester to match up replies to outstanding queries.

A one bit field that specifies whether this message is a query (0), or a response (1).

Specifies whether this message is a query or a response.

Specifies kind of query in this message. This value is set by the originator of a query and copied into the response.

This bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. Note that the contents of the answer section may have multiple owner names because of aliases. The AA bit corresponds to the name which matches the query name, or the first owner name in the answer section.

Specifies that this message was truncated due to length greater than that permitted on the transmission channel.

This bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional.

This bit is set or cleared in a response, and denotes whether recursive query support is available in the name server.

Reserved for future use. Must be false in all queries and responses.

The name server side of a security-aware recursive name server must not set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. The name server side should set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic. The resolver side must follow the Authenticating DNS Responses procedure to determine whether the RRs in question are authentic. However, for backward compatibility, a recursive name server may set the AD bit when a response includes unsigned CNAME RRs if those CNAME RRs demonstrably could have been synthesized from an authentic DNAME RR that is also included in the response according to the synthesis rules described in RFC 2672.

Exists in order to allow a security-aware resolver to disable signature validation in a security-aware name server's processing of a particular query. The name server side must copy the setting of the CD bit from a query to the corresponding response. The name server side of a security-aware recursive name server must pass the state of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether it is required to verify the response data it returns to the name server side. If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set, the recursive name server should, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, and the recursive name server should not interfere. If the resolver side implements a BAD cache and the name server side receives a query that matches an entry in the resolver side's BAD cache, the name server side's response depends on the state of the CD bit in the original query. If the CD bit is set, the name server side should return the data from the BAD cache; if the CD bit is not set, the name server side must return RCODE 2 (server failure). The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. Several of the possible reasons why signature validation might fail involve conditions that may not apply equally to the recursive name server and the client that invoked it. For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security that the recursive name server does not share. In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client.

A response of the server that can sign errors or other messages.

The queries resource records. Typically exactly one query will exist.

The answers resource records.

The authorities resource records.

The additionals resource records.

All the resource records by the order the will be written.

How to compress the domain names.

The number of bytes this layer will take.

An enum for all the different tcp option types.

End of Option List (RFC793)

No-Operation (RFC793)

Maximum Segment Size (RFC793)

WSOPT - Window Scale (RFC1323)

SACK Permitted (RFC2018)

SACK (RFC2018)

Echo (obsoleted by option 8) (RFC1072)

Echo Reply (obsoleted by option 8) (RFC1072)

TSOPT - Time Stamp Option (RFC1323)

Partial Order Connection Permitted (RFC1693)

Partial Order Service Profile (RFC1693)

CC (RFC1644)

CC.NEW (RFC1644)

CC.ECHO (RFC1644)

TCP Alternate Checksum Request (RFC1146)

TCP Alternate Checksum Data (RFC1146)

MD5 Signature Option (RFC2385)

Selective Negative Acknowledgements.

Denote Packet Mood (RFC5841)

Quick-Start Response (RFC4782)

User Timeout Option (RFC5482)

TCP Authentication Option (RFC5925)

IPv6 Routing Type. Used in Routing Extension Header.

RFCs 2460, 5095. Deprecated.

Deprecated 06-May-2009.

RFC 6275.

RFC 6554.

RFC 5844.

            +-----+------------+-----+--------------+
            | Bit | 0-5        | 6-7 | 8-15         |
            +-----+------------+-----+--------------+
            | 0   | Option Type      | Opt Data Len |
            +-----+------------+-----+--------------+
            | 16  | Prefix-len | Reserved           |
            +-----+------------+--------------------+
            | 32  | IPv4 home address               |
            |     |                                 |
            +-----+---------------------------------+

RFC 5844.

The prefix length of the address.

Contains the IPv4 home address.

The maximum value for Prefix Length.

The number of bytes this option data takes.

Creates an instance from Prefix Length and Home Address.

Indicates the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option. Contains the IPv4 home address that is being requested. The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation.

Indicates the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option.

Contains the IPv4 home address that is being requested. The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation.

RFC 6602.

Invalid value.

RFC 6602.

List of IPv6 extension headers.

Create an instance from a ReadOnlyCollection of extension headers. Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. Assumes the collection won't be modified.

The extension headers.

Create an instance from an array of extension headers. Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. Assumes the collection won't be modified.

The extension headers.

Create an instance from a list of extension headers. Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. Assumes the collection won't be modified.

The extension headers.

Create an instance from an enumerable of extension headers. Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. Assumes the collection won't be modified.

The extension headers.

Returns an enumerator that iterates through the collection.

A that can be used to iterate through the collection. 1

Returns an enumerator that iterates through a collection.

An object that can be used to iterate through the collection. 2

True iff all the extension headers are equal to the given extension headers instance.

A hash code based on all the extension headers.

Returns the extension header in the 'index' place.

The index of the extension header returned. The extension header in the 'index' place.

The extension headers.

The total number of bytes the extension headers take.

True iff a parsing issue wasn't encountered when parsing the extension headers.

The protocol of the first extension header or null if there are no extension headers.

The protocol of the last extension header or null if there are no extension headers.

The next header of the last extension header or null if there are no extension headers.

An empty list of extension headers.

Group Record Type.

Illegal record type.

A "Current-State Record" is sent by a system in response to a Query received on an interface. It reports the current reception state of that interface, with respect to a single multicast address. MODE_IS_INCLUDE - indicates that the interface has a filter mode of INCLUDE for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's source list for the specified multicast address, if it is non-empty.

A "Current-State Record" is sent by a system in response to a Query received on an interface. It reports the current reception state of that interface, with respect to a single multicast address. MODE_IS_EXCLUDE - indicates that the interface has a filter mode of EXCLUDE for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's source list for the specified multicast address, if it is non-empty.

A "Filter-Mode-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of the filter mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface on which the change occurred. CHANGE_TO_INCLUDE_MODE - indicates that the interface has changed to INCLUDE filter mode for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's new source list for the specified multicast address, if it is non-empty.

A "Filter-Mode-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of the filter mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface on which the change occurred. CHANGE_TO_EXCLUDE_MODE - indicates that the interface has changed to EXCLUDE filter mode for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's new source list for the specified multicast address, if it is non-empty.

A "Source-List-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of source list that is *not* coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface on which the change occurred. ALLOW_NEW_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the additional sources that the system wishes to hear from, for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were added to the list; if the change was to an EXCLUDE source list, these are the addresses that were deleted from the list. If a change of source list results in both allowing new sources and blocking old sources, then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES.

A "Source-List-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of source list that is *not* coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface on which the change occurred. BLOCK_OLD_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the sources that the system no longer wishes to hear from, for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were deleted from the list; if the change was to an EXCLUDE source list, these are the addresses that were added to the list. If a change of source list results in both allowing new sources and blocking old sources, then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES.

The version of the IGMP query message.

No query version - not a query.

Version 1 query - RFC1112.

Version 2 query - RFC2236.

Version 3 query - RFC3376.

The version of the query could not be interpreted.

RFC 1112. Version 1 (query or report):

            +-----+---------+------+--------+----------+
            | Bit | 0-3     | 4-7  | 8-15   | 16-31    |
            +-----+---------+------+--------+----------+
            | 0   | Version | Type | Unused | Checksum |
            +-----+---------+------+--------+----------+
            | 32  | Group Address                      |
            +-----+------------------------------------+

RFC 2236. Version 2 (query, report or leave group):

            +-----+------+---------------+----------+
            | Bit | 0-7  | 8-15          | 16-31    |
            +-----+------+---------------+----------+
            | 0   | Type | Max Resp Time | Checksum |
            +-----+------+---------------+----------+
            | 32  | Group Address                   |
            +-----+---------------------------------+

RFC 3376. Version 3 query:

            +-----+------+---+-----+---------------+-----------------------+
            | Bit | 0-3  | 4 | 5-7 | 8-15          | 16-31                 |
            +-----+------+---+-----+---------------+-----------------------+
            | 0   | Type = 0x11    | Max Resp Code | Checksum              |
            +-----+----------------+---------------+-----------------------+
            | 32  | Group Address                                          |
            +-----+------+---+-----+---------------+-----------------------+
            | 64  | Resv | S | QRV | QQIC          | Number of Sources (N) |
            +-----+------+---+-----+---------------+-----------------------+
            | 96  | Source Address [1]                                     |
            +-----+--------------------------------------------------------+
            | 128 | Source Address [2]                                     |
            +-----+--------------------------------------------------------+
            .     .                         .                              .
            .     .                         .                              .
            +-----+--------------------------------------------------------+
            | 64  | Source Address [N]                                     |
            | +   |                                                        |
            | 32N |                                                        |
            +-----+--------------------------------------------------------+

RFC 3376. Version 3 report:

            +-----+-------------+----------+-----------------------------+
            | Bit | 0-7         | 8-15     | 16-31                       |
            +-----+-------------+----------+-----------------------------+
            | 0   | Type = 0x22 | Reserved | Checksum                    |
            +-----+-------------+----------+-----------------------------+
            | 32  | Reserved               | Number of Group Records (M) |
            +-----+------------------------+-----------------------------+
            | 64  | Group Record [1]                                     |
            .     .                                                      .
            .     .                                                      .
            .     .                                                      .
            |     |                                                      |
            +-----+------------------------------------------------------+
            |     | Group Record [2]                                     |
            .     .                                                      .
            .     .                                                      .
            .     .                                                      .
            |     |                                                      |
            +-----+------------------------------------------------------+
            |     |                         .                            |
            .     .                         .                            .
            |     |                         .                            |
            +-----+------------------------------------------------------+
            |     | Group Record [M]                                     |
            .     .                                                      .
            .     .                                                      .
            .     .                                                      .
            |     |                                                      |
            +-----+------------------------------------------------------+

The number of bytes the IGMP header takes for all messages but query version 3. All the bytes but the records of the report version 3.

The number of bytes the query version 3 IGMP message header takes. All the bytes but the source addresses.

The maximum value for the query robustness varialbe.

Creates a Layer that represents the datagram to be used with PacketBuilder.

IGMP is valid if the checksum is correct, the length fits the message type and data and the MaxResponseCode is 0 in messages where it is not used.

Calculates the value from the given code as follows:

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |1| exp | mant  |
            +-+-+-+-+-+-+-+-+

Value = (mant | 0x10) << (exp + 3).

The Max Resp Code field specifies the maximum time allowed before sending a responding report.

The maximum value for the max response time in version 3 messages.

The maximum value for the query interval.

The type of the IGMP message of concern to the host-router interaction.

The version of the IGMP protocol for this datagram.

The IGMP version of a Membership Query message is determined as follows: IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero. IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-zero. IGMPv3 Query: length >= 12 octets. If the type is not a query, None will be returned. If the query message do not match any of the above conditions (e.g., a Query of length 10 octets) Unknown will be returned.

The Max Resp Code field specifies the maximum time allowed before sending a responding report. The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows: If Max Resp Code < 128, Max Resp Time = Max Resp Code. If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows:

                0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |1| exp | mant  |
                +-+-+-+-+-+-+-+-+

Max Resp Time = (mant | 0x10) << (exp + 3). Small values of Max Resp Time allow IGMPv3 routers to tune the "leave latency" (the time between the moment the last host leaves a group and the moment the routing protocol is notified that there are no more members). Larger values, especially in the exponential range, allow tuning of the burstiness of IGMP traffic on a network.

The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows: If the query version is 1 or 2 or if Max Resp Code < 128, Max Resp Time = Max Resp Code. If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |1| exp | mant  |
                +-+-+-+-+-+-+-+-+

Max Resp Time = (mant | 0x10) << (exp + 3).

The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet.

True iff the checksum value is correct according to the datagram data.

Valid only on query of version 3.

The Querier's Query Interval Code field specifies the [Query Interval] used by the querier. The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows: If QQIC < 128, QQI = QQIC If QQIC >= 128, QQIC represents a floating-point value as follows:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |1| exp | mant  |
                +-+-+-+-+-+-+-+-+

QQI = (mant | 0x10) << (exp + 3) Multicast routers that are not the current querier adopt the QQI value from the most recently received Query as their own [Query Interval] value, unless that most recently received QQI was zero, in which case the receiving routers use the default [Query Interval] value.

Valid only on query of version 3.

The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows: If QQIC < 128, QQI = QQIC If QQIC >= 128, QQIC represents a floating-point value as follows:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |1| exp | mant  |
                +-+-+-+-+-+-+-+-+

QQI = (mant | 0x10) << (exp + 3)

Valid only on query of version 3.

The Number of Sources (N) field specifies how many source addresses are present in the Query. This number is zero in a General Query or a Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. This number is limited by the MTU of the network over which the Query is transmitted. For example, on an Ethernet with an MTU of 1500 octets, the IP header including the Router Alert option consumes 24 octets, and the IGMP fields up to including the Number of Sources (N) field consume 12 octets, leaving 1464 octets for source addresses, which limits the number of source addresses to 366 (1464/4).

Valid only on query of version 3.

The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in the Number of Sources (N) field.

Valid only on query of version 3.

The Number of Group Records (M) field specifies how many Group Records are present in this Report.

Valid only on report of version 3.

Each Group Record is a block of fields containing information pertaining to the sender's membership in a single multicast group on the interface from which the Report is sent.

RFC 1788.

The value of this field determines the format of the remaining data.

The ICMP code values for Code Conversion Failed ICMP type.

RFC 1475. The introduction of network layer conversion requires a new message type, to report conversion errors. Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. This message is only sent when a valid datagram cannot be converted.

RFC 2616. Represents an HTTP layer.

Two HTTP layers are equal iff they have the same version, header and body. Extended by specific HTTP layers types for more checks.

Writes the HTTP layer to the buffer.

The buffer to write the layer to. The offset in the buffer to start writing the layer at.

True iff the message is a request and iff the message is not a response.

True iff the message is a response and iff the message is not a request.

The version of this HTTP message.

The header of the HTTP message.

Message Body.

The number of bytes this layer will take.

Base class for all datagrams that behave like Ethernet. Contains a header with an Ethernet type and a payload that should be according to this Ethernet type.

Header length in bytes.

Ethernet type (next protocol).

The Ethernet payload.

The bytes padding the Ethernet packet beyond the actual Ethernet payload until it is a 60 bytes packet. This assumes we know how to calculate the actual payload length (For example, by using the Total Length of the IPv4 payload). If we don't know how to calculate the actual payload length will be returned. The Padding doesn't include the and the if any exist.

The bytes padding the Ethernet packet beyond the actual Ethernet payload and beyond the first 60 bytes of the packet. This assumes we know how to calculate the actual payload length (For example, by using the Total Length of the IPv4 payload). If we don't know how to calculate the actual payload length will be returned. The trailer doesn't include the and the if any exist.

The 4 bytes of the Frame Check Sequence (FCS). Usually, these bytes won't be available because the device remvoed them after checking their validity. We assume they exist when we see that the Ethernet extra bytes pads to 68 bytes or more. If the packet isn't that long or we don't know how to calculate the real payload length, will be returned.

A sequence of bytes that includes the padding bytes, trailer bytes and the frame check sequence bytes.

The Ethernet payload as a VLAN Tagged Frame datagram.

The Ethernet payload as an IPv4 datagram.

The Ethernet payload as an IPv6 datagram.

Returns the IP Datagram. This is either an IPv4 Datagram or an IPv6 Datagram (according to the Ethernet Type).

The Ethernet payload as an ARP datagram.

RFC 4255.

            +-----+-----------+-----------+
            | bit | 0-7       | 8-15      |
            +-----+-----------+-----------+
            | 0   | algorithm | fp type   |
            +-----+-----------+-----------+
            | 16  | fingerprint           |
            | ... |                       |
            +-----+-----------------------+

Constructs an instance out of the algorithm, fingerprint type and fingerprint fields.

Describes the algorithm of the public key. Describes the message-digest algorithm used to calculate the fingerprint of the public key. The fingerprint is calculated over the public key blob. The message-digest algorithm is presumed to produce an opaque octet string output, which is placed as-is in the RDATA fingerprint field.

Two DnsResourceDataSshFingerprint are equal iff the algorithm, fingerprint type and fingerprint fields are equal.

A hash code based on the algorithm, fingerprint type and fingerprint fields.

Describes the algorithm of the public key.

Describes the message-digest algorithm used to calculate the fingerprint of the public key.

The fingerprint is calculated over the public key blob. The message-digest algorithm is presumed to produce an opaque octet string output, which is placed as-is in the RDATA fingerprint field.

RFC 5155.

            +-----+-------------+----------+--------+------------+
            | bit | 0-7         | 8-14     | 15     | 16-31      |
            +-----+-------------+----------+--------+------------+
            | 0   | Hash Alg    | Reserved | OptOut | Iterations |
            +-----+-------------+----------+--------+------------+
            | 32  | Salt Length | Salt                           |
            +-----+-------------+                                |
            | ... |                                              |
            +-----+----------------------------------------------+

RFC 5155.

            +-----+-------------+----------+--------+------------+
            | bit | 0-7         | 8-14     | 15     | 16-31      |
            +-----+-------------+----------+--------+------------+
            | 0   | Hash Alg    | Reserved | OptOut | Iterations |
            +-----+-------------+----------+--------+------------+
            | 32  | Salt Length | Salt                           |
            +-----+-------------+                                |
            | ... |                                              |
            +-----+----------------------------------------------+
            | ... | ...                                          |
            +-----+----------------------------------------------+

Identifies the cryptographic hash algorithm used to construct the hash-value.

Can be used to indicate different processing. All undefined flags must be zero.

Defines the number of additional times the hash function has been performed. More iterations result in greater resiliency of the hash value against dictionary attacks, but at a higher computational cost for both the server and resolver.

Appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks.

Constructs a next domain secure 3 parameters resource data from the hash algorithm, flags, iterations and salt fields.

Two DnsResourceDataNextDomainSecure3Parameters are equal if they have the hash algorithm, flags, iterations and salt fields.

A hash code made up from the combination of the hash algorithm, flags, iterations and salt fields.

RFC 3596.

            +-----+-------+
            | bit | 0-127 |
            +-----+-------+
            | 0   | IP    |
            +-----+-------+

Constructs an IPv6 resource data from the given IP.

Two IPv6 resource datas are equal if their IP is equal.

Returns the hash code of the IPv6 value.

The IPv6 value.

RFC 2671. A set of options.

Constructs options from the given list of options. The given otpions list should be modified after the call to this constructor.

Two options objects are equal if they have the same options in the same order.

A hash code based on the list of options.

Empty options.

The list of options.

The total number of bytes the options take.

http://files.dns-sd.org/draft-sekar-dns-llq.txt.

Undefined value.

An LLQ is initiated by a client, and is completed via a four-way handshake. This handshake provides resilience to packet loss, demonstrates client reachability, and reduces denial of service attack opportunities.

If the client desires to maintain the LLQ beyond the duration specified in the LEASE-LIFE field of the Request Acknowledgment, the client must send a Refresh Request. A Refresh Request is identical to an LLQ Challenge Response, but with the LLQ-OPCODE set to LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request returns no answers.

When a change ("event") occurs to a name server's zone, the server must check if the new or deleted resource records answer any LLQs. If so, the resource records must be sent to the LLQ requesters in the form of a gratuitous DNS response sent to the client, with the question(s) being answered in the Question section, and answers to these questions in the Answer section. The response also includes an OPT RR as the last record in the Additional section. This OPT RR contains, in its RDATA, an entry for each LLQ being answered in the message. Entries must include the LLQ-ID. This reduces the potential for spoof events being sent to a client.

RFC 2535.

Undefined value.

Connection with TLS.

Connection with email.

DNS security. The protocol field should be set to this value for zone keys and other keys used in DNS security. Implementations that can determine that a key is a DNS security key by the fact that flags label it a zone key or the signatory flag field is non-zero are not required to check the protocol field.

Oakley/IPSEC [RFC 2401] protocol. Indicates that this key is valid for use in conjunction with that security standard. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user flag bits are set. The presence of a KEY resource with this protocol value is an assertion that the host speaks Oakley/IPSEC.

The key can be used in connection with any protocol for which KEY RR protocol octet values have been defined. The use of this value is discouraged and the use of different keys for different protocols is encouraged.

A simple TCP option - holds only the type.

The number of bytes this option will take.

True iff this option may appear at most once in a datagram.

TCP POC-permitted Option (RFC 1693)

            +-----+------+--------+
            | Bit | 0-7  | 8-15   |
            +-----+------+--------+
            | 0   | Kind | Length |
            +-----+------+--------+

The number of bytes this option take.

The number of bytes this option value take.

Creates a partial order connection permitted option.

Tries to read the option from a buffer starting from the option value (after the type and length).

The number of bytes this option will take.

True iff this option may appear at most once in a datagram.

TCP Alternate Checksum Request Option (RFC 1146).

            +-----+----------+
            | Bit | 0-7      |
            +-----+----------+
            | 0   | Kind     |
            +-----+----------+
            | 8   | Length   |
            +-----+----------+
            | 16  | Checksum |
            +-----+----------+

Here chksum is a number identifying the type of checksum to be used. The currently defined values of chksum are: 0 - TCP checksum. 1 - 8-bit Fletcher's algorithm. 2 - 16-bit Fletcher's algorithm. Note that the 8-bit Fletcher algorithm gives a 16-bit checksum and the 16-bit algorithm gives a 32-bit checksum.

The number of bytes this option take.

The number of bytes this option value take.

Creates the option using the given checksum type.

The default checksum type is the TCP checksum.

Tries to read the option from a buffer starting from the option value (after the type and length).

The type of the checksum.

The number of bytes this option will take.

True iff this option may appear at most once in a datagram.

Represents an IPv6 address.

The number of bytes the address take.

Create an address from a 128 bit integer. 0 -> :: 1 -> ::1 256 -> ::100

Creates an address from an address string ("2001:0db8:0::22:1.2.3.4").

Gets the address value as a 128 bit integer.

Two addresses are equal if the have the exact same value.

Two addresses are different if the have different values.

The hash code of an address is the hash code of its 128 bit integer value.

Translates the address to a string (0ABC:1234:5678:0443:0ABC:1234:5678:0443).

Translates the address to a string given the format.

Translates the address to a string given the format provider.

Translates the address to a string given the format and format provider.

The zero address (::).

The maximum address value.

RFC 4782.

            +-----+-------------+------+----------+--------------+-------+-------+
            | Bit | 0-7         | 8-15 | 16-19    | 20-23        | 24-29 | 30-31 |
            +-----+-------------+------+----------+--------------+-------+-------+
            | 0   | Option Type | 6    | Function | Rate Request | QS TTL        |
            +-----+-------------+------+----------+--------------+-------+-------+
            | 32  | QS Nonce                                             | R     |
            +-----+------------------------------------------------------+-------+

RFC 4782. Common interface of a quick start option.

The function of this quick start option.

If function is request then this field is the rate request. If function is report then this field is the rate report.

The rate translated to KBPS.

The Quick-Start TTL (QS TTL) field. The sender MUST set the QS TTL field to a random value. Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. For a Rate Request, the transport sender MUST calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: TTL Diff = ( IP TTL - QS TTL ) mod 256

The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. This is particularly important if the receiver knows the original value of the Rate Request (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, when the received Rate Request was, in fact, less than K. The format for the 30-bit QS Nonce. Bits Purpose Bits 0-1Rate 15 -> Rate 14 Bits 2-3Rate 14 -> Rate 13 Bits 4-5Rate 13 -> Rate 12 Bits 6-7Rate 12 -> Rate 11 Bits 8-9Rate 11 -> Rate 10 Bits 10-11Rate 10 -> Rate 9 Bits 12-13Rate 9 -> Rate 8 Bits 14-15Rate 8 -> Rate 7 Bits 16-17Rate 7 -> Rate 6 Bits 18-19Rate 6 -> Rate 5 Bits 20-21Rate 5 -> Rate 4 Bits 22-23Rate 4 -> Rate 3 Bits 24-25Rate 3 -> Rate 2 Bits 26-27Rate 2 -> Rate 1 Bits 28-29Rate 1 -> Rate 0 The transport sender MUST initialize the QS Nonce to a random value. If the router reduces the Rate Request from rate K to rate K-1, then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. Similarly, if the router reduces the Rate Request by N steps, the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. The receiver MUST report the QS Nonce back to the sender. If the Rate Request was not decremented in the network, then the QS Nonce should have its original value. Similarly, if the Rate Request was decremented by N steps in the network, and the receiver reports back a Rate Request of K, then the last 2K bits of the QS Nonce should have their original value.

The number of bytes the option data takes.

Creates an instance from the given function, rate, TTL and nonce.

Function field. For rate request, this is the Rate Request field. For Report of Approved Rate, this is the Rate Report field. For a Rate Request, contains the Quick-Start TTL (QS TTL) field. The sender must set the QS TTL field to a random value. Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. The transport sender must calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: TTL Diff = ( IP TTL - QS TTL ) mod 256. For a Report of Approved Rate, this is not used. For a Rate Request and Report of Approved Rate, contain a 30-bit QS Nonce. The sender should set the QS Nonce to a random value.

Parses an option from the given data.

The data to parse. The option if parsing was successful, null otherwise.

Function field.

For rate request, this is the Rate Request field. For Report of Approved Rate, this is the Rate Report field.

The rate translated to KBPS.

For a Rate Request, contains the Quick-Start TTL (QS TTL) field. The sender must set the QS TTL field to a random value. Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. The transport sender must calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: TTL Diff = ( IP TTL - QS TTL ) mod 256. For a Report of Approved Rate, this is not used.

For a Rate Request and Report of Approved Rate, contain a 30-bit QS Nonce. The sender should set the QS Nonce to a random value.

+-----+-----+ | Bit | 0-7 | +-----+-----+ | 0 | 0 | +-----+-----+

RFC 2460.

            +-----+-------------+
            | Bit | 0-7         |
            +-----+-------------+
            | 0   | Option Type |
            +-----+-------------+

The number of bytes this option takes.

The number of bytes the option takes.

Constructs an instance.

RFC 5555.

            +-----+------------+---+---+--------------+
            | Bit | 0-5        | 6 | 7 | 8-15         |
            +-----+------------+---+---+--------------+
            | 0   | Option Type        | Opt Data Len |
            +-----+------------+---+---+--------------+
            | 16  | Prefix-len | P | Reserved         |
            +-----+------------+---+------------------+
            | 32  | IPv4 home address                 |
            |     |                                   |
            +-----+-----------------------------------+

The maximum value for Prefix Length.

The number of bytes this option data takes.

Creates an instance from Prefix Length, Request Prefix and Home Address.

The length of the prefix allocated to the mobile node. If only a single address is allocated, this field must be set to 32. In the first binding update requesting a prefix, the field contains the prefix length requested. However, in the following binding updates, this field must contain the length of the prefix allocated. A value of zero is invalid and must be considered an error. When true, indicates that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes. The mobile node's IPv4 home address that should be defended by the home agent. This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. The value 0.0.0.0 is used to request an IPv4 home address from the home agent. A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the RequestPrefix flag. The mobile node could then form an IPv4 home address based on the allocated prefix. Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a

When true, indicates that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes.

The mobile node's IPv4 home address that should be defended by the home agent. This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. The value 0.0.0.0 is used to request an IPv4 home address from the home agent. A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the RequestPrefix flag. The mobile node could then form an IPv4 home address based on the allocated prefix. Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a prefix.

RFC 5555, 5844.

            +-----+-------------+--------------+
            | Bit | 0-7         | 8-15         |
            +-----+-------------+--------------+
            | 0   | Option Type | Opt Data Len |
            +-----+-------------+--------------+
            | 16  | Reserved                   |
            +-----+----------------------------+
            | 32  | IPv4 address               |
            |     |                            |
            +-----+----------------------------+

The number of bytes this option data takes.

RFC 5568. A code for a Link Layer Address IPv6 option.

Wildcard requesting resolution for all nearby access points.

Link-Layer Address of the New Access Point. The address contains the link-layer address of the access point for which handover is about to be attempted. This is used in the Router Solicitation for Proxy Advertisement message.

Link-Layer Address of the MN (Mobility Node). The address contains the link-layer address of an MN. It is used in the Handover Initiate message.

Link-Layer Address of the NAR (New Access Router) (i.e., Proxied Originator). The address contains the link-layer address of the access router to which the Proxy Router Solicitation message refers.

Link-Layer Address of the source of RtSolPr (Router Solicitation for Proxy Advertisement) or PrRtAdv (Proxy Router Advertisement) message.

The access point identified by the LLA belongs to the current interface of the router.

No prefix information available for the access point identified by the LLA

No fast handover support available for the access point identified by the LLA

RFC 5844.

Success.

Failure, reason unspecified.

Administratively prohibited.

Incorrect IPv4 home address.

Invalid IPv4 address.

Dynamic IPv4 home address assignment not available.

RFC 6089.

Creates options from a list of options.

The list of options.

Creates options from a list of options.

The list of options.

No options instance.

RFC 4285

Invalid value.

Used to authenticate the Binding Update and Binding Acknowledgement messages based on the shared-key-based security association between the Mobile Node and the Home Agent. The shared-key-based mobility security association between Mobile Node and Home Agent used within this specification consists of a mobility SPI, a key, an authentication algorithm, and the replay protection mechanism in use. The mobility SPI is a number in the range [0-4294967296], where the range [0-255] is reserved. The key consists of an arbitrary value and is 16 octets in length. The authentication algorithm is HMAC_SHA1. The replay protection mechanism may use the Sequence number as specified in RFC 3775 or the Timestamp option. If the Timestamp option is used for replay protection, the mobility security association includes a "close enough" field to account for clock drift. A default value of 7 seconds should be used. This value should be greater than 3 seconds. The MN-HA mobility message authentication option must be the last option in a message with a mobility header if it is the only mobility message authentication option in the message. The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option. Authentication Data = First(96, HMAC_SHA1(MN-HA Shared key, Mobility Data)) Mobility Data = care-of address | home address | Mobility Header (MH) Data MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The Checksum field in the Mobility Header must be set to 0 to calculate the Mobility Data. The first 96 bits from the Message Authentication Code (MAC) result are used as the Authentication Data field.

The MN-AAA authentication mobility option is used to authenticate the Binding Update message based on the shared mobility security association between the Mobile Node and AAA server in Home network (AAAH). It is not used in Binding Acknowledgement messages. The corresponding Binding Acknowledgement messages must be authenticated using the MN-HA mobility message authentication option. The MN-AAA mobility message authentication option must be the last option in a message with a mobility header. The corresponding response must include the MN-HA mobility message authentication option, and must not include the MN-AAA mobility message authentication option. The Mobile Node may use the Mobile Node Identifier option (RFC 4283) to enable the Home Agent to make use of available AAA infrastructure. The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option. The authentication data shall be calculated as follows: Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) hash_fn() is decided by the value of mobility SPI field in the MN-AAA mobility message authentication option. SPI = HMAC_SHA1_SPI: If mobility SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data is calculated as follows: MAC_Mobility Data = SHA1(care-of address | home address | MH Data) MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option.

RFC 6757.

            +-----+---------------------+
            | Bit | 0-7                 |
            +-----+---------------------+
            | 0   | ANI Type            |
            +-----+---------------------+
            | 8   | ANI Length          |
            +-----+---------------------+
            | 16  | Op-ID Type          | 
            +-----+---------------------+
            | 24  | Operator-Identifier |
            | ... |                     | 
            +-----+---------------------+

RFC 6757.

True iff the two options are equal. Two options are equal iff their type, length and data are equal.

Returns the option hash code.

The type of the option.

The number of bytes this option takes.

The minimum number of bytes this option data takes.

Creates an instance from identifier type and identifier.

Indicates the type of the Operator-Identifier. Up to 253 octets of the Operator-Identifier. The encoding of the identifier depends on the used Operator-Identifier Type.

Indicates the type of the Operator-Identifier.

Up to 253 octets of the Operator-Identifier. The encoding of the identifier depends on the used Operator-Identifier Type.

Represents IPv6 layer.

A layer under an Ethernet layer. Must provide the Ethernet Type and the default destination MAC address (if any).

The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload.

The default MAC Address value when this layer is the Ethernet payload. null means there is no default value.

Creates an IPv6 layer with all zero values.

Writes the layer to the buffer.

Finalizes the layer data in the buffer. Used for fields that must be calculated according to the layer's payload (like checksum).

True iff the two IPv4 layers have the same TypeOfService, Identification, Fragmentation, Ttl, Protocol, HeaderChecksum, Source, Destination and Options.

Returns a hash code for the layer. The hash code is a XOR of the TrafficClass and HopLimit combined and the hash codes of the FlowLabel, Source, CurrentDestination, NextHeader, HeaderChecksum, ExtensionHeaders.

Contains the Source, Destination and Protocol.

Available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets.

May be 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 or "real-time" service. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet.

Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 Protocol field. null means that this value should be calculated according to the next layer.

Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.

Address of the originator of the packet.

Address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present).

The IPv6 extension headers.

The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload.

The protocol that should be written in the previous (IPv4) layer (in this case: IP).

The default MAC Address value when this layer is the Ethernet payload. null means there is no default value.

The number of bytes this layer will take.

The IPv6 last next header field. If there are no extension headers, this is the IPv6 layer next header field. If there are extesion headers, this is the last extension header next header field. Returns null if the last next header should be calculated automatically when building a packet.

RFC 5568.

            +-----+-------------+-------------------------+
            | Bit | 0-7         | 8-15                    |
            +-----+-------------+-------------------------+
            | 0   | Next Header | Header Extension Length |
            +-----+-------------+-------------------------+
            | 16  | MH Type     | Reserved                |
            +-----+-------------+-------------------------+
            | 32  | Checksum                              |
            +-----+---------------------------------------+
            | 48  | Sequence #                            |
            +-----+-------------+-------------------------+
            | 64  | Reserved    | Code                    |
            +-----+-------------+-------------------------+
            | 80  | Mobility Options                      |
            | ... |                                       |
            +-----+---------------------------------------+

The minimum number of bytes the message data takes.

Creates an instance from next header, checksum, sequence number, code and options.

Identifies the particular mobility message in question. An unrecognized MH Type field causes an error indication to be sent.

Copied from the corresponding field in the Handover Initiate message to which this message is a response, to enable the receiver to match this Handover Acknowledge message with an outstanding Handover Initiate message.

Describes whether the handover was accepted or not and more details.

RFC 5568.

            +-----+---+---+---+---+-----+-------------------------+
            | Bit | 0 | 1 | 2 | 3 | 4-7 | 8-15                    |
            +-----+---+---+---+---+-----+-------------------------+
            | 0   | Next Header         | Header Extension Length |
            +-----+---------------------+-------------------------+
            | 16  | MH Type             | Reserved                |
            +-----+---------------------+-------------------------+
            | 32  | Checksum                                      |
            +-----+---------------------+-------------------------+
            | 48  | Sequence #                                    |
            +-----+---+---+---+---+-------------------------------+
            | 64  | A | H | L | K | Reserved                      |
            +-----+---+---+---+---+-------------------------------+
            | 80  | Lifetime                                      |
            +-----+-----------------------------------------------+
            | 96  | Mobility Options                              |
            | ... |                                               |
            +-----+-----------------------------------------------+

RFCs 5568, 6275.

            +-----+---+---+---+---+-----+-------------------------+
            | Bit | 0 | 1 | 2 | 3 | 4-7 | 8-15                    |
            +-----+---+---+---+---+-----+-------------------------+
            | 0   | Next Header         | Header Extension Length |
            +-----+---------------------+-------------------------+
            | 16  | MH Type             | Reserved                |
            +-----+---------------------+-------------------------+
            | 32  | Checksum                                      |
            +-----+-----------------------------------------------+
            | 48  | Sequence #                                    |
            +-----+---+---+---+---+-------------------------------+
            | 64  | A | H | L | K | Reserved                      |
            +-----+---+---+---+---+-------------------------------+
            | 80  | Lifetime                                      |
            +-----+-----------------------------------------------+
            | 96  | Mobility Options                              |
            | ... |                                               |
            +-----+-----------------------------------------------+

The minimum number of bytes the message data takes.

Used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update.

Set by the sending mobile node to request a Binding Acknowledgement be returned upon receipt of the Binding Update. For Fast Binding Update this must be set to one to request that PAR send a Fast Binding Acknowledgement message.

Set by the sending mobile node to request that the receiving node should act as this node's home agent. The destination of the packet carrying this message must be that of a router sharing the same subnet prefix as the home address of the mobile node in the binding. For Fast Binding Update this must be set to one.

Set when the home address reported by the mobile node has the same interface identifier as the mobile node's link-local address.

If this is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) If manual IPsec configuration is used, the bit must be cleared. This bit is valid only in Binding Updates sent to the home agent, and mustbe cleared in other Binding Updates. Correspondent nodes must ignore this bit.

The number of time units remaining before the binding must be considered expired. A value of zero indicates that the Binding Cache entry for the mobile node must be deleted. One time unit is 4 seconds for Binding Update and 1 second for Fast Binding Update.

Creates an instance from next header, checksum, sequence number, acknowledge, home registration, link local address compatilibity, key management mobility capability, lifetime and options.

Identifies the particular mobility message in question. An unrecognized MH Type field causes an error indication to be sent.

RFCs 791, 2460. Represents an IP datagram.

            +-----+---------+
            | Bit | 0-3     |
            +-----+---------+
            | 0   | Version |
            +-----+---------+
            | 4   |         |
            | ... |         |
            +-----+---------+

Calculates the Transport checksum field value.

The calculated checksum value.

Indicates the format of the internet header (Internet Protocol version).

The total length - header and payload according to the IP header.

Returns whether the TCP or UDP checksum is correct. The protocol must be TCP or UDP. For UDP, the checksum is optional, so 0 checksum is still correct.

The payload of the datagram.

The payload of the datagram as an IPv4 datagram (IP over IP).

The payload of the datagram as an IPv6 datagram (IP over IP).

Returns the inner IP Datagram. This is either an IPv4 Datagram or an IPv6 Datagram (according to the Payload Protocol).

The payload of the datagram as an ICMP datagram.

The payload of the datagram as an IGMP datagram.

The payload of the datagram as a TCP datagram.

The payload of the datagram as a GRE datagram.

The payload of the datagram as a UDP datagram.

Returns the Tranposrt Datagram. This is either a TCP Datagram or a UDP Datagram (according to the payload protocol).

RFC 792.

RFC 792. Represents an ICMP Timestamp layer.

Writes the ICMP payload to the buffer. Doesn't include payload in the next layers.

The buffer to write the ICMP payload to. The offset in the buffer to start writing the payload at.

True iff the OriginateTimestamp, ReceiveTimestamp and the TransmitTimestamp fields are equal.

The time the sender last touched the message before sending it.

The time the echoer first touched it on receipt.

The time the echoer last touched the message on sending it.

The value of this field determines the format of the remaining data.

The number of bytes the ICMP payload takes.

The value of this field determines the format of the remaining data.

RFC 792. Represents an ICMP Redirect message layer.

A sub-type of the message. Specific method of this message type.

Address of the gateway to which traffic for the network specified in the internet destination network field of the original datagram's data should be sent.

The value of this field determines the format of the remaining data.

A sub-type of the message. Specific method of this message type.

A value that should be interpreted according to the specific message.

The different ICMP code values for Security Failures ICMP type.

RFC 2521. Indicates that a received datagram includes a Security Parameters Index (SPI) that is invalid or has expired.

RFC 2521. Indicates that a received datagram failed the authenticity or integrity check for a given SPI. Note that the SPI may indicate an outer Encapsulating Security Protocol when a separate Authentication Header SPI is hidden inside.

RFC 2521. Indicates that a received datagram failed a decompression check for a given SPI.

RFC 2521. Indicates that a received datagram failed a decryption check for a given SPI.

RFC 2521. Indicates that a received datagram will not be accepted without additional authentication. In this case, either no SPI is present, or an unsuitable SPI is present. For example, an encryption SPI without integrity arrives from a secure operating system with mutually suspicious users.

RFC 2521. Indicates that a received datagram will not be accepted because it has insufficient authorization. In this case, an authentication SPI is present that is inappropriate for the target transport or application. The principle party denoted by the SPI does not have proper authorization for the facilities used by the datagram. For example, the party is authorized for Telnet access, but not for FTP access.

Known HTTP request method. RFC 2616.

RFC 2616. The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. Responses to this method are not cacheable. If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body. If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource. A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0". The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

RFC 2616. The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process. The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client. The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client. The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching.

RFC 2616. The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

RFC 2616. The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources; Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; Providing a block of data, such as the result of submitting a form, to a data-handling process; Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header. Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. POST requests MUST obey the message transmission requirements.

RFC 2616. The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases. If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable. The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request. A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server. HTTP/1.1 does not define how a PUT method affects the state of an origin server. PUT requests MUST obey the message transmission requirements. Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

RFC 2616. The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

RFC 2616. The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity. TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop. If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.

RFC 2616. This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling).

Unknown request method.

Eastlake.

Undefined value.

The SNMP subset of ASN.1. Basic Encoding Rules.

The SNMP subset of ASN.1. Distinguished Encoding Rules.

The SNMP subset of ASN.1. Packed Encoding Rules Aligned.

The SNMP subset of ASN.1. Packed Encoding Rules Unaligned.

The SNMP subset of ASN.1. Canonical Encoding Rules.

The SNMP subset of ASN.1. An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding.

OSI ASN.1 1990 [ASN.1]. Basic Encoding Rules.

OSI ASN.1 1990 [ASN.1]. Distinguished Encoding Rules.

OSI ASN.1 1990 [ASN.1]. Packed Encoding Rules Aligned.

OSI ASN.1 1990 [ASN.1]. Packed Encoding Rules Unaligned.

OSI ASN.1 1990 [ASN.1]. Canonical Encoding Rules.

OSI ASN.1 1990 [ASN.1]. An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding.

OSI ASN.1 1994. Basic Encoding Rules.

OSI ASN.1 1994. Distinguished Encoding Rules.

OSI ASN.1 1994. Packed Encoding Rules Aligned.

OSI ASN.1 1994. Packed Encoding Rules Unaligned.

OSI ASN.1 1994. Canonical Encoding Rules.

OSI ASN.1 1994. An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding.

MIME structured data [RFC 2045, 2046]. The data portion is a MIME structured message. The "MIME-Version:" header line may be omitted unless the version is other than "1.0". Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. The data portion must start with an "x-" token denoting the private content-transfer-encoding immediately followed by one null (zero) octet followed by the remainder of the MIME object.

RFC 2845.

            +------+-------------+----------+-----------+
            | bit  | 0-15        | 16-31    | 32-47     |
            +------+-------------+----------+-----------+
            | 0    | Algorithm Name                     |
            | ...  |                                    |
            +------+------------------------------------+
            | X    | Time Signed                        |
            +------+-------------+----------+-----------+
            | X+48 | Fudge       | MAC Size | MAC       |
            +------+-------------+----------+           |
            | ...  |                                    |
            +------+-------------+----------+-----------+
            | Y    | Original ID | Error    | Other Len |
            +------+-------------+----------+-----------+
            | Y+48 | Other Data                         |
            | ...  |                                    |
            +------+------------------------------------+

Constructs an instance out of the algorithm time signed, fudge, message authentication code, original ID, error and other fields.

Name of the algorithm in domain name syntax. Seconds since 1-Jan-70 UTC. Seconds of error permitted in Time Signed. Defined by Algorithm Name. Original message ID. RCODE covering TSIG processing. Empty unless Error == BADTIME.

Two DnsResourceDataTransactionSignature are equal iff their algorithm time signed, fudge, message authentication code, original ID, error and other fields are equal.

A hash code of the combination of the algorithm time signed, fudge, message authentication code, original ID, error and other fields.

Name of the algorithm in domain name syntax.

Seconds since 1-Jan-70 UTC.

Seconds of error permitted in Time Signed.

Defined by Algorithm Name.

Original message ID.

RCODE covering TSIG processing.

Empty unless Error == BADTIME.

RFC 2671.

            0 Or more of:
            +-----+---------------+
            | bit | 0-15          |
            +-----+---------------+
            | 0   | OPTION-CODE   |
            +-----+---------------+
            | 16  | OPTION-LENGTH |
            +-----+---------------+
            | 32  | OPTION-DATA   |
            | ... |               |
            +-----+---------------+

Constructs an instance from options.

Two DnsResourceDataOptions are equal if the options are equal.

The hash code of the options.

The list of options.

RFCs 1035, 2136, 2671, 2845, 2930, 4635.

RFC 1035. No error condition

RFC 1035. Format error - The name server was unable to interpret the query.

RFC 1035. Server failure - The name server was unable to process this query due to a problem with the name server.

RFC 1035. Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.

RFC 1035. Not Implemented - The name server does not support the requested kind of query.

RFC 1035. Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data.

RFC 2136. YXDomain. Name Exists when it should not.

RFC 2136. YXRRSET - RR Set Exists when it should not.

RFC 2136. NXRRSET - RR Set that should exist does not (NX).

RFC 2136. Server Not Authoritative for zone.

RFC 2136. Name not contained in zone.

RFCs 2671, 2845. Bad OPT Version or TSIG Signature Failure.

RFC 2845. Key not recognized.

RFC 2845. Signature out of time window.

RFC 2930. Bad TKEY Mode.

RFC 2930. Duplicate key name.

RFC 2930. Algorithm not supported.

RFC 4635. BADTRUNC - Bad Truncation.

RFC 2535.

Indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs: The owner name is the user name as the name of a node under the entity name. For example, "j_random_user" on host.subdomain.example could have a public key associated through a KEY RR with name j_random_user.host.subdomain.example. It could be used in a security protocol where authentication of a user was desired. This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc.

Indicates that this is a zone key for the zone whose name is the KEY RR owner name. This is the public key used for the primary DNS security feature of data origin authentication. Zone KEY RRs occur only at delegation points.

Indicates that this is a key associated with the non-zone "entity" whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as a telephone number [RFC 1530] or numeric IP address. This is the public key used in connection with DNS request and transaction authentication services. It could also be used in an IP-security protocol where authentication at the host, rather than user, level was desired, such as routing, NTP, etc.

A gateway that is represented using a domain name.

Creates the gateway using the given domain name.

Two DnsGatewayDomainName are equal if their domain name values are equal.

Two gateway representations are equal if they are of the same type and the value is the same.

Returns the domain name value.

The gateway represnetation type.

The number of bytes the gateway represnetation takes.

The ATM address format values.

ATM End System Address (AESA) format.

E.164 format.

RFC 1035.

            +------+-------------------------------------------------+
            | byte | 0-1                                             |
            +------+-------------------------------------------------+
            | 0    | Name                                            |
            | ...  |                                                 |
            +------+-------------------------------------------------+
            |      | Type                                            |
            +------+-------------------------------------------------+
            |      | Class                                           |
            +------+-------------------------------------------------+

Creates a DNS query record from a domain name, type and class.

An owner name, i.e., the name of the node to which this resource record pertains. Two octets containing one of the RR TYPE codes. Two octets containing one of the RR CLASS codes.

Two query records are equal if they have the same domain name, type and class.

A hash code based on the query record's domain name, type and class.

There's no TTL in a query record.

There's no data in a query record.

A domain name represented as a series of labels, and terminated by a label with zero length.

The number of bytes a root ('.') domain name takes.

Creates a domain name out of a string.

Returns a string representation of the domain name.

Two domain names are equal if their labels are equal ignoring any casing.

Returns the hash code of the domain name.

The root ('.') domain name.

The number of labels the domain name has. For example, root ('.') has 0 labels.

Returns true iff the domain name is the root ('.') domain name.

The number of bytes the domain name takes assuming it won't be compressed.

Window Scale Option (RFC 1323) The three-byte Window Scale option may be sent in a SYN segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to do both send and receive window scaling, and (2) communicate a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations.

            +-----+-----------+
            | Bit | 0-7       |
            +-----+-----------+
            | 0   | Kind      |
            +-----+-----------+
            | 8   | Length    |
            +-----+-----------+
            | 16  | shift.cnt |
            +-----+-----------+

This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' may be zero (offering to scale, while applying a scale factor of 1 to the receive window). This option may be sent in an initial SYN segment (i.e., a segment with the SYN bit on and the ACK bit off). It may also be sent in a SYN,ACK segment, but only if a Window Scale option was received in the initial SYN segment. A Window Scale option in a segment without a SYN bit should be ignored. The Window field in a SYN (i.e., a SYN or SYN,ACK) segment itself is never scaled.

The number of bytes this option take.

The number of bytes this option value take.

Create a scale factor option using the given scale factor log.

The default scale factor log is 0 (scale factor is 1).

Tries to read the option from a buffer starting from the option value (after the type and length).

The log of the window scale factor.

The number of bytes this option will take.

True iff this option may appear at most once in a datagram.

Extension methods for byte[].

Compares all the bytes in the two ranges of the arrays. Returns the first non-zero compare value of the bytes in the ranges or zero if the ranges have the same byte values.

The first array to compare. The offset of the first byte to compare in the first array. The second array to compare. The offset of the first byte to compare in the second array. The number of bytes to compare. The first non-zero compare value of the bytes in the ranges or zero if the ranges have the same byte values.

Compares all the bytes in the two ranges of the arrays. Returns true iff the ranges have the same byte values.

Creates a DataSegment of the given byte array starting from a given offset in the segment taking a given number of bytes.

The array to build the data segment on. The offset in the array to start taking. The number of bytes to take from the array. A new DataSegment that is part of the given array.

Returns the first offset in the array where the other array's range sequence of bytes can be found or the length of the array if no match exists.

The array to search for the sequence of bytes. The offset of the first byte in the array that should be compared to the sequence to find. The number of bytes in the array that the sequence can be searched in. The array that contains the sequence of bytes to search. The offset in the array containing the sequence of the first byte of the sequence. The number of bytes of the sequence. The first offset in the array where the other array's range sequence of bytes can be found or the length of the array if no match exists.

Returns the first offset in the array where the other array sequence of bytes can be found or the length of the array if no match exists.

The array to search for the sequence of bytes. The offset of the first byte in the array that should be compared to the sequence to find. The number of bytes in the array that the sequence can be searched in. The array that contains the sequence of bytes to search. The first offset in the array where the other array sequence of bytes can be found or the length of the array if no match exists.

Copies a specified number of bytes from a source array starting at a particular offset to a destination array starting at a particular offset.

The source buffer. The byte offset into source. The destination buffer. The byte offset into destination. The number of bytes to copy.

Reads a byte from a specific offset.

The buffer to read the byte from. The offset in the buffer to start reading. The value read from the buffer.

Reads a byte from a specific offset and increments the offset by 1.

The buffer to read the byte from. The offset in the buffer to start reading and to increment. The value read from the buffer.

Reads bytes from a specific offset.

The buffer to read the bytes from. The offset in the buffer to start reading. The number of bytes to read. The value read from the buffer.

Reads bytes from a specific offset and increments the offset by the number of bytes read.

The buffer to read the bytes from. The offset in the buffer to start reading and to increment. The number of bytes to read. The value read from the buffer.

Reads 2 bytes from a specific offset as a short with a given endianity.

The buffer to read the bytes from. The offset in the buffer to start reading. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 2 bytes from a specific offset as a ushort with a given endianity.

Reads 2 bytes from a specific offset as a ushort with a given endianity and increments the offset by the number of bytes read.

Reads 3 bytes from a specific offset as a UInt24 with a given endianity.

Reads 3 bytes from a specific offset as a UInt24 with a given endianity and increments the offset by the number of bytes read.

Reads 4 bytes from a specific offset as an int with a given endianity.

Reads 4 bytes from a specific offset as a uint with a given endianity.

Reads 4 bytes from a specific offset as a uint with a given endianity and increments the offset by the number of bytes read.

Reads 6 bytes from a specific offset as a UInt48 with a given endianity.

Reads 6 bytes from a specific offset as a UInt48 with a given endianity and increments the offset by the number of bytes read.

Reads 8 bytes from a specific offset as a long with a given endianity.

Reads 8 bytes from a specific offset as a ulong with a given endianity.

Reads 16 bytes from a specific offset as a UInt128 with a given endianity.

Reads a given amount of bytes from a specific offset as an unsigned BigInteger with a given endianity.

The buffer to read the bytes from. The offset in the buffer to start reading. The number of bytes to read. The endianity to use to translate the bytes to the value. The value converted from the read bytes according to the endianity.

Reads 6 bytes from a specific offset as a MacAddress with a given endianity.

Reads 6 bytes from a specific offset as a MacAddress with a given endianity and increments the offset by the number of bytes read.

Reads 4 bytes from a specific offset as an IPv4 address with a given endianity.

Reads 4 bytes from a specific offset as an IPv4 address with a given endianity and increments the offset by the number of bytes read.

Reads 4 bytes from a specific offset as an IPv4 time of day with a given endianity.

Reads 4 bytes from a specific offset as an IPv4 time of day with a given endianity and increments the offset by the number of bytes read.

Reads 16 bytes from a specific offset as an IPv6 address with a given endianity.

Writes the given value to the buffer.

The buffer to write the value to. The offset in the buffer to start writing. The value to write.

Writes the given value to the buffer and increments the offset by the number of bytes written.

The buffer to write the value to. The offset in the buffer to start writing. The value to write.

Writes the given value to the buffer and increments the offset by the number of bytes written.

The buffer to write the value to. The offset in the buffer to start writing. The value to write.

Writes the given value to the buffer using the given endianity.

The buffer to write the value to. The offset in the buffer to start writing. The value to write. The endianity to use when converting the value to bytes.

Writes the given value to the buffer using the given endianity.

The buffer to write the value to. The offset in the buffer to start writing. The value to write. The endianity to use when converting the value to bytes.

Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written.