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/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.
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 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 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 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.