doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc1241.txt b/doc/rfc/rfc1241.txt
new file mode 100644
index 0000000..9f61533
--- /dev/null
+++ b/doc/rfc/rfc1241.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                       R. Woodburn
+Request for Comments: 1241                                         SAIC
+                                                               D. Mills
+                                                 University of Delaware
+                                                              July 1991
+
+
+            A Scheme for an Internet Encapsulation Protocol:
+                               Version 1
+
+1. Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  Discussion and suggestions for improvement are requested.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+2. Glossary
+
+   Clear Datagram -
+     The unmodified IP datagram in the User Space before
+     Encapsulation.
+
+   Clear Header -
+     The header portion of the Clear Datagram before
+     Encapsulation.  This header includes the IP header and
+     possibly part or all of the next layer protocol header,
+     i.e., the TCP header.
+
+   Decapsulation -
+     The stripping of the Encapsulation Header and forwarding
+     of the Clear Datagram by the Decapsulator.
+
+   Decapsulator -
+     The entity responsible for receiving an Encapsulated
+     Datagram, decapsulating it, and delivering it to the
+     destination User Space.  Delivery may be direct, or via
+     Encapsulation.  A Decapsulator may be a host or a gateway.
+
+   Encapsulated Datagram -
+     The datagram consisting of a Clear Datagram prepended with
+     an Encapsulation Header.
+
+   Encapsulation -
+     The process of mapping a Clear Datagram to the
+     Encapsulation Space, prepending an Encapsulation Header to
+     the Clear Datagram and routing the Encapsulated Datagram
+
+
+
+Woodburn & Mills                                                [Page 1]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+     to a Decapsulator.
+
+   Encapsulation Header -
+     The header for the Encapsulation Protocol prepended to the
+     Clear Datagram during Encapsulation.  This header consists
+     of an IP header followed by an Encapsulation Protocol
+     Header.
+
+   Encapsulation Protocol Header -
+     The Encapsulation Protocol specific portion of the
+     Encapsulation Header.
+
+   Encapsulation Space -
+     The address and routing space within which the
+     Encapsulators and Decapsulators reside.  Routing within
+     this space is accomplished via Flows.  Encapsulation
+     Spaces do not overlap, that is, the address of any
+     Encapsulator or Decapsulator is unique for all
+     Encapsulation Spaces.
+
+   Encapsulator -
+     The entity responsible for mapping a given User Space
+     datagram to the Encapsulation Space, encapsulating the
+     datagram, and forwarding the Encapsulated Datagram to a
+     Decapsulator.  An Encapsulator may be a host or a gateway.
+
+   Flow -
+     Also called a "tunnel."  A flow is the end-to-end path in
+     the Encapsulation Space over which Encapsulated Datagrams
+     travel.  There may be several Encapsulator/Decapsulator
+     pairs along a given flow.  Note that a Flow does not
+     denote what User Space gateways are traversed along the
+     path.
+
+   Flow ID -
+     A 32-bit identifier which uniquely distinguishes a flow in
+     a given Encapsulator or Decapsulator.  Flow IDs are
+     specific to a single Encapsulator/Decapsulator Entity and
+     are not global quantities.
+
+   Mapping Function -
+     This is the function of mapping a Clear Header to a
+     particular Flow.  All encapsulators along a given Flow are
+     required to map a given Clear Header to the same Flow.
+
+   User Address -
+     The address or identifier uniquely identifying an entity
+     within a User Space.
+
+
+
+Woodburn & Mills                                                [Page 2]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   Source Route -
+     A complete end-to-end route which is computed at the
+     source and enumerates transit gateways.
+
+   User Space -
+     The address and routing space within which the users
+     reside.  Routing within this space provides reachability
+     between all address pairs within the space.  User Spaces
+     do not overlap, that is, a given User Address is unique in
+     all User Spaces.
+
+3. Background
+
+   For several years researchers in the Internet community have needed a
+   means of "tunneling" between networks.  A tunnel is essentially a
+   Source Route that circumvents conventional routing mechanisms.
+   Tunnels provide the means to bypass routing failures, avoid broken
+   gateways and routing domains, or establish deterministic paths for
+   experimentation.
+
+   There are several means of accomplishing tunneling.  In the past,
+   tunneling has been accomplished through source routing options in the
+   IP header which allow gateways along a given path to be enumerated.
+   The disadvantage of source routing in the IP header is that it
+   requires the source to know something about the networks traversed to
+   reach the destination.  The source must then modify outgoing packets
+   to reflect the source route.  Current routing implementations
+   generally don't support source routes in their routing tables as a
+   means of reaching an IP address, nor do current routing protocols.
+
+   Another means of tunneling would be to develop a new IP option.  This
+   option field would be part of a separate IP header that could be
+   prepended to an IP datagram.  The IP option would indicate
+   information about the original datagram.  This tunneling option has
+   the disadvantage of significantly modifying existing IP
+   implementations to handle a new IP option.  It also would be less
+   flexible in permitting the tunneling of other protocols, such as ISO
+   protocols, through an IP environment.  An even less palatable
+   alternative would be to replace IP with a new networking protocol or
+   a new version of IP with tunneling built in as part of its
+   functionality.
+
+   A final alternative is to create a new IP encapsulation protocol
+   which uses the current IP header format.  By using encapsulation, a
+   destination can be reached transparently without the source having to
+   know topology specifics.  Virtual networks can be created by tying
+   otherwise unconnected machines together with flows through an
+   encapsulation space.
+
+
+
+Woodburn & Mills                                                [Page 3]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+                                               ++++++  Clear Datagram
+                                               ******  Encapsulated
+       Datagram
+                                                    #
+       Encapsulator/Decapsulator
+                                                    &  User Space Host
+
+
+           User Space A                        User Space C
+
+          --------------                    -----------
+         /              \                  /           \
+        /                \                /             \
+       |                  |              |               |
+       |     &            |              |               |
+       |     +   +++++    |              |      *****    |
+       |     +++++   +    |              |      *   *    |
+       |             +    |              |  *****   *    |
+        \            +   /  -----------  \ *       *    /  ----------
+         \           ++> # *         **> # *        ***> # ++++      \
+          --------------  / *        *  \  ------------  /   +        \
+                         |  *        *   |              |    +         |
+                         |  *        *   |              |    +         |
+                         |  *****    *   |              |    +++++++   |
+                         |      *****    |              |          V   |
+                         |               |              |          &   |
+                          \             /                \             /
+                           \           /                  \           /
+                            -----------                    ----------
+                           Encapsulation                      User
+                              Space B                        Space D
+
+
+                  Fig. 1.  Encapsulation Architectural Model
+
+   Up until now, there has been no standard for an encapsulation
+   protocol.  This RFC provides a means of performing encapsulation in
+   the Internet environment.
+
+4. Architecture and Approach
+
+   The architecture for encapsulation is based on two entities -- an
+   Encapsulator and a Decapsulator.  These entities and the associated
+   spaces are shown in Fig. 1.
+
+   Encapsulators and Decapsulators have addresses in the User Spaces to
+   which they belong, as well as addresses in the Encapsulation Spaces
+   to which they belong. An encapsulator will receive a Clear Datagram
+
+
+
+Woodburn & Mills                                                [Page 4]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   from its User Space, and after determining that encapsulation should
+   be used, perform a mapping function which translates the User Space
+   information in the Clear Header to an Encapsulation Header.  This
+   Encapsulation Header is then prepended to the Clear Datagram to form
+   the Encapsulated Datagram, as in Fig 2.  It is desirable that the
+   encapsulation process be transparent to entities in the User Space.
+   Only the Encapsulator need know that encapsulation is occurring.
+
+         +---------------+-----------------+--------+----------------+
+         | Encapsulating |  Encapsulation  | Clear  |  Remainder of  |
+         |   IP Header   | Protocol Header | Header | Clear Datagram |
+         +---------------+-----------------+--------+----------------+
+
+         |                                 |                         |
+         |        Encapsulation Header     |      Clear Datagram     |
+         |                                 |                         |
+
+
+                 Fig. 2.  Example of an Encapsulated Datagram
+
+   The Encapsulator forwards the datagram to a Decapsulator whose
+   identity is determined at the time of encapsulation.  The
+   Decapsulator receives the Encapsulated Datagram and removes the
+   Encapsulation Header and treats the Clear Datagram as if it were
+   received locally.  The requirement for the address of the
+   Decapsulator is that it be reachable from the Encapsulator's
+   Encapsulation Space address.
+
+5. Generation of the Encapsulation Header
+
+   The contents of the Encapsulation Header are generated by performing
+   a mapping function from the Clear Header to the contents of the
+   Encapsulation Header.  This mapping function could take many forms,
+   but the end result should be the same.  The following paragraphs
+   describe one method of performing the mapping.  The process is
+   illustrated in Fig. 3.
+
+   In the first part of the mapping function, the Clear Header is
+   matched with stored headers and masks to determine a Flow ID.  This
+   is essentially a "mask-and-match" table look up, where the lookup
+   table holds three entries, a Clear Header, a header mask, and a
+   corresponding Flow ID.  The mask can be used for allowing a range of
+   source and destination addresses to map to a given flow.  Other
+   fields, such as the IP TOS bits or even the TCP source or destination
+   port addresses could also be used to discriminate between Flows.
+   This flexibility allows many possibilities for using the mapping
+   function.  Not only can a given network be associated with a
+   particular flow, but even a particular TCP protocol or connection
+
+
+
+Woodburn & Mills                                                [Page 5]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   could be distinguished from another.
+
+   How the lookup table is built and maintained is not part of this
+   protocol.  It is assumed that it is managed by some higher layer
+   entity.  It would be sufficient to configure the tables from ascii
+   text files if necessary.
+
+                                                +--------+
+                                                |        |
+                                             +->| Encap. |--+
+                                             |  | Info.  |  |
+                   +-------+                 |  | Table  |  |
+                   | Mask  |   +---------+   |  |        |  |
+       Clear --+-->|  &    |-->| Flow ID |---+  |        |  |
+       Header  |   | Match |   +---------+      +--------+  |
+               |   +-------+                                |
+               |                                            +-->  Encap
+               +----------------------------------------------->  Header
+
+
+                Fig. 3.  Generation of the Encapsulation Header
+
+   The Flow IDs are managed at a higher layer as well.  An example of
+   how Flow IDs can be managed is found in the Setup protocol of the
+   Inter-Domain Policy Sensitive Routing Protocol (IDPR). [4] The upper
+   layer protocol would be responsible for maintaining information not
+   carried in the encapsulation protocol related to the flow.  This
+   could include the information necessary to construct the
+   Encapsulation Header (described below) as well as information such as
+   the type of data being encapsulated (currently only IP is defined),
+   and the type of authentication used if any.  Note that IDPR Setup
+   requires the use of a longer Flow ID which is unique for the entire
+   universe of Encapsulators and is the same at every Encapsulator.
+
+   The Flow ID that results from the mapping of a Clear Header is a 32
+   bit quantity and identifies the Flow as it is seen by the
+   Encapsulator.  If a Clear Datagram must be encapsulated and
+   decapsulated several times in order reach the destination, the Flow
+   ID may be different at each Encapsulator, but need not be.  The Flow
+   ID acts as an index into a table of Encapsulation Header information
+   that is used to build the Encapsulation Header.  Note that the
+   decision to make the Flow ID local to the Encapsulator is due to the
+   difficulty in choosing and maintaining globally unique identifiers.
+
+   The intermediate step of using a Flow ID entirely optional.  The
+   important requirement is that all Encapsulators along a Flow map the
+   same Clear Header to the same Flow (which could be identified by
+   different identifiers along the way).  However, by allowing for a
+
+
+
+Woodburn & Mills                                                [Page 6]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   Flow ID in the protocol, a more efficient implementation of the
+   mapping function becomes possible.  This is discussed in more detail
+   when we consider the Decapsulator.
+
+   The following information is required to construct the Encapsulation
+   Header:
+
+   Flow ID -
+     This is the key for this table of information and
+     represents the Flow ID relative to the current
+     Encapsulator.
+
+   Decapsulator Address -
+     The IP address of the Decapsulator in the Encapsulation
+     Space must be known to build the IP portion of the
+     Encapsulation Header.
+
+   Decapsulator's Flow ID -
+     The Flow ID, if any, for the Flow as seen by the
+     Decapsulator must be known.
+
+   Previous Encapsulator's Address -
+     If this is not the first Encapsulator along the Flow, the
+     previous Encapsulator's address must be known for error
+     reporting.
+
+   Previous Encapsulator's Flow ID -
+     In addition to the previous Encapsulator's address, the
+     Flow ID of the Flow relative to the previous Encapsulator
+     must be known.
+
+   The Encapsulation Header consists of an IP Header as well as an
+   Encapsulation Protocol Header.  The two pieces of information
+   required for the Encapsulation Protocol Header which must be
+   determined at the time of encapsulation are the protocol which is
+   being encapsulated and the Flow ID to send to the Decapsulator.  The
+   generation of the IP header is more complicated.
+
+   There are  two possible ways each field in the Clear Header could
+   related to the new IP header.
+
+   Copy -
+     Copy the existing field from the Clear Header to the IP
+     header in the Encapsulation Header.
+
+   Ignore -
+     The field may or may not have existed in the Clear Header,
+     but does not apply to the new IP header.
+
+
+
+Woodburn & Mills                                                [Page 7]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   The IP header has a fixed portion and a variable portion, the options
+   list.  A summary of all possible IP fields and the relation to the
+   Clear Header follows in Table 1. [2]
+
+   Note that most of the fields in the Clear Header are simply ignored.
+   Fields such as the Header Length in the Clear Header have no effect
+   on the Header Length of the new IP header.  The fields which are more
+   interesting and require some thought are now discussed.
+
+   The Quality of Service bits should be copied from the Clear Header to
+   the new IP header.  This is in keeping with the transparency
+   principle that if the User Space was providing a given service, then
+   the Encapsulation Space must provide the same service.
+
+   The More Fragments bit and Fragment Offset should not be copied,
+   since the datagram being built is a complete datagram, regardless of
+   the status of the encapsulated datagram.  If the completed datagram
+   is too large for the interface, it will be fragmented for
+   transmission to the decapsulator by the normal IP fragmentation
+   mechanism.
+
+   The Don't Fragment bit should not be copied into the Encapsulation
+   Header.  The transparency principle would again be violated.  It
+   should be up to the Encapsulator to decide whether fragmentation
+   should be allowed across the Encapsulation Space.  If it is decided
+   that the DF bit should be used, then ICMP message would be returned
+   if the Encapsulated Datagram required fragmentation across the
+   Encapsulation Space The mechanism for returning an ICMP message to
+   the source in the User space will have to be modified, however, and
+   this is discussed in the Appendix B.
+
+   Regarding the Time To Live (TTL) field, the easiest thing to do is to
+   ignore the TTL from the Clear Header.  If this field were copied from
+   the Clear Header to the new IP header, the packet life might be
+   prematurely exceeded during transit in the Encapsulation Space.  This
+   breaks the transparency rule of encapsulation as seen from the User
+   Space.  The TTL of the Clear Header is decremented before
+   encapsulation by the IP forwarding function, so there is no chance of
+   a packet looping forever if the links of a Flow form a loop.
+
+
+
+
+
+
+
+
+
+
+
+
+Woodburn & Mills                                                [Page 8]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+                          +---------------------+---------+
+                          |        Field        | Mapping |
+                          +---------------------+---------+
+                          | Version             | Ignore  |
+                          | Header Length       | Ignore  |
+                          | Precedence          | Copy    |
+                          | QoS bits            | Copy    |
+                          | Total Length        | Ignore  |
+                          | Identification      | Ignore  |
+                          | Don't Fragment Bit  | Ignore  |
+                          | More Fragments Bit  | Ignore  |
+                          | Fragment Offset     | Ignore  |
+                          | Time to Live        | Ignore  |
+                          | Protocol            | Ignore  |
+                          | Header Checksum     | Ignore  |
+                          | Source Address      | Ignore  |
+                          | Destination Address | Ignore  |
+                          | End of Option List  | Ignore  |
+                          | NOP Option          | Ignore  |
+                          | Security Option     | Copy    |
+                          | LSR Option          | Ignore  |
+                          | SSR Option          | Ignore  |
+                          | RR Option           | Ignore  |
+                          | Stream ID Option    | Ignore  |
+                          | Timestamp Option    | Ignore  |
+                          +---------------------+---------+
+
+                       Table 1.  Summary of IP Header Mappings
+
+   The protocol field for the new IP header should be filled with the
+   protocol number of the encapsulation protocol.
+
+   The source address in the new IP header becomes the IP address of the
+   Encapsulator in the Encapsulation Domain.  The destination address
+   becomes the IP address of the Decapsulator as found in the
+   encapsulation table.
+
+   IP Options are generally not copied because most don't make sense in
+   the context of the Encapsulation Space, as the transparency principle
+   would indicate.  The security option is probably the one option that
+   should get copied for the same reason QOS and precedence fields are
+   copied, the Encapsulation Space must provide the expected service.
+   Timestamp, Loose Source Route, Strict Source Route, and Record Route
+   are not copied during encapsulation.
+
+6. Decapsulation
+
+   In the ideal situation, a Decapsulator receives an Encapsulated
+
+
+
+Woodburn & Mills                                                [Page 9]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   Datagram, strips off the Encapsulation Header and sends the Clear
+   Datagram back into IP so that it is forwarded from that point.
+   However, if the Clear Datagram has not reached the destination User
+   Space, it must again be encapsulated to move it close to the
+   destination User Space.  In this latter case the Decapsulator would
+   become an Encapsulator and would perform the same calculation to
+   generate the Encapsulation Header as did the previous Encapsulator.
+   In order to make this process more efficient, the use of Flow IDs
+   have been incorporated into the protocol.
+
+   When Flow IDs are used, the Flow ID received in the Encapsulation
+   Header corresponds to a stored Flow ID in the Decapsulator.  At this
+   point the Decapsulator has the option of bypassing the mask and match
+   operation on the Clear Header.  The received Flow ID can be used to
+   point directly into the local Encapsulator tables for the
+   construction of the next Encapsulation Header.  If the Flow ID is
+   unknown, an error message is sent back to the previous Encapsulator
+   to that effect and a signal is sent to upper layer entity managing
+   the encapsulation tables.
+
+   Because the normal IP forwarding mechanism is being bypassed when
+   Flow IDs are used, certain mechanisms normally handled by IP must be
+   taken care of by the Decapsulator before encapsulation.  The
+   Decapsulator must decrement the TTL before the next encapsulation
+   occurs.  If a Time Exceeded error occurs, then an ICMP message is
+   sent to the source indicated in the Clear Header.
+
+7. Error Messages
+
+   There are two kinds of error message built into the encapsulation
+   protocol.  The first is used to report unknown flow identifiers seen
+   by a Decapsulator and the second is for the forwarding of ICMP
+   messages.
+
+   When a Decapsulator is using the received Flow ID in an Encapsulation
+   Header to forward a datagram to the next Decapsulator in a Flow, it
+   is possible that the Flow ID may not be known.  For this case the
+   Decapsulator will notify the previous Encapsulator that the Flow was
+   not known so that the problem may be reported to the layer
+   responsible for the programming of the Flow tables.  This is
+   accomplished through an encapsulation error message.
+
+   If an Encapsulator receives an ICMP messages regarding a given flow,
+   this message should be forwarded backwards along the flow to the
+   source Encapsulator.  This is accomplished by the second kind of
+   error message.  The ICMP message will contain the Flow ID of the
+   message which caused the error.  This Flow ID must be translated to
+   the Flow ID relative to the Encapsulator to which the error message
+
+
+
+Woodburn & Mills                                               [Page 10]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   is sent.
+
+   If an error occurs while sending any error message, no further error
+   message are generated.
+
+8. References
+
+   [1]  J. Postel,  Internet  Control  Message  Protocol,  RFC  792,
+        September 1981.
+
+   [2]  J. Postel, Internet Protocol, RFC 791, September 1981.
+
+   [3]  J. Postel, Transmission Control Protocol, RFC 793, September
+        1981.
+
+   [4]  ORWG, Inter-Domain Policy Routing Protocol Specification and
+        Usage, Draft, August 1990
+
+A. Packet Formats
+
+   This section describes the packet formats for the encapsulation
+   protocol.
+
+        0               8              16              24            31
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | Vers  |  HL   |  MT   |  RC   |            Checksum           |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                            Flow ID                            |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Fig. A.1.  Encapsulation Protocol Header Example
+
+       Vers      4 bits    The  version   number  of  the  encapsulation
+                           protocol.     The  version  of  the  protocol
+                           described by this document is 1.
+
+       HL        4 bits    The  header   length  of   the  Encapsulation
+                           Protocol Header in octets.
+
+       MT        4 bits    The  message   type  of   the   Encapsulation
+                           Protocol message.    A  data  message  has  a
+                           message type  of 1.   An  error message has a
+                           message type of 2.
+
+       RC        4 bits    The reason code.  This field is unused in the
+                           Data Message  and must have a value of 0.  In
+                           the Error Message it contains the reason code
+                           for the  Error Message.   Defined reason code
+
+
+
+Woodburn & Mills                                               [Page 11]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+                           values are:
+
+                                1 Unknown Flow ID
+                                2 ICMP returned
+
+       Checksum  16 bits   A   one's   complement   checksum   for   the
+                           Encapsulation Protocol Header.  This field is
+                           set to 0 upon calculation of the checksum and
+                           is  filled   with  the  checksum  calculation
+                           result before the data message is sent.
+
+       Flow ID   32 bits   The Flow  ID as  seen by  the Decapsulator or
+                           Encapsulator to  which this  message is being
+                           sent.   In the  case of  an Unknown  Flow  ID
+                           error, the Flow ID causing the error is used.
+
+For Data Messages, the Encapsulation Protocol Header is followed by the
+Clear Datagram.  For Error Messages, the header is followed by the ICMP
+message being forwarded along a flow.
+
+B. Encapsulation and Existing IP Mechanisms
+
+   This section discusses in detail the effect of this encapsulation
+   protocol upon the existing mechanisms available with IP and some the
+   possible effects of IP mechanisms upon this protocol.  Specifically
+   these are Fragmentation and ICMP messages.
+
+B.1 Fragmentation and Maximum Transmission Unit
+
+   An immediate concern of using an encapsulation mechanism is that of
+   restrictions based upon MTU size.  The source of a Clear Datagram is
+   going to generate packets consistent with MTU of the interface over
+   which datagram is transmitted.  If these packets reach an
+   Encapsulator and are encapsulated, they may be fragmented if they are
+   larger than the MTU of the Encapsulator, even though the physical
+   interfaces of the source and Encapsulator may have the same MTU.
+   Because the Encapsulated Datagram is sent to the Decapsulator using
+   IP, there is no problem in allowing IP to perform fragmentation and
+   reassembly.  However, fragmentation is known to be inefficient and is
+   generally avoided.  Because a new header is being prepended to the
+   Clear Datagram by the encapsulation process, the likelihood of
+   fragmentation occurring is increased.  If the Encapsulator decides to
+   disallow fragmentation through the Encapsulation Space, it must send
+   an ICMP message back to the source.  This means that the MTU of the
+   interface in the encapsulation space is effectively smaller than that
+   of the physical MTU of the interface.
+
+   Fragmentation by intermediate User Space Gateways introduces another
+
+
+
+Woodburn & Mills                                               [Page 12]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   problem.  Fragmentation occurs at the IP level.  If a TCP protocol is
+   in use and fragmentation occurs, the TCP header is contained in the
+   first fragment, but not the following fragments.  [3] If these
+   fragments are forwarded by an Encapsulator, discrimination of the
+   Clear Header for a given flow will only be able to occur on the IP
+   header portion of the Clear Header.  If discrimination is attempted
+   on the TCP portion of the header, then only the first fragment will
+   be matched, while remaining fragments will not.
+
+B.2 ICMP Messages
+
+   The most controversial aspect of encapsulation is the handling of
+   ICMP messages. [1] Because the Encapsulation Header contains the
+   source address of the Encapsulator in the Encapsulation Space, ICMP
+   messages which occur within the Encapsulation Space will be sent back
+   to the Encapsulator.  Once the Encapsulator receives the ICMP
+   message, the question is what should the next action be.  Since the
+   original source of the Clear Datagram knows nothing about the
+   Encapsulation Space, it does not make sense to forward an ICMP
+   message on to it and ICMP message are not supposed to beget ICMP
+   messages.  Yet not sending the original source something may break
+   some important mechanisms.
+
+   In addition to deciding what to forward to the source of the Clear
+   Datagram, there is the problem of possibly not having enough
+   information to send anything at all back to the source.  An ICMP
+   message returns the header of the offending message and the first
+   eight octets of the data after the header.  For the case of the
+   encapsulation protocol, this translates to the IP portion of the
+   Encapsulation Header, the first eight octets of the Encapsulation
+   Protocol Header, and nothing else.  The contents of the Clear
+   Datagram are completely lost.  Therefore, for the Encapsulator to
+   send an ICMP message back to the source it has to reconstruct the
+   Clear Header.  However, it is essentially impossible to reproduce the
+   exact header.
+
+   For the purpose of this specification, the Flow ID has been assumed
+   to be a unique one way mapping from a Clear Header.  There is no
+   guarantee that the Flow ID could be used to map back to the Clear
+   Header, since several headers potentially map to the same flow.  With
+   there being no effective way to regenerate the original datagram,
+   some compromises must be examined.
+
+   For each of the possible ICMP messages, the alternatives and impact
+   will be assessed.  There are three categories of ICMP message
+   involved.  The first is those ICMP messages which are not applicable
+   in the context of Encapsulation.  These are: Echo/Echo Reply and
+   Timestamp/Timestamp Reply.
+
+
+
+Woodburn & Mills                                               [Page 13]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   The second category are those ICMP messages which concern mechanisms
+   local to the encapsulation domain.  These are messages which would
+   not make sense to the original source if it did receive them.  In
+   these cases the encapsulator will have to decide what to do, but no
+   ICMP message need be sent back to the original source.  The datagram
+   will simply be lost, IP is not meant to be a reliable protocol.
+   Subsequent messages received for encapsulation may cause the
+   encapsulator to generate ICMP Destination Unreachable messages back
+   to the original source if the encapsulator can no longer send
+   messages to the destination decapsulator.  This requires that ICMP
+   messages inside the encapsulation domain affect the mapping from the
+   Flow ID.  ICMP messages in the second category are: Parameter
+   Problem, Redirect, Destination Unreachable, Time Exceeded.
+
+   Finally there is one ICMP message which has direct bearing on the
+   operation of the original source of datagrams destined for
+   encapsulation, the ICMP Source Quench message.  The only possible
+   mechanism available to the Encapsulator to handle this message is for
+   the source quench message set a flag for the offending Flow ID such
+   that subsequent messages that map the Flow cause the generation of a
+   source quench back to the original source before the datagram is
+   encapsulated.
+
+   This last mechanism may be a solution for the more general problem.
+   The rule of thumb could be that when an ICMP message is received for
+   a given flow, then flag the Flow so that then next message
+   encapsulated will cause the next message encapsulated on that flow to
+   force an ICMP message to the source.  After the ICMP message is sent
+   to the source, the mechanism could be reset.  This would effectively
+   cause every other packet to receive an ICMP message if there were a
+   persistent problem.  This mechanism is probably only safe for
+   Unreachable messages and Source Quench.
+
+C. Reception of Clear Datagrams
+
+   In order to use the encapsulation protocol a modification is required
+   to IP forwarding.  There must be some way for the IP module in a
+   system to pass Clear Datagrams to the encapsulation protocol.  A
+   suggested means of doing this is to make an addition to a system's
+   routing table structures.  A flag could be added to a route that
+   tells the forwarding function to use encapsulation.  Note that the
+   default route could also be set to use encapsulation.
+
+   With this mechanism in place, a system's IP forwarding mechanism
+   would examine its routing tables to try and match the IP destination
+   to a specific route.  If a route was found, it would be then checked
+   to see if encapsulation should be used.  If not the packet would be
+   handled normally.  If encapsulation was turned on for the route, then
+
+
+
+Woodburn & Mills                                               [Page 14]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   the datagram would be sent to encapsulation for forwarding.
+
+   In addition  to snagging packets as they are forwarded, something
+   must be  done at  the last  Decapsulator on  a given flow so that
+   packets that  are decapsulated  are properly  dumped into  the IP
+   module for  delivery.   Because the packets are encapsulated just
+   before forwarding,  it should be a simple matter for decapsulated
+   datagrams to be injected into the output portion of IP.  However, the
+   source  address in  the Clear  Header must  not change.   The address
+   must  remain the address of the source in the source User Space and
+   not be overwritten with that of the Decapsulator.
+
+D. Construction of Virtual Networks with Encapsulation
+
+   Because of the modification to the routing table to permit
+   encapsulation, it becomes possible to specify a virtual interface
+   whose sole purpose is encapsulation.  Using this mechanism, it would
+   become possible to link topologically distant entities with Flows.
+   This would allow the construction of a Virtual Network which would
+   overlay the actual routing topology.  An example of such a virtual
+   network is shown in Fig. 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woodburn & Mills                                               [Page 15]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+                                      ++++++  Virtual Network A
+                                      ******  Virtual Network B
+                                           #  Encapsulator/Decapsulator
+                                      ------  Common Routing Space
+
+           ------------                     ------------
+          /            \                   /            \
+         /      +++ #   \                 /              \
+        |  # +++    +    |               |    # ***** #   |
+        |  +        +    |               |    *       *   |
+        |  +       +     |               |     *     *    |
+        |   +      +     |               |      *   *     |
+        |   # ++++ # +   |               |       * *      |
+         \            + /  -------------  \       # **   /  ---------
+          \           + # ++            \ # ******   *** # **        \
+           ------------  /  +++          *  ------------  /  ***      \
+                        |      #        * |              |      # *** #|
+                        |      +      **  |              |      *     *|
+                        |      +     #    |              |     *    ** |
+                        |      + ++++ *   |              |    *    *   |
+                        |       #+     *  |              |   *    *    |
+           ------------  \  ++++        */  ------------  \ *    #     /
+          /            \ # +             # **           * # *****     /
+         /              +  -------------  /  # ****** # *\   --------
+        |   # +++++++   +|               |   *        *   |
+        |   +        + + |               |   *         *  |
+        |    +         # |               |   *          * |
+        |    +       ++  |               |   *          # |
+        |    # ++++++    |               |   * *********  |
+         \              /                 \   #          /
+          \            /                   \            /
+           ------------                     ------------
+
+
+                       Fig. 4.  Virtual Networks Example
+
+   Each Encapsulator shown has an virtual interface on one of the
+   virtual networks.  The lines represent individual links in the flows
+   that connect each member of the virtual network.  Note that new links
+   could be added between any points as long as the two entities are
+   visible to each other in a common Encapsulation Space.  The routing
+   within the virtual network would be handled by the encapsulation
+   mechanism.  The programming of the routing tables could be a variant
+   of any of the currently existing routing protocols, an encapsulated
+   OSPF for example.
+
+   With this in mind, it would be possible to have special encapsulation
+   gateways with virtual interfaces on two virtual networks to form an
+
+
+
+Woodburn & Mills                                               [Page 16]
+
+RFC 1241                 Internet Encapsulation                July 1991
+
+
+   entire virtual internet.  This is the role of the Encapsulators
+   joining Virtual Network A and Virtual Network B.
+
+E. Encapsulation and OSI
+
+   It is intended that the encapsulation mechanism described in the memo
+   be extensible to other environments outside of the Internet.  It
+   should be possible to encapsulate many different protocols within IP
+   and IP within many other protocols.
+
+   The key concepts defined in this memo are the mapping of a header to
+   a Flow ID and the mapping of fields in the original header to the
+   encapsulating header.  Special mappings between protocols would have
+   to be defined, i.e. for the QoS bits, and some sort of translation of
+   meanings carefully crafted, but it would be possible, none the less.
+
+F. Security Considerations
+
+   No means of authentication or integrity checking is specifically
+   defined for this protocol apart from the checksum for the header
+   information.  However for authentication or integrity checking to be
+   used with this protocol, it is suggested that the authentication
+   information be appended to the Encapsulated Datagram.  Information
+   regarding the type of authentication or integrity check in use would
+   have to be included in the flow management protocol which is used to
+   distribute the flow information.
+
+G. Authors' Addresses
+
+   Robert A. Woodburn
+   SAIC
+   8619 Westwood Center Drive
+   Vienna, VA  22182
+
+   Phone:  (703) 734-9000 or (703) 448-0210
+   EMail:  woody@cseic.saic.com
+
+
+   David L. Mills
+   Electrical Engineering Department
+   University of Delaware
+   Newark, DE  19716
+
+   Phone:  (302) 451-8247
+   EMail:  mills@udel.edu
+
+
+
+
+
+
+Woodburn & Mills                                               [Page 17]
+
\ No newline at end of file