Internet DRAFT - draft-eromenko-ipff-icmp

draft-eromenko-ipff-icmp



INTERNET-DRAFT
"Internet Protocol Five Fields - Internet Control Message Protocol", 
Alexey Eromenko, 2016-09-29,
<draft-eromenko-ipff-icmp-04.txt>
expiration date: 2017-03-29

Intended status: Standards Track

                                                              A.Eromenko
                                                          September 2016



                   INTERNET CONTROL MESSAGE PROTOCOL v5
           (for Internet Protocol "Five Fields", aka IPFF-ICMPv5)

                         PROTOCOL SPECIFICATION draft

Abstract

   This document describes the format of a set of control messages used
   in ICMPv5 (Internet Control Message Protocol).  ICMPv5 is the
   Internet Control Message Protocol for Internet Protocol Five Fields
   (IPFF).



Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.


Summary of Message Types

Error messages:
    1  Destination Unreachable
    2  Packet Too Big
    3  Hops Exceeded
    4  Parameter Problem
    5  Redirect

Other messages:
  128  Echo Request
  129  Echo Reply



Introduction

   The Internet Protocol (IP) is used for host-to-host packet
   service in a system of interconnected networks called the
   Internet.  The network connecting devices are called Routers.
   These routers communicate between themselves for control purposes
   via various routing protocols.  Occasionally a
   router or destination host will communicate with a source host, for
   example, to report an error in packet processing.  For such
   purposes this protocol, the Internet Control Message Protocol (ICMP),
   is used.  ICMP, uses the basic support of IP as if it were a higher
   level protocol, however, ICMP is actually an integral part of IP, and
   must be implemented by every IP module.

   ICMP messages are sent in several situations:  for example, when a
   packet cannot reach its destination, and when the router
   can direct the host to send traffic on a shorter route.

   The Internet Protocol is not designed to be absolutely reliable.  The
   purpose of these control messages is to provide feedback about
   problems in the communication environment, not to make IP reliable.
   There are still no guarantees that a packet will be delivered or a
   control message will be returned.  Some packets may still be
   undelivered without any report of their loss.  The higher level
   protocols that use IP must implement their own reliability procedures
   if reliable communication is required.

   The ICMP messages typically report errors in the processing of
   packets.  To avoid the infinite regress of messages about messages
   etc., no ICMP error messages are sent about ICMP error messages.


Message Formats

   ICMP messages are sent using the basic IP header.  The first byte of
   the data portion of the packet is a ICMP type field; the value of
   this field determines the format of the remaining data.  Any field
   labeled "unused" is reserved for later extensions and must be zero
   when sent, but receivers should not use these fields (except to
   include them in the checksum).  Unless otherwise noted under the
   individual format descriptions, the values of the internet header
   fields are as follows:

   Version

      5

   Payload Length

      Length of this ICMP header.

   Hops to Live

      Hops to live; as this field is decremented at each
      machine in which the packet is processed, the value in this
      field should be at least as great as the number of routers which
      this packet will traverse.

   Protocol

      ICMP = 1

   Source Address

      The address of the router or host that composes the ICMP message.
      Unless otherwise noted, this can be any of a router's addresses.

   Destination Address

      The address of the router or host to which the message should be
      sent.

      NOTE: Node SHOULD check any ICMP packet for 999 field limit.
      According to IP-FF addressing specification, fields values 
      between 1000 and 1023 are invalid.

   Source and Destination Ports or Flow Label

      0

   Type of Service

      0



Message Checksum Calculation

   The checksum is the 32-bit CRC32c checksum
   of the entire ICMPv5 message, starting with the ICMPv5 message
   type field, and prepended with a "pseudo-header" of IPFF header
   fields, as specified in [IPFF].  The Protocol value
   used in the pseudo-header is "1" (="ICMP").

   For computing the checksum, the checksum field is set to zero.


Internet Header + 512 bits of Data Packet

   The internet header plus the first 64 bits of the original
   packet's data.  This data is used by the host to match the
   message to the appropriate process.  If a higher level protocol
   uses port numbers, they are assumed to be in the first 512 bits 
   of the original packet's data.

   Design note: why 512 bits? Because it allows to cover the classic TCP
   header in full (20 bytes x8 = 160 bits, plus most IP header options,
   TCP options and then some user data); 
   It should be enough to cover most protocols.



Destination Unreachable Message

   Description

      If, according to the information in the router's routing tables,
      the network specified in the internet destination field of a
      packet is unreachable, e.g., the distance to the network is
      infinity, the router may send a destination unreachable message
      to the internet source host of the packet.  In addition, in some
      networks, the router may be able to determine if the internet
      destination host is unreachable.  Routers in these networks may
      send destination unreachable messages to the source host when the
      destination host is unreachable.

      If, in the destination host, the IP module cannot deliver the
      packet  because the indicated protocol module or process port is
      not active, the destination host may send a destination
      unreachable message to the source host.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 512 bits of Original Data Packet       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address from the original packet's data.

   ICMP Fields:

   Type

      1

   Code

      0 = network unreachable;

      1 = host unreachable;

      2 = protocol unreachable;

      3 = port unreachable;

      4 = VRF table unreachable;

      10 = communication with destination network
          administratively prohibited

      11 = communication with destination host
           administratively prohibited

      12 = communication with destination protocol or port
           administratively prohibited

      14 = Host Precedence Violation

      Codes 0, 1 and 4 may be received from a router.  
      Codes 2 and 3 may be received from a host.
      Codes 10-14 may be received from a firewall.

   Reserved

      Initialized to zero on transmission; ignored by receiver.

   Short explanation of codes:

   Network and host unreachable

      When a router cannot find either target subnet,
      or a particular host within that subnet.

   Protocol unreachable

      When the designated transport protocol is not supported.

   Port unreachable

      when the designated transport protocol (e.g., UDP) is unable to
      demultiplex the datagram but has no protocol mechanism to inform
      the sender.

   Virtual Router Forwarding table unreachable

      When a router receives a packet with VRF extension header,
      and lacks a specified routing table, or has VRF disabled;
      see [IPFF] VRF header extension for details.

   Communication with destination administratively prohibited

      It means that a firewall blocks this traffic by policy, and wants
      to inform the host.

   Host Precedence Violation

      Sent by a first-hop router or firewall (the first router to handle
      a sent datagram) when the Precedence value in the Type Of Service
      field is not permitted.



Packet Too Big Message

   Description

   A Packet Too Big MUST be sent by a router in response to a packet
   that it cannot forward because the packet is larger than the MTU of
   the outgoing link.  The information in this message is used as part
   of the Path MTU Discovery process [PMTU].

   Originating a Packet Too Big Message makes an exception to one of the
   rules as to when to originate an ICMPv5 error message.  Unlike other
   messages, it is sent in response to a packet received with an IPFF
   multicast destination address, or unicast address.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|                             MTU                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 512 bits of Original Data Packet       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPFF Fields:

   Destination Address

      Copied from the Source Address field of the invoking packet.

   ICMP Fields:

   Type           2

   Code           0


   MTU            The Maximum Transmission Unit of the next-hop link.

   Upper Layer Notification

   An incoming Packet Too Big message MUST be passed to the upper-layer
   process if the relevant process can be identified.



Hops Exceeded Message

   Description

      If the router processing a packet finds the hops to live field
      is zero it should discard the packet.  The router may also notify
      the source host via the hops exceeded message.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 512 bits of Original Data Packet       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address from the original packet's data.

   ICMP Fields:

   Type           3

   Code           0


Parameter Problem Message

   Description

      If an IPFF node processing a packet finds a problem with a field 
      in the IPFF header or extension headers such that it cannot 
      complete processing the packet, it MUST discard the packet and 
      SHOULD originate an ICMP Parameter Problem message to the 
      packet's source, indicating the type and location of the problem.

      The pointer identifies the byte of the original packet's header
      where the error was detected.


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|                            Pointer                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 512 bits of Original Data Packet       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address from the original packet's data.

   ICMP Fields:

   Type

      4

   Code

      0 = pointer indicates the error.
      2 = Unrecognized IPFF extension encountered

      Code 2 is more informative subset of Code 0.
      They may be received from a gateway or a host.

   Pointer
 
      Identifies the byte offset within the
      invoking packet where the error was detected.

      The pointer will point beyond the end of the ICMP
      packet if the field in error is beyond what can fit
      in the maximum size of an ICMP error message.



Redirect Message

   Description

      The router sends a redirect message to a host in the following
      situation.  A router, R1, receives an internet packet from a
      host on a network to which the router is attached.  The router,
      R1, checks its routing table and obtains the address of the next
      router, R2, on the route to the packet's internet destination
      network, X.  If R2 and the host identified by the source
      address of the packet are on the same network, a redirect
      message is sent to the host.  The redirect message advises the
      host to send its traffic for network X directly to router R2 as
      this is a shorter path to the destination.  The router forwards
      the original packet's data to its internet destination.

      For packets with the IP source route options and the router
      address in the destination address field, a redirect message is
      not sent even if there is a better route to the ultimate
      destination than the next address in the source route.

      NOTE: Hops-to-live (HTL) for such packets must be set to 1.
      Routers should not forward this.


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   H.Len       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|     Reserved              |                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
 16|                    Router Internet Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Hardware Address                        |
   +                                                               +
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 512 bits of Original Data Packet       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address of the original packet's data.

   ICMP Fields:

   Type

      5

   Code

      0 = Redirect packets for the Network.

      1 = Redirect packets for the Host.

      2 = Redirect packets for the Type of Service and Network.

      3 = Redirect packets for the Type of Service and Host.

      Codes 0, 1, 2, and 3 may be received from a router.
 
   H.Len = Hardware Address Length in bytes

      Typically 6, for Ethernet.
 
   Router Internet Address

      IP Address of the router to which traffic for the network 
      specified in the internet destination network field of the 
      original packet's data should be sent.

   Hardware Address of the new destination Router


Echo or Echo Reply Message

   Description

      The data received in the echo message must be returned in the echo
      reply message. Commonly used via "ping" command to test 
      connectivity.

      The identifier and sequence number may be used by the echo sender
      to aid in matching the replies with the echo requests.  For
      example, the identifier might be used like a port in TCP or UDP to
      identify a session, and the sequence number might be incremented
      on each echo request sent.  The echoer returns these same values
      in the echo reply.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|                          Identifier                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

   IP Fields:

   Addresses

      The address of the source in an echo message will be the
      destination of the echo reply message.  To form an echo reply
      message, the source and destination addresses are simply reversed,
      and the checksum recomputed.

   ICMP Fields:

   Type

      128 for echo message;

      129 for echo reply message by host.

   Code

      0   for any request, or reply by host.

      1   for reply by gateway.

   Identifier

      An identifier to aid in matching echos and replies,
      may be zero.

   Sequence Number

      A sequence number to aid in matching echos and
      replies, may be zero.

   Design note: Identifier and Sequence Number fields were extended
      in IPFF, mainly to help with "ping" NAT traversal, 
      especially at high-speeds.

References

   [IPFF] = draft-eromenko-ipff.txt

Authors' Contacts

   Alexey Eromenko
   Israel

   Skype: Fenix_NBK_
   EMail: al4321@gmail.com
   Facebook: https://www.facebook.com/technologov

Acknowledgements of prior art

   Based on the hard work of people from DARPA, whom developed ICMP 
   [RFC-792] and TCP/IP and "A. Conta", "S. Deering" and "M. Gupta",
   whom developed ICMPv6 RFC-4443 and "R. Braden", [RFC-1122].



INTERNET-DRAFT
Alexey
expiration date: 2017-03-29