Packet Formats to Remember

0x0800 Internet Protocol version 4 (IPv4)

0x0806 Address Resolution Protocol (ARP)
0x888E EAP over LAN (IEEE 802.1X)

0x8100 VLAN-tagged frame (IEEE 802.1Q)

0x8035 Reverse Address Resolution Protocol

TCP Header Format

Source port (16 bits) : identifies the sending port.

Destination port (16 bits): identifies the receiving port.
Sequence number (32 bits):Has a dual role:
If the SYN flag is set (1), then this is the initial sequence number. The sequence number of
the actual first data byte and the acknowledged number in the corresponding ACK are then
this sequence number plus 1.
If the SYN flag is clear (0), then this is the accumulated sequence number of the first data
byte of this segment for the current session.
Acknowledgement number (32 bits)
if the ACK flag is set then the value of this field is the next sequence number that the receiver
is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each
end acknowledges the other end's initial sequence number itself, but no data.
Data offset (4 bits)
specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and
the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60
bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the
fact that it is also the offset from the start of the TCP segment to the actual data.
Reserved (3 bits):for future use and should be set to zero
Flags (9 bits) (aka Control bits)
contains 9 1-bit flags
NS (1 bit) – ECN-nonce concealment protection (added to header by RFC 3540).
CWR (1 bit) – Congestion Window Reduced (CWR) flag is set by the sending host to indicate
that it received a TCP segment with the ECE flag set and had responded in congestion
control mechanism (added to header by RFC 3168).
ECE (1 bit) – ECN-Echo has a dual role, depending on the value of the SYN flag. It indicates:
If the SYN flag is set (1), that the TCP peer is ECN capable.
If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is
received during normal transmission (added to header by RFC 3168).
URG (1 bit) – indicates that the Urgent pointer field is significant
ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the
initial SYN packet sent by the client should have this flag set.
PSH (1 bit) – Push function. Asks to push the buffered data to the receiving application.
RST (1 bit) – Reset the connection
SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent from each end
should have this flag set. Some other flags and fields change meaning based on this flag, and
some are only valid for when it is set, and others when it is clear.
FIN (1 bit) – No more data from sender
Window size (16 bits)
the size of the receive window, which specifies the number of window size units (by default,
bytes) (beyond the sequence number in the acknowledgment field) that the sender of this
segment is currently willing to receive (see Flow control and Window Scaling)
Checksum (16 bits)
The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer (16 bits)
if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating
the last urgent data byte

Options (Variable 0–320 bits, divisible by 32)

UDP

Source Port Number: The first 16 bits of the UDP header contain the port number of the application sending
the data.
Destination Port Number: The next 16 bits contain the port number of the application that receives this
data.
Length: The next 16 bits identify how long the datagram is in bits.
Checksum: The last 16 bits of the UDP header are reserved for the checksum value. Checksum is used as
an error-detection mechanism. The source machine runs a mathematical algorithm on the datagram. The
destination, or recipient, machine runs the same mathematical algorithm on the datagram. If the both values
match we can assume that the datagram wasn't damaged while its journey.
The checksum field includes a 12-byte 'pseudo header' that includes the source and destination IP addresses,
the 8-bit reserved field containing 0, the 8-bit protocol ID and the 16-bit UDP length field. The pseudo header
is useful to check that the IP datagram arrived at the correct station.
Important protocols which use UDP: TFTP, DNS, SNMP, LDAP.

ARP:

Hardware Type [2 bytes]: It specifies the type of hardware used for the local network transmitting the
ARP message. Ethernet is the common Hardware Type and he value is 1. The size of this field is 2 bytes.
Protocol Type [2 bytes]: Each protocol is assigned a number used in this field, IPv4 is 2048 (0x0800
in Hexa).
Hardware Address Length: Hardware Address Length in the ARP Message is length in bytes of a
hardware (MAC) address. Ethernet MAC addresses are 6 bytes long.
Protocol Address Length: Length in bytes of a logical address (IPv4 Address). IPv4 addresses are
4 bytes long.
Opcode [Operation] [2 bytes]: Opcode field in the Address Resolution Protocol (ARP) Message
specifies the nature of the ARP message. 1 for ARP request and 2 for ARP reply.
Sender Hardware Address [4 bytes]: Layer 2 [MAC] address of the device sending the message.
Sender IP Address [4bytes]: The protocol address (IPv4 address) of the device sending the message
Target Hardware Address [6 bytes]: Layer 2 [MAC] address of the intended receiver. This field is
ignored in requests.
Target IP Address [4 bytes]: The protocol address (IPv4 Address) of the intended receiver.
 Version: - The first header field in an IP packet is the four-bit version field. Version identifies
the IP version to which the packet belongs. This four-bit field is set to binary 0100 to indicate
version 4 (IPv4) or binary 0110 to indicate version 6 (IPv6).

 Header length or Internet Header Length (IHL) :- The second field (4 bits) is the
Internet Header Length (IHL) telling the number of 32-bit words in the header. Since an
IPv4 header may contain a variable number of options, this field specifies the size of the
header (this also coincides with the offset to the data). The minimum value for this field is 5 ,
which is a length of 5×32 = 160 bits = 20 bytes. Being a 4-bit value, the maximum length is
15 words (15×32 bits) or 480 bits = 60 bytes.

 Type of Service (ToS):– now known as Differentiated Services Code Point

(DSCP). The TOS field is used to carry information to provide quality of service features.
New technologies are emerging that require real-time data streaming and therefore make use
 of the DSCP field. An example is Voice over IP (VoIP) that is used for interactive data voice
exchange.

 Total Length:- This 16-bit field defines the entire datagram size, including header and data,
in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the
maximum is 65,535 bytes — the maximum value of a 16-bit word. The minimum size
datagram that any host is required to be able to handle is 576 bytes, but most modern hosts
handle much larger packets. Sometimes subnetworks impose further restrictions on the size,
in which case datagrams must be fragmented. Fragmentation is handled in either the host or
packet switch in IPv4.
 Identification: – This field is an identification field and is primarily used for uniquely
identifying fragments of an original IP datagram. Some experimental work has suggested
using the ID field for other purposes, such as for adding packet-tracing information to
datagrams in order to help trace back datagrams with spoofed source addresses.
 Flags:–A three-bit field follows and is used to control or identify fragments. They are (in
order, from high order to low order):
 Bit 0: Reserved; must be zero.
 bit 1: Don’t Fragment (DF)
 bit 2: More Fragments (MF)
 Don’t Fragment: - Sets the Don’t Fragment bit in sent packets. When an IP datagram has its
DF flag set, intermediate devices are not allowed to fragment it so if it needs to travel across
a network with a MTU (Maximum Transmission Unit) smaller that datagram length the
datagram will have to be dropped. Normally an ICMP Destination Unreachable message is
generated and sent back to the sender.
 More Fragments: - Sets the More Fragments bit in sent packets. The MF flag is set to
indicate the receiver that the current datagram is a fragment of some larger datagram. When
set to zero it indicates that the current datagram is either the last fragment in the set or that
it is the only fragment.
 Fragment Offset:-The fragment offset field, measured in units of eight-byte blocks, is 13 bits
long and specifies the offset of a particular fragment relative to the beginning of the original
unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum
offset of (213 – 1) × 8 = 65,528 bytes which would exceed the maximum IP packet length of
65,535 bytes with the header length included (65,528 + 20 = 65,548 bytes).
 Time To Live (TTL):-It is of 8 bit field. This field indicates the maximum time the datagram
is allowed to remain in the internet system. If this field contains the value zero, then the
datagram must be destroyed. This field is modified in internet header processing. The time is
measured in units of seconds, but since every module that processes a datagram must
decrease the TTL by at least one even if it process the datagram in less than a second, the
TTL must be thought of only as an upper bound on the time a datagram may exist. The
intention is to cause undeliverable datagrams to be discarded, and to bound the maximum
datagram lifetime. <hops> must be a number in the range [0–255].
 Protocol:-This field defines the protocol used in the data portion of the IP datagram.
The Internet Assigned Numbers Authority maintains a list of IP protocol numbers.
 Header Checksum:- The 16-bit checksum field is used for error-checking of the header. At
each hop, the checksum of the header must be compared to the value of this field. If a header
checksum is found to be mismatched, then the packet is discarded. Errors in the data field
must be handled by the encapsulated protocol and both UDP and TCP have checksum fields.
As the TTL field is decremented on each hop, a new checksum must be computed each
time. The checksum field is the 16-bit one’s complement of the one’s complement sum of all
16-bit words in the header. For purposes of computing the checksum, the value of the
checksum field is zero.
 Source address :- Sets the source IP address. This option lets you specify a custom IP
address to be used as source IP address in sent packets. This allows spoofing the sender of
the packets. <addr> can be an IPv4 address or a hostname.
 Destination address :- An IPv4 address indicating the receiver of the packet. As with the
Source address, this may be changed in transit by a network address translation device.
Options:-Additional header fields may follow the destination address field, but these are not
often used. The value in the IHL field must include enough extra 32-bit words to hold all the
options (plus any padding needed to ensure that the header contains an integral number of
32-bit words). The list of options may be terminated with an EOL (End of Options List) option;
this is only necessary if the end of the options would not otherwise coincide with the end of
the header.

IPv6 Datagram Packet Header and Fields:

• Version: The size of the Version field is 4 bits. The Version field shows the version of IP
and is set to 6.
• Traffic Class: The size of Traffic Class field is 8 bits. Traffic Class field is similar to the IPv4
Type of Service (ToS) field. The Traffic Class field indicates the IPv6 packet’s class or priority.
• Flow Label: The size of Flow Label field is 20 bits. The Flow Label field provide additional
support for real-time datagram delivery and quality of service features. The purpose of Flow
Label field is to indicate that this packet belongs to a specific sequence of packets between a
source and destination and can be used to prioritized delivery of packets for services like voice.
• Payload Length: The size of the Payload Length field is 16 bits. The Payload Length field
shows the length of the IPv6 payload, including the extension headers and the upper layer
protocol data
• Next Header: The size of the Next Header field is 8 bits. The Next Header field shows either
the type of the first extension (if any extension header is available) or the protocol in the upper
layer such as TCP, UDP, or ICMPv6.
• Hop Limit: The size of the Hop Limit field is 8 bits The Hop Limit field shows the maximum
number of routers the IPv6 packet can travel. This Hop Limit field is similar to IPv4 Time to
Live (TTL) field.
This field is typically used by distance vector routing protocols, like Routing Information
Protocol (RIP) to prevent layer 3 loops (routing loops).
• Source Address: The size of the Source Address field is 128 bits. The Source Address field
shows the IPv6 address of the source of the packet.
• Destination Address: The size of the Destination Address field is 128 bits. The Destination
Address field shows the IPv6 address of the destination of the packet.
 V4/V6 Packet Format Differences.

VRRP Packet Format:

 STP:
• Broadcasts and Layer 2 loops can be a dangerous combination.
• Ethernet frames have no TTL field
• After an Ethernet frame starts to loop, it will probably continue until someone shuts off one
of the switches or breaks a link.
Ethernet:

The data packets from Internet Layer is moved to Network Access Layer as it moves down the TCP/IP
protocol stack. There is a size limitation for Ethernet Frame. The total size of the Ethernet frame must be
between 64 bytes and 1,518 bytes (not including the preamble). Network Access Layer Breaks Internet
Layer data (IP Datagram) into smaller chunks, if necessary, which will become the payload of ethernet
frames. A Frame includes data to be transmitted and also a header and a trailer which contain information
that the network adapters on the ethernet need to process the frame.
The total size of the ethernet frame must be between 64 bytes and 1,518 bytes (not including the preamble).
A frame shorter than the minimum 64 bytes but with a valid CRC is called as a runt. In most cases, such
frames arise from a collision. Any frame which is received and which is greater than the maximum frame
size, is called a "giant". A "giant" is longer than 1518 bytes yet have a valid CRC. Both runts and giants are
considered as invalid.

Structure of an Ethernet Frame

The Ethernet Frame fields are explained below.
Preamble: A sequence of 56 bits having alternating 1 and 0 values that are used for synchronization.
They serve to give components in the network time to detect the presence of a signal, and being reading
the signal before the frame data arrives.
SFD (Start Frame Delimiter): A sequence of 8 bits having the bit configuration 10101011 that
indicates the start of the frame.
Source and Destination MAC Addresses: The Source MAC Address is the MAC Address of the
device this frame is coming from. The Destination MAC Address is the MAC Address of the device
which is going to receive this frame. Both of these fields are 6 bytes long.
Length/Type: A 2-byte (16-bit) field contains the number of bytes in the Data field or the nature of
the MAC client protocol.
Data: This field contains the actual data transferred from the source device to the destination device.
The maximum size of this field is 1500 bytes. If the size of this field is less than 46 bytes, then use of the
subsequent "Pad" field is necessary to bring the frame size up to the minimum length.
Pad: If necessary, extra data bytes are appended in this field to bring the frame length up to its
minimum size. A minimum Ethernet frame size is 64 bytes from the Destination MAC Address field
through the Frame Check Sequence.

Frame Check Sequence: This field contains a 4-byte Cyclic Redundancy Check (CRC) value used for
error checking. When a source device assembles a frame, it performs a Cyclic Redundancy Check (CRC)
calculation on all fields in the frame except the Preamble, SFD (Start Frame Delimiter), and frame check
sequence using a predetermined algorithm. The source device stores the value in this field and transmits
it as part of the frame. When the frame is received by the destination device, it performs an CRC test
again using the same algorithm. If the CRC value calculated at the destination device does not match
the value in the FCS (Frame Check Sequence) field, the destination device will discards the frame,
considering this as a transmission error.

WebAuth:
http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-
wireless-controllers/108501-webauth-tshoot.html
 RADIUS - Operations
Before the Client starts communicating with the Radius Server, it is required that the
secret key is shared between the Client and the Server and the Client must be
configured to use Radius server to get service.
Once Client is configured properly then:
· The Client starts with Access-Request.
· The Server sends either Access-Accept, Access-Reject, or Access-Challenge.
· Access-Accept keeps all the required attributes to provide service to the user.
Radius Codes (decimal) are assigned as follows:
 1 Access-Request

 2 Access-Accept

 3 Access-Reject

 4 Accounting-Request

 5 Accounting-Response

 11 Access-Challenge

 12 Status-Server (experimental)

 13 Status-Client (experimental)

 255 Reserved

 No Keep Alive concept - Good or Bad??

Codes 4 and 5 are related to Radius Accounting Functionality. Codes 12 and 13 are
reserved for possible use.

RADIUS - Packet Format

The packet format of Radius is as shown below:
Code: This is 1 Octet (1 byte) long and identifies various types of packets. Normally 1
Octet means 1 Byte.
Identifier: This is again 1 Octet long and aids in matching responses with requests.
Length: This is 2 Octets long and specifies the length of the packet including code,
identifier, length, and authenticator. (Min packet is 20 Octets and max is 4096 Octets).
Authenticator: This is 16 Octets long and filled up in case of some requests and
responses.

DHCP Packet:
All Dynamic Host Configuration Protocol (DHCP) messages include a FIXED format section and a
VARIABLE format section. The fixed format section consists of several fields that are the same in every
Dynamic Host Configuration Protocol (DHCP) message. The variable format section in the Dynamic Host
Configuration Protocol (DHCP) contains "OPTIONS", which carry additional configuration parameters.
BGP Packet Formats: