Internet DRAFT - draft-eromenko-ipff

draft-eromenko-ipff



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



Intended status: Standards Track
                                                              A.Eromenko
                                                          September 2016


                  Internet Protocol, Version 5 (IPv5)
                a.k.a Internet Protocol - Five Fields (IP-FF)
                             Specification Draft

Abstract

   This document specifies version 5 of the Internet Protocol (IPv5).
   a.k.a Internet Protocol Five Fields, that started as a hybrid
   between IPv4 and IPv6, but solved problems in innovative ways, 
   and significantly improved on both.



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) 2016 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.



Table of Contents

   1. Introduction..................................................2
   1.1. Motivation..................................................
   2. Terminology...................................................3
   2.1.  Relation to Other Protocols................................
   3. IPFF Header Format............................................4
   3.1.  Alternative meaning: Ports or Flow Label...................
   3.2.  Flow-based Routing.........................................
   4.  IP Extensions................................................
       4.1 Extension Classes........................................
       4.2 Extension Header Order...................................
       4.3 Extension header.........................................
       4.4 Standard Extension: Jumbogram............................
       4.5 Standard Extension: Virtual Router Forwarding, type 1....
       4.6 Standard Extension: Virtual Router Forwarding, type 2....
       4.7 No Extension.............................................
       4.8 No Protocol.............................................
       4.9 Future Transports.......................................
   5. Packet Size Issues...........................................24
   6. Type of Service..............................................25
   7. Upper-Layer Protocol Issues..................................27
       7.1 Upper-Layer Checksums...................................27
       7.2 Maximum Packet Lifetime.................................28
       7.3 Responding to Packets Carrying Routing Headers..........29
   Appendix A. Formatting Guidelines for Options...................32
   Security Considerations.........................................35
   Acknowledgments.................................................35
   Authors' Contacts...............................................35
   References......................................................35
   Full Copyright Statement........................................39

1.  Introduction

   IP version 5 "Five Fields" (IP-FF) is a new version of the Internet
   Protocol, designed as the successor to IP version 4 (IPv4) [RFC-791] 
   and IP version 6 [RFC-2460], combining many features of both,
   removing unnecessary bloat, and solved old problems in new ways.
   Started as a hybrid between the two, but superior to both.

   The changes from IPv4 to IPFF fall primarily into the following
   categories:

      o  Expanded Addressing Capabilities

         IPFF increases the IP address size from 32 bits to 50 bits, to
         support more levels of addressing hierarchy, a much greater
         number of addressable nodes, yet keeping the familiar way.
         That over 230,000x times more than in IPv4 and should be enough
         for the next several hundred years or so...
         So even if humanity grows to 100 billion people in few hundred
         years from now, each can have 10,000 devices, before we deplete
         our address space.

      o  Header Format Simplification

         Some IPv4 header fields have been dropped or made optional, to
         reduce the common-case processing cost of packet handling and
         to limit the bandwidth cost of the IPFF header. Derived from 
         IPv6. IPFF goes even further by eliminating "Fragmentation",
         which improves NAT-router processing speeds, and simplifies 
         implementations.

      o  Improved Support for Extensions and Options

         Extensions are much simplied, and went into several distinct
         classes, either mandatory-to-process, or optional-to-process.

      o  Virtual Router Forwarding (VRF) / Layer 3 VPN extension

      o  Jumbogram support (large packets)

      o  Mobile IP problem has an order of magnitude simpler solution;
         see [Mobile TCP]

      o  Ports are at layer 3, which accelerates Flow-Based Routing,
         and Firewalling decisions.

   Dropped features, compared to IPv4:

      o  Fragmentation, as it was proven (in IPv6) that it is cheaper to
         do an MTU discovery, rather than fragment packets on each hop.
         Hosts should use either MTU path discovery or fallback to 1280
         MTU. In IPFF, fragmentation is completely eliminated.
         This increases router processing speed and NAT performance,
         and simplifies TCP/IP stack.

      o  IP Header checksums, as it was proven (in IPv6), that upper 
         layer protocols can handle it checksums and compute them 
         end-to-end, rather than hop-by-hop. This increases router 
         processing speed.

      o  Classes / classful networks.

      o  Internet Group Management Protocol, is now optional.

   The changes from IPv6 to IPFF fall primarily into the following
   categories:

      o  Human readable, simple addressing, similar to IPv4, in 5 
         fields. 10-bits per field. 50-bit addressing.
         With 3 decimal digits in each field, and familiar dotted 
         decimal notation. examples: 10.0.0.0.1  and  382.201.769.25.133

      o  Easy migration from existing IPv4 networks.

      o  Improved efficiency: an IPFF packet is smaller than IPv6, at 20
         bytes, same as in IPv4, saving bandwidth compared to IPv6.

      o  Virtual Router Forwarding (VRF) / Layer 3 VPN extension

      o  Jumbogram support, as a standard option

      o  Mobile IP problem has an order of magnitude simpler solution;
         see [Mobile TCP]

      o  Ports are at layer 3, which accelerates Flow-Based Routing,
         and Firewalling decisions.

      o  Flow Labeling Capability is totally redesigned; It is now
         implicit, merged with ports.

   Dropped features, compared to IPv6:

      o  Modularization: many components, that were the "core" of IPv6
         specification now became optional or eliminated.
         (NDP/IGMP/MLD/SLAAC/IPsec/Flow/Fragmentation/Link-Local...)

      o  Fragmentation.
         In IPFF, fragmentation is completely eliminated.
         This increases NAT performance and simplifies TCP/IP stack.
         Hosts should use either MTU path discovery or fallback to 1280
         MTU.

      o  Link-local addresses are optional; no longer needed.

      o  Neighbor Discovery Protocol (NDP).

      o  Stateless Auto-address configuration (SLAAC) is now optional. 
         Similar functionality should be provided by DHCPv5 or other 
         services.

      o  Internet Group Management Protocol, (IPv6 MLD) is now optional.

   Other important changes in the IPFF stack, vs both IPv4 and IPv6:

      o  In UDPv5 removed "Length" field in order to reduce overhead.

      o  TCP now comes in multiple flavors; "Classic" and "Modern" 
         (TCP.64-bit) variations.

      o  DNSv5 defines a new "AA" record type.

      o  New Mode: "Silent Multicast Listeners", which combines some of
         the benefits of multicasts and some of the benefits of 
         broadcasts. In this mode, Multicast listener accepts only 
         traffic targeted at his IP & Layer 2 address, but does not 
         advertise over IGMP. In this new multicast mode, IGMP protocol
         is not needed.
         Details in [IPFF-ADDRARCH]

      o  IP options / extensions mechanism was completely re-written.

   This document specifies the basic IPFF header and the initially-
   defined IPFF extension headers and options.  It also discusses packet
   size issues, the semantics of Type of Service, and
   the effects of IPFF on upper-layer protocols.  The format and
   semantics of IPFF addresses are specified separately in 
   [IPFF-ADDRARCH]. The IPFF version of ICMP, which all IPFF 
   implementations are required to include, is specified in [ICMPFF].

1.1. Motivation

1.1.1. Motivation: Usability

   In short: Usability issues in IPv6.

   IPv6 solved the scalability problems of IPv4, and simplified some 
   protocol details, but created a new problem.

   The motivation to write a new TCP/IP stack is due to exhaustion of 
   IPv4 address space and also due to the "alien" nature of IPv6, where
   network engineers are forced to use very-long addresses, that are 
   hexadecimal, hard to read & write, hard to compare, hard to memorize
   and hard to debug, at least at the IP level.

   Worse yet, forced link-local addresses, which adds needless 
   complexity. I figured, that just representing IPv6 very-long 128-bit
   addresses in  dotted decimal format would have not solved those 
   issues.

   DNS (Domain Name System), while solves the usability problem at a 
   higher level of the stack, still leaves low level administration 
   issues unsolved.

   Something like this:

   2001:db8:2e1:1a73:149f:88ff:fe81:6116

   ...is absolutely not readable by a human. Not memorizable either.

1.1.2. Motivation for "Five Fields" and 50-bits

   I wanted something simpler, with a look & feel akin to IPv4.
   Bigger address range requirements mandated adding an additional 
   field. 5 fields of 8-bits would have resulted in 40-bits, ~1 
   trillion addresses, or x256 times bigger than IPv4. Not good enough
   for the next century. This is for 15 decimal digits in human memory.
   But can I do better? Well, it turns out I can.

   The trick is to make it short enough so that addresses are easy to
   read/compare & memorize, a problem solved by IPv4, while long enough
   to handle the future requirements of the Internet, a problem solved
   by IPv6.

   50-bit address range theoretically gives me 5 fields of 0...1023 in
   each, but to improve human reading/typing/memorizing/comparing, 
   the fields were limited to 3 decimal digits each. 
   That is range was limited to 0...999 in each field.
   i.e. Address range from 0.0.0.0.0 up to 1023.1023.1023.1023.1023
   was artificially limited up to 999.999.999.999.999 to improve 
   usability. Sacrifice of ~12.5% of available address range for the 
   sake of usability.
   Still gives us over 230,000x times more addresses than IPv4, more 
   than enough for the next several centuries or so...
   And this is at a cost of only 15 decimal digits. 
   Same as five fields of 8-bits BTW, and only 3 digits more than IPv4.

   With this kind of addressing, using IP and visualizing networks in 
   human brain memory becomes easy again !

   IP addresses, as used by millions of network engineers & 
   administrators on a daily basis, should be not just computer 
   friendly, but also human-friendly, as network engineers are humans.

1.1.3. Motivation: IPv6 is too complex

   Another issue with IPv6 is that it has  *too many*  features, 
   everything  including  the  kitchen sink.  Theoretically it is 
   possible to design a network, that includes everything from 
   physical/data-link layer and up to transport, perhaps even 
   applications, but then it would be hard to understand, hard to 
   change and hard to evolve.

   A monster like Neighbor Discovery Protocol (NDP) is very complex 
   indeed, and should be cut into pieces. Much of it's functionality
   logically belongs to DHCP(or Auto-IP) and ARP, two separate pieces.

   Same is true for IGMP / IPv6 MLD - unnecessary bloat, at least for 
   link-local Multicast implementations. Should become optional module.

   Link-local addresses also add unnecessary complexity.

   IPFF, in contrast, is more minimalistic, offloading features to 
   optional modules, allowing for simpler implementations.

   IPFF also optimizes a bunch of features in new ways. 

   Fortunately TCP/IP (v4) protocol stack consists of digestible blocks.

   P.S. I am aware that IPv5 was used for "Internet Stream Protocol" at
   one point in time, but since it was not deployed, I think I can reuse
   that number to indicate both "five fields" as well as a hybrid 
   between IPv4 and IPv6. IP-FF has nothing to do with "Internet Stream
   Protocol".

   "Perfection is achieved not when there is nothing more to add, but 
   when there is nothing left to take away". Antoine de Saint-Exupery.



2.  Terminology

   node        - a device that implements IPFF.

   router      - a node that forwards IPFF packets not explicitly
                 addressed to itself.  [See Note below].

   host        - any node that is not a router.  [See Note below].

   upper layer - a protocol layer immediately above IPFF.  Examples are
                 transport protocols such as TCP and UDP, control
                 protocols such as ICMP, routing protocols such as OSPF.

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPFF.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPFF itself.

   neighbors   - nodes attached to the same link.

   interface   - a node's attachment to a link.

   address     - an IPFF-layer identifier for an interface.

   packet      - an IPFF header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in bytes, that can be conveyed over a link.

   path MTU    - the minimum link MTU of all the links in a path between
                 a source node and a destination node.

   byte        - In IP-FF, as in most computing architectures, byte is
                 defined as 8-bits. = Octet.

   Note: it is possible, though unusual, for a device with multiple
   interfaces to be configured to forward non-self-destined packets
   arriving from some set (fewer than all) of its interfaces, and to
   discard non-self-destined packets arriving from its other interfaces.
   Such a device must obey the protocol requirements for routers when
   receiving packets from, and interacting with neighbors over, the
   former (forwarding) interfaces.  It must obey the protocol
   requirements for hosts when receiving packets from, and interacting
   with neighbors over, the latter (non-forwarding) interfaces.



2.1.  Relation to Other Protocols

  The following diagram illustrates the place of the internet protocol
  in the protocol hierarchy:


        +------+ +------+ +-----+ +-----+     +------+  
        | HTTP | |Telnet| | SCP | | TFTP| ... | ping |  
        +------+ +------+ +-----+ +-----+     +------+  
            |          |   |         |           |     
            |         +-----+     +-----+     +-----+  
            +---------| TCP |     | UDP | ... | ... |
                      +-----+     +-----+     +-----+
                         |           |           |
                      +--------------------------+----+
                      |    Internet Protocol & ICMP   |
                      +--------------------------+----+
                                     |
                        +---------------------------+
                        |   Local Network Protocol  |
                        +---------------------------+

                         Protocol Relationships

                               Figure 1.

  Internet protocol interfaces on one side to the higher level
  host-to-host protocols and on the other side to the local network
  protocol.  In this context a "local network" may be a small network in
  a building or a large network such as the Internet.



3.  IPv5 Header Format

    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|Version|     Extension     |          Source Address           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
  8|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|         Protocol          |       Destination Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
 16|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20|      Source Port / Flow       |    Destination Port / Flow    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|Type of Service|   Hops to Live    |      Payload Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Extensions ... (if any)             |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Version              4-bit Internet Protocol version number = 5.

   Extension            10-bit selector. IP header extensions go here.
                        Zero value means "bottom-of-stack", and that
                        a protocol on top of IP will come next, as
                        specified in the "Protocol" field. See section 4

   Source Address       50-bit address of the originator of the packet.
                        See [IPFF-ADDRARCH].

   Protocol             14-bit selector. Identifies the type of protocol
                        or extension header immediately following the 
                        IPFF header.  Uses a similar values as the IPv4 
                        Protocol field [RFC-1700 et seq.], but with 
                        a wider variety.

   Destination Address  50-bit address of the intended recipient of the
                        packet (possibly not the ultimate recipient, if
                        a Routing header is present).  
                        See [IPFF-ADDRARCH].

   Source and Destination ports or a single Flow Label

                        Two 16-bit port identifiers, used by most 
                        Transport-layer Protocols, or a single
                        32-bit Flow label identifier. Either way they 
                        are used for flow-based routing purposes.
                        See sections 3.1 and 3.2

   Type of Service      8-bit type of service field.  See section 6.

   Hops to Live         10-bit unsigned integer.  Decremented by 1 by
                        each node that forwards the packet. The packet
                        is discarded if Hops to Live is decremented to
                        zero.

   Payload Length       14-bit unsigned integer.  Length of the IPFF
                        payload, i.e., the rest of the packet following
                        this IPFF header, in bytes.  (Note that any
                        extension headers [section 4] present are
                        considered part of the payload, i.e., included
                        in the length count.)
                        Value of zero and all-ones is reserved.



3.1.  Alternative meaning: Ports or Flow Label

   Many Transport-layer protocols (including TCP, UDP, and SCTP) 
   require 16-bit port identifiers, so they were moved to the IP layer.
   It allows to do very fast firewalling and Flow-based routing.

   For some Transport-layer protocols, that do not use 16-bit Ports,
   our port fields can have a different meaning: Flow Label.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   May become:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Flow Label                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Despite a visual difference to the human, there is no logical 
   difference to the router.

   From the router's perspective both achieve the same goal: 
   namely have all packets belonging to one Transport session 
   delivered in-order, which saves CPU time at the destination node.

   Both ways, this field(s) is meant to be read-only, set by the source
   node, and for the router it is Transport-layer indeterministic.

   There is a difference for some middleboxes, (e.g. NAT Routers)
   whom may want to write to this field, as it will trigger a
   Transport-layer-specific checksum update.
   Only the Transport-layer protocol decide the meaning.

   Flow label can only be used by protocols, whom not use 16-bit ports.
   Flow-label is meant to be a pseudo-random number set by the source
   node, which, together with source and destination addresses,
   specifies that same-flow packets must be forwarded through the same 
   path.

   Some protocols may not use it at all. For example ICMP may set
   both port fields to zero; which is the same as setting flow label 
   to zero.



3.2.  Flow-based Routing

   Flow-based routing is a type of policy-based routing, and it works
   with any standard routing protocols.

   With IP-FF, the router can use a 6-tuple to make Flow based 
   decisions in the following way:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |          Source Address           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Protocol          |       Destination Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Source Port / Flow       |    Destination Port / Flow    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type of Service|                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Routing decision may be based on 6-tuple parameters, rather 
   than only "Destination address", which sorts packets correctly,
   and prevents re-ordering, which is expensive to fix.
   6-tuple means source + destination addresses and ports, protocol 
   and Type of Service (ToS).
   5-tuple means the same, minus ToS.

   As a bonus, having 5-tuple available leads to faster firewalls.
   This 6-tuple gives us a 160-bit "virtual flow label" if you will.
   It meant to be used as an implicit flow label.

   Here is the procedure:
   1. First packet in such a flow is routed via traditional method.
      By Destination Address.
   2. The 154-bit "virtual flow label" is cached in a Router's table.
   3. All incoming packets matching this flow will be routed
      according to the label cached earlier, via the same path.

   If a link goes down, the router must invalidate a bunch of labels.
   If a new link comes up, new flows may be redirected there,
   existing flows typically should be kept flowing the old way.
   (assuming equal-cost load-balancing)

   NOTE: During Flow-based routing, some "Extensions" may be 
   relevant, including: Hop-by-Hop, Routing and VRF headers.

   If some Transport layer protocol doesn't use 16-bit ports, it can 
   re-use those fields as an explicit flow label.
   Flow-based routing decisions can happen either way, with 
   an explicit Flow Label or implicitly, with ports.

   Why 6-tuple ?

   ToS affects flow. This is useful for traffic engineering,
   as this is the only field that meants to be read-write-capable, 
   and can change between hops along the path.
   i.e. a VPN device that acts as a tunnel endpoint,
   and has static 5-tuple, can give a different ToS number to two 
   internal Transport sessions, thus creating two flows.
   In this example, ToS field is acting as a secondary "Flow label".



4.  IP Extensions

   In IPFF, optional internet-layer information is encoded in separate
   headers that may be placed between the IPFF header and the upper-
   layer header in a packet.  There are a small number of such extension
   headers, each identified by a distinct Extension value, ending with a
   "bottom-of-stack", zero-extension.

   As illustrated in these examples, an IPFF packet may carry zero, 
   one, or more extension headers, each identified by the Extension 
   field of the preceding header:

   +---------------+------------------------
   |  IPFF header  | TCP header + data
   |               |
   | Protocol = TCP|
   | Extension = 0 |
   +---------------+------------------------


   +---------------+----------------+------------------------
   |  IPFF header  | Routing header | TCP header + data
   |               |                |
   | Protocol = TCP|                |
   | Extension =   | Extension = 0  |
   |    Routing    |                |
   +---------------+----------------+------------------------


   +---------------+----------------+----------------+-----------------
   |  IPFF header  |  VRF header    | Routing header | TCP header + data
   |               |                |                |  
   | Protocol = TCP|                |                |  
   | Extension =   | Extension =    | Extension = 0  |
   |   VRF         |     Routing    |                |
   +---------------+----------------+----------------+-----------------

   The VRF extension header (Class A option), which every router along
   the way should MUST process according to its routing protocol,
   and, if not supported by router implementation, drop the packet.

   Each option header is an integer multiple of 4 bytes long, in
   order to retain 4-bytes alignment for subsequent headers.  Multi-
   byte fields within each extension header are aligned on their
   natural boundaries, i.e., fields of width n bytes are placed at an
   integer multiple of n bytes from the start of the header, for n = 1,
   2, or 4.

   In IP-FF, implementing any extensions, including standard extensions,
   is NOT mandatory, but implementing a mechanism, that will drop
   packets with an unknown class A extension is a MUST.


4.1  Extension Classes

   No Extension = 0 (Bottom-of-stack)

                            | Extension |     |               | 
   Extension Type           |  range    |Total| Length (bits) | Class
   -------------------------+-----------+-----+---------------+-------
   Hop-by-Hop Mandatory     |   1-63    |  63 |      32       |  A3
   Hop-by-Hop Mandatory     |  64-127   |  64 |      64       |  A2
   Hop-by-Hop Mandatory     | 128-255   | 128 |   variable    |  A1
   -------------------------+-----------+-----+---------------+-------
   Hop-by-Hop Discretionary | 256-319   |  64 |      32       |  B3
   Hop-by-Hop Discretionary | 320-383   |  64 |      64       |  B2
   Hop-by-Hop Discretionary | 384-511   | 128 |   variable    |  B1
   -------------------------+-----------+-----+---------------+-------
   Destination Mandatory    | 512-639   | 128 |      64       |  C2
   Destination Mandatory    | 640-767   | 128 |   variable    |  C1
   -------------------------+-----------+-----+---------------+-------
   Destination Discretionary| 768-895   | 128 |      64       |  D2
   Destination Discretionary| 896-1023  | 128 |   variable    |  D1
   -------------------------+-----------+-----+---------------+-------
   No Extension             |    0      |     |       0       |
   -------------------------+-----------+-----+---------------+-------

   Mandatory Hop-by-Hop Options means it is mandatory to process this
     extension, and, if not implemented, drop packet.
     It does NOT mean it is mandatory to implement. Class A options.
   In fact, in IP-FF, no extension is mandatory to implement.

   Discretionary Hop-by-Hop Options means: process it, but if not 
     implemented, skip over this option and continue processing 
     the header. Class B options.

   In IP-FF, a Routing header is really just a special case of 
   "Hop-by-Hop" header, and must be of either Class A, or Class B.

   If, as a result of processing a header, a node is required to proceed
   to the Option but the Option value in the current header is
   unrecognized by the node, for class A options it should discard the 
   packet and send an ICMP Parameter Problem message to the source of 
   the packet, with an ICMP Code value of 1 
   ("unrecognized Option type encountered").
   Unrecognized Class B and D options are just ignored, and traffic 
   routed in the standard fashion.

   Destination options are meant to be useful for end-node.
   All intermediate nodes (routers) may or may not process it.

   Of those numbers; the first (3/4) extension numbers of each class 
   are IANA-assigned; remaining (1/4) extension values are for 
   private/research use.

   Option Class Examples:

   Class A: IPv4-style-fragmentation; IPv4-style-IP-checksum; IP-VRF;
      Extended Hops / Length counters (Jumbograms support); 
      Mandatory Routing header / path selection. (source routing, ...)
   Class B: UniMulticast group address, additional IP address, some 
      additional routing options.
   Class C: IPv6-style-fragmentation; 
   Class D: Mobile Protocol Stack / Mobile TCP options.


4.2  Extension Header Order

   When more than one extension option header is used in the same 
   packet, it required, that options appear and processed according 
   to their class.

           IPFF header
           Class A extensions (Mandatory Hop-by-Hop options)
           Class B extensions (Discretionary Hop-by-Hop options)
           Class C extensions (Mandatory Destination options)
           Class D extensions (Discretionary Destination options)
           No Extension; Bottom-of-Stack (Extension = 0)

   Each option header may occur multiple times, except for No options
   header, which always appears once in every packet.

   Within each major class options may appear in any order,
   but the standard sets priority, in which it should appear.
   Subclasses can be mixed, i.e. options A2, then A1 then A3 may appear
   in any order.

   Priority, 8-bit unsigned integer, is not sent across the wire, 
   but are part of the standard, and have node-local significance,
   local policy, as well as function as a recommendation in which 
   order packets should be sent and processed.

   Only when previous class has listed ALL of it's options, the next
   class may appear. It is not permitted to have a previous class,
   i.e class A after Class B extension.
   
   End-hosts receiving packets MAY ignore class A and B options.
   When encountering class C or D options, Routers MAY skip over 
   them, just like when encountering option-zero.

   If the upper-layer header is another IPFF header (in the case of IPFF
   being tunneled over or encapsulated in IPFF), it may be followed by
   its own extension headers, which are separately subject to the same
   ordering recommendations.

4.3  Extension header


   32-bits Extension: (Class A3, B3)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Extension     |         (22-bits of data)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   64-bits Extension: (Class A2, B2, C2, D2)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Extension     |         (54-bits of data)                 |
   +-+-+-+-+-+-+-+-+-+-+                                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Variable-length Extension: (Class A1, B1, C1, D1)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Extension     | Ext.Length|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   .                                                               .
   .                                                               .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   (must be padded to 32-bits)

    Extension            10-bit selector. Identifies the next extension.
                         Must be terminated by zero "end-of-stack".
     
    Extension Length     6-bit unsigned integer.  Length of the Option
                         Data field of this option, in 32-bit words, 
                         not including the first 32-bits.

    Extension Data       Variable-length field.  Extension-Type-specific
                         data.




4.4 Standard Extension: Jumbogram

   Proposed Option number = 2. (Class A3; to be assigned by IANA)
   Proposed priority = 128 (average; to be assigned by IANA)
   This extension can appear only once.

   A "jumbogram" is an IPFF packet containing a payload longer than
   16,383 bytes. Jumbograms are relevant only to IPFF nodes that may 
   be attached to links with a link MTU greater than 16,407 bytes 
   (16,383 + 24 for IPFF header), and need not be implemented or 
   understood by IPFF nodes that do not support attachment to links 
   with such large MTUs.

     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|     Extension     |             Extended Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Extension            10-bit selector. Identifies the next extension.

   Extended Length      22-bit unsigned integer.  Length of the IPFF
                        jumbogram.

   This options theoretically supports up to 4 MiB packets.
   Standard Length is set to maximum value of 16,383 on transmission.


4.5 Standard Extension: Virtual Router Forwarding (VRF), type 1

   Proposed Option number = 1. (Class A3; to be assigned by IANA)
   Proposed priority = 1 (highest; to be assigned by IANA)
   This extension can appear multiple times.

   VRFs are basically a layer-3 equivalent of IEEE 802.1q VLANs.

   VRF extension header should be used together with a VRF-compatible 
   routing protocol to form multiple routing tables and multiple 
   firewall tables, each for one VRF instance. This allows enterprises
   and internet service providers using Layer 3 VPNs to drop your 
   dependency on L2-VLANs and MPLS, dramatically simplifying network 
   architecture.

   How to use those labels is dependent on the routing protocols, that
   support VRF, but the general rule of thumb is to forward traffic only
   inside the same zone / VRF, unless explicitly configured.
   Different VRFs may have duplicate IP addresses.
   Routing protocols themselves will need to be modified to support 
   IP-VRFs, and to allow VRF trunking (i.e. sync of multiple VRF tables
   via one routing process).

   The VRF header is used by an IPFF to encapsulate a layer-3 virtual
   private network information, similarly to an dot1q VLANs of layer-2
   and to Multi-Protocol Label Switching (MPLS) labels, that can form
   layer-3 VPNs, when combined with the right routing protocols.
   A stacking multiple VRF extensions is possible, like Q-in-Q VLAN
   encapsulation.

   The type 1 VRF header has the following format:

     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|     Extension     |       Virtual Router Forwarding label     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Extension            10-bit selector. Identifies the next extension.

   Virtual Router Forwarding label. 

                        22-bit selector. Described an Enterprise-wide
                        L3 VPN unique number, allowing to form 
                        layer 3 VPNs, without dot1q VLANs or MPLS.


   If a node or a router receives a packet with a VRF header and doesn't
   know how to handle it, (for example, if VRF not configured), it 
   should discard it.

   VRF label is mutable, and can be changed by any router along the way.
   A single VRF packet leakage, due to a random bit swap in VRF label 
   field, is believed not to pose a security threat.

   Recommended values:
   0 = not enabled, same as "global VRF", should be treated the same as 
       packet without VRF header.
   1 = admin domain. Recommended to be used for management interfaces 
       only for network equipment and embedded electronics.

4.6 Standard Extension: Virtual Router Forwarding (VRF), type 2

   Proposed Option number = 32. (Class A1; to be assigned by IANA)
   Proposed priority = 2 (to be assigned by IANA)
   This extension can appear multiple times.

   This is similar to the above type 1, but adds the often needed 
   information on the originating router (whom encapsulated into VRF,
   and destination Router, that is supposed to decapsulate from VRF).

   VRF header type 2 provides more information to Routing Protocols,
   which may improve routing efficiency, and emulate MPLS cloud
   more closely, at a heavier overhead cost. 
   Also VRF range is extended to full 32-bits.

   The type 2 VRF header has the following format:

    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|     Extension     | Ext.Len=5 |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|   Reserved                |                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
 12|               Encapsulating Router Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|   Reserved                |                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
 20|               Decapsulating Router Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|              Virtual Router Forwarding label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Extension            10-bit selector. Identifies the next extension.

   Length               5  (5x 32-bit words, plus 1st word)
   
   Encapsulating Router 50-bit. This is an IP address of the router that
                        first encapsulated the packet into VRF instance.
                        A source IP/ingress of a VRF cloud, basically.
                         
   Decapsulating Router 50-bit. This is an IP address of the router that
                        is supposed to decapsulate the packet from VRF
                        instance. A destination IP/egress of a VRF 
                        cloud, basically.

   Virtual Router Forwarding label. 

                        32-bit selector. Described an Enterprise-wide
                        L3 VPN unique number, allowing to form 
                        layer 3 VPNs, without dot1q VLANs or MPLS.

   Reserved fields      Must be set to zero on transmit; ignored on 
                        receive, unless specified otherwise by a 
                        routing protocol. Optionally may be used as 
                        an additional flow, ToS, or hops count.

   If a node or a router receives a packet with a VRF header and 
   doesn't know how to handle it, (for example, if VRF not configured),
   it should discard it. Otherwise it is a security issue.

   Unlike type 1 VRF, an "ICMP Destination Unreachable" should be sent
   with  code "VRF table unreachable" to the Encapsulating Router.


4.7 No Extension

   The value 0 in the Extension field of an IPv5 header or any
   extension header indicates "Bottom-of-Stack", and that "Protocol"
   data starts after this point.

4.8 No Protocol

   The value 0 in the Protocol field of an IPv5 header indicates 
   this packet is invalid.

4.9 Future Transport protocols

   Protocol values = 1-4095 are all custom protocols;

   The problem is: new Transports are undeployable in IPv4 due to huge
   amount of middleboxes, and some operating systems disallowing to use
   non-standard protocol numbers by unprivileged users.

   The fix: Protocol values between 4096-16383 At a minimum, 
   SHOULD be treated by NAT Routers and middle-boxes like UDP.
   Additionally, unprivileged users on operating-systems should be able
   to use protocol numbers 4096-16383, just like UDP is allowed.
   NAT Routers MUST place a new, updated checksum ONLY IF 
     incoming checksum is non-zero. If it was zero, it is sent as-is.

   Standard, even numbered, Future Transport protocols include 16-bit
   ports and 32-bit CRC32 checksum. Even numbers between 4096-16383. 

   Odd-numbered Future Transport protocols also behave like UDP, 
   except they do not have CRC32 checksum field. 
   They can be used by future transports if you either don't need 
   checksum at all, or don't use IP pseudo-header as a starting point.
   NAT Routers can forward them and can change port. 
   No checksum calculation is done.
   Odd numbers between 4096-16383.

   If your Future Transport doesn't use 16-bit port fields, those can
   be used for a "Flow Label" purposes.
   For unrecognized Protocols 4096-16383, NAT Router can change this
   label, as if they were ports.

   Of those last 1000 numbers are private.
   Public, assigned by IANA = 4096-15383; 
   private & research: 15384-16383.

   If you design a new Future Transport protocol, that uses a different
   checksum mechanism from UDP's CRC32,  and you still require IP 
   pseudo-header as a starting point, you SHOULD use custom protocol,
   numbered between 1-4095.
   For unknown protocol between 1-4095, NAT routers SHOULD drop packet.


5. Packet Size Issues

   IPFF requires that every link in the internet have an MTU of 1280
   bytes or greater.  On any link that cannot convey a 1280-byte
   packet in one piece, link-specific fragmentation and reassembly must
   be provided at a layer below IPFF.

   Links that have a configurable MTU (for example, PPP links [RFC-
   1661]) must be configured to have an MTU of at least 1280 bytes; it
   is recommended that they be configured with an MTU of 1500 bytes or
   greater, to accommodate possible encapsulations (i.e., tunneling).

   From each link to which a node is directly attached, the node must be
   able to accept packets as large as that link's MTU.

   It is strongly recommended that IPFF nodes implement Path MTU
   Discovery [RFC-4821] similarly to IPv6, but at Transport Layer, 
   in order to discover and take advantage of path MTUs greater 
   than 1280 bytes.  
   However, a minimal IPFF implementation (e.g., in a boot ROM) may
   simply restrict itself to sending packets no larger than 1280 
   bytes, and omit implementation of Path MTU Discovery.

6.  Type of Service

   The 8-bit Type of Service field in the IPFF header is available for 
   use by originating nodes and/or forwarding routers to identify and
   distinguish between different classes or priorities of IP-FF packets.

   Type of Service bits provide various forms of "differentiated 
   service" for IP packets.  
   This is similar to The "Traffic Class" field in the IPv6 header,
   and to "Type of Service"/Precedence in IPv4.

   The following general requirements apply to the Type of Service field:

      o  The service interface to the IPFF service within a node must
         provide a means for an upper-layer protocol to supply the value
         of the Type of Service bits in packets originated by that upper-
         layer protocol.  The default value must be zero for all 10 bits.

      o  Nodes that support a specific (experimental or eventual
         standard) use of some or all of the Type of Service bits are
         permitted to change the value of those bits in packets that
         they originate, forward, or receive, as required for that
         specific use.  Nodes should ignore and leave unchanged any bits
         of the Type of Service field for which they do not support a
         specific use.

      o  An upper-layer protocol must not assume that the value of the
         Type of Service bits in a received packet are the same as the
         value sent by the packet's source.

   In flow-based routing, ToS affects flow as part of the 6-tuple.
   See "flow-based routing" for details.


7. Upper-Layer Protocol Issues


7.1 Upper-Layer Checksums

   Any transport or other upper-layer protocol that includes the
   addresses from the IP header in its checksum computation must be
   modified for use over IPFF, to include the 50-bit IPFF addresses
   instead of 32-bit IPv4 addresses.  In particular, the following
   illustration shows the TCP and UDP "pseudo-header" for IPFF:

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved                |                                   |
   +-------------------------Source Address                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Protocol              |                                   |
   +----------------------Destination Address                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upper-Layer Packet Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o  Ports should be included by protocols, that use them.
         Else zero.

      o  If Upper layer does not use ports (but uses Flow instead),
         those must be set to zero, for checksum calculation purposes.

      o  The Upper-Layer Packet Length in the pseudo-header is the
         length of the upper-layer header and data (e.g., TCP header
         plus TCP data). It may be the standard 14-bit length,
         or the 22-bit "jumbogram" length.

         Protocols (such as TCP and UDPv5) do not carry their own
         length information, in which case the length used in the
         pseudo-header is the Payload Length from the IPFF header, minus
         the length of any extension headers present between the IPFF
         header and the upper-layer header.

   The IPFF version of ICMP (& IGMP) includes the above pseudo-header in
   its checksum computation; this is a change from the IPv4 version of
   ICMP, which does not include a pseudo-header in its checksum.  The
   reason for the change is to protect ICMP from misdelivery or
   corruption of those fields of the IPFF header on which it depends,
   which, unlike IPv4, are not covered by an internet-layer checksum.

7.2 Maximum Packet Lifetime

   Typically up to 1023 hops (= jumps between Routers).
   This is done to prevent routing loops.

   Unlike IPv4, IPFF nodes are not required to enforce maximum packet
   lifetime, that is "Hops to Live" field may be left unchanged by 
   the router, if the operator or the routing protocol decides so.



Security Considerations

   If some devices along the path do not implement VRF properly,
   it can result in data leak across VRF domains.

   Additionally a version of IPsec for IP-FF will provide IP-level
   encryption for those, who need it.
   A separate specification will be written on it.

Acknowledgments

   Based on the hard work of "Stephen E. Deering" & "Robert M. Hinden",
   from IPv6 project, as well as all previous TCP/IP developers 
   from DARPA.

   Also based on "IPv6 Jumbograms", RFC-2675, by "Stephen E. Deering",
   "Robert M. Hinden", & "D. Borman"

   While this document is largely based on [RFC-2460], forget not that
   the difference in D.N.A. between humans and monkeys is just 1%.


Authors' Contacts

   Alexey Eromenko
   Israel

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

References

   [ICMPFF]     "ICMP for the Internet Protocol Five Fields" by 
                Alexey.E.

   [IPFF-ADDRARCH] "IP Five Fields Addressing Architecture" by Alexey.E.

   [RFC-4821]   M. Mathis, J. Heffner, "Packetization 
                Layer Path MTU Discovery", RFC 4821, March 2007.

   [RFC-791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [RFC-2460]   S. Deering, R. Hinden "Internet Protocol, Version 6",
                December 1998.

   [RFC-1700]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
                RFC 1700, October 1994.  See also:
                http://www.iana.org/numbers.html

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