INTERNET-DRAFT James Stepanek
stepanek@aero.org
The Aerospace Corporation
Stephen Schwab
schwab@aero.org
Twin Sun Inc
VIPRE -- Virtual Internet Packet Relay
An Encapsulation Architecture for Unidirectional Links
<draft-ietf-udlr-vipre-00.txt>
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).
Abstract
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
Advertisement".
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
Addrs.
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:
AdvertisementAddress
The IP destination address to be used for Relay
Advertisements sent for relays in the advertisement
space.
Schwab and Stepanek Expires August 1997 [Page 6]
INTERNET-DRAFT Virtual Internet Packet Relay February 1997
Default: 224.0.0.1 if the relay server supports IP
multicast on the SVIF interface, else 255.255.255.255
MaxAdvertisementInterval
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
MinAdvertisementInterval
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
MaxAdvertisementInterval.
Default: 0.75 * MaxAdvertisementInterval
For each of its relays, the relay server's maintains the following
information:
Advertise
A flag indicating whether or not the relay is to be
advertised.
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
TRUE.
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:
PerformRelayDiscovery
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
Discovery.
RelayAddress
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
Advertisement.
- 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
relay.
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
methods.
+---------------------------+
| |
| 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
1996.
[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]
