Pages

Saturday, August 4, 2012

IP and ICMP Header Format !!


IP header

0001020304050607080910111213141516171819202122232425262728293031
VersionIHLDifferentiated ServicesTotal length
IdentificationFlagsFragment offset
TTLProtocolHeader checksum
Source IP address
Destination IP address
Options and padding :::

for Reference :
http://www.networksorcery.com/enp/protocol/ip.htm
http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch01lev1sec2.html
http://en.wikipedia.org/wiki/IPv4
http://en.wikipedia.org/wiki/Traceroute
http://en.wikipedia.org/wiki/ICMP_Echo_Reply#Echo_reply

The IP header is built up in blocks of 32 bits.
It will always be an integral number of 32-bit words. The IP header is divided up
into fields.
Version
The first field is the version field. The version field is 4 bits long. It
indicates the release version of the IP that is used in this datagram.

Header Length
The header length field is 4 bits long. It identifies the length of the IP header in
multiples of 32. The minimum value for a valid header is 5 (means 5*32Bit = 20
Bytes), Maximum is 15 (means 15*32Bit = 60 Bytes).

Differentiated Services. 8 bits.
This field is defined in RFC 2474 and obsoletes the TOS field.

0001020304050607
Codepointunused

 Codepoint. 6 bits.
CodepointDescriptionReferences
000000CS0RFC 2474
001000CS1RFC 2474
010000CS2RFC 2474
011000CS3RFC 2474
100000CS4RFC 2474
101000CS5RFC 2474
110000CS6RFC 2474
111000CS7RFC 2474
001010Assured Forwarding 11RFC 2597
001100Assured Forwarding 12RFC 2597
001110Assured Forwarding 13RFC 2597
010010Assured Forwarding 21RFC 2597
010100Assured Forwarding 22RFC 2597
010110Assured Forwarding 23RFC 2597
011010Assured Forwarding 31RFC 2597
011100Assured Forwarding 32RFC 2597
011110Assured Forwarding 33RFC 2597
100010Assured Forwarding 41RFC 2597
100100Assured Forwarding 42RFC 2597
100110Assured Forwarding 43RFC 2597
101100Voice-AdmitRFC 5865
101110Expedited Forwarding PHBRFC 2598, RFC 3246
unused. 2 bits.

Total length. 16 bits.
Contains the length of the datagram.

Identification. 16 bits.
Used to identify the fragments of one datagram from those of another. The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system. The originating protocol module of a complete datagram clears the MF bit to zero and the Fragment Offset field to zero.

 Flags. 3 bits.
000102
RDFMF
R, reserved. 1 bit.
Should be cleared to 0.
DF, Don't fragment. 1 bit.
Controls the fragmentation of the datagram. 
ValueDescription
0Fragment if necessary.
1Do not fragment.
MF, More fragments. 1 bit.
Indicates if the datagram contains additional fragments. 
ValueDescription
0This is the last fragment.
1More fragments follow this fragment.

The second flag indicates whether fragmentation is allowed. It is
called the don't fragment (DF) bit. If the flag is set to 1
fragmentation is not allowed, and if it is set to 0 fragmentation is
allowed. If the flag is set to 1, datagrams will be lost if they have to
cross networks that can only handle smaller datagrams than the
one presented to it. For this reason, it is prudent to set the flag to 0
and allow fragmentation.
The third flag is called the more fragments (MF) bit. It is used to
indicate that there are more fragments to follow, so if a datagram
is fragmented this is set on all but the last fragment. In the
fragmentation process the header information in the original
datagram must be copied into each of the fragments.
The fragment offset field is 13 bits long and is used to indicate the
relative position of the fragment to the original datagram when
fragmentation is carried out.

Might not correspond to the order in which they were sent, the MF
flag is used in conjunction with the Fragment Offset field (the next
field in the IP header) to indicate to the receiving machine the full
extent of the message.

Fragment Offset: If the MF (More Fragments) flag bit is set to 1
(indicating fragmentation of a larger datagram), the fragment offset
contains the position in the complete message of the sub message
contained within the current datagram. This enables IP to
reassemble fragmented packets in the proper order. Offsets are
always given relative to the beginning of the message. This is a 13-
bit field, so offsets are calculated in units of 8 bytes,
corresponding to the maximum packet length of 65,535 bytes.
Using the identification number to indicate which message a
receiving datagram belongs to, the IP layer on a receiving machine
can then use the fragment offset to reassemble the entire
message.

TTL
A datagram may float about the Internet without reaching its destination and therefore waste bandwidth.It is necessary to set a maximum lifetime that the datagram is allowed to survive.This is effected by indicating the maximum number of routers it is allowed to cross. The TTL field indicates the "time to live" for the datagram.

Protocol
The protocol field is 8 bits long and is used to identify the upper layer protocol that is to receive the IP data portion of the datagram.
Higher- level protocol that provide data
1 = datagrams carries an ICMP messages
6 = datagrams carries a TCP segments
17 = datagrams carries an UDP datagrams Etc.,
As the Internet address gets you to the correct host. The protocol identifier gets you to the correct service within the host. The header checksum is 16 bits long. It holds the error check result for the entire header, which includes options, if they are present As this is a connectionless protocol, full details of the source and destination addresses must be included. Both of these fields are 32 bits long.

Header checksum. 16 bits.
A 16 bit one's complement checksum of the IP header and IP options.

Source IP address. 32 bits.
IP address of the sender.

Destination IP address. 32 bits.
IP address of the intended receiver.

Options. Variable length.
0001020304050607
CClassOption
C, Copy flag. 1 bit.
Indicates if the option is to be copied into all fragments.
ValueDescription
0Do not copy.
1Copy.
Class. 2 bits.
ValueDescription
0Control.
1Reserved.
2Debugging and measurement.
3Reserved. 
Option. 5 bits.
OptionCopyClassValueLengthDescriptionReferences
00001End of options list.RFC 791
10011NOP.RFC 791
21013011Security.RFC 791, RFC 1108
310131variableLoose Source Route.RFC 791
40268variableTime stamp.RFC 781, RFC 791
5101333 to 31Extended Security.RFC 1108
610134Commercial Security.
7007variableRecord Route.RFC 791
8101364Stream Identifier.RFC 791, RFC 1122
910137variableStrict Source Route.RFC 791
100010Experimental Measurement.
1100114MTU Probe. (obsolete).RFC 1063
1200124MTU Reply. (obsolete).RFC 1063
1312205Experimental Flow Control.
1410142Expermental Access Control.
150015ENCODE.
1610144IMI Traffic Descriptor.
1710145variableExtended Internet Protocol.RFC 1385
18028212Traceroute.RFC 1393
191014710Address Extension.RFC 1475
20101484Router Alert.RFC 2113
21101496 to 38Selective Directed Broadcast Mode.RFC 1770
2210150
2310151Dynamic Packet State.
2410152Upstream Multicast Packet.
250025QS, Quick-Start.RFC 4782
26
-
29
300030EXP - RFC3692-style Experiment.RFC 4727
300294EXP - RFC3692-style Experiment.RFC 4727
3010158EXP - RFC3692-style ExperimentRFC 4727
3012222EXP - RFC3692-style Experiment.RFC 4727
31
Padding. Variable length.
Used as a filler to guarantee that the data starts on a 32 bit boundary.

Sample Output: Wareshark capture

 tshark -i eth0 -V -R "ip.addr==
10.44.88.1

4"

Frame 9753 (74 bytes on wire, 74 bytes captured)

    Arrival Time: Aug  3, 2012 10:06:34.331964000

    [Time delta from previous captured frame: 0.001201000 seconds]

    [Time delta from previous displayed frame: 0.001232000 seconds]

    [Time since reference or first frame: 8.148070000 seconds]

    Frame Number: 9753

    Frame Length: 74 bytes

    Capture Length: 74 bytes

    [Frame is marked: False]
    [Protocols in frame: eth:ip:udp:rpc]
Ethernet II, Src: Cisco_e3:1f:80 (00:1a:30:e3:1f:80), Dst: HewlettP_d9:cd:dc (00:1e:0b:d9:cd:dc)
    Destination: HewlettP_d9:cd:dc (00:1e:0b:d9:cd:dc)
        Address: HewlettP_d9:cd:dc (00:1e:0b:d9:cd:dc)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Cisco_e3:1f:80 (00:1a:30:e3:1f:80)
        Address: Cisco_e3:1f:80 (00:1a:30:e3:1f:80)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 72.163.138.51 (72.163.138.51), Dst: 10.64.88.14 (10.64.88.14)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 60
    Identification: 0xd332 (54066)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 249
    Protocol: UDP (0x11)
    Header checksum: 0x7959 [correct]
        [Good: True]
        [Bad : False]
    Source: 72.163.138.51 (72.163.138.51)
    Destination: 10.64.88.14 (10.64.88.14)
User Datagram Protocol, Src Port: 923 (923), Dst Port: surf (1010)
    Source port: 923 (923)
    Destination port: surf (1010)
    Length: 40
    Checksum: 0x2492 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
Remote Procedure Call, Type:Reply XID:0x49ae54ad
    XID: 0x49ae54ad (1236161709)
    Message Type: Reply (1)
    [Program: YPSERV (100004)]
    [Program Version: 2]
    [Procedure
    Reply State: accepted (0)
    [This is a reply to a request in frame 9751]
    [Time from request: 0.001232000 seconds]
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
    Accept State: RPC executed successfully (0)
Yellow Pages Service MATCH reply Error:YP_NOKEY
    [Program Version: 2]
    [V2 Procedure: MATCH (3)]
    Status: YP_NOKEY (-3)
    Value:
        length: 0
        contents:

Introduction to ICMP
IP provides best-effort delivery Delivery problems can be ignored; datagrams can be "dropped on the floor"
 Internet Control Message Protocol (ICMP) provides error reporting mechanism

ICMP header:
0001020304050607080910111213141516171819202122232425262728293031
TypeCodeICMP header checksum
Data :::

http://www.networksorcery.com/enp/protocol/icmp.htm
http://www.pcvr.nl/tcpip/icmp_int.htm

As said earlier IP defines a best effort communication service in
which datagrams can be lost, duplicated, delayed or delivered out
of order. It may seem that the best effort service does not need any
error detection. However, it is important to realize that the best effort
service is not careless - IP attempts to avoid errors and to report
problems when they occur. This section examines an error
reporting protocol that is integrated with IP. It reviews the basic
errors that can be reported and explains how and where such
messages are sent.

Error Correction
Internet layer can detect a variety of errors:
 Checksum (header only!)
 TTL expires
 No route to destination network
 Can't deliver to destination host (e.g., no ARP reply)
• Internet layer discards datagrams with problems
• Some - e.g., checksum error - can't trigger error messages

One example of error detection in IP is the one that makes use of
header checksum that is used to detect transmission errors. When
a host creates an IP datagram, the host includes a checksum that
covers the entire header. Whenever a datagram is received, the
checksum is verified to ensure that the header arrived intact. To
verify the checksum, the receiver recomputes the checksum
including the value in the checksum field. If a bit in the IP header
is damaged during transmission across a physical network, the
receiver will find that the checksum does not result in zero. After
changing fields in the header (e.g., after decrementing the TTL
field), a router must recompute the checksum before forwarding
the datagram to its next hop.
The action taken in response to a checksum error is straightforward: the datagram must be discarded immediately without
further processing. The receiver cannot trust any fields in the
datagram header because the receiver cannot know which bits
were altered. In particular, the receiver cannot send an error
message back to the computer that sent the datagram because the
receiver cannot trust the source address in the header. Likewise,
the receiver cannot forward the damaged datagram because the
receiver cannot trust the destination address in the header. Thus,
the receiver has no option but to discard the damaged datagram.

Error Reporting
• Some errors can be reported
 Router sends message back to source in datagram
 Message contains information about problem
• Encapsulated in IP datagram

Problems that are less severe than transmission errors result in
error conditions that can be reported. For example, suppose some
of the physical paths in a internet fail, causing the internet to be
partitioned into two sets of networks with no path between the
sets. A datagram sent from a host in one set to a host in the other
cannot be delivered.
The TCP/IP suite includes a protocol that IP uses to send error
messages when conditions such as the one described above
arise: the Internet Control Message Protocol (ICMP). The protocol
is required for a standard implementation of IP. We will se that the
two protocols are co-dependent. IP uses ICMP when it sends an
error message, and ICMP used IP to transport messages.

Types of Messages
Internet Control Message Protocol (ICMP) defines error and informational messages

• Error messages:
 Source quench
 Time exceeded
 Fragmentation required
 Destination Unreachable
 Redirect

• Informational messages:
 Echo request/reply
 Address mask request/reply
 Router discovery

ICMP error messages include :
• Source Quench : A router that has temporarily run out of buffer
space must discard incoming datagrams. When it discards a
datagram, the router sends a source quench message to the host
that created the datagram. When it receives a source quench, a
host is required to reduce the rate at which it is sending.

• Time exceeded : A time exceeded message in sent in two cases.
Whenever a router reduces the TTL field in a datagram to zero, the
router discards the datagram and sends a time exceeded
message. In addition, a time exceeded message is sent by a host if
the reassembly timer expires before all fragments from a given
datagram arrive.

• Destination unreachable : Whenever a router determines that a
datagram cannot be delivered to its final destination, it sends this
message to the host.

• Redirect : If a router determines that a host has incorrectly sent
a datagram that should be sent to a different router, it uses the
redirect message to cause the host to change its route.

• Parameter problem : One of the parameters specified in a
datagram is incorrect.

ICMP Message Summary
Type
Field
0 - Echo Reply
3 - Destination unreachable
4 - Source Quench
5 - Redirect
8 - Echo
11 - Time exceeded
12 - Parameter problem
13 - Timestamp
14 - Timestamp reply
15 - Information request (obsolete)
16 - Information reply (obsolete)
17 - Address mask request
18 - Address mask reply


ICMP information messages include :
• Echo Request/Reply : It an be sent by any computer. In response
to an incoming echo request message, ICMP s/w is required to
send an ICMP reply message.

• Address Mask Request/ Reply : A host broadcasts an address
mask request when it boots, and routers that receive the request
send an address reply that contains the correct 32 bit subnet mask
being used on the network.

ICMP uses IP to transport each error message. When a router has an
ICMP message to send, it creates an IP datagram and encapsulates
the ICMP message in it. The datagram is then forwarded as usual,
with the complete datagram being encapsulated in a frame for
transmission. Where should an ICMP message be sent? ICMP
messages are always created in response to a datagram. Either the
datagram has encountered a problem, or the datagram carries an
ICMP request message to which the router creates a reply.
Datagrams carrying ICMP messages don’t have special priority - they
are forwarded like any other datagram, with one minor exception. If a
datagram carrying an ICMP error message causes an error, no error
message is sent. The reason should be clear: the designers wanted
to avoid an internet becoming congested carrying error messages
about error messages.
Type field can contain the values listed in the PPT
The Code field expands on the message type, providing a little more
information for the receiving machine. The checksum in the ICMP
header is calculated in the same manner as the normal IP header
checksum.

The layout of the ICMP message is slightly different for each type
of message. Figure in next page shows the layouts of each type of
ICMP message header. The Destination Unreachable and Time
Exceeded messages are self-explanatory, although they are used
in other circumstances, too, such as when a datagram must be
fragmented but the Don't Fragment flag is set. This results in a
Destination Unreachable message being returned to the sending
machine.
Echo request or reply messages are commonly used for
debugging purposes. When a request is sent, a device or gateway
down the path sends a reply back to the specified device. These
request/reply pairs are useful for identifying routing problems
failed gateways, or network cabling problems. The simple act of
processing an ICMP message also acts as a check of the network,
because each gateway or device along the path must correctly
decode the headers and then pass the datagram along. Any failure
along the way could be with the implementation of the IP software.
A commonly used request/reply system is the ping command. The
ping command sends a series of requests and waits for replies.
These are used by the utility program known as ping. Ping sends
ICMP type 8 (echo request) messages to a node and expects an
ICMP type 0 reply, returning the data send in the request.
The identifier and sequence numbers are used to identify these
datagrams uniquely. If data is sent in the optional data field it must
be returned in the reply. Varying data sizes on a ping are used to
test for data transmission problems. If a router is unable to deliver
a datagram, it can return the destination unreachable ICMP
datagram to indicate why. The code field is used to identify the
cause of failure. The Internet header plus 64 bits of the datagram
prefix are used to identify uniquely the datagram which caused the
problem. The values provided in the code field help pinpoint the
reason the datagram failed to arrive at its destination.

Network Unreachable : Code value will be 0. The network
specified in the IP address cannot be found. The IP address used
should be checked or there is a fault in the routing tables of the
intervening routers.

Host Unreachable : Code value will be 1. The datagram reached the
right router but the router could not communicate with the host.
Probably ARP failed, the host is down or unavailable.

Protocol unreachable : Code value will be 2. The data gram reached the
destination host, but the particular protocol carried in the IP datagram was
not available. This is rare, but is possible if the configuration of the remote
machine is incorrect.

Port unreachable : Code value will be 3. The message from a host indicates
that the particular application layer service on the remote host to which a
connection is being established is not available. This can happen if the
application is down due to some reason.

Fragmentation needed and the do not fragment bit set : Code value is 4.
This message would normally come from a router, indicating that it needs to
fragment the datagram, but the DF bit in the flags field of the IP header is
set.

Source routed failed : Code value is 5. The management options in IP allow
an IP datagram to carry a source route definition that identifies the complete
path, based on the router addresses the IP datagram should take. The error
message indicates that the datagram referred to failed to complete the route.

The other types of ICMP messages are as follows :
The Parameter Problem ( type 12) message is used whenever a semantic or
syntactic error has been encountered in the IP header. This can happen
when options are used with incorrect arguments. When a Parameter
Problem message is sent back to the sending device, the Parameter field in
the ICMP error message contains a pointer to the byte in the IP header that
caused the problem.

Timestamp requests (type 13 ) and replies (type 14) enable the timing of
message passing along the network to be monitored. When combined with
strict routing, this can be useful in identifying bottlenecks. Address mask
requests and replies are used for testing within a specific network or
subnetwork.

The Source Quench ICMP (type 4, code 0) message is used to control the
rate at which datagrams are transmitted, although this is a very rudimentary
form of flow control. When a device receives a Source Quench message, it
should reduce the transmittal rate over the network until the Source Quench
messages cease. The messages are typically generated by a gateway or
host that either has a full receiving buffer or has slowed processing of
incoming datagrams because of other factors.

Redirection messages ( type 5) are sent to a gateway in the path when a
better route is available. For example, if a gateway has just received a
datagram from another gateway but on checking its data fields finds a better
route, it sends the Redirection message back to that gateway with the IP
address of the better route. When a Redirection message is sent, an integer
is placed in the code field of the header to indicate the conditions for which
the rerouting applies. A value of 0 means that datagrams for any device on
the destination network should be redirected. A value of 1 indicates that
only datagrams for the specific device should be rerouted. A value of 2
implies that only datagrams for the network with the same type of service
(read from one of the IP header fields) should be rerouted. Finally, a value of
3 reroutes only for the same host with the same type of service.

Ping Process
A Ping program tests to see if a given destination can be reached. Ping
uses ICMP echo request and echo reply messages. When invoked, ping
sends an IP datagram that contains an ICMP echo request message to the
specified destination. After sending the request, it waits a short time for the
reply. If no reply arrives, ping retransmits the request. If no reply arrives for
the retransmissions, ping declares that the remote machine is not
reachable.
ICMP software on a remote machine replies to the echo request message.
According to the protocol, whenever, an echo request arrives, the ICMP s/w
must send an echo reply.
ICMP messages are used by the trace- route tool when it constructs a list
of all routers along a path to a given destination.
Trace-route either uses ICMP message type 30, or its uses the UDP. When
using the UDP, trace-route sends the UDP datagram to a nonexistent
program on the destination machine. When a UDP message arrives for a
non existent program, ICMP sends a destination unreachable message.
Thus, each time it transmits a datagram, trace-route either receives an
ICMP time exceeded message from a router along the part or an ICMP
destination unreachable message from the ultimate destination computer.
Trace-route simply sends a series of datagrams and waits for a response
for each. Trace-route sets the TTL value in the first datagram to 1 before
sending the datagram. The first router that receives the datagram
decrements the TTL , discards the datagram and sends back an ICMP time
exceeded message. Because the ICMP message travels in an IP datagram,
trace-route can extract the IP source address and announce the address of
the first router along the path to the destination.
After it discovers the address of the first router, trace-route sends a
datagram with TTL set to 2. The first router decrements the counter and
forwards the datagram; the second router discards the datagram and
sends an error message. Similarly, once it has received an error message
from a router that is distance 2, trace-route sends a datagram with TTL set
to 3, then 4 and so on.
Several details remain that trace-route must handle. Because IP uses besteffort
delivery, datagrams can be lost, duplicated, or delivered out of order.
Thus, trace-route must be prepared to handle duplicate responses and to
transmit datagrams that are lost.
Trace-route faces another problem: routes can change dynamically . If
routes change between two probes, the second probe may take a longer or
shorter path than the first. More important, the sequence of routers that
trace-route finds may not correspond to a valid path through the internet.
Thus, trace-route is most useful on an internet in which routes are
relatively stable.

Ping options
The Ping options allows you to change some of the characteristic of the Ping ICMP echo request packets
Packet Size (bytes)
Specify the size of the packet in bytes, available choices are 32,64,128,256,512,1024 (Default value is 64 bytes).
Time Out (seconds)
Specify the maximum time that the LoriotPro Ping software wait before considering that there is no response. (Default value is 2 seconds).
Time to live (hop count)
Specify the maximum number of hops (IP router) that the packet can go through.
Ping Interval (Milliseconds)
Specify the time interval between 2 consecutive Ping (Default value is 1 second)
Repeat (-1 continuous)
Specify the number of Ping that will be sent (default value is 4). A value of -1 sends Ping continuously. In that case a click on the stop button is mandatory to stop the Ping.
List of devices/Operating systems with default TTL
OS/Device
Version
Protocol
TTL
AIX
TCP
60
AIX
UDP
30
AIX
3.2, 4.1
ICMP
255
BSDI
BSD/OS 3.1 and 4.0
ICMP
255
Compa
Tru64 v5.0
ICMP
64
Cisco
ICMP
254
DEC Pathworks
V5
TCP and UDP
30
Foundry
ICMP
64
FreeBSD
2.1R
TCP and UDP
64
FreeBSD
3.4, 4.0
ICMP
255
FreeBSD
5
ICMP
64
HP-UX
9.0x
TCP and UDP
30
HP-UX
10.01
TCP and UDP
64
HP-UX
10.2
ICMP
255
HP-UX
11
ICMP
255
HP-UX
11
TCP
64
Irix
5.3
TCP and UDP
60
Irix
6.x
TCP and UDP
60
Irix
6.5.3, 6.5.8
ICMP
255
juniper
ICMP
64
MPE/IX (HP)
ICMP
200
Linux
2.0.x kernel
ICMP
64
Linux
2.2.14 kernel
ICMP
255
Linux
2.4 kernel
ICMP
255
Linux
Red Hat 9
ICMP and TCP
64
MacOS/MacTCP
2.0.x
TCP and UDP
60
MacOS/MacTCP
X (10.5.6)
ICMP/TCP/UDP
64
NetBSD
ICMP
255
Netgear FVG318
ICMP and UDP
64
OpenBSD
2.6 & 2.7
ICMP
255
OpenVMS
07.01.2002
ICMP
255
OS/2
TCP/IP 3.0
64
OSF/1
V3.2A
TCP
60
OSF/1
V3.2A
UDP
30
Solaris
2.5.1, 2.6, 2.7, 2.8
ICMP
255
Solaris
2.8
TCP
64
Stratus
TCP_OS
ICMP
255
Stratus
TCP_OS (14.2-)
TCP and UDP
30
Stratus
TCP_OS (14.3+)
TCP and UDP
64
Stratus
STCP
ICMP/TCP/UDP
60
SunOS
4.1.3/4.1.4
TCP and UDP
60
SunOS
5.7
ICMP and TCP
255
Ultrix
V4.1/V4.2A
TCP
60
Ultrix
V4.1/V4.2A
UDP
30
Ultrix
V4.2 – 4.5
ICMP
255
VMS/Multinet
TCP and UDP
64
VMS/TCPware
TCP
60
VMS/TCPware
UDP
64
VMS/Wollongong
1.1.1.1
TCP
128
VMS/Wollongong
1.1.1.1
UDP
30
VMS/UCX
TCP and UDP
128
Windows
for Workgroups
TCP and UDP
32
Windows
95
TCP and UDP
32
Windows
98
ICMP
32
Windows
98, 98 SE
ICMP
128
Windows
98
TCP
128
Windows
NT 3.51
TCP and UDP
32
Windows
NT 4.0
TCP and UDP
128
Windows
NT 4.0 SP5-
32
Windows
NT 4.0 SP6+
128
Windows
NT 4 WRKS SP 3, SP 6a
ICMP
128
Windows
NT 4 Server SP4
ICMP
128
Windows
ME
ICMP
128
Windows
2000 pro
ICMP/TCP/UDP
128
Windows
2000 family
ICMP
128
Windows
Server 2003
128
Windows
XP
ICMP/TCP/UDP
128
IP Header Checksum Example
Since now we have enough theoretical knowledge on IP header checksum, lets take an IP header and actually try this algorithm out.
Here is a IP header from an IP packet received at destination :
4500 003c 1c46 4000 4006 b1e6 ac10 0a63 ac10 0a0c
Lets first map these values with the header
§  ’45′ corresponds to the first two fields in the header ie  ’4′ corresponds to the IP version and ’5′ corresponds to the header length. Since header length is described in 4 byte words so actual header length comes out to be 5×4=20 bytes.
§  ’00′ corresponds to TOS or the type of service. This value of TOS indicated normal operation.
§  ’003c’ corresponds to total length field of IP header. So in this case the total length of IP packet is 60.
§  ’1c46′ corresponds to the identification field.
§  ’4000′ can be divided into two bytes. These two bytes (divided into 3 bits and 13 bits respectively) correspond to the flags and fragment offset of IP header fields.
§  ’4006′ can be divided into ’40′ and ’06′. The first byte ’40′ corresponds to the TTL field and the byte ’06′ corresponds to the protocol field of the IP header. ’06′ indicates that the protocol is TCP.
§  ‘be16′ corresponds to the checksum which is set at the source end (which sent the packet). Please note that as already discussed this field will be set to zero while computing the checksum at destination end.
§  The next set of bytes ‘ac10′ and ’0a0c’ correspond to the source IP address and the destination IP address in the IP header.
So now we have a basic idea as to what these fields map to in IP header. Lets convert all these values in binary :
4500 -> 0100010100000000
003c -> 0000000000111100
1c46 -> 0001110001000110
4000 -> 0100000000000000
4006 -> 0100000000000110
0000 -> 0000000000000000 // Note that the checksum is set to zero since we are computing checksum at destination end
ac10 -> 1010110000010000
0a63 -> 0000101001100011
ac10 -> 1010110000010000
0a0c -> 0000101000001100
Now lets add these binary values one by one :
4500 -> 0100010100000000
003c -> 0000000000111100
453C -> 0100010100111100  /// First result

453C -> 0100010100111100  // First result plus next 16-bit word.
1c46 -> 0001110001000110
6182 -> 0110000110000010 // Second result.

6182 -> 0110000110000010 // Second result plus next 16-bit word.
4000 -> 0100000000000000
A182 -> 1010000110000010 // Third result.

A182 -> 1010000110000010 // Third result plus next 16-bit word.
4006 -> 0100000000000110
E188 -> 1110000110001000 // Fourth result.

E188 -> 1110000110001000 // Fourth result plus next 16-bit word.
AC10 -> 1010110000010000
18D98 -> 11000110110011000 // One odd bit (carry),  add that odd bit to the result as we need to keep the checksum in 16 bits.

18D98 -> 11000110110011000
8D99 -> 1000110110011001 // Fifth result

8D99 -> 1000110110011001 // Fifth result plus next 16-bit word.
0A63 -> 0000101001100011
97FC -> 1001011111111100 // Sixth result

97FC -> 1001011111111100  // Sixth result plus next 16-bit word.
AC10 -> 1010110000010000
1440C -> 10100010000001100 // Again a carry, so we add it (as done before)

1440C -> 10100010000001100
440D -> 0100010000001101 // This is seventh result

440D -> 0100010000001101 //Seventh result plus next 16-bit word
0A0C -> 0000101000001100
4E19 -> 0100111000011001 // Final result.
So now 0100111000011001 is our final result of summing up all the 16 bit words in the header. As a last step we just need to do a one’s compliment of it to obtain the checksum.
4E19 -> 0100111000011001
B1E6 ->1011000111100110 // CHECKSUM
Now if you compare this checksum with the one obtained in the packet you will find that both are exactly same and hence the IP header’s integrity was not lost.
So this is the way we calculate IP header checksum to check the integrity of IP header.
 why there are two length fields (IP header length, IP datagram length) in the IP header?
The size of the IP header is not fixed. Depending on the IP options present, the size of the IP header will vary. A separate field for the IP header length is added, so that the destination system can separate the IP datagram header from the payload.

Why data is send in ping packet?
To accommodate the minimum size of Ethernet frame ie 64 bytes.

Minimum ICMP size for ping packet is?
IP (20) + ICMP(12) = 32 bytes

AF (Assured forwarding)in Diffser is used most of the times.
EF (Expidet forwarding) in Diff Serv is mainly used for voice/video

In Router one interface can have multiple queues but in case of PC, one interface can have only one queue.

1. A best-effort delivery service such as IPv4 includes _______.
A)       error checking
B)       error correction
C)       datagram acknowledgment
D)      none of the above

2. In IPv4 header, an HLEN value of decimal 10 means _______.
A)       there are 10 bytes of options
B)       there are 40 bytes of options
C)       there are 10 bytes in the header
D)      there are 40 bytes in the header
3. In IPv4, what is the value of the total length field in bytes if the header is 28 bytes and the data field is 400 bytes?
A)       428
B)       407
C)       107
D)      427
4. In IPv4, what is the length of the data field given an HLEN value of 12 and total length value of 40,000?
A)       39,988
B)       40,012
C)       40,048
D)      39,952
5. An IPv4 datagram is fragmented into three smaller datagrams. Which of the following is true?
A)       The do not fragment bit is set to 1 for all three datagrams.
B)       The more fragment bit is set to 0 for all three datagrams.
C)       The identification field is the same for all three datagrams.
D)      The offset field is the same for all three datagrams.
6. In IPv4, if the fragment offset has a value of 100, it means that _______.
A)       the datagram has not been fragmented
B)       the datagram is 100 bytes in size
C)       the first byte of the datagram is byte 100
D)      the first byte of the datagram is byte 800
7. In IPv4, what is needed to determine the number of the last byte of a fragment?
A)       Identification number
B)       Offset number
C)       Total length
D)      (b) and (c)
8. The IPv4 header size _______.
A)       is 20 to 60 bytes long
B)       is always 20 bytes long
C)       is always 60 bytes long
D)      depends on the MTU
9. Which of the following is a necessary part of the IPv6 datagram?
A)       Base header
B)       Extension header
C)       Data packet from the upper layer
D)      (a) and (c)
10. In IPv6, the _______ field in the base header restricts the lifetime of a datagram.
A)       version
B)       next-header
C)       hop limit
D)      neighbor-advertisement
11. The ________ protocol is the transmission mechanism used by the TCP/IP suite.
A)       ARP
B)       IP
C)       RARP
D)      none of the above
12. IP is _________ datagram protocol.
A)       an unreliable
B)       a connectionless
C)       both a and b
D)      none of the above
13. The term ________ means that IP provides no error checking or tracking. IP assumes the unreliability of the underlying layers and does its best to get a transmission through to its destination, but with no guarantees.
A)       reliable delivery
B)       connection-oriented delivery
C)       best-effort delivery
D)      none of the above
14. In IPv4, an HLEN value of decimal 10 means _______.
A)       there are 10 bytes of options
B)       there are 40 bytes of options
C)       there are 40 bytes in the header
D)      none of the above
15. In IPv4, which field or bit value unambiguously identifies the datagram as a fragment?
A)       Do not fragment bit ? 0
B)       More Fragment bit ? 0
C)       Fragment offset = 1000
D)      none of the above
16. The IPv4 header size _______.
A)       is 20 to 60 bytes long
B)       is 20 bytes long
C)       is 60 bytes long
D)      none of the above
17. In IPv4, when a datagram is encapsulated in a frame, the total size of the datagram must be less than the _______.
A)       MUT
B)       MAT
C)       MTU
D)      none of the above
18. The IPv4 header field formerly known as the service type field is now called the _______ field.
A)       IETF
B)       checksum
C)       differentiated services
D)      none of the above
 19. In IPv6, options are inserted between the _________ and the ___________ data.
A)       base header; extension header
B)       base header; upper-layer data
C)       base header; frame header
D)      none of the above
 20. IPv6 allows _________ security provisions than IPv4.
A)       more
B)       less
C)       the same level
D)      none of the above
 21. In IPv6, when a datagram needs to be discarded in a congested network, the decision is based on the _______ field in the base header.
A)       hop limit
B)       priority
C)       next header
D)      none of the above
 22. In IPv6, the _______ field in the base header and the sender IP address combine to indicate a unique path identifier for a specific flow of data.
A)       flow label
B)       next header
C)       hop limit
D)      destination IP address

Summary:
IPv4 is an unreliable connectionless protocol responsible for source-to-destination delivery.

Packets in the IPv4 layer are called datagrams. A datagram consists of a header (20 to 60 bytes) and data. The maximum length of a datagram is 65,535 bytes.

The MTU is the maximum number of bytes that a data link protocol can encapsulate. MTUs vary from protocol to protocol.

Fragmentation is the division of a datagram into smaller units to accommodate the MTU of a data link protocol.

The IPv4 datagram header consists of a fixed, 20-byte section and a variable options section with a maximum of 40 bytes.

The options section of the IPv4 header is used for network testing and debugging. The six IPv4 options each have a specific function. They are as follows: filler between options for alignment purposes, padding, recording the route the datagram takes, selection of a mandatory route by the sender, selection of certain routers that must be visited, and recording of processing times at routers.
IPv6, the latest version of the Internet Protocol, has a 128-bit address space, a revised header format, new options, an allowance for an extension, support for resource allocation, and increased security measures.

An IPv6 datagram is composed of a base header and a payload.

Extension headers add functionality to the IPv6 datagram.

Three strategies used to handle the transition from version 4 to version 6 are dual stack, tunneling, and header translation.

http://highered.mcgraw-hill.com/sites/0072967722/student_view0/chapter_8_quiz.html












Posted by at

3 comments:

  1. AnonymousDecember 2, 2017 at 4:13 AM

    Your mode of explaining all in this article is in fact nice, every one can easily understand it, Thanks
    a lot.

    ReplyDelete
  2. Nawraj LekhakDecember 2, 2017 at 12:12 PM

    I am glad you liked it!! Thank you!!

    ReplyDelete
  3. AwaisDecember 15, 2020 at 10:13 PM

    Sir can you upload most repeated mcqs of computer on your site it will be nice of you..

    ReplyDelete

Subscribe to: Post Comments (Atom)