How to convert Decimal to Binary and Hexa decimal values:

146.149.186.20
128 64 32 16 8 4 2 1 128 64 32 16 8 4 2 1 128 64 32 16 8 4 2 1 128 64 32 16 8 4 2 1

1 0 0 1 0 0 1 0 1 0 0 1 0 10 1 1 0 1 1 1 0 1 0 0 0 0 1 0 1 0 0

9 2 9 5 b a 1 4

169.124.21.149

a9 7c 15 95

The IP datagram structure

An IP datagram consists of a header part and text part.

-------------------------------------------
| |
| IP HEADER |
| |
-------------------------------------------
| |
| DATA |
| |
-------------------------------------------

The header has a 20 bytes fixed part and a variable length optional part. It is
transmitted in big endian order. (on little endian machines, software conversion is
required).

The IP datagram header format

Version
 Which version of the protocol the datagram belongs to.
 The current version number is 4.
 Next version: 6

IHL
 The number of 32-bit words in the header
 Because this is 4 bits, the max header length is 15 words (i.e. 60 bytes)
 The header is at least 20 bytes, but options may make it bigger

Type of Service
 Contains a 3-bit precedence field (that is ignored today), 4 service bits, and 1
unused bit.
 The four service bits can be:
o 1000 - minimize delay
o 0100 - maximize throughput
o 0010 - maximize reliability
o 0001 - minimize monetary cost
 This is a "hint" of what characteristics of the physical layer to use
 The Type of Service is not supported in most. implementations. However, some
implementations have extra fields in the routing table to indicate delay,
throughput, reliability, and monitary cost.

Total Length
 total length of the datagram in bytes.
 we know where the data starts by the header length
 we know the size of the data by computing "total length - header length"

Identification
  Uniquely identifies the datagram.
 Usually incremented by 1 each time a datagram is sent.
 All fragments of a datagram contain the same identification value.
 This allows the destination host to determine which fragment belongs to which
datagram.

Flags and Fragmentation Offset

 Used for fragmentation
 DF means do not fragment. It is a request to routers not to fragment the
datagram since the destination is incapable of putting the pieces back together.
 MF means more fragments to follow. All fragments except the last one have
this bit set. It is needed to know if all fragments of a datagram have arrived.

Fragment offset
number of fragment.

Time to Live
 Upper limit of routers
 usually set to 32 or 64.
 decremented by each router that processes the datagram,
 router discards the datagram when TTL reaches 0.

Protocol
 Tells IP where to send the datagram up to.
 6 means TCP
 17 means UDP

Header checksum
Only covers the header, not the data.

Source IP address
The sender

Destination IP address
the final destination

Options
 Optional data.
 Some examples include having the router put in a IP address of router and a
time stamp so the final destination knows how long it took to get to each hop.

The source and destination in the IP header is the original source and the final
destination! The physical layer addresses pass the datagram from router to router. So,
while the physical layer addresses change from router to router, the source and
destination IP addresses in the IP datagram remain constant!

The checksum
 How to compute a checksum?
o Put a 0 in the checksum field.
o Add each 16-bit value together.
o Add in any carry
o Inverse the bits and put that in the checksum field.
 To check the checksum:
o Add each 16-bit value together (including the checksum).
o Add in carry.
o Inverse the bits.
o The result must be 0.
 Remember, only the bits in the header are calculated in the IP checksum.

Example:
Consider the following IP header, with source IP address of 146.149.186.20 and
destination address of 169.124.21.149. All values are given in hex:
45 00 00 6c
92 cc 00 00
38 06 00 00
92 95 ba 14
a9 7c 15 95

So, first add all 16-bit values together, adding in the carry each time:
4500
+ 006c
----
456c
 + 92cc
----
d838
+ 0000
----
d838
+ 3806
----
1103e <---But, we have a carry here! So, remove the leftmost bit
and add it back in. So, we get: 103e + 1 = 103f.
103f
+ 0000
----
103f
+ 9295
----
a2d4
+ ba14
----
15ce8 <---Again, we have a carry here! So, remove the leftmost bit
and add it back in. So, we get: 5ce8 + 1 = 5ce9.
5ce9
+ a97c
----
10665 <---Again, we have a carry here! So, remove the leftmost bit
and add it back in. So, we get: 0665 + 1 = 0666.
0666
+ 1595
----
1bfb

Now we have to inverse the bits.

1bfb = 0001 1011 1111 1011
inverse bits: 1110 0100 0000 0100 = e404

So, the checksum is e404. So, the IP header we send looks like:
45 00 00 6c
92 cc 00 00
38 06 e4 04
92 95 ba 14
a9 7c 15 95

As an excercise, please act as the receiver, compute the checksum on that packet, and
make sure the result is 0!

IP Fragmentation
 Note: the total_length field in the IP header is 16 bits. that means the max size
of of an IP datagram is 65535 bytes.
  BUT, the physical layer may not allow a packet size of that many bytes (for
example, a max ethernet packet is 1500 bytes)
 SO, IP must sometimes fragment packets.
 When an IP datagram is fragmented, each fragment is treated as a separate
datagram.
o it is reassembles at the final destination, not at a router!
o it does that because the router may have to fragment it again!
 Each fragment has its own header.
 The identification number is copied into each fragment.
 One bit in the "flags" field says "more fragments are coming. If that bit is 0,
then it signifies this is the last fragment.
 The "fragment offset" field contains the offset of the data.
o fragment flag of 0 and offset of 0 means the datagram is not fragmented.
o fragment offset is measured in units of 8 bytes (64 bits). That is because
the fragment offset field is 3 bits shorter than the total length field (and
2^3 is 8).
 The entire flags field looks like this:
 --------------------------
 | bit 0 | bit 1 | bit 2 |
 --------------------------

 bit 0: not used
 bit 1: if 1, it means "don't fragment".
 If IP must fragment the packet and
 this bit is set, IP throws away the datagram.
 bit 2: The fragment flag.

Example:
 Suppose we have a physical layer that can transmit a maximum of 660 bytes.
And, suppose IP wants to send 1460 bytes of data. So, the IP datagram is a total
of 1480 bytes, including the 20 byte IP header:
 ---------------------------------------------
 | 20-byte ip header | 1460 bytes of data |
 ---------------------------------------------
 Here is what IP sends:
 First packet:
 bytes: 20 640
 ---------------------------------------------
 | IP header | first 640 bytes of data |
 ---------------------------------------------
 In that packet, "fragment flag" is 1, offset is 0.
 Second packet:
 bytes: 20 640
 ---------------------------------------------
 | IP header | second 640 bytes of data |
 ---------------------------------------------
 
 In that packet, "fragment flag" is 1, offset is 80. The offset is 80 because (80 *
8) is 640, so the offset of that data is 640 byes into the packet.
 Note: all other fields of the IP header are identical to the first packet (except the
checksum)!
 Third packet:
 bytes: 20 640
 ---------------------------------------------
 | IP header | third 180 bytes of data |
 ---------------------------------------------
 In that packet, "fragment flag" is 0, offset is 160. The offset is 160 because
(160 * 8) is 1280, so the offset of that data is 1280 byes into the packet.
 Note: all other fields of the IP header are identical to the first packet except the
checksum.
 IMPORTANT: The routers see 3 separate packets. The final destination
reassembles the packet before passing the packet to the upper layers.

Exercise
 Now, as an exercise, please try to figure out what the "frag flag" and "offset"
would be for the above packets if a router had to pass the above three packets to
a physical layer than only accepted packets of max size 400. I'll probably put a
question like that on the final.
 Note: IP can tell if it's fragmenting a fragment, right? If a packet has "frag flag"
of 0 and offset of 0, then the packet is not fragmented. When fragmenting a
fragment, IP must make sure the final destination can put the packet back
together correctly. So, IP only sets the "frag flag" to 0 on a packet if in fact the
packet contains the very last fragment of the entire packet.

UDP - The User DataGram Protocol

 UDP is a simple, connectionless protocol. It provides no reliability; it simply
sends data to the IP layer
 To use UDP, an application associates itself with a "transport address"
o for UDP, a transport address is a combination of an IP address and a port
number
o a port number is a 16-bit number that uniquely identifies the application
using UDP.
 On the server side, the server application does the following:
o Get a transport endpoint into UDP
o Bind to a transport address
 o Wait for a datagram to arrive
o Read the datagram
o Send a reply datagram is the application protocol warrents it.
 On the client side, the client application does the following:
o Get a transport endpoint into UDP
o Bind to a transport address
o Send a datagram to the application on the server machine, specifying the
transport address to which the server bound.
o Wait for a reply if the application protocol warrents it
o Client should time-out and resend the datagram if a response does not
arrive after a time-out period.
 Let's look at the UDP protocol:
 -----------------------------------------------------------------
 | 16-bit source port number | 16-bit destination port number |
 -----------------------------------------------------------------
 | 16-bit UDP length | 16-bit UDP checksum |
 -----------------------------------------------------------------
 | data |
 -----------------------------------------------------------------
 The length is that of the header and the data in bytes.
o Header is 8 bytes
o Note: Max IP datagram size is 65535 bytes, minus 20 bytes for the IP
header ===> 65515 bytes left for data. But, UDP header is 8 bytes,
leaving 65507 bytes for the maximum amount of user data.
o However, some implementations of UDP limit that value. AIX 3.2.2 and
Solaris 2.5 and 2.6 allow the full size. SunOS 4.1.3 can only accept UDP
packets of no more than 32766 bytes (i.e., 32758 bytes of user data).
 UDP Checksum covers header, data, and extra information.
 To compute checksum:
o If the data has an odd length, pad the data with a 0 byte.
o Put a 0 in the checksum field.
o Create a "pseudo-header" that contains a 32-bit source IP address, a 32-
bit destination IP address, 8 bits of 0's, an 8-bit protocol number (17 for
UDP), and a 16-bit UDP length, followed by the real UDP header,
followed by the data.
o Compute the checksum just like IP does it.
o If calculated checksum is 0, store it as all 1's.
 Note: You don't have to compute the checksum! If you don't, you must store a
0 in the checksum field. Checksum is optional to speed things up in a reliable
physical layer.

Example of checksum
Let's say an application at 198.75.24.121, port 4052 wants to send a packet containing
elvis0 to 198.75.24.36, port 5134.

Now, port 4052 is hex 0FD4, and port 5134 is hex 140E. And, because the data has 6
characters, the total length is 14 (that hex E). And, the word "elvis0" has a ASCII hex
representation of "65 6c 76 69 73 00"

So, if we put a 0 in the checksum field, the packet looks like this:
0FD4 140E
000E 0000
656c 7669
7300

To compute the checksum, we have to create a pseudo header. Now, 198.75.24.121

has a hex value of C6 4B 18 79. Also, the destination (198.75.24.36) has a hex value
of C6 4B 18 24. And, the value "17" has a hex value of "11". So, we create a "pseudo-
header" that looks like this:
C64B 1879 <- source IP address
C64B 1824 <- destination IP address
0011 000E <- 00, 17, and length
0FD4 140E <- source port, dest port
000E 0000 <- length (again) and 0 checksum
656c 7669 <- "elvi"
7300 <- "s0"

Now add all the 16-bit values together and add in any carry.
C64B
+ 1879
====
DEC4
+ C64B
====
A50F
+ 1 <- carry
====
A510
+ 1824
====
BD34
+ 0011
====
BD45
+ 000E
====
BD53
+ 0FD4
====
CD27
+ 140E
====
E135
+ 000E
====
E143
+ 0000
====
E143
+ 656c
====
46AF
+ 1 <- carry
====
46B0
+ 7669
====
BD19
+ 7300
====
3019
+ 1 <- carry
====
301A

In binary, that 0011000000011010. Inverse it, you get 1100111111100101, which is

CFE5. That's the checksum!

IP Datagram Structure
Share This:
The term 'datagram' or 'packet' is used to describe a chunk of IP data. Each IP
datagram contains a specific set of fields in a specific order so that the reader knows
how to decode and read the stream of data received. The description of the IP
datagram format in this tutorial is suitable for most purposes.

An IP datagram looks something like this:

Versio IH
TOS Total Length
n L
Flag Fragment
Identification
s Offset
Protoco
TTL Header Checksum
l
Source IP Address
Destination IP Address
Options Padding

Payload (TCP/UDP/ICMP etc.)

VERSION (4 bits)
The version field is set to the value '4' in decimal or '0100' in binary. The value
indicates the version of IP (4 or 6, there is no version 5).
IHL (4 bits)
The Internet Header Length (IHL) describes how big the header is in 32-bit
words. For instance, the minimum value is 5, as that is the minimum size of an
IP header that contains all the correct fields is 160 bits, or 20 bytes. This allows
the receiver to know exactly where the payload data begins.
TOS (8 bits)
Type of service allows the intermediate receiving stations (the routers) to have
some notion of the quality of service desired. This allows the network to make
adaptations for delay, throughput, or reliability.
TOTAL LENGTH (16 bits)
This informs the receiver of the datagram where the end of the data in this
datagram is. This is the length of the entire datagram in octets, including the
header. This is why an IP datagram can be up to 65,535 bytes long, as that is
the maximum value of this 16-bit field.
IDENTIFICATION (16 bits)
Sometimes, a device in the the middle of the network path cannot handle the
datagram at the size it was originally transmitted, and must break it into
 fragments. If an intermediate system needs to break up the datagram, it uses
this field to aid in identifying the fragments.
FLAGS (3 bits)
The flags field contains single-bit flags that indicate whether the datagram is a
fragment, whether it is permitted to be fragmented, and whether the datagram is
the last fragment, or there are more fragments. The first bit in this field is
always zero.
FRAGMENT OFFSET (13 bits)
When a datagram is fragmented, it is necessary to reassemble the fragments in
the correct order. The fragment offset numbers the fragments in such a way that
they can be reassembled correctly.
TIME TO LIVE (8 bits)
This field determines how long a datagram will exist. At each hop along
a network path, the datagram is opened and it's time to live field is decremented
by one (or more than one in some cases). When the time to live field reaches
zero, the datagram is said to have 'expired' and is discarded. This prevents
congestion on the network that is created when a datagram cannot be forwarded
to it's destination. Most applications set the time to live field to 30 or 32 by
default.
PROTOCOL (8 bits)
This indicates what type of protocol is encapsulated within the IP datagram.
Some of the common values seen in this field include:

Number
Protocol
(Decimal)
ICMP 1
IGMP 2
TCP 6
UDP 17
HEADER CHECKSUM (16 bits)
According to RFC 791, the header checksum formula is:"the 16-bit ones
compliment of the ones compliment sum of all 16-bit words in the header."
The checksum allows IP to detect datagrams with corrupted headers and
discard them. Since the time to live field changes at each hop, the checksum
must be re-calculated at each hop. In some cases, this is replaced with a cyclic
redundancy check algorithm.
SOURCE ADDRESS (32 bits)
This is the IP address of the sender of the IP datagram.
DESTINATION ADDRESS (32 bits)
This is the IP address of the intended receiver(s) of the datagram. If the host
portion of this address is set to all 1's, the datagram is an 'all hosts' broadcast.
OPTIONS & PADDING (variable)
Various options can be included in the header by a particular vendor's
implementation of IP. If options are included, the header must be padded with
zeroes to fill in any unused octets so that the header is a multiple of 32 bits, and
matches the count of bytes in the Internet Header Length (IHL) field.