| Home |
| Misc |
| Linux |
| TCP/IP |
| Windows |
| Random Daodejing |
| Photos |
TCP/IP Notes
Intro / Network Addressing / Network Addressing IPv6 / Packet Headers / Networking and Data Link Layers / Transport Layer Protocols / Application Layer Protocols / IP Routing / ICMP / DHCP / Name Resolution and DNS / Security
ICMP
Internet Control Message Protocol (ICMP) provides error handling and data handling control, forming an important part of the Network layer. It provides information about network connectivity and routing behavior which unreliable protocols at this stage within the TCP/IP stack are unable to (e.g., IP), which makes this protocol suitable for diagnosis and repairing problems. When analyzing how packets move from source to destination within a network via forwarding nodes ("reachability"), ICMP can be used to return information to the sending host about the routes traveled, as well as delivery error reports.
At its base, ICMP messages are specially formatted IP datagrams, subject to the same conditions as other packets within network traffic. As ICMP does not inherently improve upon IP's 'best effort' approach, IP hosts can receive ICMP messages providing useful and important information which the hosts can then act upon. The content of these messages indicate network congestion problems and other issues, ultimately serving to supply the best path info in terms of how packets can be sent from IP hosts. For example, when an IP datagram doesn't reach its destination, an ICMP message can alert the sender, and when a gateway or router can direct the host to use a better (shorter) route it will send a redirect message.
Message Types
--------------------
- IP routing behavior
- Reachability (packet forwarding)
- Routes between hosts
- Delivery errors
- Network health
- Delivery errors
- Path discovery
- Path Maximum Transmission Unit (MTU) Discovery
Not all of these are mutually exclusive, as at its root multiple forms of information coming from ICMP messages can be used for network troubleshooting. The basic message types form the foundation upon which troubleshooting can occur.
Echo/Echo Reply - Functionality for reachability utilities such as Ping and Traceroute; Used for installing, configuring and troubleshooting networks.
Destination Unreachable - Routing or delivery errors preventing IP datagrams from reaching intended destinations, and also used for Path MTU Discovery between pairs of hosts.
Source Quench - Allows gateway to instruct sending host to lower its sending rate to lessen network congestion problems.
Redirect - Allows a router or gateway to redirect traffic to use a more optimal route between sender and receiver.
Router Advertisement - Allows host to request information about local routers, permits routers to advertise existence on a IP host.
Time Exceeded - Indicates IP datagram TTL has expired; This can show a TTL which is too short or a routing loop problem.
Parameter Problem - Indicates error has occurred while processing IP header of incoming datagram.
ICMPv4
----------
ICMP is a core protocol of the IP suite, originally specified in 1981 in RFC 777, which became obsoleted by RFC 792 (https://tools.ietf.org/html/rfc792). The most basic form of ICMP visible to many users is the Ping tool (https://ss64.com/bash/ping.html) used to test connections between hosts. Although ICMP may appear to be a Transport Layer protocol, it itself does not carry any payload data, instead relying upon a series of network testing and error messages to provide tools which can be used to diagnose network problems. The Tracert/Traceroute tool is equally widely utilized (https://ss64.com/bash/traceroute.html) to trace an IP packet from source to destination while counting the number of hops and the time required for each hop.
RFC 792, "Internet Control Message Protocol" defines all valid ICMP messages, and also the relationship between ICMP and IP:
- ICMP provides a mechanism for gateways/routers/destination hosts to communicate with source hosts.
- ICMP messages are specially formatted IP datagrams with associated message types and codes.
- ICMP is a required component of TCP/IP.
- ICMP only reports errors about non-ICMP IP datagrams. In other words, ICMP is not self-referential.
ICMPv4 Header
--------------------
Within the IPv4 header, the protocol field value of "1" indicates that the ICMP header follows the IP header:
ICMP headers can be divided into two functional units: constant and variable.
Constant Fields
--------------------
After the IP header, ICMP packets contain only three required fields: Type, Code, and Checksum. In some packets, additional fields can provide information or details about the message (e.g., redirect packet must include the address of the gateway).
The Type field indicates types of ICMP messages which can be sent. A list of numbers corresponding to message types can be found at https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml. Not all messages are currently in general use, some are experimental and some are still in development.
The Code field codes and definitions are based on packet types.
The Checksum field provides error detection for the ICMP header.
Types of ICMPv4 Messages
------------------------------------
The ICMP message types can be categorized between error and informational. The error messages are used by source routers and nodes to communicate that the transmitted datagram has a problem with the network, and generally requires a response:
Destination Unreachable - Returned to sender when packet can not be delivered, includes portion of the datagram.
Source Quench - Instructs source node to reduce rate of speed at which it transmits packets to the destination node; The receiving node will slow transmission rate until the message stops.
Time Exceeded - There are two situations: when a packet's TTL field is 0 (routing loop), or when fragments are not complete.
Timestamp Request/Reply - Used by routers to synchronize system clock for date/time. Not recommended on large networks; NTP is generally used instead.
Router Advertisement/Solicitation - Allows host not manually configured with the address of the first router to request and receive information about routers on the network. The Solicitation message uses the multicast address of 224.0.0.2, and is considered optional, as DHCP can be used for this purpose.
Address Mask Request/Reply - Supplies subnet mask information about other hosts on the network to host sending the request. Routers do not generally advertise subnet information, but rather transmit subnet data in response to a request. Considered optional via DHCP.
Traceroute - Similar to Echo request/reply but also traces the sequence of hops. In Windows, the Tracert tool is used, and traceroute on Unix-like systems.
Variable ICMP Structures and Functions - Some packets must send specific information (e.g. ICMP Redirect).
Types 0 and 8: Echo Reply/Request (http://www.networksorcery.com/enp/protocol/icmp/msg8.htm) - Type 0 is used for Echo Reply and Type 8 is used for Echo Request. Both packets share the same structure.
An "identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each Echo Request sent. The echoer returns these same values in the Echo Reply" (RFC 792).
Windows Server 2008/Vista/7 ping packets have the following profile:
- Identifier field is set to 512 decimal (0x200).
- On the first echo sent, the Sequence Number field value is set to a multiple of 512 decimal, with each subsequent echo incremented by 256 decimal (02100).
- Data field value = abcdefghijklmnopqrstuvwabcdefghi.
Type 3: Destination Unreachable Packets (http://www.networksorcery.com/enp/protocol/icmp/msg3.htm) - Can indicate configuration or service fault within the network.
The host that sends the Destination Unreachable packet returns the IP header and 8 bytes of the original datagram.
A total of 16 (0-15) possible codes are currently assigned to the ICMP Destination Unreachable type number, as defined in RFC 1812 (https://tools.ietf.org/html/rfc1812).
Hexadecimal Decimal Description
---------------------------------------------------------------------------
0x00 0 Network Unreachable - Generated by a router if a forwarding path
(route) to the destination network is not available.
0x01 1 Host Unreachable - Generated by a router if a forwarding path
(route) to the destination host on a directly connected network
is not available (does not respond to ARP).
0x02 2 Protocol Unreachable - Generated if the transport protocol
designated in a datagram is not supported in the transport layer
of the final destination.
0x03 3 Port Unreachable - Generated if the designated transport protocol
(e.g., UDP) is unable to demultiplex the datagram in the
transport layer of the final destination but has no protocol
mechanism to inform the sender.
0x04 4 Fragmentation Needed and DF Set - Generated if a router needs to
fragment a datagram but cannot since the DF flag is set.
0x05 5 Source Route Failed - Generated if a router cannot forward a
packet to the next hop in a source route option.
0x06 6 Destination Network Unknown - This code SHOULD NOT be generated
since it would imply on the part of the router that the
destination network does not exist (net unreachable code 0
SHOULD be used in place of code 6).
0x07 7 Destination Host Unknown - Generated only when a router can
determine (from link layer advice) that the destination host
does not exist.
0x0B 11 Network Unreachable For Type Of Service - Generated by a router
if a forwarding path (route) to the destination network with the
requested or default TOS is not available.
0x0C 12 Host Unreachable For Type Of Service - Generated if a router
cannot forward a packet because its route(s) to the destination
do not match either the TOS requested in the datagram or the
default TOS (0).
0x0D 13 Communication Administratively Prohibited - Generated if a
router cannot forward a packet due to administrative filtering.
0x0E 14 Host Precedence Violation. Sent by the first hop router to a
host to indicate that a requested precedence is not permitted
for the particular combination of source/destination host or
network, upper layer protocol, and source/destination port.
0x0F 15 Precedence cutoff in effect. The network operators have imposed
a minimum level of precedence required for operation. The
datagram was sent with a precedence below this level.
Type 4: Source Quench - Used as a way to indicate that router/host is becoming congested or overloaded.
A RFC in May of 2012 (https://tools.ietf.org/html/rfc6633) formally deprecates reaction to Source Quench messages via Transport protocols:
"The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant as a mechanism for
congestion control. ICMP Source Quench has been known to be an
ineffective (and unfair) antidote for congestion, and generation of
ICMP Source Quench messages by routers has been formally deprecated
by [RFC1812] since 1995. However, reaction to ICMP Source Quench
messages in transport protocols has never been formally deprecated.
This document formally deprecates reaction to ICMP Source Quench
messages by transport protocols such as TCP [RFC0793], formally
updating [RFC0792], [RFC1122], and [RFC1812]. Additionally, it
provides a recommendation against the implementation of [RFC1016].
The rationale for these specification updates is as follows:
o Processing of ICMP Source Quench messages by routers has been
deprecated for nearly 17 years [RFC1812].
o Virtually all popular host implementations have removed support
for ICMP Source Quench messages since (at least) 2005 [RFC5927].
o Widespread deployment of ICMP filtering makes it impossible to
rely on ICMP Source Quench messages for congestion control.
o The IETF has moved away from ICMP Source Quench messages for
congestion control (e.g., note the development of Explicit
Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6
[RFC4443] does not even specify a Source Quench message)."
Type 5: Redirect (http://www.networksorcery.com/enp/protocol/icmp/msg5.htm) - Router sends redirect messages to host indicating a preferable route exists. There are however several security vulnerabilities inherent (see Further Reading). Ideally clients should update their routing tables with the optimal paths. Four codes define whether an ICMP Redirect packet contains a new route (routers alone cannot determine which portion of a destination address is network and which is host).
Code 0 - Redirect Datagram for the Network (or Subnet) - Router sends this message to indicate there is a better way to reach the desired network.
Code 1 - Redirect Datagram for the Host - Router sends this message to indicate there is a better way to reach the desired host. Most common seen on networks.
Code 2 - Redirect Datagram for the Type of Service and Network - Router can send this message to indicate there is a better way to reach the desired network using the desired TOS.
Code 3 - Redirect Datagram for the Type of Service and Host - Router can send this message to indicate there is a better way to reach the destination host using the requested TOS.
Types 9 and 10: Router Advertisement/Solicitation (http://www.networksorcery.com/enp/protocol/icmp/msg9.htm & http://www.networksorcery.com/enp/protocol/icmp/msg10.htm) - Hosts send Solicitation packets, and routers respond with Advertisement packets.
Some packets are addressed to the 'all router' multicast address of 224.0.0.2 by default, and hosts may be configured to send packets to the broadcast address. Advertisement packets contain the following fields after he Checksum:
# of Addresses - Number of router addresses advertised in packet.
Address Size - The number of 4 byte increments used to define each router address advertised (2(2+2+4 bytes)).
Lifetime - Maximum number of seconds router information is considered valid.
Router Address 1 - Sending router local IP address.
Precedence Level 1 - Preference value of each router address advertised (higher value indicates greater preferences). May be configured at router to make one of out others the default gateway.
Router Address 2/Precedence Level 2 - Additional router addresses and precedence levels.
Type 11: Time Exceeded (http://www.networksorcery.com/enp/protocol/icmp/msg11.htm) - Sent by routers (TTL exceeded in transit) or hosts (Fragment Reassembly Time Exceeded).
Code 0 Time to Live Exceeded in Transit - Router sends this message to indicate that a packet arrived with a TTL value of 1 (routers cannot decrement TTL value to 0 and forward it, so the packet is discarded and this message is sent).
Code 1 Fragment Reassembly Time Exceeded - Sent by host when it does not receive all fragment parts before expiration (in seconds of holding time) of the TTL value of the first fragment received; Causes original packet to be resent.
Type 12: Parameter Problem (http://www.networksorcery.com/enp/protocol/icmp/msg12.htm) - Indicates problems not covered by other ICMP error messages. Packet structure contains Codes 0, 1 or 2:
Code 0 Pointer Indicates Error - Includes Pointer field that shows where in the returned IP header and datagram the error occurred.
Code 1 Missing a Required Option - Indicates that the sender expected additional information in the Option field of the original packet.
Code 2 Bad Length - Indicates original packet structure had an invalid length.
Types 13 and 14: Timestamp Request/Reply (http://www.networksorcery.com/enp/protocol/icmp/msg13.htm & http://www.networksorcery.com/enp/protocol/icmp/msg14.htm) - Defined as a method for one IP host to obtain current time, returned as the number of milliseconds since midnight Universal Time (UT). Both packets share the same structure:
The requester uses the current send time in the Originate Timestamp field, and the receiver uses its current time value in the Receive Timestamp field. At the moment the receiver sends the message back to the requester the current Timestamp is placed in the Transit Timestamp field. Other protocols such as Network Time Protocol (NTP) provide a more functional method for time synchronization.
Types 15 and 16: Information Request/Reply (http://www.networksorcery.com/enp/protocol/icmp/msg15.htm & http://www.networksorcery.com/enp/protocol/icmp/msg16.htm) - Provides a way for the host to find out what network it is on. Both packets share the same structure and are similar to Echo Request/Reply. The host sends Information Request packet and leaves the source and destination IP address fields set to 0; The destination hardware address is broadcast. The router replies using the Information Reply packet.
Types 17 and 18: Address Mask Request/Reply (http://www.networksorcery.com/enp/protocol/icmp/msg17.htm & http://www.networksorcery.com/enp/protocol/icmp/msg18.htm) - Enables the host to determine network mask information, both packets share the same structure:
Type 30: Traceroute (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm) - Documented in RFC 1393 (https://tools.ietf.org/html/rfc1393) but not in use because it requires functionality in routers. Process requires hosts to send IP packet with the IP Traceroute Option to destination, and destination sends IP Traceroute Option Reply packet. While in transit routers are set to send ICMP Traceroute Return packets to the host containing information from IP Traceroute Option Outbound and Return packets.
The Outbound Hop Count field indicates the hop count from the outbound IP Traceroute Option packet, and the Return Hop Count field contains the value from the return IP Traceroute Option packet. Output Link Speed indicates the speed at which the packet is sent between links in bytes per second. The Outbound Link MTU is the MTU size of the link over which the IP Traceroute Option Outbound/Return packet is next sent.
ICMPv6
----------
In IPv6, ICMPv6 provides the same basic mechanism for error reporting and information. As the original IPv4 ICMP specifications are more than 30 years old, the new version of ICMP is seen as required for modern networking messaging requirements. While the two main groups of messages between error and informational have not changed, the message types have changed.
ICMPv6 was originally specified in RFC 1885 which was then obsoleted by RFC 2463 (https://tools.ietf.org/html/rfc2463). A more current specification is RFC 4443 (https://tools.ietf.org/html/rfc4443), "Internet Control Message Protocol (ICMPv6) for Internet Protocol Version 6 (IPv6) Specification." Not all message types are documented in this RFC (some are found in RFC 4861: https://tools.ietf.org/html/rfc4861, and others are found elsewhere).
The current list of message types for ICMPv6 can be found at: https://www.iana.org/assignments/icmpv6-parameters.
There is a general packet structure for ICMPv6 messages, but some my have their own unique formatting. A IPv6 header and possibly one or more extension headers will come before the ICMPv6 message. The Next Header value for the ICMPv6 header is 58.
The value within the Type field can determine the formatting of the remaining structure. The Code field contains the value of the message type, and the contents of the Message body depend on message type.
ICMPv6 Error Messages
--------------------------------
Values for error messages fall between 0 and 127 as defined in RFC 4443. Common messages include Destination Unreachable, Packet Too Big, Time Exceeded and Parameter Problem, while others are unassigned, reserved or set aside (experimental).
Destination Unreachable - As with IPv4, IPv6 is unreliable. Therefore as with ICMPv4 Destination Unreachable messages, ICMPv6 uses the same idea to allow routers to inform source nodes of a problem with packets not reaching their intended destinations. When the source node receives this message it determines what to issue as a response. The header includes TYPE, CODE, CHECKSUM and an UNUSED portion which is set to 0 by the source node and ignored by the destination node. Below this is as much of the invoking packet as possible without exceeding the minimum IPv6 MTU:
Type - 1
Code 0 - No route to destination.
Code 1 - Communication with destination prohibited.
Code 2 - Beyond scope of source address.
Code 3 - Address unreachable.
Code 4 - Port unreachable.
Code 5 - Source address failed ingress/egress policy.
Code 6 - Reject route to destination.
Destination Unreachable messages are typically sent by the router or the IPv6 layer of the source node for any reason other than network congestion.
Packet Too Big - Required due to how IPv6 handles data fragmentation and reassembly. IPv6 routers don't fragment packets to accommodate link MTU between hops. Instead source nodes use Path MTU (PMTU) Discovery to determine the smallest MTU size for all links between source and destination. If the route changes after the initial discovery and a link MTU is found to be smaller than the packet MTU sent, the router will drop the packet and issue this error message to the source node, which then modifies the MTU to fit the smaller link MTU for resending.
Type - 2
The format is the same as the previous message, with the exception that the Unused field in the Destination Unreachable message is the MTU field in the Packet Too Big message:
This can be sent in response to a IPv6 multicast destination address or link layer multicast or broadcast address, but usually ICMPv6 messages are only sent in response to IPv6 unicast.
Time Exceeded - Similar to ICMPv4, the format is the same as Destination Unreachable.
Type - 3
Code 0 - Hop limit exceeded in transit (common reason = routing loop).
Code 1 - Fragment reassembly time exceeded.
Parameter Problem - Similar to ICMPv4 in that these are considered "generic" error messages. The format is identical to Destination Unreachable except that the Unused field becomes the Pointer field to show where the error occurred.
Type - 4
Code 0 - Erroneous header.
Code 1 - Unrecognized Next Header type.
Code 2 - Unrecognized IPv6 options.
ICMPv6 Informational Messages
-------------------------------------------
These exist in the 128-255 range and are specified in multiple RFC documents. Common messages include Echo Request/Reply, Router Advertisement/Solicitation, Neighbor Advertisement/Solicitation, Redirect and Router Renumbering. As with ICMPv4 informational messages, these are used to provide diagnostic information. Depending on message type they can include mandatory, recommended and optional parameters.
Echo Request/Reply - Similar to ICMPv4. Each IPv6 network node is required to implement a ICMPv6 Echo responder function to accept Request messages and issue Reply messages.
Type - 128 (request)/129 (reply)
Code - 0
Identifier - Matches Replies to Requests and for Echo Replies is the identifier from invoking Request.
Sequence Number - Same as above, used for matching.
The Data field may consist of 0 or more octets of arbitrary data (data for Reply messages is from the invoking Request message). The source address of an Echo Reply message sent in response to a unicast Echo Request message is the same as the destination address of the Echo Request message.
Router Advertisement/Solicitation - Specified in RFC 4861 (https://tools.ietf.org/html/rfc4861), "Neighbor Discovery for IP version 6 (IPv6)". These messages function in the same way as in ICMPv4 except that the router discovery function has been built into the Neighbor Discovery (ND) protocol. The format for Solicitation and Advertisement messages are not the same.
Type - 133
Code - 0
Checksum - Specified for ICMPv6 messages.
Reserved - Set to 0 by the source node and ignored by destination mode.
Options - The source link layer address is the only valid option as specified by RFC 4861; future versions may define new valid options.
Router Advertisement:
Type - 134
Code - 0
Checksum - Specified for ICMPv6 messages.
Cur Hop Limit - Unsigned 8 bit integer. The default value should be the IPv6 packet's Hop Count field for outgoing packets. If unspecified by the router it is set to 0.
M Flag - 1 bit "managed address configuration" flag, set to indicate that all addresses are available through DHCPv6. If the M flag is set, the O flag becomes redundant.
O Flag - 1 bit "other configuration" flag, indicates that other configuration information is available via DHCPv6 (DNS, other server info).
Reserved - 6 bit unused field set to 0.
Router Lifetime - 16 bit unsigned integer, indicates lifetime of default router in seconds. Maximum value of 65535, but sender often limits this rule to 9000. A value of 0 indicates that the router is not the default router.
Reachable Time - 32 bit unsigned integer, time in milliseconds that a node assumes a neighbor is reachable after receiving reachability confirmation. If the value is 0, the reachable time is unspecified by the router.
Retrans Timer - 32 bit unsigned integer, time in milliseconds between retransmitted Neighbor Solicitation message. If the value is 0, the retrans time is unspecified by the router.
Options - Available options include source link layer address, MTU, and Prefix information.
Router Solicitation messages are typically sent to the IPv6 multicast address for "all routers" (ff02::2). Router Advertisement messages are sent to the IPv6 multicast address for "all nodes" on the local link (ff02::1). A Router Advertisement message sent in response to a Solicitation message is sent as unicast.
Neighbor Solicitation/Advertisement - Specified in RFC 4861 and part of the IPv6 Neighbor Discovery (ND) protocol. Neighbor Solicitation messages are sent to request the link layer address of a target node and simultaneously send the target node its own link layer address, but are sent multicast when the node needs to resolve a neighbor address and sent unicast when the node needs to verify reachability.
The Target Address field denotes the IPv6 address of the target node for the solicitation message and cannot be a multicast address. The only possible option is the source link layer address which is not added when unspecified, but must be included in all unicast and multicast solicitations.
The Neighbor Advertisement message can also send unsolicited messages to propagate network information, and is sent multicast to "all nodes." The format is similar to Solicitation except in the Reserved field where there are three possible flags:
R Flag - Router flag, indicates that the sender is a router and used typically for Neighbor Unreachability Detection.
S Flag - Solicited flag, indicates that advertisement was sent in response to solicitation message from the destination address. Used for reachability verification .
O Flag - Override flag, indicates that the advertisement should override an existing cache entry and update link-layer address.
In the current implementation the only possible Option is the target link-layer address/source node address, which is set on link layers when responding to multicast solicitations.
Redirect Messages - Specified in RFC 4861, provides information to a network node specifying the need to change routers within the local link (used on networks with more than one local router). An example might be one router which is used as a gateway to the Internet and another to send traffic to other internal networks on different local links. When a node sends a packet to the gateway as default but the destination address indicates an internal location from another local link, the gateway router forwards the packet to the other router and send a Redirect message to the source node.
The message structure is similar to the previous example. The Target Address is the IPv6 address of the default router the host is using to forward its traffic to the destination, and can contain the same address as the Destination Address field if the target is considered the endpoint. If the target is a router, the field contains the link-local address of the router.
Router Renumbering Messages - Specified in RFC 2894 (https://tools.ietf.org/html/rfc2894), allows address prefixes on routers to be configured with ND and address autoconfiguration.
Three types of Router Renumbering messages include:
Commands - Sent to routers, code value of 0.
Results - Responses sent by routers, code value of 1.
Sequence Number Reset - Used to cancel cryptographic keys, code value of 255.
Each message type has a different value in the ICMPv6 header Code field and within the Message Body field.
The SequenceNumber field is an unsigned 32 bit sequence number which must be non-decreasing between Sequence Number Resets. The SegmentNumber is an unsigned 8 bit field containing the values for different types of Router Renumbering messages having the same SequenceNumber value.
Flags:
T - Test command
R - Result requested
A - All interfaces
S - Site specific
P - Processed previously
MaxDelay - Unsigned 16 bit, specified maximum amount of time in milliseconds that a router must delay sending reply to a command message.
Reserved - Set to 0.
ICMPv4 and ICMPv6 share the same functions, but ICMPv6 provides added functionality. In addition to connectivity, error-checking, informational messages and fragmentation, ICMPv6 also includes messages related to address assignment, address resolution, multicast group management, and mobile IPv6 support.
Path MTU Discovery
--------------------------
In IPv4 networks Path MTU Discovery allows routers to notify hosts through ICMPv4 messages if a change in the MTU size of packets is needed. Each PMTU is composed of the links between sender and receiver, and each link can have a different MTU size. The PMTU is the size of the smallest MTU for an individual link. In IPv6 MTU sizing and fragmentation has been updated to improve efficiency, first by establishing default packet MTU size from 576 to 1280 bytes, and through the ability to reduce or eliminate fragmenting when possible while allowing the largest MTU size possible. Source nodes in IPv6 can use PMTU to become aware of the smallest link MTU to adjust their own packet MTU, although this is not perfect as MTU sizes can switch across links if a route changes during transit.
Path MTU Discovery is documented in RFC 1191 (https://tools.ietf.org/html/rfc1191) as a way other than fragmenting to learn a currently supported MTU across a network path. Using this method, the host sets the DF flag in the IP packet header to 1, under which receiving routers may discard the message if too large (e.g., Fragmentation Needed or Packet Too Big). PMTU-capable routers can include the MTU of the restricting link (link which does not support forwarding based on current packet format and configuration) in the ICMP reply. A PMTU host upon receiving a "Fragmentation Needed" or "Don't Fragment was Set" ICMP reply must either reduce the MTU size of the message or remove the DF flag in the IP header. As each router further along the path sends these messages back to the source an end-to-end minimum MTU size is discovered.
ICMPv4 Security Issues
-------------------------------
Use of ICMP tools is often the first step toward a network break-in, as these tools provide a way to learn about a network including configuration and connectivity status. By address scanning to see which hosts on a network are available and pinging each host to note the response, port scanning can then be used on hosts considered valid targets. Typically entire address ranges will be scanned via unicast scripts to find targets, as many systems do not reply to pings sent to a broadcast address. Most basic attacks are easy to mitigate against, which focuses attention upon more sophisticated usage of the ICMP protocols.
ICMP Redirect Attack - MIM-style attack in which the attacker redirects traffic to their own machine via trust based service exploitation. It is recommended to disable ICMP redirect from public facing networks. See Further Reading.
ICMP Router Discovery - MIM-style attack in which attacker receives Router Solicitation message and forges the reply to send back to the source host before the router does, tricking the host machine into believing that the attacker's machine is actually the router.
Inverse Mapping - Attacker sends packets to unused network addresses which an intermediate router sends to an internal router which replies with a Host Unreachable message. This information can be used to deduce valid and live target addresses.
Firewalking - Attacker determines firewall rules via Traceroute. It is a two-phase attack method in which the attacker first sends a Traceroute to determine hop count, and then sending a packet with a TTL of one greater than the final hop count, eliciting a Time Exceeded message from beyond the firewall which gives the attacker a valid target.
ICMPv6 has built-in security features designed to prevent attacks, including the Hop Limit field value being set at 255, and the source address of ICMPv6 packets being either link local or unspecified (::/128) for Router Advertisement and Neighbor Solicitation messages. ICMPv6 also includes support for authentication via IP Authentication Header (IPv6-AUTH) and IP Encapsulating Security Payload Header (IPv6-ESP).
Further Reading
---------------------
How to Use TRACERT to Troubleshoot TCP/IP Problems in Windows
https://support.microsoft.com/kb/162326
Network Time Protocol
https://en.wikipedia.org/wiki/Network_Time_Protocol
Neighbor Discovery Protocol
https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
IPv6 Multicast Addresses
https://en.wikipedia.org/wiki/Multicast_address#IPv6
Subverting the ICMP protocol
https://www.pkdavies.co.uk/articles/101-subverting-the-icmp-protocol.html
Network Forensic System for ICMP Attacks
https://www.ijcaonline.org/volume2/number3/pxc387906.pdf
ICMP Attacks Illustrated
https://www.sans.org/reading-room/whitepapers/threats/icmp-attacks-illustrated-477
ICMP Redirect Attacks in the Wild
https://www.agwa.name/blog/post/icmp_redirect_attacks_in_the_wild