[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                            James Stepanek
                                               The Aerospace Corporation
                                                          Stephen Schwab
                                                            Twin Sun Inc

                VIPRE -- Virtual Internet Packet Relay
         An Encapsulation Architecture for Unidirectional Links

                             November 1997

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


   This memo describes a method of incorporating unidirectional links
   into an IP network in a bidirectional mode by relaying encapsulated
   IP packets over a bidirectional network.

1.  Introduction

   Successful incorporation of asymmetric, unidirectional satellite
   links into a internetwork requires special treatment of those links.
   The design of many protocols commonly used in the Internet assume the
   existence of symmetrical, bidirectional links between nodes.  As a
   result, many of these same protocols do not work as intended over
   links which are asymmetric, unidirectional, or both.  Asymmetric
   network topologies, for example, those which incorporate satellite
   links, primarily affect protocols which use link-dependent state for
   their operation.  This usually occurs whenever the network needs to
   treat a link as a distinct resource.  Examples of this include
   protocols which handle routing and group management, as well as
   link-bound heuristics of transport protocols and management software.

   For example, consider a host with connectivity through two

Schwab and Stepanek       Expires August 1997                   [Page 1]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   interfaces, in other words, a "multi-homed" host.  On this host, one
   interface forms the receiving end of a connection to a
   unidirectional, high-bandwidth satellite link.  The second interface
   connects the host to a low-bandwidth, bidirectional terrestrial
   network.  Ideally, an internetwork in this topology makes use of the
   satellite link where appropriate while still behaving much like a
   common symmetrical internet.

   This document describes one approach to incorporating unidirectional
   satellite links into an internet--the Virtual Internet Packet Relay
   (VIPRe).  This document describes an architecture for incorporating
   unidirectional links into an internet--reducing the problem of
   unidirectional links to the more general problem of asymmetric links.

   Note that while this approach was developed for use in unidirectional
   satellite links, it could quite possibly be used on other types of
   unidirectional links.

   Before describing the details of the architecture, a couple of
   alternative existing approaches are summarized for the below for the
   purposes of discussion.

1.1.  Terminology

   For the purposes of this discussion, consider two types of network
   nodes with connections to a unidirectional satellite links.  "Uplink"
   nodes have the ability to send data over a unidirectional link, while
   "downlink" nodes have the ability to receive data from a
   unidirectional link.

1.2.  Split Routing

   A simple, straight-forward approach modifies routing tables on the
   uplink and downlink nodes.  By introducing a static "split" route on
   both the downlink and uplink nodes, traffic originating from downlink
   and destined for uplink nodes is always sent out a bidirectional
   interface.  Similarly, traffic originating from a uplink host and
   destined for a down link node is always sent out the unidirectional
   interface.  This allows some IP traffic to flow between the uplink
   and downlink nodes much as it does in a "normal" internet.  However,
   for large networks maintaining the static "split" routes requires
   significant system management.  Also, protocols with bidirectional
   link assumptions remain broken under this routing configuration.

1.3.  Routing Protocol Modification

   Another method of dealing with unidirectional links involves
   modifying routing protocols to account for one-way hops.  The
   modified routing processes share information with each other for the
   purpose of directing traffic in a "split" fashion.  Essentially, this
   incorporates a mechanism for "discovery" of uplink nodes by downlink
   nodes, as well as a mechanism for distributing routing information
   from downlink nodes back to uplink nodes directly.  By handling the
   problem directly, this approach offers the most general of solutions.

Schwab and Stepanek       Expires August 1997                   [Page 2]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   In fact in addition to routing protocols, it's expected that many
   protocols require modification or extensions to remove asymmetric
   links assumptions.

1.4.  Virtual Packet Relays

   A third approach, uses a "relay", or one-way tunnel, to transmit
   packets back to the uplink node.  Virtual Packet Relays, described
   here in detail, attempt to make a functionally bidirectional
   interface out of a unidirectional interface.  To achieve this,
   traffic sent out the unidirectional interface of the downlink node is
   captured somewhere beneath the network layer and relayed through a
   bidirectional interface on the downlink node to a bidirectional
   interface on the uplink node.  Once the captured data arrives at the
   uplink node, it's taken out of the relay and injected into the
   unidirectional interface of the uplink node where it's received as a
   "normal" network packet by the uplink node.

   Using a Virtual Packet Relay to deal with unidirectional links
   differs slightly from the other approaches described earlier.  Unlike
   the "split" route approach, using a Virtual Packet Relay does not
   require modification of routing table entries for attached networks.
   This means packets originating on downlink nodes which are destined
   for uplink nodes can be sent out the unidirectional interface of the
   downlink node, as if this interface were bidirectional.  For this
   reason, some protocols which include bidirectional link assumptions
   will operate unmodified under this architecture.

   A Virtual Packet Relay provides functionality similar to "split" IP
   routing, but hides the details of the one-way network from IP route
   tables and routing protocols.  This holds the appealing property of
   allowing some existing protocols to function in this environment
   without modification.  However, this approach assumes that uplink and
   downlink nodes are connected on a bidirectional network.  It also
   fails to handle the asymmetric nature of the bidirectional link it
   approximates.  In other words, the routing protocols in use will have
   to be configured to reflect the high cost of the virtual IP hop from
   receiver to uplink site.

   In effect, a Virtual Packet Relay creates a virtual network over
   which IP packets can flow as if there is a reverse path on the
   unidirectional link.  Bandwidth of this path is limited by the
   underlying bandwidth of the bidirectional internet, so bandwidth
   management of the reverse link is important.

   Implementing a Virtual Packet Relay requires two components.  On the
   uplink side, a relay "server" handles unencapsulating and injection
   of PDUs.  On the downlink side a relay "client" handles the capture
   and encapsulation of PDUs.  In practice, this is accomplished with a
   pair of "Split" Virtual Interfaces (SVIFs).  On the server side, a
   special interface exists which transmits data normally, but receives
   incoming traffic from a set of one or more relays.  On the client
   side, another special interface exists which receives traffic
   normally, but transmits outgoing traffic through a set of one or more

Schwab and Stepanek       Expires August 1997                   [Page 3]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   relays.  Together, these two components maintain one-way flows of
   encapsulated IP traffic, including two SVIFs on either side.

   In this architecture, relay clients keep a list of relay servers with
   which they participate, each with a set of corresponding relay
   endpoints.  And when a single relay client communicates with multiple
   relay servers, the client must use a separate SVIF for each.

                +----+       +---------------+
                |    |======>|\              |
                |SVIF|       | downlink node |
                |    |<===1==|/              |
                +----+       |               |
                   |         +--relay client-+
                   |              ^   |
                   +===2==>======>|   +---3---> relay server
                                         (via bidirectional network)

        ===> link traffic (below network layer)
        ---> IP traffic

                      Figure 1: Downlink Node Detail

                +---------------+       +----+
                |              /|======>|    |
                |  uplink node  |       |SVIF|
                |              \|<==6===|    |
                |               |       +----+
                +--relay server-+         |
                     |   |                ^
        -----4---->--+   +=======>===5===>|
        relay client
        (via bidirectional network)

        ===> link traffic (below network layer)
        ---> IP traffic

                       Figure 2: Uplink Node Detail

2.  ICMP Relay Discovery Protocol

   Before a relay client can provide a fully-functioning SVIF, it must
   know the IP address of at least one functioning "endpoint" of a relay

Schwab and Stepanek       Expires August 1997                   [Page 4]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   corresponding to that SVIF.  In other words, it must know where to
   send payload packets so they arrive at the relay server for this
   SVIF.  One method of acquiring this knowledge involves using
   configuration files to inform the relay client of all the relay
   servers it needs to know about.  Another possible method involves
   listening to exiting protocol traffic on the unidirectional link and
   deducing--based on this traffic--the addresses of suitable relay
   endpoints.  Since, both of these methods have drawbacks, a third
   method is described here, which relies heavily upon the concepts
   presented in ICMP Router Discovery [RFC1256].  Like ICMP Router
   Discovery, this method introduces a new ICMP message called a "Relay

   In fact, the ICMP Relay Discovery process works much like ICMP Router
   Discovery.  If a relay server wishes to advertise its willingness to
   accept relayed packets, it periodically sends Relay Advertisements on
   its unidirectional link.  Relay clients discover the relay endpoints
   by listening for Relay Advertisements on their unidirectional link.

   Like Router Advertisements, Relay Advertisement contain a "lifetime"
   field.  This specifies the maximum time that relay endpoints are
   considered valid in the absence of further Advertisements.  Relay
   clients use this value to maintain a timer for each relay.

   Unlike Router Advertisements, Relay Advertisements include a vector
   of "relay addresses" instead of a "router addresses".  They also omit
   the "preference" field found in Router Advertisements.  And unlike
   ICMP Router Discovery's "Router Addresses", the addresses advertised
   in Relay Advertisements will likely reside in different subnets or
   different networks than the address(s) of the interface which
   receives them.

2.1.  Message Formats

   ICMP Relay Advertisement Message

       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
      |     Type      |     Code      |           Checksum            |
      |   Num Addrs   |Addr Entry Size|           Lifetime            |
      |                        Relay Address[1]                       |
      |                        Relay Address[2]                       |
      |                               .                               |
      |                               .                               |
      |                               .                               |

   IP Fields:

Schwab and Stepanek       Expires August 1997                   [Page 5]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

      Source Address        An IP address belonging to the interface
                            from which this message is sent.

      Destination Address   The configured AdvertisementAddress or the
                            IP address of a neighboring host.

      Time-to-Live          1 if the Destination Address is an IP
                            multicast address; at least 1 otherwise.

   ICMP Fields:

      Type                  TBD

      Code                  0

      Checksum              The 16-bit one's complement of the one's
                            complement sum of the ICMP message, starting
                            with the ICMP Type.  For computing the
                            checksum, the Checksum field is set to 0.

      Num                   The number of relay endpoint addresses
                            advertised in this message.

      Addr Entry Size       The number of 32-bit words of information
                            per each relay address (1, in the version of
                            the protocol described here).

      Lifetime              The maximum number of seconds that the relay
                            addresses may be considered valid.

      Relay Address[i]      The addresses of the relay endpoints
                            advertised in this message, where i = 1..Num

2.2.  Relay Server Specification

2.2.1.  Relay Server Configuration Variables

   Relay Server Configuration Variables for ICMP Relay Discovery are
   analogous to the Router Configuration Variable in ICMP Router
   Discovery.  A relay server implementing ICMP Relay Discovery must
   allow configuration of the following variables by system management.

   The term "advertisement space" refers to a set of relays associated
   with a single SVIF for which a relay server sends Relay Advertisement
   messages.  For each advertisement space, the relay server maintains
   the following variables:

                The IP destination address to be used for Relay
                Advertisements sent for relays in the advertisement

Schwab and Stepanek       Expires August 1997                   [Page 6]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

                Default: if the relay server supports IP
                multicast on the SVIF interface, else

                The maximum time allowed between sending Relay
                Advertisements for relays in this advertisement space,
                in seconds.  As in ICMP Router Discovery, this must be
                no less than 4 seconds and no greater than 1800 seconds.

                Default: 600 seconds

                The minimum time allowed between sending multicast Relay
                Advertisements from relays in the advertisement space,
                in seconds.  As in ICMP Router Discovery, this must be
                no less than 3 seconds and no greater than

                Default: 0.75 * MaxAdvertisementInterval

   For each of its relays, the relay server's maintains the following

                A flag indicating whether or not the relay is to be

                Default: TRUE

2.2.2.  Relay Server Behavior

   For each advertisement space with at least one relay whose Advertise
   flag is TRUE, the relay server transmits periodic Relay
   Advertisements, with the following values.

     - In the destination address field of the IP header: the configured
       AdvertisementAddress for the advertisement space.

     - In the Lifetime field: the configured AdvertisementLifetime for
       the advertisement space.

     - In the Relay Address[i] fields: all the addresses of the relay
       endpoints in the advertisement space with Advertise flags marked

   To avoid unwanted synchronization, the interval between sending Relay
   Advertisements varies randomly.  Many other protocols which transmit
   "periodic" messages describe why and how to achieve this, including
   ICMP Router Discovery.

Schwab and Stepanek       Expires August 1997                   [Page 7]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

2.3.  Relay Client Specification

2.3.1.  Relay Client Configuration Variables

   Relay Client Configuration Variables for ICMP Relay Discovery are
   analogous to the Host Configuration Variable in ICMP Router
   Discovery.  A relay client implementing ICMP Relay Discovery must
   allow configuration of the following variables by system management.

   For each SVIF, a relay client maintains the following variables:

                A flag indicating whether or not the relay client
                performs ICMP Relay Discovery for the SVIF.

                Default: TRUE

   For SVIFs which will not perform ICMP Relay Discovery, the relay
   client must support a configurable list of relay endpoints.  The
   following variables exist for each SVIF not performing ICMP Relay

                The IP address of the endpoint of the desired relay for
                this SVIF.

                Default:  (none)

2.3.2.  Message Validation by Relay Clients

   Relay Advertisements are validated by relay clients in the same way
   that Router Advertisements are validated by hosts--as described in
   Section 5.2 of RFC 1256--except when validating Relay Advertisements,
   the ICMP Addr Entry Size must be greater than or equal to 1, instead
   of greater that or equal to 2.

2.3.3.  Relay Client Behavior

   Upon receiving and validating a Relay Advertisement, the relay client
   executes the following process for each Relay Address in the

     - If the address does not already exist in the relay client's list
       of relay addresses, it may create a new entry in the list for the
       new address.  The new entry contains the address along with a
       timer initialized with the Lifetime value of the advertisement.

     - If the address already exists in the relay client's list as a
       result of a previously-received advertisement, the client resets
       the timer using the Lifetime value of the advertisement.

   If no Relay Advertisement are received such that the timer expires

Schwab and Stepanek       Expires August 1997                   [Page 8]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   for a entry created as a result of a previously received
   advertisement, the client removes this entry from its list

3.  Encapsulating Traffic

   Once a relay client knows of one or more relay endpoints, it may
   begin encapsulating captured traffic, and sending it through the

   Currently, many protocols exist for the purpose of transporting
   encapsulated packets.  Some of these are discussed in the context of
   IP mobility [RFC2002][RFC2003], point-to-point link transport
   [RFC1661], security [RFC1827], and multicast routing [RFC1075].  If a
   relay server does not support a protocol with "advertisements", it
   must support IP in IP encapsulation using an intervening GRE
   [RFC1701] header, that is, using GRE with IP as both the delivery and
   payload protocol as discussed in [RFC1702] (see Figure 3).
   Otherwise, the relay server must advertise the tunneling protocols it
   supports.  If a desired tunneling protocol supports a suitable notion
   of advertisement, then these messages provide one method of uplink
   discovery for Relay Clients.  Alternatively, extensions to the Relay
   Discovery protocol--by adding additional information the the Address
   Entries of advertisements--would support use of other encapsulation

                       |                           |
                       |      Outer IP Header      |
                       |                           |
                       |                           |
                       |        GRE Header         |
                       |                           |
                       |                           |
                       |         IP Header         |
                       |                           |
                       |                           |
                       |                           |
                       |         IP Payload        |
                       |                           |
                       |                           |

                 Figure 3: Baseline Encapsulation Protocol

   The correct choice of encapsulation protocol depends upon the nature
   of network. Important considerations include security and bandwidth
   management of bidirectional links, as well as the expected number of
   participating downlink nodes.  In addition to these considerations,
   the encapsulation process itself affects several IP mechanisms.
   Appendix B of [RFC1241] contains a discussion of some of the

Schwab and Stepanek       Expires August 1997                   [Page 9]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   implications of encapsulating IP traffic.

4.  Security Considerations

   RFC 1256 points out that systems can use ICMP Router Discovery to
   masquerade as a default router.  In a similar manner, systems can use
   ICMP Relay Discovery to masquerade as a relay server.  As described
   in Section 7 of RFC 1256, one possible method of addressing this
   problem involves adding authentication information to advertisements.

   On the relay server side, the simple encapsulation method described
   in this memo fails to provide relay server's with the ability to
   authenticate relay clients.  And since relay client transmit payload
   packets entirely in the clear, potentially malicious intermediate
   nodes have the ability to interpret the payload of the relay.  The
   protocols and architecture described in the memo were intended to
   tolerate variety in choice encapsulation protocol, so where
   authenticating relay clients and protecting payload transmissions are
   concerns, an alternative encapsulation protocol which provides these
   services may be used instead of the simple one describe here.

   Security mechanisms may also reside on entities conceptually above
   the relay, using the relay as it's intended, that is, as just another
   IP link.

5.  References

   [RFC1256] S. Deering, "ICMP Router Discovery Messages", RFC 1256,
        September 1991.

   [RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
        October 1996.

   [RFC2003] C. Perkins, "IP Encapsulation within IP", RFC 2003, October

   [RFC1661]  W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
        Daydreamer, July 1994.

   [RFC1827] R. Atkinoson, "IP Encapsulating Security Payload (ESP)",
        RFC1827, August 1995

        [RFC1075] D. Waitzman, C. Partridge, and S. Deering, "Distance
        Vector Multicast Routing Protocol", RFC 1705, November 1988.

   [RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
        Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco
        Systems, October 1994.

   [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
        Routing Encapsulation over IPv4 networks", RFC 1702, NetSmiths,
        Ltd., cisco Systems, October 1994.

Schwab and Stepanek       Expires August 1997                  [Page 10]

INTERNET-DRAFT       Virtual Internet Packet Relay         February 1997

   [RFC1241] R. Woodburn, D. Mils, "A Scheme for an Internet
        Encapsulation Protocol:  Version 1", RFC 1241, July 1991.

6.  Authors'  Address:

Schwab and Stepanek       Expires August 1997                  [Page 11]