Intended status: Standards Track A.Eromenko December 2015
draft-eromenko-ipff-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Alexey Eromenko | ||
| Last updated | 2015-12-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eromenko-ipff-00
INTERNET-DRAFT
"Internet Protocol - Five Fields",
Alexey Eromenko, 2015-12-10,
<draft-eromenko-ipff-00.txt>
expiration date: 2016-06-10
Intended status: Standards Track
A.Eromenko
December 2015
Internet Protocol, Version 5 (IPv5)
a.k.a IP-FF (Internet Protocol - Five Fields)
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."
This Internet-Draft will expire on December 9, 2014.
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
3. IPFF Header Format............................................4
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 Flow Label extension....................................
4.6 Destination Options Header..............................23
4.7 No Protocol.............................................24
4.8 Virtual Router Forwarding (VRF) extension...............24
5. Packet Size Issues...........................................24
6. Traffic Classes..............................................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]
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 1320
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 Broadcasts. Multicasts are effectively more efficient versions
of those, just filtered at a different layer.
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]
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 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 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, that have replaced Broadcast
of IPv4. 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.
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 or a set of
interfaces.
packet - an IPFF 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 [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.
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 IPFF
payload, i.e., the rest of the packet following
this IPFF 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. 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 |
+---------------+------------------------
+---------------+----------------+------------------------
| IPFF header | Routing header | TCP header + data
| | |
| Protocol = | Protocol = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+----------------+-----------------
| IPFF 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 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 immediately follow the IPFF header. Its presence
is indicated by the value zero in the Protocol field of the IPFF
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 Protocol but the Protocol 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 Protocol value of zero in any header other
than an IPFF 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 IPFF 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.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
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 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).
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 Hop-by-Hop Options header which is restricted to
appear 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 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 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
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 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 octet 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 Protocol value of
0 in the IPFF 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 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 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 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.
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 IPFF 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 Protocol 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 Protocol in the packet, whose type is
identified by the Protocol 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.5 Flow Label extension
Proposed Protocol number = 270. (to be assigned by IANA)
The 18-bit Flow Label field in the IPFF header may be used by a
source to label sequences of packets for which it requests special
handling by the IPFF routers, such as non-default quality of service
or "real-time" service. This aspect of IPFF 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.
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 Protocol 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 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 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 Protocol
The value 59 in the Protocol 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 Protocol 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 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| 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.
5. Packet Size Issues
IPFF 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 IPFF.
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 IPFF nodes implement Path MTU
Discovery [RFC-1981] similarly to IPv6, in order to discover and take
advantage of path MTUs greater than 1320 octets. However, a minimal
IPFF 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.
6. Type of Service
The 8-bit Type of Service field in the IPFF header is available for
use by originating nodes and/or forwarding routers to identify and
distinguish between different classes or priorities of IPFF 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.
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | 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 If the IPFF 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 IPFF header if there
are extension headers between the IPFF 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 IPFF header, minus
the length of any extension headers present between the IPFF
header and the upper-layer header.
o Unlike IPv4, when UDP packets are originated by an IPFF node,
the UDP checksum is not optional. That is, whenever
originating a UDP packet, an IPFF 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.
IPFF receivers must discard UDP packets containing a zero
checksum, and should log the error.
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 255 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 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" & "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 only 1%.
Authors' Contacts
Alexey Eromenko
Israel
Skype: Fenix_NBK_
EMail: al4321@gmail.com
References
[ICMPFF] "ICMP for the Internet Protocol Five Fields" by
Alexey.E.
[IPFF-ADDRARCH] "IP Five Fields Addressing Architecture" by Alexey.E.
[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
INTERNET-DRAFT
Alexey
expiration date: 2016-06-10