idnits 2.17.1 draft-eromenko-ipff-icmp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 600 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 138: '... NOTE: Node SHOULD check any ICMP...' RFC 2119 keyword, line 283: '...A Packet Too Big MUST be sent by a rou...' RFC 2119 keyword, line 321: '... Too Big message MUST be passed to the...' RFC 2119 keyword, line 360: '...g the packet, it MUST discard the pack...' RFC 2119 keyword, line 361: '... SHOULD originate an ICMP Paramet...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 188 has weird spacing: '... packet becau...' -- The document date (2017-03-29) is 2579 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: 'PMTU' is mentioned on line 286, but not defined == Missing Reference: 'RFC-1122' is mentioned on line 570, but not defined == Unused Reference: 'RFC-792' is defined on line 569, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'IPFF' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields - Internet Control Message Protocol", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 9 A.Eromenko 10 September 2016 12 INTERNET CONTROL MESSAGE PROTOCOL v5 13 (for Internet Protocol "Five Fields", aka IPFF-ICMPv5) 15 PROTOCOL SPECIFICATION draft 17 Abstract 19 This document describes the format of a set of control messages used 20 in ICMPv5 (Internet Control Message Protocol). ICMPv5 is the 21 Internet Control Message Protocol for Internet Protocol Five Fields 22 (IPFF). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Summary of Message Types 56 Error messages: 57 1 Destination Unreachable 58 2 Packet Too Big 59 3 Hops Exceeded 60 4 Parameter Problem 61 5 Redirect 63 Other messages: 64 128 Echo Request 65 129 Echo Reply 67 Introduction 69 The Internet Protocol (IP) is used for host-to-host packet 70 service in a system of interconnected networks called the 71 Internet. The network connecting devices are called Routers. 72 These routers communicate between themselves for control purposes 73 via various routing protocols. Occasionally a 74 router or destination host will communicate with a source host, for 75 example, to report an error in packet processing. For such 76 purposes this protocol, the Internet Control Message Protocol (ICMP), 77 is used. ICMP, uses the basic support of IP as if it were a higher 78 level protocol, however, ICMP is actually an integral part of IP, and 79 must be implemented by every IP module. 81 ICMP messages are sent in several situations: for example, when a 82 packet cannot reach its destination, and when the router 83 can direct the host to send traffic on a shorter route. 85 The Internet Protocol is not designed to be absolutely reliable. The 86 purpose of these control messages is to provide feedback about 87 problems in the communication environment, not to make IP reliable. 88 There are still no guarantees that a packet will be delivered or a 89 control message will be returned. Some packets may still be 90 undelivered without any report of their loss. The higher level 91 protocols that use IP must implement their own reliability procedures 92 if reliable communication is required. 94 The ICMP messages typically report errors in the processing of 95 packets. To avoid the infinite regress of messages about messages 96 etc., no ICMP error messages are sent about ICMP error messages. 98 Message Formats 100 ICMP messages are sent using the basic IP header. The first byte of 101 the data portion of the packet is a ICMP type field; the value of 102 this field determines the format of the remaining data. Any field 103 labeled "unused" is reserved for later extensions and must be zero 104 when sent, but receivers should not use these fields (except to 105 include them in the checksum). Unless otherwise noted under the 106 individual format descriptions, the values of the internet header 107 fields are as follows: 109 Version 111 5 113 Payload Length 115 Length of this ICMP header. 117 Hops to Live 119 Hops to live; as this field is decremented at each 120 machine in which the packet is processed, the value in this 121 field should be at least as great as the number of routers which 122 this packet will traverse. 124 Protocol 126 ICMP = 1 128 Source Address 130 The address of the router or host that composes the ICMP message. 131 Unless otherwise noted, this can be any of a router's addresses. 133 Destination Address 135 The address of the router or host to which the message should be 136 sent. 138 NOTE: Node SHOULD check any ICMP packet for 999 field limit. 139 According to IP-FF addressing specification, fields values 140 between 1000 and 1023 are invalid. 142 Source and Destination Ports or Flow Label 144 0 146 Type of Service 148 0 150 Message Checksum Calculation 152 The checksum is the 32-bit CRC32c checksum 153 of the entire ICMPv5 message, starting with the ICMPv5 message 154 type field, and prepended with a "pseudo-header" of IPFF header 155 fields, as specified in [IPFF]. The Protocol value 156 used in the pseudo-header is "1" (="ICMP"). 158 For computing the checksum, the checksum field is set to zero. 160 Internet Header + 512 bits of Data Packet 162 The internet header plus the first 64 bits of the original 163 packet's data. This data is used by the host to match the 164 message to the appropriate process. If a higher level protocol 165 uses port numbers, they are assumed to be in the first 512 bits 166 of the original packet's data. 168 Design note: why 512 bits? Because it allows to cover the classic TCP 169 header in full (20 bytes x8 = 160 bits, plus most IP header options, 170 TCP options and then some user data); 171 It should be enough to cover most protocols. 173 Destination Unreachable Message 175 Description 177 If, according to the information in the router's routing tables, 178 the network specified in the internet destination field of a 179 packet is unreachable, e.g., the distance to the network is 180 infinity, the router may send a destination unreachable message 181 to the internet source host of the packet. In addition, in some 182 networks, the router may be able to determine if the internet 183 destination host is unreachable. Routers in these networks may 184 send destination unreachable messages to the source host when the 185 destination host is unreachable. 187 If, in the destination host, the IP module cannot deliver the 188 packet because the indicated protocol module or process port is 189 not active, the destination host may send a destination 190 unreachable message to the source host. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 4| CRC32 Checksum | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 8| Type | Code | Reserved | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Internet Header + 512 bits of Original Data Packet | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 IP Fields: 204 Destination Address 206 The source network and address from the original packet's data. 208 ICMP Fields: 210 Type 212 1 214 Code 216 0 = network unreachable; 218 1 = host unreachable; 220 2 = protocol unreachable; 222 3 = port unreachable; 224 4 = VRF table unreachable; 226 10 = communication with destination network 227 administratively prohibited 229 11 = communication with destination host 230 administratively prohibited 232 12 = communication with destination protocol or port 233 administratively prohibited 235 14 = Host Precedence Violation 237 Codes 0, 1 and 4 may be received from a router. 238 Codes 2 and 3 may be received from a host. 239 Codes 10-14 may be received from a firewall. 241 Reserved 243 Initialized to zero on transmission; ignored by receiver. 245 Short explanation of codes: 247 Network and host unreachable 249 When a router cannot find either target subnet, 250 or a particular host within that subnet. 252 Protocol unreachable 254 When the designated transport protocol is not supported. 256 Port unreachable 258 when the designated transport protocol (e.g., UDP) is unable to 259 demultiplex the datagram but has no protocol mechanism to inform 260 the sender. 262 Virtual Router Forwarding table unreachable 264 When a router receives a packet with VRF extension header, 265 and lacks a specified routing table, or has VRF disabled; 266 see [IPFF] VRF header extension for details. 268 Communication with destination administratively prohibited 270 It means that a firewall blocks this traffic by policy, and wants 271 to inform the host. 273 Host Precedence Violation 275 Sent by a first-hop router or firewall (the first router to handle 276 a sent datagram) when the Precedence value in the Type Of Service 277 field is not permitted. 279 Packet Too Big Message 281 Description 283 A Packet Too Big MUST be sent by a router in response to a packet 284 that it cannot forward because the packet is larger than the MTU of 285 the outgoing link. The information in this message is used as part 286 of the Path MTU Discovery process [PMTU]. 288 Originating a Packet Too Big Message makes an exception to one of the 289 rules as to when to originate an ICMPv5 error message. Unlike other 290 messages, it is sent in response to a packet received with an IPFF 291 multicast destination address, or unicast address. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 4| CRC32 Checksum | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 8| Type | Code | Reserved | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 12| MTU | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Internet Header + 512 bits of Original Data Packet | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 IPFF Fields: 307 Destination Address 309 Copied from the Source Address field of the invoking packet. 311 ICMP Fields: 313 Type 2 315 Code 0 317 MTU The Maximum Transmission Unit of the next-hop link. 319 Upper Layer Notification 321 An incoming Packet Too Big message MUST be passed to the upper-layer 322 process if the relevant process can be identified. 324 Hops Exceeded Message 326 Description 328 If the router processing a packet finds the hops to live field 329 is zero it should discard the packet. The router may also notify 330 the source host via the hops exceeded message. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 4| CRC32 Checksum | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 8| Type | Code | Reserved | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Internet Header + 512 bits of Original Data Packet | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 IP Fields: 344 Destination Address 346 The source network and address from the original packet's data. 348 ICMP Fields: 350 Type 3 352 Code 0 354 Parameter Problem Message 356 Description 358 If an IPFF node processing a packet finds a problem with a field 359 in the IPFF header or extension headers such that it cannot 360 complete processing the packet, it MUST discard the packet and 361 SHOULD originate an ICMP Parameter Problem message to the 362 packet's source, indicating the type and location of the problem. 364 The pointer identifies the byte of the original packet's header 365 where the error was detected. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 4| CRC32 Checksum | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 8| Type | Code | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 12| Pointer | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Internet Header + 512 bits of Original Data Packet | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 IP Fields: 381 Destination Address 383 The source network and address from the original packet's data. 385 ICMP Fields: 387 Type 389 4 391 Code 393 0 = pointer indicates the error. 394 2 = Unrecognized IPFF extension encountered 396 Code 2 is more informative subset of Code 0. 397 They may be received from a gateway or a host. 399 Pointer 401 Identifies the byte offset within the 402 invoking packet where the error was detected. 404 The pointer will point beyond the end of the ICMP 405 packet if the field in error is beyond what can fit 406 in the maximum size of an ICMP error message. 408 Redirect Message 410 Description 412 The router sends a redirect message to a host in the following 413 situation. A router, R1, receives an internet packet from a 414 host on a network to which the router is attached. The router, 415 R1, checks its routing table and obtains the address of the next 416 router, R2, on the route to the packet's internet destination 417 network, X. If R2 and the host identified by the source 418 address of the packet are on the same network, a redirect 419 message is sent to the host. The redirect message advises the 420 host to send its traffic for network X directly to router R2 as 421 this is a shorter path to the destination. The router forwards 422 the original packet's data to its internet destination. 424 For packets with the IP source route options and the router 425 address in the destination address field, a redirect message is 426 not sent even if there is a better route to the ultimate 427 destination than the next address in the source route. 429 NOTE: Hops-to-live (HTL) for such packets must be set to 1. 430 Routers should not forward this. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 4| CRC32 Checksum | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 8| Type | Code | H.Len | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 12| Reserved | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 441 16| Router Internet Address | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Hardware Address | 444 + + 445 . . 446 . . 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Internet Header + 512 bits of Original Data Packet | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 IP Fields: 453 Destination Address 455 The source network and address of the original packet's data. 457 ICMP Fields: 459 Type 461 5 463 Code 465 0 = Redirect packets for the Network. 467 1 = Redirect packets for the Host. 469 2 = Redirect packets for the Type of Service and Network. 471 3 = Redirect packets for the Type of Service and Host. 473 Codes 0, 1, 2, and 3 may be received from a router. 475 H.Len = Hardware Address Length in bytes 477 Typically 6, for Ethernet. 479 Router Internet Address 481 IP Address of the router to which traffic for the network 482 specified in the internet destination network field of the 483 original packet's data should be sent. 485 Hardware Address of the new destination Router 487 Echo or Echo Reply Message 489 Description 491 The data received in the echo message must be returned in the echo 492 reply message. Commonly used via "ping" command to test 493 connectivity. 495 The identifier and sequence number may be used by the echo sender 496 to aid in matching the replies with the echo requests. For 497 example, the identifier might be used like a port in TCP or UDP to 498 identify a session, and the sequence number might be incremented 499 on each echo request sent. The echoer returns these same values 500 in the echo reply. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 4| CRC32 Checksum | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 8| Type | Code | Reserved | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 12| Identifier | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 16| Sequence Number | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Data ... 514 +-+-+-+-+- 516 IP Fields: 518 Addresses 520 The address of the source in an echo message will be the 521 destination of the echo reply message. To form an echo reply 522 message, the source and destination addresses are simply reversed, 523 and the checksum recomputed. 525 ICMP Fields: 527 Type 529 128 for echo message; 531 129 for echo reply message by host. 533 Code 535 0 for any request, or reply by host. 537 1 for reply by gateway. 539 Identifier 541 An identifier to aid in matching echos and replies, 542 may be zero. 544 Sequence Number 546 A sequence number to aid in matching echos and 547 replies, may be zero. 549 Design note: Identifier and Sequence Number fields were extended 550 in IPFF, mainly to help with "ping" NAT traversal, 551 especially at high-speeds. 553 References 555 [IPFF] = draft-eromenko-ipff.txt 557 Authors' Contacts 559 Alexey Eromenko 560 Israel 562 Skype: Fenix_NBK_ 563 EMail: al4321@gmail.com 564 Facebook: https://www.facebook.com/technologov 566 Acknowledgements of prior art 568 Based on the hard work of people from DARPA, whom developed ICMP 569 [RFC-792] and TCP/IP and "A. Conta", "S. Deering" and "M. Gupta", 570 whom developed ICMPv6 RFC-4443 and "R. Braden", [RFC-1122]. 572 INTERNET-DRAFT 573 Alexey 574 expiration date: 2017-03-29