This page shows the Layer 3 (network layer) encapsulation headers included in the E地et 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地et frame header/FCS, similar to the layers of an onion.

 

The Layer 3 header that is encapsulated by the E地et frame header is identified by the E地et frame type. This is the two bytes immediately following the SMAC address in the E地et header. For TCP/IP the E地et frame type (or E稚ype) 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稚ype 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稚ype was 0x806 the following schematic demonstrates the detailed format expected in the data field of an E地et frame carrying an ARP packet:

 

Hardware Type (16 bits / 2 bytes): 0x1 E地et

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地et it is accessed by specifying E稚ype = 0x800. When this value appears in the E稚ype, 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地et

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地et 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痴 port 25 using port 110 in a TCP header which is signified by a protocol number of 0x06 in the IP header. The client痴 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地et/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地et/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.