idnits 2.17.1 draft-ietf-ipngwg-icmp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 133 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 87: '...tegral part of IPv6 and MUST be fully...' RFC 2119 keyword, line 290: '... Implementations MUST observe the fo...' RFC 2119 keyword, line 293: '...of unknown type is received, it MUST...' RFC 2119 keyword, line 297: '... it MUST be silently discarded....' RFC 2119 keyword, line 310: '... error message MUST NOT be sent ...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... Drafts are ...' == Line 14 has weird spacing: '...cuments of t...' == Line 15 has weird spacing: '... groups may ...' == Line 19 has weird spacing: '... Drafts may ...' == Line 20 has weird spacing: '...iate to use ...' == (128 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1995) is 10535 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6' is mentioned on line 285, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-DISC' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Conta (Digital Equipment Corporation) 2 INTERNET-DRAFT S. Deering (Xerox PARC) 3 June 1995 5 Internet Control Message Protocol (ICMPv6) 6 for the Internet Protocol Version 6 (IPv6) 7 Specification 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Distribution of this memo is unlimited. 32 Abstract 34 This document specifies a set of Internet Control Message Protocol 35 (ICMP) messages for use with version 6 of the Internet Protocol 36 (IPv6). The Internet Group Management Protocol (IGMP) messages 37 specified in RFC-1112 have been merged into ICMP, for IPv6, and are 38 included in this document. 40 Table of Contents 41 1. Introduction........................................3 42 2. ICMPv6 (ICMP for IPv6)..............................3 43 2.1 Message General Format.......................3 44 2.2 Message Source Address Determination.........5 45 2.3 Message Checksum Calculation.................5 46 2.4 Message Processing Rules.....................8 47 3. ICMPv6 Error Messages..............................10 48 3.1 Destination Unreachable Message.............10 49 3.2 Packet Too Big Message......................12 50 3.3 Time Exceeded Message.......................13 51 3.4 Parameter Problem Message...................14 52 4. ICMPv6 Informational Messages......................16 53 4.1 Echo Request Message........................16 54 4.2 Echo Reply Message..........................17 55 4.3 Group Membership Messages...................18 56 5. References.........................................19 57 6. Acknowledgements...................................20 58 7. Security Considerations............................20 59 Authors' Addresses....................................21 60 1. Introduction 62 The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6 63 uses the Internet Control Message Protocol (ICMP) as defined for IPv4 64 [RFC-792], with a number of changes. The Internet Group Membership 65 Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised 66 and has been absorbed into ICMP for IPv6. The resulting protocol is 67 called ICMPv6, and has an IPv6 Next Header value 58. 69 This document describes the format of a set of control messages used 70 in ICMPv6. It does not describe the procedures for using these 71 messages to achieve functions like Path MTU discovery or multicast 72 group membership maintenance; such procedures are described in other 73 documents (e.g., [RFC-1112, RFC-1191]). Other documents may also 74 introduce additional ICMPv6 message types, such as Neighbor Discovery 75 messages [IPv6-DISC], subject to the general rules for ICMPv6 76 messages given in section 2 of this document. 78 Terminology defined in the IPv6 specification [IPv6] and the IPv6 79 Routing and Addressing specification [IPv6-ADDR] applies to this 80 document as well. 82 2. ICMPv6 (ICMP for IPv6) 84 ICMPv6 is used by IPv6 nodes to report errors encountered in 85 processing packets, and to perform other internet-layer functions, 86 such as diagnostics (ICMPv6 "ping") and multicast membership 87 reporting. ICMPv6 is an integral part of IPv6 and MUST be fully 88 implemented by every IPv6 node. 90 2.1 Message General Format 92 ICMPv6 messages are grouped into two classes: error messages and 93 informational messages. Error messages are identified as such by 94 having a zero in the high-order bit of their message Type field 95 values. Thus, error messages have message Types from 0 to 127; 96 informational messages have message Types from 128 to 255. 98 This document defines the message formats for the following ICMPv6 99 messages: 101 ICMPv6 error messages: 103 1 Destination Unreachable (see section 3.1) 104 2 Packet Too Big (see section 3.2) 105 3 Time Exceeded (see section 3.3) 106 4 Parameter Problem (see section 3.4) 108 ICMPv6 informational messages: 110 128 Echo Request (see section 4.1) 111 129 Echo Reply (see section 4.2) 112 130 Group Membership Query (see section 4.3) 113 131 Group Membership Report (see section 4.3) 114 132 Group Membership Termination (see section 4.3) 116 Every ICMPv6 message is preceded by an IPv6 header and zero or more 117 IPv6 extension headers. The ICMPv6 header is identified by a Next 118 Header value of 58 in the immediately preceding header. (NOTE: this 119 is different than the value used to identify ICMP for IPv4.) 121 The ICMPv6 messages have the following general format: 123 0 1 2 3 124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | Code | Checksum | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | | 129 + Message Body + 130 | | 132 The type field indicates the type of the message. Its value 133 determines the format of the remaining data. 135 The code field depends on the message type. It is used to create an 136 additional level of message granularity. 138 The checksum is the 16-bit one's complement of the one's complement 139 sum of the IPv6 Source Address, the IPv6 Destination Address the IPv6 140 Payload Length, the Next Header type that identifies ICMPv6 (value = 141 58), and the entire ICMPv6 message starting with the ICMPv6 message 142 type. 144 2.2 Message Source Address Determination 146 A node that sends an ICMPv6 message has to determine both the Source 147 and Destination IPv6 Addresses in the IPv6 header before calculating 148 the checksum. If the node has more than one unicast address, it must 149 choose the Source Address of the message as follows: 151 (a) If the message is a response to a message sent to one of the 152 node's unicast addresses, the Source Address of the reply must be 153 that same address. 155 (b) If the message is a response to a message sent to a multicast or 156 anycast group in which the node is a member, the Source Address 157 of the reply must be a unicast address belonging to the interface 158 on which the multicast packet was received. 160 (c) If the message is a response to a message sent to an address that 161 does not belong to the node, the Source Address should be that 162 unicast address belonging to the node that will be most helpful 163 in diagnosing the error. For example, if the message is a 164 response to a packet forwarding action that cannot complete 165 successfully, the Source Address should be a unicast address 166 belonging to the interface on which the packet forwarding failed. 168 (d) Otherwise, the node's routing table must be examined to determine 169 which interface will be used to transmit the message to its 170 destination, and a unicast address belonging to that interface 171 must be used as the Source Address of the message. 173 2.3 Message Checksum Calculation 175 An illustration of the IPv6 and ICMPv6 header fields fetched into a 176 pseudo-header for calculating the ICMPv6 checksum is: 178 From the IPv6 Header: 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 + + 185 | | 186 + Source Address + 187 | | 188 + + 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 + + 193 | | 194 + Destination Address + 195 | | 196 + + 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | zero | Next Hdr = 58 | Payload Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 From the ICMPv6 Header and Message: 204 0 1 2 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Code | Checksum = zero | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 + Message Body + 211 | | 213 An illustration of the IPv6, IPv6 Hop-by-Hop Jumbo Payload Option and 214 ICMPv6 headers fields fetched into a pseudo-header for calculating 215 the ICMPv6 checksum in case of a Jumbo Payload (IPv6 packet payload 216 longer than 65535 octets) is: 218 From the IPv6 Header: 220 0 1 2 3 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 + + 225 | | 226 + Source Address + 227 | | 228 + + 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 + + 233 | | 234 + Destination Address + 235 | | 236 + + 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | zero | Next Hdr = 58 | zero | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 From the IPv6 Hop-by-Hop Jumbo Payload Option Extension Header: 244 0 1 2 3 245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Payload Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 From the ICMPv6 Header and Message: 252 0 1 2 3 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Code | Checksum = zero | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 + Message Body + 259 | | 261 The ICMPv6 checksum calculation rules are: 263 (a) If the packet contains a Routing header, the Destination Address 264 used in the pseudo-header is that of the final destination. At 265 the originating system, that address will be in the last element 266 of the Routing header; at the recipient(s), that address will be 267 in the Destination Address field of the IPv6 header. 269 (b) The Next Header value in the pseudo-header identifies the ICMPv6 270 protocol (e.g., 58). It will differ from the Next Header value in 271 the IPv6 header if there are additional headers between the IPv6 272 header and the ICMPv6 header. 274 (c) The Payload Length used in the pseudo-header is the length of the 275 ICMPv6 message, including the ICMPv6 header. It will be less 276 than the Payload Length in the IPv6 header or in the IPv6 Hop- 277 by-Hop Jumbo Payload Option header if there are additional 278 headers between the IPv6 header and the ICMPv6 header, 279 respectively the IPv6 Hop-by-Hop Jumbo Option Header and the 280 ICMPv6 Header. 282 (d) For computing the checksum, the checksum field is set to zero. 284 (NOTE: the inclusion of the IPv6 header fields in the ICMPv6 285 checksum is a change from IPv4; see [IPv6] for the rationale for 286 this change.) 288 2.4 Message Processing Rules 290 Implementations MUST observe the following rules when processing 291 ICMPv6 messages (from [RFC-1122]): 293 (a) If an ICMPv6 error message of unknown type is received, it MUST 294 be passed to the upper layer. 296 (b) If an ICMPv6 informational message of unknown type is received, 297 it MUST be silently discarded. 299 (c) Every ICMPv6 error message (type < 128) includes as much of the 300 IPv6 offending (invoking) packet (the packet that causes the 301 error) as will fit without making the error message packet exceed 302 576 octets. 304 (d) In those cases where the Internet layer is required to pass a 305 ICMPv6 error message to the transport layer, the IPv6 Transport 306 Protocol is extracted from the original header (contained in the 307 body of the ICMPv6 error message) and used to select the 308 appropriate transport protocol entity to handle the error. 310 (e) An ICMPv6 error message MUST NOT be sent as a result of 311 receiving: 313 (e.1) an ICMPv6 error message, or 315 (e.2) a packet destined to an IPv6 multicast address (an 316 exception to this rule is the Packet Too Big Message - 317 Section 3.2 - to allow Path MTU discovery to work for IPv6 318 multicast), or 320 (e.3) a packet sent as a link-layer multicast, (the exception 321 from e.2. applies to this case too), or 323 (e.4) a packet sent as a link-layer broadcast, (the exception 324 from e.2., applies to this case too), or 326 (e.5) a packet whose source address does not uniquely identify a 327 single node -- e.g., the IPv6 Unspecified Address, or an 328 IPv6 multicast address, or an IPv6 anycast address. 330 (f) Finally, to each sender of an erroneous data packet, an IPv6 node 331 MUST limit the rate of ICMPv6 error messages sent, in order to 332 limit the bandwidth and forwarding costs incurred by the error 333 messages when a generator of erroneous packets does not respond 334 to those error messages by ceasing its transmissions. There are 335 a variety of ways of implementing the rate-limiting function, for 336 example: 338 (f.1) Timer-based - for example, limiting the rate of 339 transmission of error messages to a given source, or to 340 any source, to at most once every T milliseconds. 342 (f.2) Bandwidth-based - for example, limiting the rate at which 343 error messages are sent from a particular interface to 344 some fraction F of the attached link's bandwidth. 346 The limit parameters (e.g., T or F in the above examples) MUST be 347 configurable for the node, with a conservative default value 348 (e.g., T = 1 second, NOT 0 seconds, or F = 2 percent, NOT 100 349 percent). 351 The following sections describe the message formats for the above 352 ICMPv6 messages. 354 3. ICMPv6 Error Messages 356 3.1 Destination Unreachable Message 358 0 1 2 3 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Code | Checksum | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Unused | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | As much of invoking packet | 366 + as will fit without ICMPv6 packet + 367 | exceeding 576 octets | 368 + + 369 | | 371 IPv6 Fields: 373 Destination Address 374 Copied from the Source Address field of the invoking 375 packet. 377 ICMPv6 Fields: 379 Type 1 381 Code 0 - no route to destination 382 1 - communication with destination 383 administratively prohibited 384 2 - not a neighbor 385 3 - address unreachable 386 4 - port unreachable 388 Unused This field is unused for all code values. 389 It must be initialized to zero by the sender 390 and ignored by the receiver. 392 Description 394 A Destination Unreachable message SHOULD be generated by a router, or 395 by the IPv6 layer in the originating node, in response to a packet 396 that cannot be delivered to its destination address for reasons other 397 than congestion. (An ICMPv6 message MUST NOT be generated if a 398 packet is dropped due to congestion.) 400 If the reason for the failure to deliver is lack of a matching entry 401 in the forwarding node's routing table, the Code field is set to 0 402 (NOTE: this error can occur only in routers that do not hold a 403 "default route" in their routing tables). 405 If the reason for the failure to deliver is administrative 406 prohibition, e.g., a "firewall filter", the Code field is set to 1. 408 If the reason for the failure to deliver is that the next destination 409 address in the Routing header is not a neighbor of the processing 410 node but the "strict" bit is set for that address, then the Code 411 field is set to 2. 413 If there is any other reason for the failure to deliver, e.g., 414 inability to resolve the IPv6 destination address into a 415 corresponding link address, or a link-specific problem of some sort, 416 then the Code field is set to 3. 418 A destination node SHOULD send a Destination Unreachable message with 419 Code 4 in response to a packet for which the transport protocol 420 (e.g., UDP) has no listener, if that transport protocol has no 421 alternative means to inform the sender. 423 Upper layer notification 425 A node receiving the ICMPv6 Destination Unreachable message MUST 426 notify the upper layer. 428 3.2 Packet Too Big Message 430 0 1 2 3 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Code | Checksum | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | MTU | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | As much of invoking packet | 438 + as will fit without ICMPv6 packet + 439 | exceeding 576 octets | 440 + + 441 | | 443 IPv6 Fields: 445 Destination Address 446 Copied from the Source Address field of the invoking 447 packet. 449 ICMPv6 Fields: 451 Type 2 453 Code 0 455 MTU The Maximum Transmission Unit of the next-hop link. 457 Description 459 A Packet Too Big MUST be sent by a router in response to a packet 460 that it cannot forward because the packet is larger than the MTU of 461 the outgoing link. The information in this message is used as part 462 of the Path MTU Discovery process [RFC-1191]. 464 Sending a Packet Too Big Message makes an exception to one of the 465 rules of when to send an ICMPv6 error message, in that unlike other 466 messages, it is sent in response to a packet received with an IPv6 467 multicast destination address, or a link-layer multicast or link- 468 layer broadcast address. 470 Upper layer notification 472 An incoming Packet Too Big message MUST be passed to the upper layer. 474 3.3 Time Exceeded Message 476 0 1 2 3 477 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type | Code | Checksum | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Unused | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | As much of invoking packet | 484 + as will fit without ICMPv6 packet + 485 | exceeding 576 octets | 486 + + 487 | | 489 IPv6 Fields: 491 Destination Address 492 Copied from the Source Address field of the invoking 493 packet. 495 ICMPv6 Fields: 497 Type 3 499 Code 0 - hop limit exceeded in transit 501 1 - fragment reassembly time exceeded 503 Unused This field is unused for all code values. 504 It must be initialized to zero by the sender 505 and ignored by the receiver. 507 Description 509 If a router receives a packet with a Hop Limit of zero, or a router 510 decrements a packet's Hop Limit to zero, it MUST discard the packet 511 and send an ICMPv6 Time Exceeded message with Code 0 to the source of 512 the packet. This indicates either a routing loop or too small an 513 initial Hop Limit value. 515 The router sending an ICMPv6 Time Exceeded message with Code 0 SHOULD 516 consider the receiving interface of the packet as the interface on 517 which the packet forwarding failed in following rule (d) for 518 selecting the Source Address of the message. 520 IPv6 systems are expected to avoid fragmentation by implementing Path 521 MTU discovery. However, IPv6 defines an end-to-end fragmentation 522 function for backwards compatibility with existing higher-layer 523 protocols. All IPv6 implementations are required to support 524 reassembly of IPv6 fragments. There MUST be a reassembly timeout. 525 The reassembly timeout SHOULD be a fixed value. It is recommended 526 that this value lie between 60 and 120 seconds. If the timeout 527 expires, the partially-reassembled packet MUST be discarded. If the 528 fragment with offset zero was received during the reassembly time, 529 the destination host SHOULD also send an ICMPv6 Time Exceeded message 530 with Code 1 to the source of the fragment. 532 Upper layer notification 534 An incoming Time Exceeded message MUST be passed to the upper layer. 536 3.4 Parameter Problem Message 538 0 1 2 3 539 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type | Code | Checksum | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Pointer | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | As much of invoking packet | 546 + as will fit without ICMPv6 packet + 547 | exceeding 576 octets | 548 + + 549 | | 551 IPv6 Fields: 553 Destination Address 554 Copied from the Source Address field of the invoking 555 packet. 557 ICMPv6 Fields: 559 Type 4 561 Code 0 - erroneous header field encountered 563 1 - unrecognized Next Header type encountered 565 2 - unrecognized IPv6 option encountered 567 Pointer identifies the octet offset within the 568 invoking packet where the error was detected. 570 The pointer will point beyond the end of the ICMPv6 571 packet if the field in error is beyond what can fit 572 in the 576-byte limit of an ICMPv6 error message. 574 Description 576 If an IPv6 node processing a packet finds a problem with a field in 577 the IPv6 header or extension headers such that it cannot complete 578 processing the packet, it MUST discard the packet and SHOULD send an 579 ICMPv6 Parameter Problem message to the packet's source, indicating 580 the type and location of the problem. 582 The pointer identifies the octet of the original datagram's header 583 where the error was detected. For example, an ICMPv6 message with 584 Type field = 4, Code field = 1, and Pointer field = 48 would indicate 585 that the IPv6 extension header following the IPv6 header of the 586 original datagram is holds an unrecognized Next Header field value. 588 Upper layer notification 590 A node receiving this ICMPv6 message MUST notify the upper layer. 592 4. ICMPv6 Informational Messages 594 4.1 Echo Request Message 596 0 1 2 3 597 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Code | Checksum | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Identifier | Sequence Number | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Data ... 604 +-+-+-+-+- 606 IPv6 Fields: 608 Destination Address 609 Any legal IPv6 address. 611 ICMPv6 Fields: 613 Type 128 615 Code 0 617 Identifier If code = 0, an identifier to aid in matching 618 Echo Replies to this Echo Request. May be zero. 620 Sequence Number 621 If code = 0, a sequence number to aid in matching 622 Echo Replies to this Echo Request. May be zero. 624 Data If code = 0, zero or more octets of arbitrary data. 626 Description 628 Every node MUST implement an ICMPv6 Echo responder function that 629 receives Echo Requests and sends corresponding Echo Replies. A node 630 SHOULD also implement an application-layer interface for sending Echo 631 Requests and receiving Echo Replies, for diagnostic purposes. 633 Upper layer notification 635 A node receiving this ICMPv6 message MAY notify the upper layer. 637 4.2 Echo Reply Message 639 0 1 2 3 640 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Type | Code | Checksum | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Identifier | Sequence Number | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Data ... 647 +-+-+-+-+- 649 IPv6 Fields: 651 Destination Address 652 Copied from the Source Address field of the invoking 653 Echo Request packet. 655 ICMPv6 Fields: 657 Type 129 659 Code 0 661 Identifier If code = 0, the identifier from the invoking 662 Echo Request message. 664 Sequence If code = 0, the sequence number from the invoking 665 Number Echo Request message. 667 Data If code = 0, the data from the invoking 668 Echo Request message 670 Description 672 Every node MUST implement an ICMPv6 Echo responder function that 673 receives Echo Requests and sends corresponding Echo Replies. A node 674 SHOULD also implement an application-layer interface for sending Echo 675 Requests and receiving Echo Replies, for diagnostic purposes. 677 The source address of an Echo Reply sent in response to a unicast 678 Echo Request message MUST be the same as the destination address of 679 that Echo Request message. 681 An Echo Reply SHOULD be sent in response to an Echo Request message 682 sent to an IPv6 multicast address. The source address of the reply 683 MUST be a unicast address belonging to the interface on which the 684 multicast Echo Request message was received. 686 The data received in the ICMPv6 Echo Request message MUST be returned 687 entirely and unmodified in the ICMPv6 Echo Reply message, unless the 688 Echo Reply would exceed the MTU of the path back to the Echo 689 requester, in which case the data is truncated to fit that path MTU. 691 Upper layer notification 693 Echo Reply messages MUST be passed to the ICMPv6 user interface, 694 unless the corresponding Echo Request originated in the IP layer. 696 4.3 Group Membership Messages 698 The ICMPv6 Group Membership Messages have the following format: 700 0 1 2 3 701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Code | Checksum | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Maximum Response Delay | Unused | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 + + 709 | Multicast | 710 + + 711 | Address | 712 + + 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 IPv6 Fields: 718 Destination Address 719 In a Group Membership Query message, the multicast 720 address of the group being queried, or the Link-Local 721 All-Nodes multicast address. 723 In a Group Membership Report or a Group Membership 724 Termination message, the multicast address of the 725 group being reported or terminated. 727 Hop Limit 1 729 ICMPv6 Fields: 731 Type 130 - Group Membership Query 732 131 - Group Membership Report 733 132 - Group Membership Termination 735 Code 0 737 Maximum Response Delay 738 In Query messages, the maximum time that responding 739 Report messages may be delayed, in milliseconds. 741 In Report and Termination messages, this field is 742 is initialized to zero by the sender and ignored by 743 receivers. 745 Unused Initialized to zero by the sender; ignored by receivers. 747 Multicast Address 748 The address of the multicast group about which the 749 message is being sent. In Query messages, the Multicast 750 Address field may be zero, implying a query for all 751 groups. 753 Description 755 The ICMPv6 Group Membership messages are used to convey information 756 about multicast group membership from nodes to their neighboring 757 routers. The details of their usage is given in [RFC-1112]. 759 5. References 761 [IPv6]S. Deering, R. Hinden, "Internet Protocol, Version 6, 762 Specification", April 1995 764 [IPv6-ADDR] 765 R. Hinden, "IP Version 6 Addressing Architecture", April 1995 767 [IPv6-DISC] 768 W. A. Simpson, "IPv6 Neighbor Discovery", April 1995 770 [RFC-792] 771 J. Postel, "Internet Control Message Protocol", RFC 792. 773 [RFC-1112] 774 S. Deering, "Host Extensions for IP Multicasting", RFC 1112. 776 [RFC-1122] 777 R. Braden, "Requirements for Internet Hosts - Communication 778 Layers", RFC 1122. 780 [RFC-1191] 781 J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191. 783 6. Acknowledgements 785 The document is derived from previous ICMP drafts of the SIPP and 786 IPng working group. 788 The IPng working group and particularly Robert Elz, Jim Bound, Bill 789 Simpson, Thomas Narten, Charlie Lynn, Bill Fink, and Scott Bradner 790 (in chronological order) provided extensive review information and 791 feedback. 793 7. Security Considerations 795 Security considerations are not discussed in this memo. 797 Authors' Addresses: 799 Alex Conta Stephen Deering 800 Digital Equipment Corporation Xerox Palo Alto Research Center 801 110 Spitbrook Rd 3333 Coyote Hill Road 802 Nashua, NH 03062 Palo Alto, CA 94304 803 +1-603-881-0744 +1-415-812-4839 805 email: conta@zk3.dec.com email: deering@parc.xerox.com