home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-stepanek-vipre-00.txt < prev    next >
Text File  |  1997-09-03  |  27KB  |  685 lines
  1.  
  2.  
  3.  
  4.  
  5. INTERNET-DRAFT                                            James Stepanek
  6. <draft-stepanek-vipre-00.txt>                          stepanek@aero.org
  7.                                                The Aerospace Corporation
  8.                                                           Stephen Schwab
  9.                                                          schwab@aero.org
  10.                                                             Twin Sun Inc
  11.  
  12.  
  13.                 VIPRE -- Virtual Internet Packet Relay
  14.          An Encapsulation Architecture for Unidirectional Links
  15.  
  16.                                March 1997
  17.  
  18. Status of this Memo
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference
  28.    material or to cite them other than as ``work in progress.''
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  32.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36. Abstract
  37.  
  38.    This memo describes a method of incorporating unidirectional links
  39.    into an IP network in a bidirectional mode by relaying encapsulated
  40.    IP packets over a bidirectional network.
  41.  
  42.  
  43. 1.  Introduction
  44.  
  45.    Successful incorporation of asymmetric, unidirectional satellite
  46.    links into a internetwork requires special treatment of those links.
  47.    The design of many protocols commonly used in the Internet assume the
  48.    existence of symmetrical, bidirectional links between nodes.  As a
  49.    result, many of these same protocols do not work as intended over
  50.    links which are asymmetric, unidirectional, or both.  Asymmetric
  51.    network topologies, for example, those which incorporate satellite
  52.    links, primarily affect protocols which use link-dependent state for
  53.    their operation.  This usually occurs whenever the network needs to
  54.    treat a link as a distinct resource.  Examples of this include
  55.    protocols which handle routing and group management, as well as
  56.    link-bound heuristics of transport protocols and management software.
  57.  
  58.    For example, consider a host with connectivity through two
  59.  
  60.  
  61.  
  62. Schwab and Stepanek       Expires August 1997                   [Page 1]
  63.  
  64. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  65.  
  66.  
  67.    interfaces, in other words, a "multi-homed" host.  On this host, one
  68.    interface forms the receiving end of a connection to a
  69.    unidirectional, high-bandwidth satellite link.  The second interface
  70.    connects the host to a low-bandwidth, bidirectional terrestrial
  71.    network.  Ideally, an internetwork in this topology makes use of the
  72.    satellite link where appropriate while still behaving much like a
  73.    common symmetrical internet.
  74.  
  75.    This document describes one approach to incorporating unidirectional
  76.    satellite links into an internet--the Virtual Internet Packet Relay
  77.    (VIPRe).  This document describes an architecture for incorporating
  78.    unidirectional links into an internet--reducing the problem of
  79.    unidirectional links to the more general problem of asymmetric links.
  80.  
  81.    Note that while this approach was developed for use in unidirectional
  82.    satellite links, it could quite possibly be used on other types of
  83.    unidirectional links.
  84.  
  85.    Before describing the details of the architecture, a couple of
  86.    alternative existing approaches are summarized for the below for the
  87.    purposes of discussion.
  88.  
  89. 1.1.  Terminology
  90.  
  91.    For the purposes of this discussion, consider two types of network
  92.    nodes with connections to a unidirectional satellite links.  "Uplink"
  93.    nodes have the ability to send data over a unidirectional link, while
  94.    "downlink" nodes have the ability to receive data from a
  95.    unidirectional link.
  96.  
  97. 1.2.  Split Routing
  98.  
  99.    A simple, straight-forward approach modifies routing tables on the
  100.    uplink and downlink nodes.  By introducing a static "split" route on
  101.    both the downlink and uplink nodes, traffic originating from downlink
  102.    and destined for uplink nodes is always sent out a bidirectional
  103.    interface.  Similarly, traffic originating from a uplink host and
  104.    destined for a down link node is always sent out the unidirectional
  105.    interface.  This allows some IP traffic to flow between the uplink
  106.    and downlink nodes much as it does in a "normal" internet.  However,
  107.    for large networks maintaining the static "split" routes requires
  108.    significant system management.  Also, protocols with bidirectional
  109.    link assumptions remain broken under this routing configuration.
  110.  
  111. 1.3.  Routing Protocol Modification
  112.  
  113.    Another method of dealing with unidirectional links involves
  114.    modifying routing protocols to account for one-way hops.  The
  115.    modified routing processes share information with each other for the
  116.    purpose of directing traffic in a "split" fashion.  Essentially, this
  117.    incorporates a mechanism for "discovery" of uplink nodes by downlink
  118.    nodes, as well as a mechanism for distributing routing information
  119.    from downlink nodes back to uplink nodes directly.  By handling the
  120.    problem directly, this approach offers the most general of solutions.
  121.  
  122.  
  123.  
  124. Schwab and Stepanek       Expires August 1997                   [Page 2]
  125.  
  126. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  127.  
  128.  
  129.    In fact in addition to routing protocols, it's expected that many
  130.    protocols require modification or extensions to remove asymmetric
  131.    links assumptions.
  132.  
  133. 1.4.  Virtual Packet Relays
  134.  
  135.    A third approach, uses a "relay", or one-way tunnel, to transmit
  136.    packets back to the uplink node.  Virtual Packet Relays, described
  137.    here in detail, attempt to make a functionally bidirectional
  138.    interface out of a unidirectional interface.  To achieve this,
  139.    traffic sent out the unidirectional interface of the downlink node is
  140.    captured somewhere beneath the network layer and relayed through a
  141.    bidirectional interface on the downlink node to a bidirectional
  142.    interface on the uplink node.  Once the captured data arrives at the
  143.    uplink node, it's taken out of the relay and injected into the
  144.    unidirectional interface of the uplink node where it's received as a
  145.    "normal" network packet by the uplink node.
  146.  
  147.    Using a Virtual Packet Relay to deal with unidirectional links
  148.    differs slightly from the other approaches described earlier.  Unlike
  149.    the "split" route approach, using a Virtual Packet Relay does not
  150.    require modification of routing table entries for attached networks.
  151.    This means packets originating on downlink nodes which are destined
  152.    for uplink nodes can be sent out the unidirectional interface of the
  153.    downlink node, as if this interface were bidirectional.  For this
  154.    reason, some protocols which include bidirectional link assumptions
  155.    will operate unmodified under this architecture.
  156.  
  157.    A Virtual Packet Relay provides functionality similar to "split" IP
  158.    routing, but hides the details of the one-way network from IP route
  159.    tables and routing protocols.  This holds the appealing property of
  160.    allowing some existing protocols to function in this environment
  161.    without modification.  However, this approach assumes that uplink and
  162.    downlink nodes are connected on a bidirectional network.  It also
  163.    fails to handle the asymmetric nature of the bidirectional link it
  164.    approximates.  In other words, the routing protocols in use will have
  165.    to be configured to reflect the high cost of the virtual IP hop from
  166.    receiver to uplink site.
  167.  
  168.    In effect, a Virtual Packet Relay creates a virtual network over
  169.    which IP packets can flow as if there is a reverse path on the
  170.    unidirectional link.  Bandwidth of this path is limited by the
  171.    underlying bandwidth of the bidirectional internet, so bandwidth
  172.    management of the reverse link is important.
  173.  
  174.    Implementing a Virtual Packet Relay requires two components.  On the
  175.    uplink side, a relay "server" handles unencapsulating and injection
  176.    of PDUs.  On the downlink side a relay "client" handles the capture
  177.    and encapsulation of PDUs.  In practice, this is accomplished with a
  178.    pair of "Split" Virtual Interfaces (SVIFs).  On the server side, a
  179.    special interface exists which transmits data normally, but receives
  180.    incoming traffic from a set of one or more relays.  On the client
  181.    side, another special interface exists which receives traffic
  182.    normally, but transmits outgoing traffic through a set of one or more
  183.  
  184.  
  185.  
  186. Schwab and Stepanek       Expires August 1997                   [Page 3]
  187.  
  188. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  189.  
  190.  
  191.    relays.  Together, these two components maintain one-way flows of
  192.    encapsulated IP traffic, including two SVIFs on either side.
  193.  
  194.    In this architecture, relay clients keep a list of relay servers with
  195.    which they participate, each with a set of corresponding relay
  196.    endpoints.  And when a single relay client communicates with multiple
  197.    relay servers, the client must use a separate SVIF for each.
  198.  
  199.  
  200.           #*#
  201.              \
  202.               \
  203.                \
  204.                 +----+       +---------------+
  205.                 |    |======>|\              |
  206.                 |SVIF|       | downlink node |
  207.                 |    |<===1==|/              |
  208.                 +----+       |               |
  209.                    |         +--relay client-+
  210.                    |              ^   |
  211.                    +===2==>======>|   +---3---> relay server
  212.                                          (via bidirectional network)
  213.  
  214.         ===> link traffic (below network layer)
  215.         ---> IP traffic
  216.  
  217.                       Figure 1: Downlink Node Detail
  218.  
  219.  
  220.                                                  #*#
  221.                                                 /
  222.                                                /
  223.                                               /
  224.                 +---------------+       +----+
  225.                 |              /|======>|    |
  226.                 |  uplink node  |       |SVIF|
  227.                 |              \|<==6===|    |
  228.                 |               |       +----+
  229.                 +--relay server-+         |
  230.                      |   |                ^
  231.         -----4---->--+   +=======>===5===>|
  232.         relay client
  233.         (via bidirectional network)
  234.  
  235.         ===> link traffic (below network layer)
  236.         ---> IP traffic
  237.  
  238.                        Figure 2: Uplink Node Detail
  239.  
  240.  
  241. 2.  ICMP Relay Discovery Protocol
  242.  
  243.    Before a relay client can provide a fully-functioning SVIF, it must
  244.    know the IP address of at least one functioning "endpoint" of a relay
  245.  
  246.  
  247.  
  248. Schwab and Stepanek       Expires August 1997                   [Page 4]
  249.  
  250. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  251.  
  252.  
  253.    corresponding to that SVIF.  In other words, it must know where to
  254.    send payload packets so they arrive at the relay server for this
  255.    SVIF.  One method of acquiring this knowledge involves using
  256.    configuration files to inform the relay client of all the relay
  257.    servers it needs to know about.  Another possible method involves
  258.    listening to exiting protocol traffic on the unidirectional link and
  259.    deducing--based on this traffic--the addresses of suitable relay
  260.    endpoints.  Since, both of these methods have drawbacks, a third
  261.    method is described here, which relies heavily upon the concepts
  262.    presented in ICMP Router Discovery [RFC1256].  Like ICMP Router
  263.    Discovery, this method introduces a new ICMP message called a "Relay
  264.    Advertisement".
  265.  
  266.    In fact, the ICMP Relay Discovery process works much like ICMP Router
  267.    Discovery.  If a relay server wishes to advertise its willingness to
  268.    accept relayed packets, it periodically sends Relay Advertisements on
  269.    its unidirectional link.  Relay clients discover the relay endpoints
  270.    by listening for Relay Advertisements on their unidirectional link.
  271.  
  272.    Like Router Advertisements, Relay Advertisement contain a "lifetime"
  273.    field.  This specifies the maximum time that relay endpoints are
  274.    considered valid in the absence of further Advertisements.  Relay
  275.    clients use this value to maintain a timer for each relay.
  276.  
  277.    Unlike Router Advertisements, Relay Advertisements include a vector
  278.    of "relay addresses" instead of a "router addresses".  They also omit
  279.    the "preference" field found in Router Advertisements.  And unlike
  280.    ICMP Router Discovery's "Router Addresses", the addresses advertised
  281.    in Relay Advertisements will likely reside in different subnets or
  282.    different networks than the address(s) of the interface which
  283.    receives them.
  284.  
  285.  
  286. 2.1.  Message Formats
  287.  
  288.  
  289.    ICMP Relay Advertisement Message
  290.  
  291.        0                   1                   2                   3
  292.        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
  293.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  294.       |     Type      |     Code      |           Checksum            |
  295.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  296.       |   Num Addrs   |Addr Entry Size|           Lifetime            |
  297.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.       |                        Relay Address[1]                       |
  299.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  300.       |                        Relay Address[2]                       |
  301.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302.       |                               .                               |
  303.       |                               .                               |
  304.       |                               .                               |
  305.  
  306.    IP Fields:
  307.  
  308.  
  309.  
  310. Schwab and Stepanek       Expires August 1997                   [Page 5]
  311.  
  312. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  313.  
  314.  
  315.       Source Address        An IP address belonging to the interface
  316.                             from which this message is sent.
  317.  
  318.       Destination Address   The configured AdvertisementAddress or the
  319.                             IP address of a neighboring host.
  320.  
  321.       Time-to-Live          1 if the Destination Address is an IP
  322.                             multicast address; at least 1 otherwise.
  323.  
  324.    ICMP Fields:
  325.  
  326.       Type                  TBD
  327.  
  328.       Code                  0
  329.  
  330.       Checksum              The 16-bit one's complement of the one's
  331.                             complement sum of the ICMP message, starting
  332.                             with the ICMP Type.  For computing the
  333.                             checksum, the Checksum field is set to 0.
  334.  
  335.       Num                   The number of relay endpoint addresses
  336.                             advertised in this message.
  337.  
  338.       Addr Entry Size       The number of 32-bit words of information
  339.                             per each relay address (1, in the version of
  340.                             the protocol described here).
  341.  
  342.       Lifetime              The maximum number of seconds that the relay
  343.                             addresses may be considered valid.
  344.  
  345.       Relay Address[i]      The addresses of the relay endpoints
  346.                             advertised in this message, where i = 1..Num
  347.                             Addrs.
  348.  
  349.  
  350. 2.2.  Relay Server Specification
  351.  
  352. 2.2.1.  Relay Server Configuration Variables
  353.  
  354.    Relay Server Configuration Variables for ICMP Relay Discovery are
  355.    analogous to the Router Configuration Variable in ICMP Router
  356.    Discovery.  A relay server implementing ICMP Relay Discovery must
  357.    allow configuration of the following variables by system management.
  358.  
  359.    The term "advertisement space" refers to a set of relays associated
  360.    with a single SVIF for which a relay server sends Relay Advertisement
  361.    messages.  For each advertisement space, the relay server maintains
  362.    the following variables:
  363.  
  364.    AdvertisementAddress
  365.                 The IP destination address to be used for Relay
  366.                 Advertisements sent for relays in the advertisement
  367.                 space.
  368.  
  369.  
  370.  
  371.  
  372. Schwab and Stepanek       Expires August 1997                   [Page 6]
  373.  
  374. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  375.  
  376.  
  377.                 Default: 224.0.0.1 if the relay server supports IP
  378.                 multicast on the SVIF interface, else 255.255.255.255
  379.  
  380.    MaxAdvertisementInterval
  381.                 The maximum time allowed between sending Relay
  382.                 Advertisements for relays in this advertisement space,
  383.                 in seconds.  As in ICMP Router Discovery, this must be
  384.                 no less than 4 seconds and no greater than 1800 seconds.
  385.  
  386.                 Default: 600 seconds
  387.  
  388.    MinAdvertisementInterval
  389.                 The minimum time allowed between sending multicast Relay
  390.                 Advertisements from relays in the advertisement space,
  391.                 in seconds.  As in ICMP Router Discovery, this must be
  392.                 no less than 3 seconds and no greater than
  393.                 MaxAdvertisementInterval.
  394.  
  395.                 Default: 0.75 * MaxAdvertisementInterval
  396.  
  397.    For each of its relays, the relay server's maintains the following
  398.    information:
  399.  
  400.    Advertise
  401.                 A flag indicating whether or not the relay is to be
  402.                 advertised.
  403.  
  404.                 Default: TRUE
  405.  
  406.  
  407. 2.2.2.  Relay Server Behavior
  408.  
  409.    For each advertisement space with at least one relay whose Advertise
  410.    flag is TRUE, the relay server transmits periodic Relay
  411.    Advertisements, with the following values.
  412.  
  413.      - In the destination address field of the IP header: the configured
  414.        AdvertisementAddress for the advertisement space.
  415.  
  416.      - In the Lifetime field: the configured AdvertisementLifetime for
  417.        the advertisement space.
  418.  
  419.      - In the Relay Address[i] fields: all the addresses of the relay
  420.        endpoints in the advertisement space with Advertise flags marked
  421.        TRUE.
  422.  
  423.    To avoid unwanted synchronization, the interval between sending Relay
  424.    Advertisements varies randomly.  Many other protocols which transmit
  425.    "periodic" messages describe why and how to achieve this, including
  426.    ICMP Router Discovery.
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434. Schwab and Stepanek       Expires August 1997                   [Page 7]
  435.  
  436. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  437.  
  438.  
  439. 2.3.  Relay Client Specification
  440.  
  441. 2.3.1.  Relay Client Configuration Variables
  442.  
  443.    Relay Client Configuration Variables for ICMP Relay Discovery are
  444.    analogous to the Host Configuration Variable in ICMP Router
  445.    Discovery.  A relay client implementing ICMP Relay Discovery must
  446.    allow configuration of the following variables by system management.
  447.  
  448.    For each SVIF, a relay client maintains the following variables:
  449.  
  450.    PerformRelayDiscovery
  451.                 A flag indicating whether or not the relay client
  452.                 performs ICMP Relay Discovery for the SVIF.
  453.  
  454.                 Default: TRUE
  455.  
  456.    For SVIFs which will not perform ICMP Relay Discovery, the relay
  457.    client must support a configurable list of relay endpoints.  The
  458.    following variables exist for each SVIF not performing ICMP Relay
  459.    Discovery.
  460.  
  461.    RelayAddress
  462.                 The IP address of the endpoint of the desired relay for
  463.                 this SVIF.
  464.  
  465.                 Default:  (none)
  466.  
  467.  
  468. 2.3.2.  Message Validation by Relay Clients
  469.  
  470.    Relay Advertisements are validated by relay clients in the same way
  471.    that Router Advertisements are validated by hosts--as described in
  472.    Section 5.2 of RFC 1256--except when validating Relay Advertisements,
  473.    the ICMP Addr Entry Size must be greater than or equal to 1, instead
  474.    of greater that or equal to 2.
  475.  
  476.  
  477. 2.3.3.  Relay Client Behavior
  478.  
  479.    Upon receiving and validating a Relay Advertisement, the relay client
  480.    executes the following process for each Relay Address in the
  481.    Advertisement.
  482.  
  483.      - If the address does not already exist in the relay client's list
  484.        of relay addresses, it may create a new entry in the list for the
  485.        new address.  The new entry contains the address along with a
  486.        timer initialized with the Lifetime value of the advertisement.
  487.  
  488.      - If the address already exists in the relay client's list as a
  489.        result of a previously-received advertisement, the client resets
  490.        the timer using the Lifetime value of the advertisement.
  491.  
  492.    If no Relay Advertisement are received such that the timer expires
  493.  
  494.  
  495.  
  496. Schwab and Stepanek       Expires August 1997                   [Page 8]
  497.  
  498. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  499.  
  500.  
  501.    for a entry created as a result of a previously received
  502.    advertisement, the client removes this entry from its list
  503.  
  504.  
  505. 3.  Encapsulating Traffic
  506.  
  507.    Once a relay client knows of one or more relay endpoints, it may
  508.    begin encapsulating captured traffic, and sending it through the
  509.    relay.
  510.  
  511.    Currently, many protocols exist for the purpose of transporting
  512.    encapsulated packets.  Some of these are discussed in the context of
  513.    IP mobility [RFC2002][RFC2003], point-to-point link transport
  514.    [RFC1661], security [RFC1827], and multicast routing [RFC1075].  If a
  515.    relay server does not support a protocol with "advertisements", it
  516.    must support IP in IP encapsulation using an intervening GRE
  517.    [RFC1701] header, that is, using GRE with IP as both the delivery and
  518.    payload protocol as discussed in [RFC1702] (see Figure 3).
  519.    Otherwise, the relay server must advertise the tunneling protocols it
  520.    supports.  If a desired tunneling protocol supports a suitable notion
  521.    of advertisement, then these messages provide one method of uplink
  522.    discovery for Relay Clients.  Alternatively, extensions to the Relay
  523.    Discovery protocol--by adding additional information the the Address
  524.    Entries of advertisements--would support use of other encapsulation
  525.    methods.
  526.  
  527.                        +---------------------------+
  528.                        |                           |
  529.                        |      Outer IP Header      |
  530.                        |                           |
  531.                        +---------------------------+
  532.                        |                           |
  533.                        |        GRE Header         |
  534.                        |                           |
  535.                        +---------------------------+
  536.                        |                           |
  537.                        |         IP Header         |
  538.                        |                           |
  539.                        +---------------------------+
  540.                        |                           |
  541.                        |                           |
  542.                        |         IP Payload        |
  543.                        |                           |
  544.                        |                           |
  545.                        +---------------------------+
  546.  
  547.                  Figure 3: Baseline Encapsulation Protocol
  548.  
  549.    The correct choice of encapsulation protocol depends upon the nature
  550.    of network. Important considerations include security and bandwidth
  551.    management of bidirectional links, as well as the expected number of
  552.    participating downlink nodes.  In addition to these considerations,
  553.    the encapsulation process itself affects several IP mechanisms.
  554.    Appendix B of [RFC1241] contains a discussion of some of the
  555.  
  556.  
  557.  
  558. Schwab and Stepanek       Expires August 1997                   [Page 9]
  559.  
  560. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  561.  
  562.  
  563.    implications of encapsulating IP traffic.
  564.  
  565.  
  566. 4.  Security Considerations
  567.  
  568.    RFC 1256 points out that systems can use ICMP Router Discovery to
  569.    masquerade as a default router.  In a similar manner, systems can use
  570.    ICMP Relay Discovery to masquerade as a relay server.  As described
  571.    in Section 7 of RFC 1256, one possible method of addressing this
  572.    problem involves adding authentication information to advertisements.
  573.  
  574.    On the relay server side, the simple encapsulation method described
  575.    in this memo fails to provide relay server's with the ability to
  576.    authenticate relay clients.  And since relay client transmit payload
  577.    packets entirely in the clear, potentially malicious intermediate
  578.    nodes have the ability to interpret the payload of the relay.  The
  579.    protocols and architecture described in the memo were intended to
  580.    tolerate variety in choice encapsulation protocol, so where
  581.    authenticating relay clients and protecting payload transmissions are
  582.    concerns, an alternative encapsulation protocol which provides these
  583.    services may be used instead of the simple one describe here.
  584.  
  585.    Security mechanisms may also reside on entities conceptually above
  586.    the relay, using the relay as it's intended, that is, as just another
  587.    IP link.
  588.  
  589.  
  590. 5.  References
  591.  
  592.    [RFC1256] S. Deering, "ICMP Router Discovery Messages", RFC 1256,
  593.         September 1991.
  594.  
  595.    [RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
  596.         October 1996.
  597.  
  598.    [RFC2003] C. Perkins, "IP Encapsulation within IP", RFC 2003, October
  599.         1996.
  600.  
  601.    [RFC1661]  W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
  602.         Daydreamer, July 1994.
  603.  
  604.    [RFC1827] R. Atkinoson, "IP Encapsulating Security Payload (ESP)",
  605.         RFC1827, August 1995
  606.  
  607.         [RFC1075] D. Waitzman, C. Partridge, and S. Deering, "Distance
  608.         Vector Multicast Routing Protocol", RFC 1705, November 1988.
  609.  
  610.    [RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
  611.         Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco
  612.         Systems, October 1994.
  613.  
  614.    [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
  615.         Routing Encapsulation over IPv4 networks", RFC 1702, NetSmiths,
  616.         Ltd., cisco Systems, October 1994.
  617.  
  618.  
  619.  
  620. Schwab and Stepanek       Expires August 1997                  [Page 10]
  621.  
  622. INTERNET-DRAFT       Virtual Internet Packet Relay            March 1997
  623.  
  624.  
  625.    [RFC1241] R. Woodburn, D. Mils, "A Scheme for an Internet
  626.         Encapsulation Protocol:  Version 1", RFC 1241, July 1991.
  627.  
  628.  
  629. 6.  Authors'  Address:
  630.  
  631.    James Stepanek
  632.    The Aerospace Corporation
  633.    Mail Station: 11/102
  634.    P.O. Box 92957
  635.    Los Angeles, CA 90009-2957
  636.  
  637.    Phone: (310) 336-7911
  638.    EMail: stepanek@aero.org
  639.  
  640.  
  641.  
  642.    Stephen Schwab
  643.    Twin Sun, Inc.
  644.    360 N. Sepulveda Blvd., Suite 2055
  645.    El Segundo, CA 90245
  646.  
  647.    Phone: (310) 524 1800
  648.    EMail: schwab@twinsun.com
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682. Schwab and Stepanek       Expires August 1997                  [Page 11]
  683.  
  684.  
  685.