





Network Working Group                                         A.Eromenko
Category: Proposed Standard                                          
                                                           December 2015


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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" draft (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) by Alexey Eromenko, based on previous work of IETF IPv4
   (RFC791) and IPv6 (RFC2460) standards.  All Rights Reserved.

Abstract

   This document specifies version 5 of the Internet Protocol (IPv5).
   a.k.a Internet Protocol Five-Field, that attempts to build a hybrid 
   between IPv4 and IPv6. [Draft]

Table of Contents

   1. Introduction..................................................2
   1.1. Motivation
   2. Terminology...................................................3
   3. IPv5 Header Format............................................4
   4. IPv5 Extension Headers........................................6
       4.1 Extension Header Order...................................7
       4.2 Options..................................................9
       4.3 Hop-by-Hop Options Header...............................11
       4.4 Routing Header..........................................12
       4.5 ...
       4.6 Destination Options Header..............................23
       4.7 No Next Header..........................................24
       4.8 Virtual Router Forwarding (VRF) extension...............
       4.9 Flow Label extension....................................
   5. Packet Size Issues...........................................24
   ...
   7. Traffic Classes..............................................25
   8. Upper-Layer Protocol Issues..................................27
       8.1 Upper-Layer Checksums...................................27
       8.2 Maximum Packet Lifetime.................................28
       8.3 Maximum Upper-Layer Payload Size........................28
       8.4 Responding to Packets Carrying Routing Headers..........29

   Appendix A. Semantics and Usage of the Flow Label Field.........30
   Appendix B. Formatting Guidelines for Options...................32
   Security Considerations.........................................35
   Acknowledgments.................................................35
   Authors' Contacts...............................................35
   References......................................................35
   Changes Since RFC-1883..........................................36
   Full Copyright Statement........................................39

1.  Introduction

   IP version 5 (IPv5) 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 the features of both.
   A hybrid between the two.

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

      o  Expanded Addressing Capabilities

         IPv5 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 IPv5 header. Derieved from IPv6.

      o  Improved Support for Extensions and Options

         Changes in the way IP header options are encoded allows for
         more efficient forwarding, less stringent limits on the length
         of options, and greater flexibility for introducing new options
         in the future. Derieved from IPv6.

      o  Address Resolution Protocol (ARP) now became Link Address 
         Resolution Protocol (LARP), moved to layer 3, and got multicast
         capability.

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

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

   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 1320 MTU.
         In IPv5, 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  Broadcasts. Multicasts are effectively more efficient versions of 
         those, just filtered at Layer 2 and 3 (as opposed to Layer 4).

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

   The changes from IPv6 to IPv5 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  -  382.201.769.25.133

      o  Easy migration from existing IPv4 networks.

      o  Improved efficiency: an IPv5 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  Mobile IP problem now has an order of magnitude simpler solution;
         see [Mobile TCP]

   Dropped features, compared to IPv6:

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

      o  Flow Labeling Capability is now optional extension.

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

      o  Neighbor Discovery Protocol (NDP), divided into Link Address 
         Resolution Protocol (LARP), and optional extensions.

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

      o  Internet Group Management Protocol, (IGMP/IPv6 MLD) is now optional.
         i.e. Link-local Multicast hosts do not send any updates to anyone.

   Other important changes in the IPv5 stack:

      o  In UDPv5 removed "Length" field in order to support future
         jumbogram extension, and reduce overhead.

      o  DNSv5 defines a new "AA" record type.

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

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 readble by a human. Not memorizable either.

   What's the point of a protocol, that has more addresses than the amount
   of sand grains in the Sahara desert ? 
   Or more than stars in the known Universe?
   Sure, it looks cool on paper, but absolute usability disaster in reality.

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, evething 
   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, that have replaced Broadcast of IPv4.
   Should become optional module.

   Link-local addresses also add unnecessary complexity.

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

   Fortunately TCP/IP (v4) protocol stack consists of digestable 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 IPv5.

   router      - a node that forwards IPv5 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 IPv5.  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 IPv5.  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 IPv5 itself.

   neighbors   - nodes attached to the same link.

   interface   - a node's attachment to a link.

   address     - an IPv5-layer identifier for an interface or a set of
                 interfaces.

   packet      - an IPv5 header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, 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.

   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.

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|     Reserved      |          Source Address           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
  8|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|         Protocol          |       Destination Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
 16|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20| Hops to Live  |Type of Service|       Payload Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Version              4-bit Internet Protocol version number = 5.

   Reserved             10-bit field for future extensions. 
                        Must be set to zero for transmission, ignored
                        by receiver.

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

   Protocol             14-bit selector.  Identifies the type of protocol
                        or extension header immediately following the IPv5
                        header.  Uses a similar values as the IPv4 Protocol
                        field [RFC-1700 et seq.], but with 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 [IPv5-ADDRARCH]
                        and section 4.4.

   Hops to Live         8-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.

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

   Payload Length       16-bit unsigned integer.  Length of the IPv5
                        payload, i.e., the rest of the packet following
                        this IPv5 header, in octets.  (Note that any
                        extension headers [section 4] present are
                        considered part of the payload, i.e., included
                        in the length count.)


4.  IPv5 Extension Headers

   In IPv5, optional internet-layer information is encoded in separate
   headers that may be placed between the IPv5 header and the upper-
   layer header in a packet.  There are a small number of such extension
   headers, each identified by a distinct Protocol value.  As
   illustrated in these examples, an IPv5 packet may carry zero, one, or
   more extension headers, each identified by the Next Header field of
   the preceding header:

   +---------------+------------------------
   |  IPv5 header  | TCP header + data
   |               |
   | Protocol =    |
   |      TCP      |
   +---------------+------------------------


   +---------------+----------------+------------------------
   |  IPv5 header  | Routing header | TCP header + data
   |               |                |
   | Protocol =    |  Protocol =    |
   |    Routing    |      TCP       |
   +---------------+----------------+------------------------


   +---------------+----------------+-----------------+-----------------
   |  IPv5 header  | Routing header | VRF header      | TCP header + data
   |               |                |                 |  
   | Protocol =    |  Protocol =    |  Protocol =     |
   |    Routing    |    VRF         |       TCP       |
   +---------------+----------------+-----------------+-----------------

   With few exceptions, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv5 header.

   There, normal demultiplexing on the Protocol field of the IPv5
   header invokes the module to process the first extension header, or
   the upper-layer header if no extension header is present.  The
   contents and semantics of each extension header determine whether or
   not to proceed to the next header.  Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

   The few exceptions referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv5 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv5
   header.

   Another exception is the VRF extension header, which every router
   along the way must examine according to it's routing protocol.

   If, as a result of processing a header, a node is required to proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, 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 Protocol type encountered")
   and the ICMP Pointer field containing the offset of the unrecognized
   value within the original packet.  The same action should be taken if
   a node encounters a Next Header value of zero in any header other
   than an IPv5 header.

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

   A full implementation of IPv5 includes implementation of the
   following extension headers:

           Hop-by-Hop Options
           Routing (Type 0)
           Destination Options
           Virtual Router Forwarding (VRF)
           Flow Label

   The first four are specified in this document; the last two are
   specified in [RFC-2402] and [RFC-2406], respectively.


4.a Extension numbers: mutable and non-mutable :
   
   Protocol headers between 0 up to 13-bit (8191) are non-mutable, cannot
   be changed by routers till destination of upper layer protocols (TCP+UDP).

   Protocol extensions between 13-bits (8192) up to 14-bit (16383) are 
   mutable, and can be changed by routers along the path. 
   Only 2 is known: Hop-by-Hop and VRF header.

4.1  Extension Header Order

   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

           IPv5 header
           Hop-by-Hop Options header
           Destination Options header (note 1)
           Routing header
           VRF header
           Flow header
           Authentication header (note 2)
           Encapsulating Security Payload header (note 2)
           Destination Options header (note 3)
           upper-layer header

           note 1: for options to be processed by the first destination
                   that appears in the IPv5 Destination Address field
                   plus subsequent destinations listed in the Routing
                   header.

           note 2: additional recommendations regarding the relative
                   order of the Authentication and Encapsulating
                   Security Payload headers are given in [RFC-2406].

           note 3: for options to be processed only by the final
                   destination of the packet.

   Each extension header should occur at most once, except for the
   Destination Options header which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

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

   If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers must be specified.

   IPv5 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header which is restricted to
   appear immediately after an IPv5 header only.  Nonetheless, it is
   strongly advised that sources of IPv5 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

4.2  Options

   Two of the currently-defined extension headers -- the Hop-by-Hop
   Options header and the Destination Options header -- carry a variable
   number of type-length-value (TLV) encoded "options", of the following
   format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      Option Type          8-bit identifier of the type of option.

      Opt Data Len         8-bit unsigned integer.  Length of the Option
                           Data field of this option, in octets.

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

   The sequence of options within a header must be processed strictly in
   the order they appear in the header; a receiver must not, for
   example, scan through the header looking for a particular kind of
   option and process that option prior to processing all preceding
   ones.

   The Option Type identifiers are internally encoded such that their
   highest-order two bits specify the action that must be taken if the
   processing IPv5 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

   The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en-route to the
   packet's final destination.  When an Authentication header is present
   in the packet, for any option whose data may change en-route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

      0 - Option Data does not change en-route

      1 - Option Data may change en-route

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type.

   The same Option Type numbering space is used for both the Hop-by-Hop
   Options header and the Destination Options header.  However, the
   specification of a particular option may restrict its use to only one
   of those two headers.

   Individual options may have specific alignment requirements, to
   ensure that multi-octet values within Option Data fields fall on
   natural boundaries.  The alignment requirement of an option is
   specified using the notation xn+y, meaning the Option Type must
   appear at an integer multiple of x octets from the start of the
   header, plus y octets.  For example:

      2n    means any 2-octet offset from the start of the header.
      8n+2  means any 8-octet offset from the start of the header,
            plus 2 octets.

   There is a padding option which are used when necessary to align
   subsequent options and to pad out the containing header to a multiple
   of 8 octets in length.  This padding option must be recognized by
   all IPv5 implementations:

   Pad option  (alignment requirement: none)

      +-+-+-+-+-+-+-+-+
      |       0       |
      +-+-+-+-+-+-+-+-+

      NOTE! the format of the Pad option is a special case -- it does
            not have length and value fields.

      The Pad option is used to insert one octet of padding into the
      Options area of a header. 

   Appendix B contains formatting guidelines for designing new options.

4.3  Hop-by-Hop Options Header

   The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.
   The Hop-by-Hop Options header is identified by a Protocol value of
   0 in the IPv5 header, and has the following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Protocol                 | 0 |  Hdr Ext Len  |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol             14-bit selector.  Identifies the type of header
                        immediately following the Hop-by-Hop Options
                        header.  Uses the similar values as the IPv4
                        Protocol field [RFC-1700 et seq.], with extras.

   ...followed by 2 zeroes. (padding)

   Hdr Ext Len          8-bit unsigned integer.  Length of the Hop-by-
                        Hop Options header in 64-bit units, not
                        including the first 64 bits.

   Options              Variable-length field, of length such that the
                        complete Hop-by-Hop Options header is an integer
                        multiple of 64 bits long.  Contains one or more
                        TLV-encoded options, as described in section
                        4.2.

   The only hop-by-hop option defined in this document is the Pad
   option specified in section 4.2.


4.4  Routing Header

   The Routing header is used by an IPv5 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.  This function is very similar to IPv4's Loose Source
   and Record Route option.  The Routing header is identified by 
   a Protocol value of 43 in the immediately preceding header, and has the
   following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Protocol                 | 0 |  Hdr Ext Len  |  Routing Type |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Segments Left |                                               |
    +-+-+-+-+-+-+-+-+                                               +
    .                                                               .
    .                       type-specific data                      .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol             14-bit selector.  Identifies the type of header
                        immediately following the Hop-by-Hop Options
                        header.  Uses the similar values as the IPv4
                        Protocol field [RFC-1700 et seq.], with extras.

   ...followed by 2 zeroes. (padding)

   Hdr Ext Len          8-bit unsigned integer.  Length of the Routing
                        header in 8-octet units, not including the first
                        16 bits.

   Routing Type         8-bit identifier of a particular Routing header
                        variant.

   Segments Left        8-bit unsigned integer.  Number of route
                        segments remaining, i.e., number of explicitly
                        listed intermediate nodes still to be visited
                        before reaching the final destination.

   type-specific data   Variable-length field, of format determined by
                        the Routing Type, and of length such that the
                        complete Routing header is an integer multiple
                        of 8 octets long.

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.

   If, after processing a Routing header of a received packet, an
   intermediate node determines that the packet is to be forwarded onto
   a link whose link MTU is less than the size of the packet, the node
   must discard the packet and send an ICMP Packet Too Big message to
   the packet's Source Address.


   The Type 0 Routing header has the following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Protocol                 | 0 |  Hdr Ext Len  | Routing Type=0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Segments Left |            Reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Padding Zeroes            |                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-Address[1]                          +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Padding Zeroes            |                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-Address[2]                          +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                               .                               .
    .                               .                               .
    .                               .                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Zeroes                    |                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-Address[n]                          +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol             14-bit selector.  Identifies the type of header
                        immediately following the Hop-by-Hop Options
                        header.  Uses the similar values as the IPv4
                        Protocol field [RFC-1700 et seq.], with extras.

   ...followed by 2 zeroes. (padding)

   Hdr Ext Len          8-bit unsigned integer.  Length of the Routing
                        header in 8-octet units, not including the first
                        16 bits.

   Routing Type         0.

   Segments Left        8-bit unsigned integer.  Number of route
                        segments remaining, i.e., number of explicitly
                        listed intermediate nodes still to be visited
                        before reaching the final destination.

   Reserved             24-bit reserved field.  Initialized to zero for
                        transmission; ignored on reception.

   Address[1..n]        Vector of 50-bit addresses, numbered 1 to n.
                        Pre-padded by a set of 14 zero bits, for a data
                        structure of 64-bits.

   Multicast addresses must not appear in a Routing header of Type 0, or
   in the IPv5 Destination Address field of a packet carrying a Routing
   header of Type 0.

   A Routing header is not examined or processed until it reaches the
   node identified in the Destination Address field of the IPv6 header.
   In that node, dispatching on the Next Header field of the immediately
   preceding header causes the Routing header module to be invoked,
   which, in the case of Routing Type 0, performs the following
   algorithm:

   if Segments Left = 0 {
      proceed to process the next header in the packet, whose type is
      identified by the Next Header field in the Routing header
   }
   else if Hdr Ext Len is odd {
         send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Hdr Ext Len field, and discard the
         packet
   }
   else {
      compute n, the number of addresses in the Routing header, by
      dividing Hdr Ext Len by 2

      if Segments Left is greater than n {
         send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Segments Left field, and discard the
         packet
      }
      else {
         decrement Segments Left by 1;
         compute i, the index of the next address to be visited in
         the address vector, by subtracting Segments Left from n

         if Address [i] or the IPv6 Destination Address is multicast {
            discard the packet
         }
         else {
            swap the IPv6 Destination Address and Address[i]

            if the IPv6 Hop Limit is less than or equal to 1 {
               send an ICMP Time Exceeded -- Hop Limit Exceeded in
               Transit message to the Source Address and discard the
               packet
            }
            else {
               decrement the Hop Limit by 1

               resubmit the packet to the IPv6 module for transmission
               to the new destination
            }
         }
      }
   }

   As an example of the effects of the above algorithm, consider the
   case of a source node S sending a packet to destination node D, using
   a Routing header to cause the packet to be routed via intermediate
   nodes I1, I2, and I3.  The values of the relevant IPv6 header and
   Routing header fields on each segment of the delivery path would be
   as follows:

   As the packet travels from S to I1:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I1            Segments Left = 3
                                            Address[1] = I2
                                            Address[2] = I3
                                            Address[3] = D

   As the packet travels from I1 to I2:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I2            Segments Left = 2
                                            Address[1] = I1
                                            Address[2] = I3
                                            Address[3] = D

   As the packet travels from I2 to I3:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I3            Segments Left = 1
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = D

   As the packet travels from I3 to D:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = D             Segments Left = 0
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = I3

4.6  Destination Options Header

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s).  The
   Destination Options header is identified by a Next Header value of 60
   in the immediately preceding header, and 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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Protocol                | 0 |  Hdr Ext Len  |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol             14-bit selector.  Identifies the type of header
                        immediately following the Hop-by-Hop Options
                        header.  Uses the similar values as the IPv4
                        Protocol field [RFC-1700 et seq.], with extras.

   ...followed by 2 zeroes. (padding)

   Hdr Ext Len          8-bit unsigned integer.  Length of the
                        Destination Options header in 64-bit units, not
                        including the first 64 bits.

   Options              Variable-length field, of length such that the
                        complete Destination Options header is an
                        integer multiple of 8 octets long.  Contains one
                        or  more TLV-encoded options, as described in
                        section 4.2.

   The only destination option defined in this document is the Pad
   option specified in section 4.2.

   Note that there are two possible ways to encode optional destination
   information in an IPv5 packet: either as an option in the Destination
   Options header, or as a separate extension header.  The Authentication
   header are examples of the latter
   approach.  Which approach can be used depends on what action is
   desired of a destination node that does not understand the optional
   information:

      o  If the desired action is for the destination node to discard
         the packet and, only if the packet's Destination Address is not
         a multicast address, send an ICMP Unrecognized Type message to
         the packet's Source Address, then the information may be
         encoded either as a separate header or as an option in the
         Destination Options header whose Option Type has the value 11
         in its highest-order two bits.  The choice may depend on such
         factors as which takes fewer octets, or which yields better
         alignment or more efficient parsing.

      o  If any other action is desired, the information must be encoded
         as an option in the Destination Options header whose Option
         Type has the value 00, 01, or 10 in its highest-order two bits,
         specifying the desired action (see section 4.2).

4.7 No Next Header

   The value 59 in the Next Header field of an IPv6 header or any
   extension header indicates that there is nothing following that
   header.  If the Payload Length field of the IPv6 header indicates the
   presence of octets past the end of a header whose Next Header field
   contains 59, those octets must be ignored, and passed on unchanged if
   the packet is forwarded.

4.8  Virtual Router Forwarding (VRF) extension, type 1

   Proposed Protocol number = 258. (to be assigned by IANA)

   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 Layer3 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 IPv5 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|   Protocol                |  Virtual Router Forwarding label  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)
   Protocol             14-bit selector.  Identifies the type of header
                        immediately following this VRF header.  Uses
                        similar values as the IPv4 Protocol field
                        [RFC-1700 et seq.], with extra options.

   Virtual Router Forwarding label. 18-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. Otherwise it is a security issue.

   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.8.1.  Virtual Router Forwarding (VRF) extension, type 2

   Proposed Protocol number = 259. (to be assigned by IANA)

   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 de-capsulate 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|   Protocol                |                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
   8|               Encapsulating Router Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  12|   Reserved                |                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
  16|               Decapsulating Router Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  20|               Virtual Router Forwarding label                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Protocol             14-bit selector.  Identifies the type of header
                        immediately following this VRF header.  Uses
                        similar values as the IPv4 Protocol field
                        [RFC-1700 et seq.], with extra options.
   
   Encapsulating Router. 18-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. 18-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 field       Must be set to zero on transmit; ignored on receive,
                        unless specified otherwise by a routing protocol.
                        Optionally may be used as a flow or ToS field,
                        or additional 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.9  Flow Label extension

   Proposed Protocol number = 270. (to be assigned by IANA)

   The 18-bit Flow Label field in the IPv5 header may be used by a
   source to label sequences of packets for which it requests special
   handling by the IPv5 routers, such as non-default quality of service
   or "real-time" service.  This aspect of IPv5 is experimental and subject
   to change as the requirements for flow support in become clearer.
   Hosts or routers that do not support the functions of the Flow Label 
   field are SHOULD pass the extension unchanged when forwarding a packet,
   and ignore the field when receiving a packet.

   This extensions emulates the "Flow" field of an IPv6 packet.

   The Flow label 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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Protocol                |            Flow label             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protocol Header      14-bit selector.  Identifies the type of header
                        immediately following the Routing header.  Uses
                        similar values as the IPv4 Protocol field
                        [RFC-1700 et seq.], with extra options.

   Flow label.          18-bit selector. Describes a sequence of packets.

5. Packet Size Issues

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

   Links that have a configurable MTU (for example, PPP links [RFC-
   1661]) must be configured to have an MTU of at least 1320 octets; it
   is recommended that they be configured with an MTU of 1500 octets 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 IPv5 nodes implement Path MTU
   Discovery [RFC-1981], in order to discover and take advantage of path
   MTUs greater than 1320 octets.  However, a minimal IPv5
   implementation (e.g., in a boot ROM) may simply restrict itself to
   sending packets no larger than 1320 octets, and omit implementation
   of Path MTU Discovery.

7.  Type of Service

   The 8-bit Type of Service field in the IPv5 header is available for use
   by originating nodes and/or forwarding routers to identify and
   distinguish between different classes or priorities of IPv5 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 IPv6 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 8 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.


8. Upper-Layer Protocol Issues

8.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 IPv5, to include the 50-bit IPv5 addresses
   instead of 32-bit IPv4 addresses.  In particular, the following
   illustration shows the TCP and UDP "pseudo-header" for IPv5:

    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                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved                    |   Upper-Layer Packet Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o  If the IPv5 packet contains a Routing header, the Destination
         Address used in the pseudo-header is that of the final
         destination.  At the originating node, that address will be in
         the last element of the Routing header; at the recipient(s),
         that address will be in the Destination Address field of the
         IPv5 header.

      o  If the IPv5 packet contains a VRF header, the label must not be
         included in the checksum calculation, as this field is mutable, 
         and can be changed by any router along the way.

      o  The Protocol value in the pseudo-header identifies the
         upper-layer protocol (e.g., 6 for TCP, or 17 for UDP).  It will
         differ from the Protocol value in the IPv5 header if there
         are extension headers between the IPv5 header and the upper-
         layer header.

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

         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 IPv5 header, minus
         the length of any extension headers present between the IPv5
         header and the upper-layer header.

      o  Unlike IPv4, when UDP packets are originated by an IPv5 node,
         the UDP checksum is not optional.  That is, whenever
         originating a UDP packet, an IPv5 node must compute a UDP
         checksum over the packet and the pseudo-header, and, if that
         computation yields a result of zero, it must be changed to hex
         FFFF (or 0xFFFF FFFF) for placement in the UDP header.  
         IPv5 receivers must discard UDP packets containing a zero checksum,
         and should log the error.

   The IPv5 version of ICMP [ICMPv5] 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 IPv5 header on which it depends,
   which, unlike IPv4, are not covered by an internet-layer checksum.
   The Next Header field in the pseudo-header for ICMP contains the
   value 58, which identifies the IPv5 version of ICMP.

8.2 Maximum Packet Lifetime

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

   Unlike IPv4, IPv5 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 decides so.

8.4 Responding to Packets Carrying Routing Headers

   When an upper-layer protocol sends one or more packets in response to
   a received packet that included a Routing header, the response
   packet(s) must not include a Routing header that was automatically
   derived by "reversing" the received Routing header UNLESS the
   integrity and authenticity of the received Source Address and Routing
   header have been verified (e.g., via the use of an Authentication
   header in the received packet).  In other words, only the following
   kinds of packets are permitted in response to a received packet
   bearing a Routing header:

      o  Response packets that do not carry Routing headers.

      o  Response packets that carry Routing headers that were NOT
         derived by reversing the Routing header of the received packet
         (for example, a Routing header supplied by local
         configuration).

      o  Response packets that carry Routing headers that were derived
         by reversing the Routing header of the received packet IF AND
         ONLY IF the integrity and authenticity of the Source Address
         and Routing header from the received packet have been verified
         by the responder.


Appendix B. Formatting Guidelines for Options

   This appendix gives some advice on how to lay out the fields when
   designing new options to be used in the Hop-by-Hop Options header or
   the Destination Options header, as described in section 4.2.  These
   guidelines are based on the following assumptions:

      o  One desirable feature is that any multi-octet fields within the
         Option Data area of an option be aligned on their natural
         boundaries, i.e., fields of width n octets should be placed at
         an integer multiple of n octets from the start of the Hop-by-
         Hop or Destination Options header, for n = 1, 2, 4, or 8.

      o  Another desirable feature is that the Hop-by-Hop or Destination
         Options header take up as little space as possible, subject to
         the requirement that the header be an integer multiple of 8
         octets long.

      o  It may be assumed that, when either of the option-bearing
         headers are present, they carry a very small number of options,
         usually only one.

   These assumptions suggest the following approach to laying out the
   fields of an option: order the fields from smallest to largest, with
   no interior padding, then derive the alignment requirement for the
   entire option based on the alignment requirement of the largest field
   (up to a maximum alignment of 8 octets).  This approach is
   illustrated in the following examples:

   Example 1

   Option X required two data fields, one of length 8 octets and
   one of length 4 octets.
   Its alignment requirement is 8n+2, to ensure that the 8-octet field
   starts at a multiple-of-8 offset from the start of the enclosing
   header.  A complete Hop-by-Hop or Destination Options header
   containing this one option would look as follows:

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol                 | 0 | Hdr Ext Len=2 |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |       0       |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |       0       | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         8-octet field                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where Zero-fields are the padding option:

   +-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Example 2

   If an option Y required three data fields, one of length 4 octets,
   one of length 2 octets, and one of length 1 octet, its alignment 
   requirement is 4n+3, to ensure that the 4-octet field
   starts at a multiple-of-4 offset from the start of the enclosing
   header.  A complete Hop-by-Hop or Destination Options header
   containing this one option would look as follows:

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol                 | 0 | Hdr Ext Len=1 | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Opt Data Len=7 | 1-octet field |         2-octet field         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |       0       |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Example 3

   A Hop-by-Hop or Destination Options header containing both options X
   and Y from Examples 1 and 2 would have one of the two following
   formats, depending on which option appeared first:

   A less efficient, but valid variant would be:

    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|  Protocol                 | 0 | Hdr Ext Len=4 |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|       0       |       0       |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|       0       |       0       | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|                         4-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20|                                                               |
   +                         8-octet field                         +
 24|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 28|       0       |       0       |       0       | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 32|Opt Data Len=7 | 1-octet field |         2-octet field         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 36|                         4-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 40|       0       |       0       |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   An efficient variant would be:

    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|  Protocol                 | 0 | Hdr Ext Len=3 | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|Opt Data Len=7 | 1-octet field |         2-octet field         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|                         4-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|       0       |       0       |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20|       0       |       0       | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|                         4-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 28|                                                               |
   +                         8-octet field                         +
 32|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The difference is due to the 8-octet alignment optimization.

Acknowledgments

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

Authors' Contacts

   Alexey Eromneko
   Israel

   Skype: Fenix_NBK_
   EMail: al4321@gmail.com

References

   [ICMPv6]     Conta, A. and S. Deering, "ICMP for the Internet
                Protocol Version 6 (IPv6)", RFC 2463, December 1998.

   [ADDRARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 2373, July 1998.

   [RFC-1981]   McCann, J., Mogul, J. and S. Deering, "Path MTU
                Discovery for IP version 6", RFC 1981, August 1996.

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

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

   [RFC-1661]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD
                51, RFC 1661, July 1994.

Full Copyright Statement

   Copyright (C) Alexey Eromenko, based on the previous work of 
   The Internet Society.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




Alexey            Standards Track                    [Page ..]

