IPvLX

[Fred Templin <ftemplin@iprg.nokia.com>]

Hello,

With Nokia hat off, I would like to announce a proposal for IPng
called: "IPvLX - IP with virtual Link eXtension". See:

 http://www.ietf.org/internet-drafts/draft-templin-ipvlx-00.txt

IPvLX uses IPv4 as an L2 protocol for network traversal and IPv6
as an L3 addressing protocol. It inserts an L2.5 "shim" layer between
the IPv4 header and upper layer protocol headers, and establishes
virtual links between peers using IPv6 neighbor discovery messages
for control plane signalling.

IPvLX uses a special IPv4 header construction that encodes VCI/VPI
information for virtual circuit switching in IPvLX Gateways. This
allows virtual link extension between peers located in different
enterprises/sites.

IPvLX is compatible with legacy IPv4 hosts and routers, and requires
no "flag day" changes in the Internet. It provides an adaptation layer
similar to AAL5 for efficient multiaccess segment sizing based on
path MTU.

IPvLX is a unified package combining familiar mechanisms having
various degrees of operational experience, and presents a potential
"one size fits all" alternative for IPng. Please respond on the list
with any comments/questions.

Fred L. Templin
ftemplin@iprg.nokia.com

P.S. An appendix on multiprotocol support that did not make
  it in time for the I-D submission is attached below.

Appendix B.  IPvLX as a Layer 2.5 Shim

   Section 4 presents IPvLX as boh an IPv4 encapsulation method and an
   IPv6 header compression method that is tightly coupled with IPv6 as
   both the addressing (control plane) mechanism and data exchange (data
   plane) protocol. IPvLX could instead be decoupled from IPv6 and
   specified as a distinct Layer 2.5 "shim" between IPv4 as the L2
   protocol and any IP protocol in the IANA "Protocol Numbers" registry
   as the L3 protocol. In this model, IPv6 would serve as the control
   plane mechanism to set up virtual links between peers that can
   support data plane exchanges using any IP protocol.

   The IPvLX Flow Header (see: section 4.4.2) could be trivially
   extended to support this multiprotocol operation by adding a 1 byte
   "Protocol" field the same as for the IPv4 "Protocol" ([RFC0791],
   section 3.1) and IPv6 "Next Header" ([RFC2460], section 3) fields as
   follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|    Protocol   |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version         4-bit version number - value TBA by IANA.

   Protocol        8-bit field; indicates the IANA IP protocol number
                   exactly as for the IPv4 "Protocol" and IPv6 "Next
                   Header" fields.

   Flow Label      20-bit flow label [RFC3697].

   With this extended format, the IPvLX Flow Header becomes 4 bytes in
   length instead of just 3 and would occur immediately following the
   20-byte IPv4 header in all IPvLX packets (see: section 4.2.1) as
   follows:

                  +-------------------------------+
                  |     IPv4 Header (20 bytes)    |
                  |                               |
                  | RF = DF = 1; MF = [0|1]       |
                  | 1 <= SEGID <= 31              |
                  | 23 < Length <= (20 + SEGSIZE) |
                  |                               |
                  +-----------------------+-------+
                  |  IPvLX Flow Header (4 bytes)  |
                  +-------------------------------+
                  |                               |
                  ~ Up to (SEGSIZE - 4) PDU bytes ~
                  |                               |
                  +-------------------------------+

                    Format for all IPvLX packets

   The extended format has the disadvantage of consuming 1 extra byte
   per IPvLX packet, and reducing the maximum IPvLX PDU Payload (see:
   section 4.2) to (2^16 - (32 * 4) - 1) = 65407 bytes. These
   disadvantages are outweighed by numerous advantages, including:

       -  IPvLX gateways can process all IPvLX packets in fast-path
          since the 4-byte IPvLX Flow Header occurs in all packets.

       -  Awkward, special-case encodings that lead to slow path
          handling (e.g., the IPvLX Fragment Header - see: section
          4.4.3) are no longer needed.

       -  The 4-byte IPvLX Flow Header following the 20-byte IPv4 header
          provides a natural 8-byte alignment needed for any protocol
          headers that follow (e.g., IPv6 header extensions).

       -  The "Protocol" field allows multiprotocol operation on the
          data plane with IPv6 as the control plane mechanism for
          virtual link setup.