ICMP Messages
ICMP Unreachable Messages
Resources
Web Links:
RFC Lists:
- Host
Implementation
792
1122
- Router
Implementation - Recommended reading
1191 - Concerning
PMTUD
1435 - Concerning
PMTUD
1812
1940
2003
ICMP unreachable
messages (Type 3) are control messages generated by network devices
to alert the source host that a destination unicast address is
unreachable. Wikipedia has a great table detailing all the different
ICMP Type/Codes. ICMP unreachable messages can be generated for
networks, hosts, ports or even protocols. Code identifies the
destination for which the message is generated.
Information
contained in ICMP unreachable message:
- The first 8 bytes
of the original datagram. It is assumed that there will be enough
information in the first 64 bits of a datagram (packet for example)
will contain enough information for the sending host to identify the
process/application generating the flow.
Common reasons why
ICMP unreachable can be sent
- A routing device
does not have a destination network to route in which to route the
packet, or the distance to the network is infinity. (Type 3, Code 0)
- If a gateway
device can determine if the destination host is unreachable (Type 3,
Code 1)
- If the port or
protocol is not configured/enabled on the destination host, the
destination host can send the ICMP unreachable (Type3, Code 2 or 3)
- If a datagram must
be fragmented, due to MTU for example, yet the DF (Don't Fragment)
bit is set. (Type 3, Code 4)
RFC 1191 specifies
how ICMP unreachable message (Type 3, Code 4 messages specifically)
facilitate PMTUD.
- When a router
drops a packet because fragmentation is needed, but DF bit set, the
router responds with an ICMP T3,C4 indicating "fragmentation
needed and DF set". The router must included the MTU of the
next-hop network in the low-order 16 bits of the ICMP header filed
labeled "unused". The high-order 16 bits must be set to 0.
Disabling ICMP
unreachable messages can have negative effects, such as PMTUD process
failing. It is recommended to leave ICMP unreachable messages enabled
in most cases.
ICMP Redirect Messages
Web Links:
ICMP redirect
messages (Type 5) are used to notify a host to send data packets to a
better, alternate route. ICMP redirect messages are used by gateway
devices to let a host know to send traffic to an alternate gateway.
The gateway that sent the ICMP redirect does go ahead and forward the
datagram.
Sending ICMP
redirects can be exploited by an attacker to perform network
reconnaissance or DoS attacks. For this reason, ICMP redirect message
should be, in most cases, disabled on routed interfaces.
Routers MUST NOT
generate a Redirect Message unless all the following conditions are
met:
- The packet is
being forwarded out the same physical interface that it was received
from.
- The IP source
address in the packet is on the same Logical IP (sub)network as the
next-hop IP address.
- The packet does
not contain an IP source route option.IP Header Options Field
IPv4 Options
Web Links:
IPv4 header is
consists of 14 fields, only 13 of which are required. The 14th field,
the "options" field, is optional. A standard IPv4 header is
20 bytes in length without any additional options.
Important IPv4
Header Fields:
- Version
- IHL (Internet
Header Length, including any options. Without options the header is
20 bytes long. With max options 60 bytes long)
- DSCP (Formerly ToS
field)
- Length (of the
entire packet, including payload)
- Flags (DF bit is
here)
- TTL (Ninth byte)
- Protocol
(Identifies payload protocol, TCP or UDP for example)
- Source IP address
- Destination IP
address
- Options field
follows
It is important to
point out that switches/routers cannot CEF switch a packet with any
IP options defined. This means that all of these packets will be
punted to the CPU. A device can be configured to drop all options
packets with the global command: ip options drop.
IPv6 Extensions
Web Links:
IPv6 extension
headers fill a similar function to IPv4 options. Unlike IPv4 options,
there are well defined IPv6 extensions. Wikipedia offers a great
write-up on important extensions. IPv6 headers are built in 8 byte
chunks. If a node does not recognize a specific extension in a
packet, that packet should be discarded with an ICMPv6 type 4, code 1
(Parameter Problem) message in return.
= Type 0 -
Hop-by-Hop
This extension
signifies that the packet should be examined by all nodes along a
path, including the source and destination of the packet.
= Type 60 -
Destination Options (can appear twice for different scenarios. Before
routing header and before upper-layer header)
Signifies that only
the destination care to examine the optional
= Type 43 - Routing
Used to specify
the route for a datagram
Can direct a packet
to one or more intermediate nodes before sending to destination
There are different
routing types, 0-2.
= 0 could result
in a DoS so the header is deprecated and devices are required to
ignore
= 1 Used for
Nimrod
= 2 Limited
version of type 0 and used for mobile IPv6. Hold "Home Address"
of mobile node
= Type 44 - Fragment
Contains parameters
for fragmentation
Carries information
necessary to reassemble the original packet
= Type 51 -
Authentication Header (AH)
Contains
information used to verify the authenticity of most of the packet
https://en.wikipedia.org/wiki/IPsec#Authentication_Header
Used with IPsec.
Protects most of the base header, AH and the rest of the packet. Does
not protect DSCP, ECN, Flow Label and Hop Limit headers.
Can also be used by
other protocols, such as OSPFv3, to provide authentication
= Type 50 -
Encapsulating Security Payload (ESP)
Carries encrypted
data for secure communication
Used with IPsec.
Protects most of the base header, AH and the rest of the packet. Does
not protect DSCP, ECN, Flow Label and Hop Limit headers.
Can also be used by
other protocols, such as OSPFv3, to provide encryption
= Type 135 -
Mobility
Used with IPv6
mobility
= Type 59 - No next
header
Says that this is
the end of the packet. No data what so ever should follow.
IP Fragmentation
IPv4 Fragmentation
Web
Links:
IPv4
fragmentation occurs when a packet larger than the MTU of a network
in which it needs to be forwarded (and DF bit is 0/not set), the
sending device is forced to fragment the packet. This function will
need to be punted to the CPU.
Fragmentation
is done by dividing the packet into smaller packets, each with its
own IP header with copies of all the original information. The max
size of which is the MTU minus 20 bytes (the length of the IP header,
longer if options fields are present). Even fragmented packets can be
fragmented again.
-
The total length field of each fragment needs to be updated to
reflect the new packet
-
The MF (More Fragments) field of every packet, save the last, is set
to 1. The last is set to 0.
-
The fragment offset field is set so that all packets can be
reassembled.
-
Just like the total length field, header checksums have to be
recomputed.
The
destination knows that a packet has been fragmented because:
-
The MF field is set to 1
-
There is a fragment offset value
*
All fragmented packets will have at least one of these values set, on
the first and last packet fragment will have a non-value in one of
the fields.
The
destination can then use the source/destination and fragment
information (MF and fragment offset) in the IP header to reassemble
the original packet.
Web Links:
https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation
Unlike IPv4, IPv6 does not allow the fragmentation of IP datagrams by routers. Instead, the router must drop the packet and respond with an ICMPv6 type 2, code 0 (Packet to Big message). This is similar in function to an IPv4 ICMP type 3, code 4 message and used for IPv6 PMTUD.
IPv6 end nodes are expected to perform PMTUD and applications to use this information to limit packet size. If an application cannot limit the size of packets sent, the sending node can use the IPv6 fragment extension header and, using PMTUD information, push packet fragmentation down to the TCP\IP stack. Of note, a network must be capable of delivering a packet of at least 1280 bytes without fragmentation.
Similar to IPv4, a fragmented packet contains the same IPv6 header information, including Routing or Hop-by-hop extension headers (other extension headers are only found in the first packet fragment); as well as fragmentable portions of the original packet. These packets, similar to IPv4 are identified by a Fragment Offset. The Fragment extension header is 8 bytes (64 bits) in length. Again like IPv4, the first packet fragment has its Fragment Offset value set to 0. The fragment information is found in the Fragment extension header, value 44. Again like IPv4, all packet fragments, save the last, have a MF value set to 1.
The receiving host can use the information contained in the Fragment extension to reassemble the packet. Of note, the destination node will discard the Fragment extensions upon reassembly. If a host does not receive all the fragments in 60 seconds, all fragmented packets (included those not received) will be dropped. An ICMPv6 Type 3, code 1 (Time Exceeded) message well be send to the sending host for notification.
Sending hosts should also take care to ensure that all fragments contain up to 1500 bytes. Hosts can send more data in a fragment, but should be confident that the destination can receive larger packets.
https://en.wikipedia.org/wiki/Time_to_live#IP_packets
IPv4 and IPv6 have similar TTL mechanisms.
- IPv4 - TTL field
- IPv6 - Hop Limit field
Both fields are 8 bits in length, giving a max numarical value of 255. A sender can specifiy whatever it likes in the TTL field. By rule each time a device forwards a packet along, it decrements the TTL (similar to a timer). If a device receives a packet with the TTL value at 0, it will drop the packet and respond with an ICMP type 11, code 0 (TTL Expired in transit) or ICMPv3 type 3, code 0 (hop limit exceeded in transit). Trace route uses these message to trace a path from host to destination.
IP MTU
Web Links:
http://packetlife.net/blog/2008/nov/5/mtu-manipulation/
http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html
MTU is the maximum length of data that can be transmitted by a protocol at one time. Ethernet, for example, has a default MTU of 1500 byte frame (not including the header or trailer). The MTU and IP MTU of an interface are actually different, one referring to Ethernet (MTU) and the other referring to IP (IP MTU).
IP MTU minimum values:
- IPv4 - 576 bytes
- IPv6 - 1280 bytes
Reference for IP header size:
- IPv4 - 20 bytes (no options)
- IPv4 - 60 bytes (max size)
- IPv6 - 40 byte (Fixed)
- Extension headers will be found before payload and take up space there.
IPv6 Fragmentation
Web Links:
https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation
Unlike IPv4, IPv6 does not allow the fragmentation of IP datagrams by routers. Instead, the router must drop the packet and respond with an ICMPv6 type 2, code 0 (Packet to Big message). This is similar in function to an IPv4 ICMP type 3, code 4 message and used for IPv6 PMTUD.
IPv6 end nodes are expected to perform PMTUD and applications to use this information to limit packet size. If an application cannot limit the size of packets sent, the sending node can use the IPv6 fragment extension header and, using PMTUD information, push packet fragmentation down to the TCP\IP stack. Of note, a network must be capable of delivering a packet of at least 1280 bytes without fragmentation.
Similar to IPv4, a fragmented packet contains the same IPv6 header information, including Routing or Hop-by-hop extension headers (other extension headers are only found in the first packet fragment); as well as fragmentable portions of the original packet. These packets, similar to IPv4 are identified by a Fragment Offset. The Fragment extension header is 8 bytes (64 bits) in length. Again like IPv4, the first packet fragment has its Fragment Offset value set to 0. The fragment information is found in the Fragment extension header, value 44. Again like IPv4, all packet fragments, save the last, have a MF value set to 1.
The receiving host can use the information contained in the Fragment extension to reassemble the packet. Of note, the destination node will discard the Fragment extensions upon reassembly. If a host does not receive all the fragments in 60 seconds, all fragmented packets (included those not received) will be dropped. An ICMPv6 Type 3, code 1 (Time Exceeded) message well be send to the sending host for notification.
Sending hosts should also take care to ensure that all fragments contain up to 1500 bytes. Hosts can send more data in a fragment, but should be confident that the destination can receive larger packets.
TTL
Web Links:https://en.wikipedia.org/wiki/Time_to_live#IP_packets
IPv4 and IPv6 have similar TTL mechanisms.
- IPv4 - TTL field
- IPv6 - Hop Limit field
Both fields are 8 bits in length, giving a max numarical value of 255. A sender can specifiy whatever it likes in the TTL field. By rule each time a device forwards a packet along, it decrements the TTL (similar to a timer). If a device receives a packet with the TTL value at 0, it will drop the packet and respond with an ICMP type 11, code 0 (TTL Expired in transit) or ICMPv3 type 3, code 0 (hop limit exceeded in transit). Trace route uses these message to trace a path from host to destination.
IP MTU
Web Links:
http://packetlife.net/blog/2008/nov/5/mtu-manipulation/
http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html
MTU is the maximum length of data that can be transmitted by a protocol at one time. Ethernet, for example, has a default MTU of 1500 byte frame (not including the header or trailer). The MTU and IP MTU of an interface are actually different, one referring to Ethernet (MTU) and the other referring to IP (IP MTU).
IP MTU minimum values:
- IPv4 - 576 bytes
- IPv6 - 1280 bytes
Reference for IP header size:
- IPv4 - 20 bytes (no options)
- IPv4 - 60 bytes (max size)
- IPv6 - 40 byte (Fixed)
- Extension headers will be found before payload and take up space there.
