INTERNET-DRAFT "Internet Protocol - Five Fields", Alexey Eromenko, 2016-01-02, expiration date: 2016-07-02 Intended status: Standards Track A.Eromenko January 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 attempts to build a hybrid between IPv4 and IPv6, improving 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) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. IPFF 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 Virtual Router Forwarding (VRF) extension............... 4.6 Destination Options Header..............................23 4.7 No Extension............................................24 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 and adding new, and optimizing the old. A hybrid between the two, plus plus. 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 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. Derived from IPv6. o Virtual Router Forwarding (VRF) / Layer 3 VPN extension 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 Address Resolution Protocol (ARP) now became Link Address Resolution Algorithm (LARA). It is now computed on the CPU. 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 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), divided into Link Address Resolution Algorithm (LARA), 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, (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 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] 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. 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| Type of Service | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Protocol | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Source Port / Flow | Destination Port / Flow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24| Hops to Live | Extension | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) Version 4-bit Internet Protocol version number = 5. Type of Service 10-bit type of service field. See section 6. 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] and section 4.4. 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 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. Extension 6-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. Payload Length 16-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.) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So a complete IP header may look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4|Version| Type of Service | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Protocol | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24| Hops to Live | Extension | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) Despite a visual difference to the human, there is no logical difference to the router, which is why this field is interchangeable. From the router's standpoint 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 With IP-FF, the router can use a 6-tuple to make Flow based decisions in the following way: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4|Version| Type of Service | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Protocol | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) 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, without ToS. As a bonus, having 5-tuple leads to faster firewalls in IP-FF. 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 160-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 1: During Flow-based routing, some "Extensions" may be relevant, including: Hop-by-Hop, Routing and VRF headers. NOTE 2: 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". 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. 4. IPFF Extension Headers 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 Protocol value. As illustrated in these examples, an IPFF packet may carry zero, one, or more extension headers, each identified by the Protocol 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 | | +---------------+----------------+----------------+----------------- 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 IPFF header. There, normal demultiplexing on the Protocol field of the IPFF 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 Protocol. 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 follow the IPFF header and VRF. Its presence is indicated by a pre-defined value in the Extension field of the IPFF (or VRF) header. Another exception is the VRF extension header, which every router along the way should must examine according to its routing protocol, and, if VRF extension is present, but not supported by router implementation, drop the packet. If, as a result of processing a header, a node is required to proceed to the Extension but the Extension 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 Extension type encountered"). Each extension header is an integer multiple of 8 bytes long, in order to retain 8-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, 4, or 8. A full implementation of IPFF includes implementation of the following extension headers: Hop-by-Hop Options Destination Options The first four are specified in this document; the last two are specified in [RFC-2402] and [RFC-2406], respectively. In IP-FF, as in most computing architectures, byte is defined as 8-bits. 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: IPFF header VRF header type 1 VRF header type 2 Hop-by-Hop Options header Destination Options header (note 1) Routing header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) No extension header (Extension = 0) upper-layer header note 1: for options to be processed by the first destination that appears in the IPFF 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), and except the VRF header, which may occur multiple times. 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. If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified. IPFF 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 VRF and Hop-by-Hop Options header which are restricted to appear in this particular order, immediately after an IPFF header only. Nonetheless, it is strongly advised that sources of IPFF 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 bytes. 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 IPFF 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 (from IPsec) 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 bytes 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-byte 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 bytes from the start of the header, plus y bytes. For example: 2n means any 2-byte offset from the start of the header. 8n+2 means any 8-byte offset from the start of the header, plus 2 bytes. 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 bytes in length. This padding option must be recognized by all IPFF 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 byte of padding into the Options area of a header. Appendix A 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 Extension value of 3 in the IPFF header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension 8-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 IPFF 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 Extension value of 43 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension 8-bit selector. Identifies the next extension. Hdr Ext Len 8-bit unsigned integer. Length of the Routing header in 8-byte 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 bytes 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 Protocol in the packet, whose type is identified by the Protocol 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. 4.5 Virtual Router Forwarding (VRF) extension, type 1 Proposed Extension number = 1. (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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) Extension 8-bit selector. Identifies the next extension. Virtual Router Forwarding label. 24-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 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. 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.5.1. Virtual Router Forwarding (VRF) extension, type 2 Proposed Extension number = 2. (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 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 | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8| Encapsulating Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| Decapsulating Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Virtual Router Forwarding label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) Extension 8-bit selector. Identifies the next extension. 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.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 Extension value of 4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension 8-bit selector. Identifies the next extension. 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 bytes 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 IPFF 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 bytes, 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 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. 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 10-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 If the IPFF 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 IPFF header. 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 IPFF header if there are extension headers between the IPFF header and the upper- layer header. o Ports should be included by protocols, that use them. Else zero. 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 IPFF header, minus the length of any extension headers present between the IPFF header and the upper-layer header. The IPFF version of ICMP [ICMPFF] 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. The Protocol field in the pseudo-header for ICMP contains the value 58, which identifies the IPFF version of ICMP. 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. 7.3 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 A. Formatting Guidelines for Options [ this section is similat to IPv6 specification ] 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-byte fields within the Option Data area of an option be aligned on their natural boundaries, i.e., fields of width n bytes should be placed at an integer multiple of n bytes 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 bytes 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 bytes). This approach is illustrated in the following examples: Example 1 If an option X required two data fields, one of length 8 bytes and one of length 4 bytes, it would be laid out as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-byte field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its alignment requirement is 8n+2, to ensure that the 8-byte 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-byte field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example 2 If an option Y required three data fields, one of length 4 bytes, one of length 2 bytes, and one of length 1 byte, it would be laid out as follows: +-+-+-+-+-+-+-+-+ | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-byte field | 2-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its alignment requirement is 4n+3, to ensure that the 4-byte 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-byte field | 2-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-byte field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-byte field | 2-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-byte field | 2-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=4 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-byte field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-byte field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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: 2016-07-02