idnits 2.17.1 draft-ietf-ipngwg-icmp-01.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-25) 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.) ** There are 100 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 295 instances of too long lines in the document, the longest one being 3 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 83: '...P is an integral part of IPv6 and MUST...' RFC 2119 keyword, line 160: '... Implementations MUST observe the foll...' RFC 2119 keyword, line 163: '...unknown type is received, it MUST be...' RFC 2119 keyword, line 178: '...MP error message MUST NOT be sent ...' RFC 2119 keyword, line 201: '... MUST limit the rate of ICM...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '... Drafts are ...' == Line 12 has weird spacing: '...cuments of t...' == Line 13 has weird spacing: '... groups may ...' == Line 17 has weird spacing: '... Drafts may ...' == Line 18 has weird spacing: '...iate to use ...' == (95 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'RFC-792' on line 634 looks like a reference -- Missing reference section? 'RFC-1112' on line 637 looks like a reference -- Missing reference section? 'IPv6-DISC' on line 631 looks like a reference -- Missing reference section? 'IPv6' on line 137 looks like a reference -- Missing reference section? 'IPv6-ADDR' on line 627 looks like a reference -- Missing reference section? 'RFC-1122' on line 640 looks like a reference -- Missing reference section? 'RFC-1191' on line 644 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Conta (Digital Equipment Corporation) 3 INTERNET-DRAFT S. Deering (Xerox PARC) 4 February 1995 | 6 ICMP for the Internet Protocol Version 6 (IPv6) 7 draft-ietf-ipngwg-icmp-01.txt | 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this memo is unlimited. 30 Abstract 32 This document specifies a set of Internet Control Message Protocol 33 (ICMP) messages for use with version 6 of the Internet Protocol 34 (IPv6). The Internet Group Management Protocol (IGMP) messages 35 specified in RFC-1112 have been merged into ICMP, for IPv6, and are 36 included in this document. 38 Table of Contents 40 1. Introduction........................................3 | 41 2. ICMP for IPv6.......................................3 | 42 3. ICMP Error Messages.................................7 | 43 3.1 Destination Unreachable Message..............7 | 44 3.2 Packet Too Big Message.......................8 | 45 3.3 Time Exceeded Message........................9 | 46 3.4 Parameter Problem Message...................11 | 47 4. ICMP Informational Messages........................12 | 48 4.1 Echo Request Message........................12 | 49 4.2 Echo Reply Message..........................13 | 50 4.3 Group Membership Messages...................15 | 51 5. References.........................................16 | 52 6. Acknowledgements...................................17 | 53 7. Security Considerations............................17 | 54 8. Authors' Addresses.................................17 | 55 1. Introduction | 57 The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6 58 uses the Internet Control Message Protocol (ICMP) as defined for 59 IPv4 [RFC-792], with a number of changes. The Internet Group | 60 Membership | 61 Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised 62 and has been absorbed into ICMP for IPv6. 64 This document describes the format of a set of control messages used 65 in ICMP 66 for IPv6. It does not describe the procedures for using these | 67 messages to achieve functions like Path MTU discovery or multicast | 68 group membership maintenance; such procedures are described in other | 69 documents (e.g., [RFC-1112, RFC-1191]). Other documents may also | 70 introduce additional ICMP message types, such as Neighbor Discovery | 71 messages [IPv6-DISC], subject to the general rules for ICMP messages | 72 given in section 2 of this document. | 74 Terminology defined in the IPv6 specification [IPv6] and the IPv6 75 Routing and Addressing specification [IPv6-ADDR] applies to this 76 document as well. 78 2. ICMP for IPv6 80 IPv6 ICMP is used by IPv6 nodes to report errors encountered in 81 processing packets, and to perform other internet-layer functions, 82 such as diagnostics (ICMP "ping") and multicast | 83 membership reporting. IPv6 ICMP is an integral part of IPv6 and MUST 84 be implemented by every IPv6 node. 86 ICMP messages are grouped into two classes: error messages and | 87 informational messages. Error messages are identified as such by | 88 having a zero in the high-order bit of their message Type values. | 89 Thus, error messages have message Types from 0 to 127; informational | 90 messages have message Types from 128 to 255. | 92 This document defines the message formats for the following IPv6 ICMP | 93 messages: | 94 ICMP error messages: | 95 1 Destination Unreachable (see section 3.1) | 96 2 Packet Too Big (see section 3.2) | 97 3 Time Exceeded (see section 3.3) | 98 4 Parameter Problem (see section 3.4) | 99 ICMP informational messages: | 100 128 Echo Request (see section 4.1) | 101 129 Echo Reply (see section 4.2) | 102 130 Group Membership Qeury (see section 4.3) | 103 131 Group Membership Report (see section 4.3) | 104 132 Group Membership Termination (see section 4.3) | 106 Every IPv6 ICMP message is preceded by an IPv6 header and zero or | 107 more | 108 IPv6 extension headers. The ICMP header is identified by a Next | 109 Header value of in the immediately preceding header. (NOTE: | 110 this is different than the value used to identify ICMP for IPv4.) | 112 The IPv6 ICMP messages have the following general format: 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Type | Code | Checksum | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | | | 120 + Message Body + | 121 | | | 123 The type field indicates the type of the message. Its value | 124 determines the format of the remaining data. | 126 The code field depends on the message type. It is used to create an 127 additional level of message granularity. 129 The checksum is the 16-bit one's complement of the one's complement 130 sum of the IPv6 Source Address, the IPv6 Destination 131 Address (the final destination, if a Routing Header is being used), | 132 the IPv6 Payload Length, the Next Header type that identifies IPv6 | 133 ICMP(), and the entire ICMP message starting with the ICMP | 134 message type. For | 135 computing the checksum, the checksum field is set to zero. 136 (NOTE: the inclusion of the IPv6 header fields in the ICMP checksum | 137 is a change from IPv4; see [IPv6] for the rationale for this change.) | 138 Implementation Notes: | 140 A node that sends an ICMP message has to determine both | 141 the Source and Destination IPv6 Addresses in the IPv6 header before 142 calculating the checksum. 143 If the node has more than one unicast address, it must choose the | 144 Source Address of the message as follows: | 146 If the message is a response to a message sent to one of the | 147 node's unicast address, the Source Address of the reply must be | 148 that same address. | 150 If the message is a response to a message sent to a multicast | 151 group in which the node is a member, the Source Address of the | 152 reply must be a unicast address belonging to the interface on | 153 which the multicast packet was received. | 155 Otherwise, the node's routing table must be examined to determine | 156 which interface will be used to transmit the message to its | 157 destination, and a unicast address belonging to that interface | 158 must be used as the Source Address of the message. | 160 Implementations MUST observe the following rules when processing IPv6 161 ICMP messages (from [RFC-1122]): 163 (a) If an IPv6 ICMP message of unknown type is received, it MUST be 164 silently discarded. 166 (b) Every IPv6 ICMP error message (the first four messages in the 167 above list) includes as much of the IPv6 offending (invoking) 168 packet (the packet that causes the error) as will fit without 169 making the error message packet exceed 576 octets. 171 (c) In those cases where the Internet layer is required to pass a | 172 IPv6 ICMP error message to the transport layer, the IPv6 | 173 Transport | 174 Protocol is extracted from the original header (contained in | 175 the body of the IPv6 ICMP error message) and used to select the 176 appropriate transport protocol entity to handle the error. 178 (d) An IPv6 ICMP error message MUST NOT be sent as a result of 179 receiving: 181 (d.1.)an IPv6 ICMP error message, or | 182 (d.2.)a packet destined to an IPv6 multicast address (an | 183 exception to this rule is the Packet Too Big Message - 184 Section 3.2 - to allow Path MTU discovery to work for 185 IPv6 multicast), or 187 (d.3.) | 188 a packet sent as a link-layer multicast, (the exception | 189 from d.2. applies to this case too) or | 191 (d.4.) 192 a packet sent as a link-layer broadcast, (the exception | 193 from d.2. applies to this case too) or | 195 (d.5.)a packet whose source address does not uniquely identify 196 a single node -- e.g., the IPv6 Unspecified Address, or 197 an IPv6 multicast address. 199 (e) Finally, to each sender of an erroneous data packet, an IPv6 200 node 201 MUST limit the rate of ICMP error messages sent, in order to | 202 limit the bandwidth and forwarding costs incurred by the the | 203 error messages when a generator of erroneous packets does | 204 not respond to those error messages by ceasing its | 205 transmissions. There are a variety of ways of implementing | 206 the rate-limiting function, for example: | 208 (e.1.)Timer-based - for example, limiting the rate of | 209 transmission of error messages to a given source, or to | 210 any source, to at most once every T milliseconds. | 212 (e.2.)Bandwidth-based - for example, limiting the rate at | 213 which error messages are sent from a particular interface | 214 to some fraction F of the attached link's bandwidth. | 216 The limit parameters (e.g., T or F in the above examples) | 217 MUST be configurable for the node, with a conservative | 218 default value (e.g., T = 1 second, NOT 0 seconds, or F = 2 | 219 percent, NOT 100 percent). | 221 The following sections describe the message formats for the above 222 IPv6 ICMP messages. 224 3. ICMP Error Messages 226 3.1. Destination Unreachable Message 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Code | Checksum | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Unused | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | As much of invoking packet | 236 + as will fit without ICMP packet + | 237 | exceeding 576 octets | 238 + + | 239 | | 241 IPv6 Fields: | 243 Destination Address | 244 Copied from the Source Address field of the invoking | 245 packet. | 247 IPv6 ICMP Fields: | 249 Type 1 | 251 Code 0 - no route to destination | 252 1 - communication with destination | 253 administratively prohibited | 254 3 - address unreachable | 255 4 - port unreachable | 257 Unused This field is unused for all code values. 258 It must be initialized to zero by the sender 259 and ignored by the receiver. 261 Description 263 A Destination Unreachable message SHOULD be generated by a router, or | 264 by the IPv6 layer in the originating node, in response to a packet | 265 that cannot be delivered to its destination address for reasons other | 266 than congestion. (If a packet is dropped due to congestion, no ICMP | 267 error message is generated.) If the reason for the failure to | 268 deliver is lack of a matching entry in the forwarding node's routing | 269 table, the Code field is set to 0 (NOTE: this error can occur only in | 270 routers that do not hold a "default route" in their routing tables). | 271 If the reason for the failure to deliver is administrative | 272 prohibition, e.g., a "firewall filter", the Code field is set to 1. | 273 If there is any other reason for the failure to deliver, e.g., | 274 inability to resolve the IPv6 destination address into a | 275 corresponding link address, or a link-specific problem of some sort, | 276 then the Code field is set to 3. | 278 A destination node SHOULD send a Destination Unreachable message with | 279 Code 4 in response to a packet for which the transport protocol | 280 (e.g., UDP) has no listener, if that transport protocol has no | 281 alternative means to inform the sender. | 283 Upper layer notification | 285 A node receiving the ICMP Destination Unreachable message MUST notify | 286 the upper layer. | 288 3.2. | 289 Packet Too Big Message | 291 0 1 2 3 | 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Code | Checksum | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | MTU | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | As much of invoking packet | 299 + as will fit without ICMP packet + | 300 | exceeding 576 octets | 301 + + | 302 | | 304 IPv6 Fields: | 306 Destination Address | 307 Copied from the Source Address field of the invoking | 308 packet. | 310 IPv6 ICMP Fields: | 312 Type 2 | 314 Code 0 316 MTU The Maximum Transmission Unit of the next-hop link. | 318 Description 320 A Packet Too Big MUST be sent by a router in 321 response to a packet that it cannot forward because the packet is | 322 larger than the MTU of the outgoing link. The information in this | 323 message is used as part of the Path MTU Discovery process [RFC-1191]. | 325 Sending a Packet Too Big Message makes an exception to the rules of | 326 when to send an ICMP error message, in that unlike other messages, it | 327 is sent in response to a packet received with an IPv6 multicast | 328 destination address, or a link-layer multicast or link-layer | 329 broadcast address. | 331 Upper layer notification 333 An incoming Packet Too Big message MUST be passed to the transport 334 layer. 336 3.3. 337 Time Exceeded Message | 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Code | Checksum | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Unused | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | As much of invoking packet | 347 + as will fit without ICMP packet + | 348 | exceeding 576 octets | 349 + + | 350 | | 352 IPv6 Fields: | 354 Destination Address | 355 Copied from the Source Address field of the invoking | 356 packet. | 358 IPv6 ICMP Fields: | 360 Type 3 | 362 Code 0 - hop limit exceeded in transit 364 1 - fragment reassembly time exceeded 366 Unused This field is unused for all code values. | 367 It must be initialized to zero by the sender | 368 and ignored by the receiver. | 370 Description 372 If a router receives a packet with a Hop Limit of zero, or a router 373 decrements a packet's Hop Limit to zero, it discards the packet and 374 sends an IPv6 ICMP Time Exceeded message with 375 Code 0 to the source of the packet. This indicates either a routing | 376 loop or too small an initial | 377 Hop Limit value. 379 IPv6 systems are expected to avoid fragmentation by implementing Path 380 MTU discovery. However, IPv6 defines an end-to-end fragmentation 381 function for backwards compatibility with existing higher-layer | 382 protocols. All IPv6 implementations are required to support | 383 reassembly | 384 of IPv6 fragments. There MUST be a reassembly timeout. The 385 reassembly timeout SHOULD be a fixed value. It is recommended that 386 this value lie between 60 and 120 seconds. If the timeout expires, 387 the 388 partially-reassembled packet MUST be discarded. If the fragment | 389 with offset zero was received, the destination host SHOULD also send 390 an IPv6 ICMP Time Exceeded message with Code 1 to the source of the | 391 fragment. | 393 Upper layer notification 395 An incoming Time Exceeded message MUST be passed to the transport 396 layer. 398 3.4. | 399 Parameter Problem Message 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Code | Checksum | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Pointer | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | As much of invoking packet | 409 + as will fit without ICMP packet + | 410 | exceeding 576 octets | 411 + + | 412 | | 414 IPv6 Fields: | 416 Destination Address | 417 Copied from the Source Address field of the invoking | 418 packet. | 420 IPv6 ICMP Fields: | 422 Type 4 | 424 Code 0 - erroneous header field encountered | 426 1 - unrecognized Next Header type encountered | 428 2 - unrecognized IPv6 option encountered | 430 Pointer identifies the octet offset within the 431 invoking packet where the error was detected. | 433 The pointer will point beyond the end of the ICMP | 434 packet if the field in error is beyond what can fit | 435 in the 576-byte limit of an ICMP error message. | 437 Description 438 If an IPv6 node processing a packet finds a problem with a field in | 439 the IPv6 header or extension headers such that it cannot complete | 440 processing the packet, it MUST discard the packet and SHOULD send an | 441 ICMP Parameter Problem message to the packet's source, indicating the | 442 type and location of the problem. | 444 Upper layer notification 446 A node receiving this ICMP message MUST notify the upper layer. 448 4. | 449 ICMP Informational Messages | 451 4.1. 452 Echo Request Message | 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Code | Checksum | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Identifier | Sequence Number | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Data ... 462 +-+-+-+-+- 464 IPv6 Fields: | 466 Destination Address | 467 Any legal IPv6 address. | 468 | 469 IPv6 ICMP Fields: 471 Type 128 | 473 Code 0 475 Identifier If code = 0, an identifier to aid in matching | 476 Echo Replies to this Echo Request. May be zero. | 478 Sequence If code = 0, a sequence number to aid in matching | 479 Number Echo Replies to this Echo Request. May be zero. | 481 Data If code = 0, zero or more octets of arbitrary data. | 483 Description 485 Every node MUST implement an ICMP Echo responder function that | 486 receives Echo Requests and sends corresponding Echo Replies. A node 487 SHOULD also implement an application-layer interface 488 for sending Echo Requests and receiving Echo Replies, for | 489 diagnostic purposes. 491 Upper layer notification | 493 A node receiving this ICMP message MAY notify the upper layer. | 495 4.2. | 496 Echo Reply Message | 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Code | Checksum | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Identifier | Sequence Number | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Data ... 506 +-+-+-+-+- 508 IPv6 Fields: | 510 Destination Address | 511 Copied from the Source Address field of the invoking | 512 Echo Request packet. | 514 IPv6 ICMP Fields: | 516 Type 129 | 518 Code 0 520 Identifier If code = 0, the identifier from the invoking | 521 Echo Request message. | 523 Sequence If code = 0, the sequence number from the invoking | 524 Number Echo Request message. | 526 Data If code = 0, the data from the invoking | 527 Echo Request message | 529 Description 531 Every node MUST implement an ICMP Echo responder function that | 532 receives Echo Requests and sends corresponding Echo Replies. A node 533 SHOULD also implement an application-layer interface 534 for sending Echo Requests and receiving Echo Replies, for | 535 diagnostic purposes. 537 The source address of an Echo Reply sent in response to a unicast | 538 Echo Request message MUST be the same as the destination address of | 539 that Echo Request message. | 541 An Echo Reply SHOULD be sent in response to an Echo Request message | 542 sent | 543 to an IPv6 multicast address. The source address of the reply MUST 544 be a unicast address belonging to the interface on which 545 the multicast Echo Request message was received. | 547 The data received in the ICMP Echo Request message MUST be returned | 548 entirely and unmodified in the ICMP Echo Reply message, unless the | 549 Echo Reply would exceed the MTU of the path back to the Echo | 550 requester, in which case the data is truncated to fit that path MTU. | 552 Upper layer notification 554 Echo Reply messages MUST be passed to the ICMP user interface, unless 555 the corresponding Echo Request originated in the IP layer. 557 4.3. | 558 Group Membership Messages | 560 The ICMP Group Membership Messages have the following format: | 562 0 1 2 3 | 563 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 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 565 | Type | Code | Checksum | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 567 | Maximum Response Delay | Unused | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 + + 571 | Multicast | 572 + + 573 | Address | 574 + + 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 IPv6 Fields: | 580 Destination Address | 581 In a Group Membership Query message, the multicast | 582 address of the group being queried, or the Link-Local | 583 All-Nodes multicast address. | 585 In a Group Membership Report or a Group Membership | 586 Termination message, the multicast address of the | 587 group being reported or terminated. | 589 Hop Limit 1 | 591 IPv6 ICMP Fields: 593 Type 130 - Group Membership Query | 594 131 - Group Membership Report | 595 132 - Group Membership Termination | 597 Code 0 | 599 Maximum Response Delay | 600 In Query messages, the maximum time that responding | 601 Report messages may be delayed, in milliseconds. | 603 In Report and Termination messages, this field is | 604 is initialized to zero by the sender and ignored by 605 receivers. 607 Unused Initialized to zero by the sender; ignored by receivers. 609 Multicast Address 610 The address if the multicast group about which the 611 message is being sent. In Query messages, the Multicast 612 Address field may be zero, implying a query for all 613 groups. 615 Description 617 The ICMP Group Membership messages are used to convey information | 618 about | 619 multicast group membership from nodes to their neighboring routers. 620 The details of their usage is given in [RFC-1112]. 622 5. References | 624 [IPv6]R. Hinden, "Internet Protocol Version 6 Specification", | 625 February 1995 | 627 [IPv6-ADDR] 628 R. Hinden, "IP Next Generation Addressing Architecture", | 629 February 1995 | 631 [IPv6-DISC] 632 W. A. Simpson, "IPv6 Neighbor Discovery", February 1995 | 634 [RFC-792] | 635 J. Postel, "Internet Control Message Protocol", RFC 792. | 637 [RFC-1112] | 638 S. Deering, "Host Extensions for IP Multicasting", RFC 1112. | 640 [RFC-1122] | 641 R. Braden, "Requirements for Internet Hosts - Communication | 642 Layers", RFC 1122. | 644 [RFC-1191] | 645 J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191. | 647 6. Acknowledgements | 649 The document is derived from the "ICMP and IGMP for SIPP" document 650 published as a draft by Ramesh Govindan and Steve Deering in March 651 1994. 653 The working group and particularly Robert Elz, Jim Bound, and Bill | 654 Simpson provided extensive review information and feedback. | 656 7. Security Considerations | 658 Security considerations are not discussed in this memo. 660 Authors' Addresses: 662 Alex Conta Stephen Deering 663 Digital Equipment Corporation Xerox Palo Alto Research Center 664 110 Spitbrook Rd 3333 Coyote Hill Road 665 Nashua, NH 03062 Palo Alto, CA 94304 666 +1-603-881-0744 +1-415-812-4839 668 email: conta@zk3.dec.com email: deering@parc.xerox.com