This page shows the Layer 3 (network layer) encapsulation headers included in the E’net frame (ARP and IP), and the various common Layer 4 (transport layer) headers that are encapsulated in the IP packet (ICMP, TCP, and UDP).   These headers are will all be encapsulated within the E’net frame header/FCS, similar to the layers of an onion.

 

The Layer 3 header that is encapsulated by the E’net frame header is identified by the E’net frame type.  This is the two bytes immediately following the SMAC address in the E’net header.  For TCP/IP the E’net frame type (or E’type) will usually be 0x806 for ARP (Address Resolution Protocol) or 0x800 for IP (Internet Protocol).

 

The Layer 3 header identifies the type of transport (Layer 4) the data encapsulated by the IP header will use.  The IP header uses the protocol number field to identify which Layer 4 header it encapsulates.  The most common protocol numbers are:

 

                                    1   (0x01) for ICMP/Internet Control Message Protocol

2   (0x02) for IGMP/Internet Group Management Protocol

3   (0x06) for TCP/Transmission Control Protocol (Connection-oriented communications)

17 (0x11) for UDP/User Datagram Protocol (Connectionless communications)

 

The Layer 4 headers for TCP and UDP typically encapsulate data for higher-level applications.  These higher-level applications are typically identified by port numbers in the Layer 4 header.  These port numbers identify memory addresses in the local computer that are configured to accept data I/O from TCP/IP.  Many standard applications such as Domain Name Service (DNS), telnet, sendmail/Simple Mail Transfer Protocol (SMTP), and Hypertext Transfer Protocol (HTTP) use standard ports that are recognized by IANA and the ITU.  Other applications must dynamically assign private port numbers to the buffers they are using.  This port/buffer management is managed by the local computers memory management facilities and the remote procedure call manager or end-mapper.  A list of common TCP/IP ports is listed below.  The combination of an IP address and a port number is commonly called a socket.  A similar facility is also used by IPX/SPX and is also called a socket.

 

ARP (Address Resolution Protocol)

 

ARP/Reverse ARP are a separate protocol from TCP/IP (E’type 0x806), but they are part of the TCP/IP suite

 

The following is a simplified schematic of the ARP header.  Each row represents 32 bits or 4 bytes.

 

General Header information

Source MAC (48 bits/6 bytes)

Source IP (32 bits/4 bytes)

Destination MAC (48 bits/6 bytes)

Destination IP (32 bits/4 bytes)

 

 

The ARP packet header is the first field in the data area of the frame.  Because the preceding E’type was 0x806 the following schematic demonstrates the detailed format expected in the data field of an E’net frame carrying an ARP packet:

 

Hardware Type (16 bits / 2 bytes): 0x1 – E’net

Protocol Type (16 bits / 2 bytes): 0x800, again

Hardware Addr. Length (8 bits / 1 byte): = 0x6

Protocol Addr. Length (8 bits / 1 byte): = 0x4

Operation (16 bits / 2 bytes):    0x1. ARP Request

                                       0x2. ARP Reply

Source Hardware Address (32 bits / 4 bytes): Bytes 0 – 3

Source Hardware Address (2 bytes): Bytes 4 - 5

Source IP Address (16 bits / 2 bytes): Bytes 0 - 1

Source IP Address (16 bits / 2 bytes): Bytes 2 - 3

Target Hardware Address (2 bytes): Bytes 0 - 1

Target Hardware Address (32 bits / 4 bytes): Bytes 2 - 5

Target IP Address (32 bits / 4 bytes)

 

In an ARP request the unknown Target Hardware Address field is set 00-00-00-00-00-00.

 

IP

 

TCP/IP is the core protocol suite of the internet.  In E’net it is accessed by specifying E’type = 0x800.  When this value appears in the E’type, the following IP header is expected to be the first part of the data payload of the frame.

 

The following is a simplified schematic for the common 20-byte IP header.  Each row represents 32 bits or 4 bytes.

 

General Information

General Information

General Information

Protocol (8 bits / 1byte)

General Information

Source IP Address (32 bits / 4 bytes)

Destination IP Address (32 bits / 4 bytes)

 

The following is a detailed schematic of the IP header, showing exact sizes and names of various fields:

 

Ver (4 bits): = 0x04

HLEN (4 bits): = 0x05

Precedence / Type of Service

 

Length of Datagram: In bytes, includes IP header and payload data, 1500 max. for E’net

Identification (16 bits / 2 bytes): fragment source identification

Flags (3 bits):

Fragment Offset (13 bits):

Time To Live (TTL, 8 bits / 1 byte): Hops

Protocol (8 bits / 1byte)

Header Checksum (16 bits / 2 bytes)

Source IP Address (32 bits / 4 bytes)

Destination IP Address (32 bits / 4 bytes)

Options (optional): Up to 40 bytes, not used a lot

Data

 

Common values for the Protocol field:

0x01 (1):  ICMP

0x02 (2): IGMP

0x06 (6): TCP

0x09 (9): Cisco IGRP

0x11 (17): UDP

0x29 (47): GRE

0x32 (50): IPSec ESP

0x33 (51): IPSec AH

0x58 (88): Cisco EIGRP

0x59 (89): OSPF

 

The protocol field is very important for identifying native IP protocols, which run with their own subheaders that will appear in the data field.  Note that in the absence of options, which are not commonly used, the IP header will be 20 bytes long.

 

IP-Accessed Protocols:

 

ICMP

ICMP is considered a network layer protocol but it is accessed via TCP/IP with the protocol field set to 0x01.

ICMP rides directly on IP, i.e., it is specified as a separate protocol in the IP header (0x01)

ICMP is used to generate traffic control and error messages

The following schematic represents the ICMP header

 

Type (8 bits / 1 byte):

Code (8 bits / 1 byte):

Checksum (16 bits / 2 bytes):

Variable fields, depends on the ICMP type

 

 

UDP

UDP is the connectionless packet mechanism for forwarding data with little overhead

UDP rides directly on the IP layer (Protocol 0x11)

The header is compact allowing more of a short message to be encoded in the 64-byte minimum E’net frame

The following schematic represents the UDP header

 

Source Port (16 bits / 2 bytes):

Destination Port (16 bits / 2 bytes):

UDP Length (includes UDP header and data) (1 byte)

Checksum (16 bits / 2 bytes):

 

TCP

TCP is the connection-oriented workhorse protocol of TCP/IP

TCP rides directly on the IP layer (Protocol 0x06)

Larger, more complex header to accommodate routines to ensure the connection

The following diagram shows the organization of the TCP header:

 

Source Port (16 bits / 2 bytes):

Destination Port (16 bits / 2 bytes_:

Sequence Number (32 bits / 4 bytes):

Acknowledgement Number (32 bits / 4 bytes):

HLEN

(4 bits):

Reserved (6 bits):

Flags (6 bits):

Window Size (16 bits / 2 bytes):

Checksum (16 bits / 2 bytes):

Urgent Pointer (16 bits / 2 byte):

Options and padding (variable):

 

Note:  HLEN measures the header size in 4-byte words.  The header must be a multiple of 4 bytes in size.  The most common TCP header is 20 bytes long.

 

TCP sets up a session in what is commonly called the three-way handshake which establishes:

·         Receive buffer sizes

·         Maximum segment size (optional)

·         Initial sequence number

 

The three-way handshake consists of  three messages: SYN, SYN, and Ack.

 

The set of seven stages represents the full set of states the system goes through to set up a TCP session:

1.        Server sets up for business (passive open)

2.        The client asks TCP to open a connection to the server (active open)

3.        The client picks an initial sequence number and send a synchronize segment (SYN) to the server, which specifies its starting sequence number, receive window buffer size, and the maximum transmission unit (MTU)

4.        Server receives the client SYN.  It selects its own initial sequence number, buffer size, and MTU (optional) and sends its own SYN to the client (an implicit ACK to the client request).  This SYN also states the anticipated sequence number of the first byte of data to be received from the client (the announced sequence number + 1).

5.        The client sends an acknowledgement (ACK) to the server.  The ACK announces the sequence number it expects for the first byte of data (again, the announced sequence number +1)

6.        The client TCP stack informs the application the connection is open.

7.        Server receives the ACK and the TCP stack informs its application that the connection is open.

 

All packets but the initial SYN packet (Step 3.) have a flag bit in the TCP header set to 1.  The RST flag is used to indicate an error or to abort a session.  Either of these flag conditions is what is commonly called ESTABLISHED.  The ESTABLISHED condition is used commonly to control access to a network through a router.

 

Ports:

 

The following are some common ports that are used extensively by TCP/IP at the UDP/TCP header level.  They were extracted from the Microsoft Windows 2000 file \WINNT\SYSTEM32\DRIVERS\ETC\SERVICES.  These ports are typically used as the destination port by the client.  For instance, a client will send a POP3 request to the mail server’s port 25 using port 110 in a TCP header which is signified by a protocol number of 0x06 in the IP header.  The client’s own source port, as used by either UDP or TCP, is typically set by the local RPC end-mapper service.  It can be nearly any port in the range from 1025 to 65535.  In windows machines certain applications can be statically assigned to a fixed port via the registry.  This will often be done to simplify server-to-server communications through a firewall.

 

ftp-data           20/tcp                           #FTP, data

ftp                21/tcp                           #FTP. control

telnet             23/tcp

smtp               25/tcp    mail                   #Simple Mail Transfer Protocol

domain             53/tcp                           #Domain Name Server

domain             53/udp                           #Domain Name Server

bootps             67/udp    dhcps                  #Bootstrap Protocol Server

bootpc             68/udp    dhcpc                  #Bootstrap Protocol Client

tftp               69/udp                           #Trivial File Transfer

gopher             70/tcp

http               80/tcp    www www-http           #World Wide Web

kerberos           88/tcp    krb5 kerberos-sec      #Kerberos

kerberos           88/udp    krb5 kerberos-sec      #Kerberos

pop3              110/tcp                           #Post Office Protocol - Version 3

sunrpc            111/tcp    rpcbind portmap        #SUN Remote Procedure Call

sunrpc            111/udp    rpcbind portmap        #SUN Remote Procedure Call

nntp              119/tcp    usenet                 #Network News Transfer Protocol

ntp               123/udp                           #Network Time Protocol

netbios-ns        137/tcp    nbname                 #NETBIOS Name Service

netbios-ns        137/udp    nbname                 #NETBIOS Name Service

netbios-dgm       138/udp    nbdatagram             #NETBIOS Datagram Service

netbios-ssn       139/tcp    nbsession              #NETBIOS Session Service

imap              143/tcp    imap4                  #Internet Message Access Protocol

snmp              161/udp                           #SNMP

snmptrap          162/udp    snmp-trap              #SNMP trap

bgp               179/tcp                           #Border Gateway Protocol

irc               194/tcp                           #Internet Relay Chat Protocol       

ldap              389/tcp                           #Lightweight Directory Access Protocol

isakmp            500/udp    ike                    #Internet Key Exchange

syslog            514/udp

doom              666/tcp                           #Doom Id Software

doom              666/udp                           #Doom Id Software

 

 

Example Frames: 

A standard representation of a packet is in the 32-bit (4-byte) double-word format used above:  Below are a couple of demonstration frames for different types of traffic.

 

A TCP/IP DNS query using UDP transport (heavy black lines separate E’net/IP and IP/UDP headers):

 

DMAC (bytes 0 – 3)

DMAC (bytes 4 – 5)

SMAC (bytes 0 – 1)

SMAC (bytes 2 – 5)

Ethertype = 0x800 (TCP/IP)

Ver. = 4

HLEN = 0x05

Precedence/Type of Service

Length of Datagram (Packet) including this header

(Fragment) Identification

Flags: 3-bits

Fragment Offset: 13 bits

Time to Live (TTL) = 31

Protocol = 17 (0x11)  for UDP

Header Checksum

Source IP: First two bytes

Source IP: Second two bytes

Destination IP: First two bytes

Destination IP: Second two bytes

Source Port: Usually dynamic

Destination Port: Usually dynamic; set to 53 (0x35) for DNS

Length of Datagram (Segment), including this header

Header Checksum

 

 

Data

 

FCS

 

 

The following schematic represents a frame containing a TCP segment, also for DNS.  This time it will be for a DNS zone transfer (heavy black lines separate E’net/IP and IP/TCP headers):

 

DMAC (bytes 0 – 3)

DMAC (bytes 4 – 5)

SMAC (bytes 0 – 1)

SMAC (bytes 2 – 5)

Ethertype = 0x800 (TCP/IP)

Ver. = 4

HLEN = 0x05

Precedence/Type of Service

Length of Datagram (Packet) including this header

(Fragment) Identification

Flags: 3-bits

Fragment Offset: 13 bits

Time to Live (TTL) = 31

Protocol = 0x06 (TCP/IP)

Header Checksum

Source IP: First two bytes

Source IP: Second two bytes

Destination IP: First two bytes

Destination IP: Second two bytes

Source Port: Usually dynamic; set to 53 (0x35) for DNS zone transfer

Destination Port: Usually dynamic

Sequence Number: First two bytes

Sequence Number: Second two bytes

Acknowledgement Number: First two bytes

Acknowledgement Number: Second two bytes

HLEN = 0x05

Reserved

Flags

Window Size

Urgent Pointer

Header Checksum

 

 

Data

 

FCS

 

 

Notice that the source port is the 53 (0x35) for the destination port in both cases – the frame is destined for a DNS server.  The first frame, a query, is sent by a client and uses a random source port.  However, the second frame is sent by a DNS server so it uses a source port of 53 also.

 

Reserved Addresses:

 

Three address spaces have been reserved for private network numbering

10.0.0.0/255.0.0.0 (10.0.0.0/8)

172.16.0.0 through 172.31.0.0/255.255.0.0 (10.16.0.0/12)

192.168.0.0 through 192.168.255.0/255.255.255.0 (192.168.0.0/16)

This is done through RFC 1918.  This allows network administrators to have access to a large pool of addresses without requiring leased addresses from an ISP.

 

Additionally, Microsoft has registered 169.254.0.0/255.255.0.0 (169.254.0.0/16) with IANA/ICANN.  These addresses have been reserved for DHCP clients that cannot reach a DHCP server to generate a random private address (called Automatic Private IP Addressing or APIPA) in order to bring up the TCP/IP stack.  These clients are supposed to reconfigure themselves within 5 minutes of when a DHCP server first becomes available on the network segment.  However, personal experience has shown that this does not occur.  In fact releasing and renewing the ipconfiguration doe not reconfigure the client via DHCP.  The client must either be restarted in the case of DOS clients like Win98 or WinME, or the interface must be disabled and re-enabled in the case of Win2k/XP.  This can be a source of security problems for clients on cable.

 

http://www.win2000mag.com/Articles/Index.cfm?ArticleID=7464

 

http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q220874&

 

None of the addresses in these ranges may be advertised into the Internet.