Random Daodejing

TCP/IP Notes

Intro  /  Network Addressing  /  Network Addressing IPv6  /  Packet Headers  /  Networking and Data Link Layers  /  Transport Layer Protocols  /  Application Layer Protocols  /  IP Routing  /  ICMP  /  DHCP  /  Name Resolution and DNS  /  Security


IP packet headers differ in structure between IPv4 and IPv6:

IPv4 versus IPv6 packet header structure

IPV4 packet header structure:

IPV4 packet header structure

A packet header can be between 20 and 60 bytes in length, and packet size can be as much as 65,535 bytes but most packet sizes are 576 bytes due to network limitations.

There are 14 possible fields (multiples of 4 bytes), 13 of which are required.  Byte order is 'big endian' (most significant precedes least significant) and uses MSB 0 bit numbering.

IPv4 header fields

Version Field (4 bit) - IP protocol version number.

Header Length Field (variable, multiples of 32 bits) - Defines header length, typically 20 bytes.

Type of Service Field - *More recently known as Differentiated Services Code Point (DSCP) (6 bit)  and Differentiated Service Field (8 bit), see RFC 2474 (https://tools.ietf.org/html/rfc2474), RFC 3168 (https://tools.ietf.org/html/rfc3168), and RFC 3260 (https://tools.ietf.org/html/rfc3260).

Broken into Precedence (first 3 bits used by routers) and Type of Service (follows path type).  A buffering system called a router queue holds packets when congestion occurs.  TOS default is 00000000, split between two functional groups:  differentiating services (traffic prioritization) and congestion notification.  Typically routers make independent decisions on how to direct traffic, but a revision RFC exists (http://tools.ietf.org/html/rfc3248) to address DoS (Denial of Service) attacks.  Other examples of services include expedited forwarding, real-time applications and Voice over IP (VoIP).

Explicit Congestion Notification (ECN) (2 bit) - Mitigates dropped packets by sending a message to the receiver to decrease traffic throughput.

Total Length Field (16 bit) - Defines header length. 

Identification Field (16 bit) - Can identify fragmented packets based on MTU discrepancies.

Flags Field (3 bit)

Bit 0 - Reserved (0)
Bit 1 - Fragment (0), Don't fragment (1)
Bit 2 - More fragments bit:  Last (0), (1) More to come

Fragment Offset Field (13 bit) - Shows where to place fragments together. Measured in 8 byte blocks. 

Time to Live Field (8 bit) - Remaining distance of a packet defined by number of hops.

Protocol Field (8 bit) - Assigned Internet protocol number:  https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml.

Header Checksum Field (16 bit) - Error detection of IP header.

Source Address Field (32 bit) - IP address of source.

Destination Address Field (32 bit) - IP address of destination.

Options Field (variable, 40 bits max) - Table available at:   https://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconfig-security/uses-for-ip-packet-header-options.html

Padding - Makes sure header ends at 32 bit limit and makes sure header length is always multiple of 32 bits.

IPv6 packet header

IPv6 packets offer improvements over IPv4, including more options and more efficient packet forwarding.  The header is fixed at the first 40 octets (320 bits) of a packet.
IPv6 header fields

Version (4 bit) - IP protocol version number.

Traffic Class (8 bit) - Used by source host and forwarding routers.

Bit 0 - Delay Sensitive (1).

Bits  2-4 - Precedence.

Bits 5-8 - Currently reserved.

Flow Label Field - 20-bit, special handling for sets of packets, still experimental.

Payload Length Field - 16-bit, size of payload in octets. 

Next Header Field - 8-bit, specifies header type, uses same values as IPv4 and extension headers (inserted before IP headers and higher-layer protocol headers).

Hop Limit Field - 8-bit, maximum 255 hops.

Source Address Field - 128-bit address of packet source.  There are current address text representations (http://tools.ietf.org/html/rfc5952) and translators being proposed (http://tools.ietf.org/html/rfc6052). 

Destination Address Field - 128-bit destination address.

IPv6 extension headers are defined by Next Header values which create a nested chained structure until the upper-layer protocol is reached.  An order is recommended (https://tools.ietf.org/html/rfc2460):

1)  Hop-by-Hop Options -  Composed of next header field and extended header field, carries information affecting routers in transit. 

2)  Destination Options - Extends header for packet handling options, can be used for encryption and makes room for future standards.  May appear in more than one location (immediately before routing extension header and/or last header before upper-layer protocol).

3)  Routing - Defined by extension header length, contains routing information.

4)  Fragment - Used if sent packets exceed MTU.  Contains flag field with More Fragments.  Divided between unfragmentable (length is changed from the size of the original packet to length of fragment packet - length of IPv6 header) and fragmentable (split into two parts).

5)  Authentication - Identifies origin of packet and prevents spoofing.

6)  Encapsulating Security Payload (ESP) - Used to encrypt data, must always be in the last header of the IP header chain.

        -Both Authentication & ESP are part of IPSec (IP security), which is a suite of add-in security protocols.
        -In IPv4, Authentication protects payload and header fields.
        -In IPv6, Authentication protects the authentication extension header itself, destination options, IP payload, and fixed IPv6 header.
Jumbogram packets (https://tools.ietf.org/html/rfc2675) use alternate 32 byte Packet Length fields with the Hop-by-Hop options extension.  This allows larger than 64 kilobytes of data to be carried per packet.  From an internet backbone perspective, this means smaller chunks of larger data rather than larger small chunks which should increase operational efficiency.  This option is used when the values of the Payload Length Field and the Next Header Field  are both set to 0, which then processes Hop-by-Hop options.  Upper-layer protocols must also use this field in order to calculate the values.

Quality of Service (QoS) is a rating of network traffic based on differentiated services, since network needs differ (faster delivery, temporary use of large bandwidth, etc.).  Originally, Resource Reservation Protocol (RSVP) was designed to address this.  Currently two approaches are put forth:

        1)  Per-Hop Behaviors (PHBs)- Depends on routers supporting required level of service.
        2)  Per-Domain Behaviors (PDBs) - Available across all hops within a given domain.
QoS is part of IPv4, and plans for IPv6 include future updates.  Rather than having separate header fields as in IPv4, IPv6 utilizes Hop-by-Hop options, the Routing extension header and the Destination options header to implement current and future QoS.  RFC 2711 (https://tools.ietf.org/html/rfc2711) defines a router alert setting in the Hop-by-Hop options.

IPv6 MTU and packet handling

Path MTU Discovery

In IPv6, RFC 1981 (https://tools.ietf.org/html/rfc1981) defines the Path MTU (PMTU) Discovery, a method for learning which network paths have a greater than minimum link MTU value (maximum size of a packet in octets which can be transmitted as a single unit).  When a receiving node is given a packet too large to transfer, it discards the packet and sends a ICMPv6 Packet Too Big message back to the source, prompting an MTU resize and resend operation. 

Minimum size - 1,280 bytes

PMTU Discovery works dynamically via weakest-link path MTU, and also determining if PMTU has increased/can accommodate larger size.   PMTU Discovery supports both unicast and multicast.

Upper-layer checksums

An upper-layer protocol which contains header addresses in the checksum must have the 128-bit IPv6 address.  When data is sent UDP, a pseudo header is used.  In this case the source host calculates the checksum and if the value is 0, then changes it to hexidecimal FFFF.

When calculating payload size, the upper-layer protocol calculates the difference in header size and maximum lifetime between IPv6 header and IPv4 (IPv6 is not required to enforce maximum lifetime).

IPv4 vs IPv6 packet headers

- Although IPv6 is larger in size (mainly to accommodate larger address space), it has a simpler structure than IPv4. 
- No required checksum calculation in IPv6. 
- In general IPv6 header Hop Limit field replaces IPv4 header TTL field (obsoleting second to hop calculation).
- Length of IPv4 header can be variable, IPv6 remains constant at 40 bytes (indicated in Data field).
- Unlike IPv4, routers do not fragment IPv6 packets (only source and destination; due to PMTU Discovery packets are fragmented before transmission).

Transition to IPv6

Generally, IPv4 and IPv6 packets are incompatible due mainly to hardware and software which was originally designed for IPv4.  Tunnel-less options (https://tools.ietf.org/html/rfc3056) using clouds have been proposed to allow IPv6 sites to operate on IPv4 networks (6to4).  This uses a form of encapsulation and decapsulation of packets.  Unfortunately, it appears this method despite attempted best practices is slow to adoption due to relay problems (tech support will often advise customers to simply turn off native IPv6).

Transport Relay Translator (https://www.ietf.org/rfc/rfc3142.txt) doesn't require specific configuration of network nodes, but can only be used for bi-directional traffic.     

Further Reading


Understanding Big and Little Endian Byte Order

Linux IPv6 HOWTO

Implementing Cisco IPv6 Networks

Oracle IPv6 Administration Guide


Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec

Differentiated services

IPv6 Headers