Hi Fred,
(to the IPv6 wg only)
It may be worth mentioning, before you get a huge amount of IPv6-WG ire flamed down upon you that the IPVLX BoF was discussing some related ideas at the past IETF 60.
It was not in all proposals that IPv4 were being used as transport, nor were the v4/v6 implications being discussed.
The concept has some different applications than just replacing IPv6 (;-) and these are being discussed on the [EMAIL PROTECTED] mailing list.
Greg Daley
Fred Templin wrote:
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 [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------