[rbridge] An IPvLX Study

[Fred L. Templin]

Joe Touch and I have been discussing off-list about a study
I have been involved with over the past few years which has
resulted in the following two Internet-Drafts:

  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-05.txt

and an updated version that will obsolete both of these at:

  http://ipvlx.com/IPVLX.txt

The study proposes mechanisms and operational practices for
establishing virtual links between IP peer end nodes. The virtual
link can provide authentication (e.g., using Secure Neighbor
Discovery - SEND) and confidentiality (e.g., using IPSec). In
some cases, the virtual link can be extended all the way to the
end nodes but in other cases it may be desireable to terminate
the link at a router in the end node's network, e.g., to protect
people and assets from would-be attackers. (Both alternatives are
supported in the model proposed by the study.)

The study proposes IPv6 as the L3 protocol for end-node addressing
and IPv4 as the L2 protocol, i.e., IPv6-in-IPv4 tunneling, but it
could easily be extended to deal generically with IP-in-IP tunneling
(where "IP" could refer to any IP version). The study proposes special
nodes called: "IPvLX Gateways" that get involved in establishing and
providing transit switching for virtual links. These nodes exhibit
some of the same hybrid routing/bridging features proposed for Rbridges,
and can be deployed incrementally without requiring flag-day upgrades
of existing routers and bridges. In fact, IPvLX gateways need only
be deployed in the same locations that an IPv4 NAT would be deployed.

While the study presents a big-picture proposal for a next-generation
Internet architecture, it is also useful to consider the component
aspects seperately. In particular:

  1) Autoconfiguration - IPvLX nodes automatically configure
     themselves for operation with zero configuration.

  2) Encapsulation - the study proposes a special encapsulation in
     the L2 (IPv4) header to encode flow identification information.

  3) Link adaptation - the study proposes a link adaptation scheme
     used by virtual link endpoints to dynamically determine the
     best-fit L2 segment size (without packet loss) while presenting
     a uniform MTU to L3.

  4) Virtual link extension - the study proposes methods for
     establishing virtual links through Secure Neighbor Discovery
     and establishing soft state for flow switching in intermediate
     IPvLX gateways.

  5) Error handling - a method for relaying ICMPv4 error messages
     back to the IPvLX gateway at the near-end of a virtual link
     is proposed.

  6) Mobilitiy - aspects of IPvLX node mobility are discussed.
       

Although this study is now concluded, it is my sincere hope
that some/all of its aspects may be found useful for adoption
as work items for this group and that others will be interested
in helping to carry the work forward.

Please send any questions/comments,

Fred L. Templin
American Kestrel Consulting
fltemplin at acm.org