ICMPv6 - PowerPoint PPT Presentation

Icmpv6 l.jpg
1 / 46

  • Updated On :
  • Presentation posted in: General

ICMPv6. Presented by Dr.Apichan Kanjanavapastit. Introduction. Another protocol that has been modified in version 6 of the TCP/IP protocol suite is ICMP The Internet Control Message Protocol version 6 (ICMPv6), follows the same strategy and purposes of version 4

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Icmpv6 l.jpg


Presented by

Dr.Apichan Kanjanavapastit

Introduction l.jpg


  • Another protocol that has been modified in version 6 of the TCP/IP protocol suite is ICMP

  • The Internet Control Message Protocol version 6 (ICMPv6), follows the same strategy and purposes of version 4

  • However, ICMPv6 is more complicated than ICMPv4: some protocols that were independent in version 4 are now part of ICMPv6 and some new messages have been added to make it more useful

  • An ICMP message is identified by a value of 58 in the Next Header field of the IPv6 header

Comparison of network layer in v4 and v6 l.jpg

Comparison of Network Layer in v4 and v6

Taxonomy of icmpv6 messages l.jpg

Taxonomy of ICMPv6 messages

  • ICMPv6 is message-oriented; it uses messages to report errors, to get information, probe a neighbor, or manage multicast communication

  • In this taxonomy, all messages have the same type of format and the message types are handled by ICMPv6 protocol although a few other protocols such as ND and MLD are added to define the functionality and interpretation the some messages

Packet format l.jpg

Packet Format

  • The 8-bit Type field indicates the type of the message. If the high-order bit has value zero (values in the range from 0 to 127), it is an error message; if the high-order bit has value 1 (values in the range from 128 to 255), it is an information message

  • The 8-bit Code field content depends on the message type, and it is used to create an additional level of message granularity

  • The Checksum field is used to detect errors in the ICMP message

Types of icmp messages l.jpg

Types of ICMP Messages

Icmp message transmission l.jpg

ICMP Message Transmission

  • A node that forwards an ICMP message has to determine both the source and the destination IPv6 addresses for the ICMP message

  • Particular care must be put into the choice of the source address. If a node has more than one unicast address, it must choose the source address of the message as follows:

    • If the message is a response to a message sent to one of the node unicast addresses, the Source Address of the reply must be that same address

    • If the message is a response to a message sent to a multicast oranycast group to which the node belongs,the Source Address of thereply must be a unicast address belonging to the interface on which themulticast or anycast packet was received

Icmp message transmission cont l.jpg

ICMP Message Transmission (cont.)

  • If the message is a response to a message sent to an address that does not belong to the node, the Source Address should be the unicast address belonging to the node that will be the most helpful in checking the error (for example, the unicast address belonging to the interface on which the packet forwarding failed)

  • In other cases, the node routing tables must be examined to determine which interface will be used to transmit the message to its destination, and the unicast address belonging to that interface must be used as the Source Address of the message

Error messages l.jpg

Error Messages

  • One of the main responsibilities of ICMP is to report errors

  • Four types of errors are handled: destination unreachable, packet too big, time exceeded, and parameter problem

  • The source-quenched message used to congestion control in version 4 is eliminated in version 6 because the traffic class and flow label fields are supported to take care of congestion

  • The redirection message has moved from the error-reporting category to the neighbor-discovery category

Destination unreachable messages l.jpg

Destination-Unreachable Messages

  • When a router cannot forward a datagram or a host cannot deliver the content of the datagram to the upper layer protocol, the router or the host discards the datagram and sends a destination-unreachable error message to the source host

  • A packet is dropped without generating a message of this type only when the network is congested; generating ICMP messages will make the congestion worse

Destination unreachable messages cont l.jpg

Destination-Unreachable Messages (cont.)

  • The code field specifies the reason for discarding the datagram:

    • Code 0. No route to destination: A router cannot find a matching entry for the destination address in its routing table, and therefore it doesn’t know on which interface to retransmit the packet

    • Code 1. Communication with destination administratively prohibited: The message is dropped by a firewall—that is, by a router that contains a set of rules that forbid some communications

    • Code 2. Not a neighbor: The message contains a Routing header, the next destination address has the Strict / Loose bit equal to Strict, and the next destination address doesn’t belong to any of the router links (it is not a neighbor)

Destination unreachable messages cont12 l.jpg

Destination-Unreachable Messages (cont.)

  • Code 3. Address unreachable: The destination address is unreachable for other reasons—for example, for an interface error or for the inability to compute the link layer address of the destination node

  • Code 4. Port unreachable: The packet reached the destination node, but the layer 4 protocol (for example, UDP) to which the packet should be delivered (the port) is unreachable

Packet too big message l.jpg

Packet-Too-Big Message

  • This is a new type of message added to version 6

  • Since IPv6 does not fragment at the router, if a router receives a datagram that is larger than the maximum transmission unit (MTU) size of the network through which the datagram should pass, two things happen

  • First, the router discards the datagram. Second, an ICMP error packet—a packet-too-big message—is sent to the source

Use packet too big message in path mtu discovery l.jpg

Use Packet-Too-Big Message in Path MTU Discovery

Time exceeded messages l.jpg

Time-Exceeded Messages

  • A time-exceeded error message is generated in 2 cases: when the time to live value becomes zero (code 0) and when not all fragments of a datagram have arrived in the time limit (code 1)

  • The format of this message type is similar to the one in version 4 except the type value has changed to 3

Parameter problem messages l.jpg

Parameter-Problem Messages

  • Any ambiguity in the header of the datagram can create serious problems as the datagram travels through the Internet

  • If a router or the destination host discovers any ambiguous or missing value in any field, it discards the datagram and sends a parameter-problem message to the source

  • The message ICMPv6 is similar to its version 4 counterpart. However, the type value has been changed to 4 and the size of the offset pointer field has been increased to 4 bytes.

Parameter problem messages cont l.jpg

Parameter-Problem Messages (cont.)

  • There are also 3 different codes instead of two

    • Code 0. Erroneous header field: A field in a header holding an illegal value has been detected

    • Code 1. Unrecognized next header type: A Next Header is unrecognized for the IPv6 implementation present on the node

    • Code 2. Unrecognized IPv6 option: The packet holds an unrecognized option

Informational messages l.jpg

Informational Messages

  • Two of the ICMPv6 messages can be categorized as informational messages: echo request and echo reply messages

  • The echo request and echo reply messages are designed to check if two devices in the Internet can communicate with each other

Echo-request message

Echo-reply message

Example of echo reply message l.jpg

Example of Echo-Reply Message

Neighbor discovery messages l.jpg

Neighbor-Discovery Messages

  • Several messages in the ICMPv4 have been redefined in ICMPv6 to handle the issue of neighbor discovery

  • The most important issue is the definition of two new protocols that clearly define the functionality of these group messages: the Neighbor-Discovery (ND) protocol and the Inverse-Neighbor-Discovery (IND) protocol

  • These protocols are used for 3 main purposes:

    • Hosts use the ND to find routers in the neighborhood that will forward packets for them

    • Nodes use the ND to find the link layer address of neighbors

    • Nodes use the IND to find the IPv6 addresses of the neighbors

Router solicitation message l.jpg

Router-Solicitation Message

  • A host uses the router-solicitation message to find a router in the network that can forward an IPv6 datagram for the host

  • The destination address is typically the All-Router multicast group

  • The Hop Limit field of the IPv6 header is set to 255. This setting is a form of protection against attack from hackers

  • In fact, routers verify that this field has value 255, and if not, they discard the packet. A hacker could never forward a message with the Hop Limit equal to 255 from outside the LAN because the router will decrement it by one.

Router solicitation message cont l.jpg

Router-Solicitation Message (cont.)

  • The only option that is so far defined for this message is the inclusion of physical address of the host to make the response easier for the router

Example of router solicitation message l.jpg

Example of Router-Solicitation Message

Router advertisement message l.jpg

The router-advertisement message is sent periodically by a router or in response to a router solicitation message

The IPv6 source address is set equal to the link local address of the interface from which the message is sent, and the destination address is equal either to the address of the node that solicited the message or to the All-Node multicast address

The Hop Limit field of the IPv6 header is set to 255

Router-Advertisement Message

Router advertisement message cont l.jpg

Router-Advertisement Message (cont.)

  • The fields in the router-advertisement message are as follows:

    • Hop Limit. This 8-bit field limits the number of hops that the requestor should use as the hop limit in its IPv6 datagram

    • M. This 1-bit field is the “manage address configuration” field. When this bit is set, the host must use the stateful protocol for address autoconfiguration (based on DHCP servers) in addition to the stateless address autoconfiguration that is, autonomous—autoconfiguration procedure without resorting to servers

Router advertisement message cont26 l.jpg

Router-Advertisement Message (cont.)

  • O. This 1-bit field is the “other stateful configuration” field indicates whether the host must use the stateful autoconfiguration for other information (except addresses)

  • Router Lifetime. This 16-bit field defines the lifetime (in second) of the router as the default router. When the value of this field is 0, it means that the router is not a default router

  • Reachable Time. This 32-bit field defines the time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. This parameter is used by the Neighbor Unreachability Detection algorithm

Router advertisement message cont27 l.jpg

Router-Advertisement Message (cont.)

  • Retransmission Interval. This 32-bit field contains the time, in milliseconds, between retransmitted Neighbor Solicitation messages. It is used by address resolution and Neighbor Unreachability Detection algorithms

  • Option. Some possible options are the link layer address of the link from which the message is sent, the MTU of the link, and address prefix information which specifies prefixes to be used for the address autoconfiguration

Example of router advertisement message l.jpg

Example of Router-Advertisement Message

Neighbor solicitation message l.jpg

Neighbor-Solicitation Message

  • The Address Resolution Protocol (ARP) used in version 4 is eliminated in version 6 since the ARP duties are included in ICMPv6

  • The neighbor-solicitation message is sent when a host or router has a message to send to a neighbor but it does not know the data link address of the receiver

  • Neighbor Solicitation messages are sent to multicast addresses when a node needs to resolve an address (from IPv6 to link layer) or to unicast addresses when a node seeks to verify the reachability of a neighbor

Neighbor solicitation message cont l.jpg

Neighbor-Solicitation Message (cont.)

  • The source address of a Neighbor Solicitation message is either the unicast address of the interface that transmits the message or, during the Duplicate Address Detection procedure, the unspecified address

  • The Hop Limit field of the IPv6 header is set to 255

  • The only option announces the sender data link address for the convenience of the receiver

Example of neighbor solicitation message l.jpg

Example ofNeighbor-Solicitation Message

Neighbor advertisement message l.jpg

Neighbor-Advertisement Message

  • When the state of a node changes, it forwards a Neighbor Advertisement message to propagate modifications quickly and in response to a Neighbor Solicitation message

  • The destination address is equal either to the address of the node that solicited the message or to the All-Node (FF02::1) multicast address

  • The Hop Limit field of the IPv6 header is set equal to 255

Neighbor advertisement message cont l.jpg

Neighbor-Advertisement Message (cont.)

  • The fields are explained below:

    • R. This field is the “router” flag. When it is set, it means the sender of this message is a router

    • S. This field is the “solicitation” flag. When it is set, it means that the sender is sending in response to a solicitation.

    • O. This field is the “override” flag. When it is set, it means that the advertisement should override existing information in the cache

    • Target Address.This field specifies, for solicited advertisements, the address of the node that prompted this advertisement. For unsolicited advertisements, this field specifies the IPv6 address whose link layer address has changed

    • Option. The only possible option is the link layer address of the advertiser

Example of neighbor advertisement message l.jpg

Example of Neighbor-Advertisement Message

Redirection message l.jpg

Redirection Message

  • The purpose of the redirection message is the same as described for version 4

  • However, the format of the packet in version 6 accommodates the size of the IPv6 address

  • The IPv6 source address field is equal to the link local address of the interface from which the message is sent, and the destination address is equal to the source address of the packet that caused the Redirect message

  • The Hop Limit field of the IPv6 header is set equal to 255

Redirection message cont l.jpg

Redirection Message (cont.)

  • Target Addressfield contains the link local address of a better first hop router toward the destination

  • Destination Addresscontains the IPv6 address of the destination that is redirected to the Target Address

  • In the Optionsfield, the following options can appear:

    • The option containing the link layer address of the Target Address if known

    • The Redirect header—that is, the option containing the initial part of the packet that caused the Redirect message

Redirection example l.jpg

Redirection Example

Inverse neighbor solicitation message l.jpg

Inverse-Neighbor-Solicitation Message

  • The inverse-neighbor-solicitation message is sent by a node that knows the link layer address of a neighbor, but not the neighbor’s IP address

  • The message is encapsulated in an IPv6 datagram using an all-node multicast address

  • The sender must send the following 2 pieces of information in the option field: its link layer address and the link layer address of the target

  • The sender can also include its IP address and the MTU value for the link

Inverse neighbor advertisement message l.jpg

Inverse-Neighbor-Advertisement Message

  • The inverse-neighbor-advertisement message is sent in response to the inverse-neighbor-solicitation message

  • The sender of this message must include the link layer address of the sender and the link layer address of the target node in the options field

Group membership messages l.jpg

Group Membership Messages

  • In IPv6, the management of multicast delivery is given to the Multicast Listener Delivery protocol instead of the IGMPv3 as used in IPv4

  • MLDv1 is the counterpart to IGMPv2; MLDv2 is the counterpart to IGMPv3

  • The idea is the same as discussed in IGMPv3, but the sizes and formats of the messages have been changed to fit the larger multicast address size in IPv6

  • Like IGMPv3, MLDv2 has 2 types of messages: membership-query message and membership-report message

  • The first type can be divided into 3 subtypes: general, group-specific, and group-and-source specific

Membership query message l.jpg

Membership-Query Message

  • The fields are almost the same as the ones in IGMPv3 except the size of the multicast address and the source address has been changed to 128 bits

  • Another change is in the maximum response code field in which the size has been changed to 16 bits

  • Note that the format of the first 8 bytes matches the format for other ICMPv6 packets because MLDv2 is considered to be part of ICMPv6

Membership report message l.jpg

Membership-Report Message

  • The format of the membership report in MLDv2 is exactly the same as the one in IGMPv3 except that the sizes of the fields are changed because of the address size

  • In particular, the record type is the same as the one defined for IGMPv3 (type 1 to 6)

Functionality l.jpg


  • MDLv2 protocol behaves in the same way as IGMPv3. However, there are a few differences that are: calculation of maximum response time and calculation of query interval

Functionality cont l.jpg

Functionality (cont.)

  • Login