RFC 1241
Scheme for an internet encapsulation protocol: Version 1
RFC 1241: A Scheme for an Internet Encapsulation Protocol: Version 1 🎀
- RFC number: 1241
- Group: Network Working Group
- Authors: R. Woodburn (SAIC) and D. Mills (University of Delaware)
- Category: Experimental
- Date: July 1991
- Obsoletes / Updates: nothing listed in the title block
1. Status of this Memo 📜
Okay so this memo defines an Experimental Protocol for the Internet community 🧪 They really want your thoughts, so discussion and suggestions for improvement are requested. If you want to know where this protocol stands on standardization and status, check the current edition of the "IAB Official Protocol Standards." And distribution of this memo is unlimited, so share away 💌
2. Glossary 📖
Bestie, here's the vocab you need to know 🤓
Clear Datagram - The unmodified IP datagram sitting in the User Space before it gets encapsulated 🫶
Clear Header - The header part of the Clear Datagram before encapsulation. This includes the IP header and maybe some or all of the next layer protocol header, like the TCP header.
Decapsulation - Stripping off the Encapsulation Header and forwarding the Clear Datagram, done by the Decapsulator ✂️
Decapsulator - The entity that receives an Encapsulated Datagram, decapsulates it, and delivers it to the destination User Space. Delivery can be direct or go through encapsulation again. A Decapsulator can be a host or a gateway 🧚
Encapsulated Datagram - A Clear Datagram with an Encapsulation Header stuck on the front 🎁
Encapsulation - Mapping a Clear Datagram into the Encapsulation Space, prepending an Encapsulation Header to it, and routing the Encapsulated Datagram to a Decapsulator 💅
Encapsulation Header - The header for the Encapsulation Protocol that gets prepended to the Clear Datagram during Encapsulation. It's an IP header followed by an Encapsulation Protocol Header.
Encapsulation Protocol Header - The part of the Encapsulation Header that's specific to the Encapsulation Protocol.
Encapsulation Space - The address and routing space where Encapsulators and Decapsulators live. Routing inside this space happens via Flows. Encapsulation Spaces don't overlap, so the address of any Encapsulator or Decapsulator is unique across all Encapsulation Spaces 🌈
Encapsulator - The entity that maps a given User Space datagram into the Encapsulation Space, encapsulates it, and forwards the Encapsulated Datagram to a Decapsulator. An Encapsulator can be a host or a gateway 🦋
Flow - Also called a "tunnel." A flow is the end-to-end path in the Encapsulation Space that Encapsulated Datagrams travel along. There can be several Encapsulator/Decapsulator pairs on one flow. Note that a Flow doesn't say which User Space gateways get traversed on the path 🛣️
Flow ID - A 32-bit identifier that uniquely distinguishes a flow within a given Encapsulator or Decapsulator. Flow IDs are specific to a single Encapsulator/Decapsulator Entity and are not global quantities 🔢
Mapping Function - The function that maps 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 that uniquely identifies an entity within a User Space 🪪
Source Route - A complete end-to-end route, computed at the source, that enumerates the transit gateways 🧭
User Space - The address and routing space where users live. Routing within this space provides reachability between all address pairs in it. User Spaces don't overlap, so a given User Address is unique in all User Spaces 🏠
3. Background 🌸
Okay so for years, researchers in the Internet community have needed a way to "tunnel" between networks 🚇 A tunnel is basically a Source Route that goes around conventional routing. Tunnels let you bypass routing failures, avoid broken gateways and routing domains, or set up deterministic paths for experiments. Iconic behaviour, honestly 👑
There are a few ways to do tunneling. In the past, it's been done with source routing options in the IP header, which let you list the gateways along a path. The downside is that the source has to know stuff about the networks it's traveling through in order to reach the destination. The source then has to modify outgoing packets to reflect that source route 😩 Current routing implementations generally don't support source routes in their routing tables as a way to reach an IP address, and current routing protocols don't either.
Another option would be to make a brand-new IP option 🧩 That option would sit in a separate IP header prepended to an IP datagram, and it would carry info about the original datagram. The catch is that this means significantly modifying existing IP implementations to handle the new option. It's also less flexible for tunneling other protocols, like ISO protocols, through an IP environment. An even less palatable option would be replacing IP with a new networking protocol, or making a new version of IP with tunneling built in as part of its functionality 🙈
The final option is a new IP encapsulation protocol that uses the current IP header format ✨ With encapsulation, a destination can be reached transparently, so the source doesn't have to know the topology specifics. You can even create virtual networks by tying otherwise unconnected machines together with flows through an encapsulation space 🦋
++++++ 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 ModelUp until now, there hasn't been any standard for an encapsulation protocol 😭 This RFC gives us a way to do encapsulation in the Internet environment, and it's about time 💖
4. Architecture and Approach 🧚
Okay the architecture for encapsulation is built on two entities: an Encapsulator and a Decapsulator 🫶 These entities and their associated spaces are shown in Fig. 1.
Encapsulators and Decapsulators have addresses in the User Spaces they belong to, and they also have addresses in the Encapsulation Spaces they belong to. An Encapsulator receives a Clear Datagram from its User Space. After it figures out that encapsulation should be used, it runs a mapping function that translates the User Space information in the Clear Header into an Encapsulation Header. That Encapsulation Header gets prepended to the Clear Datagram to form the Encapsulated Datagram, as in Fig 2 💅 It's really desirable that encapsulation is transparent to entities in the User Space. Only the Encapsulator needs to know that encapsulation is happening 🤫
+---------------+-----------------+--------+----------------+
| Encapsulating | Encapsulation | Clear | Remainder of |
| IP Header | Protocol Header | Header | Clear Datagram |
+---------------+-----------------+--------+----------------+
| | |
| Encapsulation Header | Clear Datagram |
| | |
Fig. 2. Example of an Encapsulated DatagramThe Encapsulator forwards the datagram to a Decapsulator, and the identity of that Decapsulator gets determined at the time of encapsulation 🎯 The Decapsulator receives the Encapsulated Datagram, removes the Encapsulation Header, and treats the Clear Datagram as if it had been received locally. The requirement for the Decapsulator's address is that it be reachable from the Encapsulator's Encapsulation Space address 🦋
Part 1 of 4 done, bestie! More coming soon 💜
5. Generation of the Encapsulation Header ✨
okay bestie, so the Encapsulation Header gets built by running a mapping function on the Clear Header 🎀 there are lots of ways to write that mapping, but the end result should be the same no matter which one you pick 💅 the paragraphs below walk through one method, and it's shown in Fig. 3 🦋
In the first part of the mapping, the Clear Header gets "mask-and-matched" against stored headers and masks to find a Flow ID 🔍 picture a lookup table where each row has three entries: a Clear Header, a header mask, and the Flow ID that goes with them 💜 the mask lets a whole range of source and destination addresses land in one flow, which is so clean ✨ other fields, like the IP TOS bits or even the TCP source or destination port, can help tell Flows apart too 🌸 so you can link a whole network to one flow, or even one specific TCP protocol or connection 😭 that is some serious flexibility
How the lookup table gets built and maintained is not part of this protocol 🙈 it's assumed that some higher layer entity handles it. Honestly, configuring the tables from ascii text files would be totally fine if needed 📄
+--------+
| |
+->| Encap. |--+
| | Info. | |
+-------+ | | Table | |
| Mask | +---------+ | | | |
Clear --+-->| & |-->| Flow ID |---+ | | |
Header | | Match | +---------+ +--------+ |
| +-------+ |
| +--> Encap
+-----------------------------------------------> HeaderFig. 3. Generation of the Encapsulation Header
The Flow IDs get managed at a higher layer too 🧚 an example of how that can work is the Setup protocol of the Inter-Domain Policy Sensitive Routing Protocol (IDPR). [4] The upper layer protocol is responsible for keeping track of the stuff that isn't carried in the encapsulation protocol but is still related to the flow 📝 that includes the info needed to build the Encapsulation Header (more on that below), the type of data being encapsulated (currently only IP is defined), and the type of authentication used, if any 🔐 also, IDPR Setup requires a longer Flow ID that's unique across the entire universe of Encapsulators and is the same at every Encapsulator 🌈
The Flow ID that comes out of mapping a Clear Header is a 32 bit quantity, and it identifies the Flow as the Encapsulator sees it ✨ if a Clear Datagram has to be encapsulated and decapsulated several times to reach the destination, the Flow ID may be different at each Encapsulator, but it doesn't have to be 🦋 the Flow ID acts as an index into a table of Encapsulation Header info that's used to build the header. And the reason the Flow ID is local to each Encapsulator? Choosing and maintaining globally unique identifiers is genuinely hard, so that's the call they made 🫶
Using a Flow ID is entirely optional at this intermediate step ✨ the important requirement is that all Encapsulators along a Flow map the same Clear Header to the same Flow, even if that Flow goes by different identifiers along the way 💅 having a Flow ID in the protocol does make a more efficient mapping implementation possible, though, and we'll get into that when we talk about 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 is made of an IP Header plus an Encapsulation Protocol Header 🎀 there are two pieces of info the Encapsulation Protocol Header needs that get figured out at encapsulation time: the protocol being encapsulated, and the Flow ID to send to the Decapsulator 💜 the IP header part is where things get a bit more complicated 😭
There are two possible ways each field in the Clear Header could relate 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 it does not apply to the new IP header.
The IP header has a fixed portion and a variable portion, which is the options list 📦 a summary of every possible IP field and how it relates to the Clear Header is in Table 1. [2]
+---------------------+---------+
| 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
Most of the fields in the Clear Header just get ignored 🙈 the Header Length in the Clear Header has zero effect on the Header Length of the new IP header, for example. The ones that are more interesting, and need a bit of thought, are next 🧠
The Quality of Service bits should be copied from the Clear Header to the new IP header 💖 this follows the transparency principle, which says that if the User Space was providing a given service, then the Encapsulation Space must provide that same service. No dropping the vibe 💅
The More Fragments bit and Fragment Offset should not be copied 🧩 the datagram being built is a complete datagram, no matter what the status of the encapsulated datagram is. If the completed datagram is too big for the interface, the normal IP fragmentation mechanism will fragment it for transmission to the decapsulator.
The Don't Fragment bit should not be copied into the Encapsulation Header either ⚠️ that would violate transparency again. Whether fragmentation should be allowed across the Encapsulation Space is up to the Encapsulator to decide 🔥 if the DF bit is going to be used, then an ICMP message would be returned if the Encapsulated Datagram needed fragmentation across the Encapsulation Space. The mechanism for returning that ICMP message to the source in the User Space will have to be modified, though, and that's covered in Appendix B 🎀
The Time To Live field is a big one 🙈 the easiest thing is to ignore the TTL from the Clear Header. If it got copied over, the packet life might be prematurely exceeded while it's in transit through the Encapsulation Space, and that breaks the transparency rule as seen from the User Space. The TTL of the Clear Header gets decremented before encapsulation by the IP forwarding function, so there's no chance of a packet looping forever if the links of a Flow form a loop 🔄
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, and the destination address becomes the IP address of the Decapsulator as found in the encapsulation table 📬
IP Options are generally not copied, because most of them don't make sense in the context of the Encapsulation Space, which is exactly what the transparency principle would tell you 🙅♀️ the security option is probably the one option that should get copied, for the same reason the 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 Datagram, strips off the Encapsulation Header, and sends the Clear Datagram back into IP so it gets forwarded from that point 🦋 but if the Clear Datagram hasn't reached the destination User Space yet, it must be encapsulated again to move it close to that destination 🚀 in this case the Decapsulator becomes an Encapsulator and does the same calculation to generate the Encapsulation Header that the previous Encapsulator did. To make this more efficient, the use of Flow IDs has been built 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 to skip the mask and match operation on the Clear Header 🙌 the received Flow ID can point directly into the local Encapsulator tables to build the next Encapsulation Header. If the Flow ID is unknown, an error message gets sent back to the previous Encapsulator to say so, and a signal gets sent to the upper layer entity that's managing the encapsulation tables 🚨
Because the normal IP forwarding mechanism gets bypassed when Flow IDs are used, certain mechanisms that IP normally handles must be taken care of by the Decapsulator before encapsulation 🧚 the Decapsulator must decrement the TTL before the next encapsulation occurs. And if a Time Exceeded error happens, then an ICMP message is sent to the source indicated in the Clear Header 💀
7. Error Messages 🚨✨
okay so the encapsulation protocol has two kinds of error message built right in 💅 The first one reports unknown flow identifiers that a Decapsulator runs into, and the second one forwards ICMP messages back along a flow 🦋
When a Decapsulator uses the Flow ID from an Encapsulation Header to forward a datagram to the next Decapsulator in a Flow, that Flow ID might not be known 😭 If it isn't, the Decapsulator tells the previous Encapsulator that the Flow was not known, so the problem can get reported to the layer in charge of programming the Flow tables. This happens through an encapsulation error message.
If an Encapsulator gets an ICMP message about a given flow, that message should be forwarded backwards along the flow to the source Encapsulator 🫶 The second kind of error message handles this. The ICMP message carries the Flow ID of the message that caused the error, and that Flow ID has to be translated into the Flow ID relative to the Encapsulator the error message is being sent to.
If an error happens while sending any error message, no further error messages 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 is all about the packet formats for the encapsulation protocol 🎀 here's the header layout:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | HL | MT | RC | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. A.1. Encapsulation Protocol Header Examplehere's what each field does 🧁
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 holds the reason code for that Error Message. The defined reason code values are listed below.
1 Unknown Flow ID
2 ICMP returnedChecksum(16 bits): a one's complement checksum for the Encapsulation Protocol Header. This field is set to 0 when the checksum is calculated, and it gets filled with the checksum result before the data message is sent.Flow ID(32 bits): the Flow ID as seen by the Decapsulator or Encapsulator this message is being sent to. For an Unknown Flow ID error, the Flow ID that caused 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 gets into the nitty-gritty of how this encapsulation protocol affects existing IP mechanisms, and how some IP mechanisms can affect this protocol 🧠 specifically, we're looking at Fragmentation and ICMP messages.
B.1 Fragmentation and Maximum Transmission Unit 🧩
okay so the big worry with any encapsulation mechanism is MTU size 😬 The source of a Clear Datagram builds packets that match the MTU of the interface the datagram gets sent out on. If those packets reach an Encapsulator and get encapsulated, they may be fragmented when they're larger than the Encapsulator's MTU, even if the physical interfaces of the source and the Encapsulator have the same MTU. The Encapsulated Datagram goes to the Decapsulator over IP, so letting IP handle fragmentation and reassembly is no problem 🧚 However, fragmentation is known to be inefficient and is generally avoided. Because the encapsulation process prepends a new header to the Clear Datagram, fragmentation becomes more likely. If the Encapsulator decides to disallow fragmentation through the Encapsulation Space, it must send an ICMP message back to the source. That means the MTU of the interface in the encapsulation space is effectively smaller than the physical MTU of the interface 📏
fragmentation by intermediate User Space Gateways adds another wrinkle 🙃 Fragmentation happens at the IP level. If TCP is in use and fragmentation occurs, the TCP header is in the first fragment but not in the following fragments [3]. If an Encapsulator forwards those fragments, it can only tell which Clear Header belongs to a given flow from the IP portion of the Clear Header. If it tries to match on the TCP portion, only the first fragment will match, and the remaining fragments won't 💔
B.2 ICMP Messages 🙈
the most controversial part of encapsulation is how ICMP messages get handled [1] 🫣 Because the Encapsulation Header contains the Encapsulator's source address in the Encapsulation Space, ICMP messages that happen inside the Encapsulation Space get sent back to the Encapsulator. Once the Encapsulator has the ICMP message, the question is what it should do next. The original source of the Clear Datagram knows nothing about the Encapsulation Space, so forwarding an ICMP message on to it doesn't make sense, and ICMP messages aren't supposed to beget ICMP messages. Still, not telling the original source anything may break some important mechanisms 😵
there's also the problem of possibly not having enough information to send anything back to the source at all 🫠 An ICMP message returns the header of the offending message plus the first eight octets of the data after that header. For this protocol, that means 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. So for the Encapsulator to send an ICMP message back to the source, it has to reconstruct the Clear Header. Yet it's essentially impossible to reproduce the exact header 💀
for this specification, the Flow ID is assumed to be a unique one-way mapping from a Clear Header. There's no guarantee the Flow ID can map back to the Clear Header, since several headers can potentially map to the same flow. With no effective way to regenerate the original datagram, some compromises have to be looked at 🤝
each possible ICMP message gets its alternatives and impact assessed. There are three categories of ICMP message involved 📋
The first category is ICMP messages that don't apply in the context of Encapsulation. These are:
- Echo/Echo Reply
- Timestamp/Timestamp Reply
The second category is ICMP messages about mechanisms local to the encapsulation domain. These are messages that wouldn't make sense to the original source if it did receive them. In these cases the encapsulator has to decide what to do, but no ICMP message needs to be sent back to the original source. The datagram just gets lost, because IP isn't meant to be a reliable protocol. Later 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 means ICMP messages inside the encapsulation domain have to affect the mapping from the Flow ID. The ICMP messages in the second category are:
- Parameter Problem
- Redirect
- Destination Unreachable
- Time Exceeded
Finally, there's one ICMP message that directly affects the original source of datagrams headed for encapsulation: the ICMP Source Quench message 🚦 The only option the Encapsulator has for handling it is for the Source Quench to set a flag for the offending Flow ID. Then, subsequent messages that map to that Flow cause a source quench to be sent back to the original source before the datagram is encapsulated.
This last mechanism might be a solution for the more general problem ✨ The rule of thumb could be this: when an ICMP message is received for a given flow, flag the Flow so the next message encapsulated on that flow forces an ICMP message back to the source. Once that ICMP message has been sent to the source, the mechanism could be reset. This would effectively mean every other packet gets an ICMP message if there's a persistent problem. This mechanism is probably only safe for Unreachable messages and Source Quench 🫶
C. Reception of Clear Datagrams 📨
okay so to use the encapsulation protocol, IP forwarding needs a modification 🔧 There has to be some way for the IP module in a system to pass Clear Datagrams to the encapsulation protocol. A suggested approach is to add something to a system's routing table structures. A flag could be added to a route that tells the forwarding function to use encapsulation. The default route could also be set to use encapsulation 🌸
With this in place, a system's IP forwarding mechanism looks through its routing tables to try to match the IP destination to a specific route. If a route is found, it gets checked to see whether encapsulation should be used. If not, the packet is handled normally. If encapsulation is turned on for the route, the datagram gets sent to encapsulation for forwarding 🦋
Snagging packets as they're forwarded isn't the only thing that has to happen. Something also has to be done at the last Decapsulator on a given flow, so the packets that get decapsulated are properly dumped into the IP module for delivery 📬 Because the packets were encapsulated just before forwarding, it should be a simple matter to inject the decapsulated datagrams into the output portion of IP. However, the source address in the Clear Header must not change. That address has to remain the address of the source in the source User Space, and it must not be overwritten with the Decapsulator's address 🌈💖 that's the whole point!
D. Construction of Virtual Networks with Encapsulation 🌸
Okay so this part is so fun 💖. Since the routing table can now handle encapsulation, you can set up a virtual interface whose whole job is encapsulation 🦋. That means you can link entities that are topologically far apart using Flows 🧚. You get a Virtual Network sitting on top of the real routing topology, basically an overlay ✨. Fig. 4 is the vibe:
++++++ Virtual Network A
****** Virtual Network B
# Encapsulator/Decapsulator
------ Common Routing Space
------------ ------------
/ \ / \
/ +++ # \ / \
| # +++ + | | # ***** # |
| + + | | * * |
| + + | | * * |
| + + | | * * |
| # ++++ # + | | * * |
\ + / ------------- \ # ** / ---------
\ + # ++ \ # ****** *** # ** \
------------ / +++ * ------------ / *** \
| # * | | # *** #|
| + ** | | * *|
| + # | | * ** |
| + ++++ * | | * * |
| #+ * | | * * |
------------ \ ++++ */ ------------ \ * # /
/ \ # + # ** * # ***** /
/ + ------------- / # ****** # *\ --------
| # +++++++ +| | * * |
| + + + | | * * |
| + # | | * * |
| + ++ | | * # |
| # ++++++ | | * ********* |
\ / \ # /
\ / \ /
------------ ------------
Fig. 4. Virtual Networks ExampleEach Encapsulator in the picture has a virtual interface on one of the virtual networks 💅. The lines are the individual links in the flows that connect each member of the virtual network 🌈. New links can be added between any two points, as long as the two entities can see each other in a common Encapsulation Space 🫶. Routing inside the virtual network is handled by the encapsulation mechanism itself. The routing tables could be programmed with a variant of any of the existing routing protocols, like an encapsulated OSPF, for example 🤓.
With all that in mind, it's possible to have special encapsulation gateways with virtual interfaces on two virtual networks, which together form a whole virtual internet 👑. That's the job of the Encapsulators joining Virtual Network A and Virtual Network B 😭.
E. Encapsulation and OSI 🌏
The plan is for this encapsulation mechanism to be extensible to environments beyond the Internet 🚀. You should be able to wrap many different protocols inside IP, and IP inside many other protocols 🎀.
The big ideas in this memo are mapping a header to a Flow ID, and mapping fields from the original header onto the encapsulating header 💜. Special mappings between protocols would have to be defined, like for the QoS bits, plus some carefully crafted translation of meanings. But it would still totally be possible, nonetheless 💪.
F. Security Considerations 🔐
Okay, serious moment 🥺. This protocol doesn't specifically define any authentication or integrity checking, apart from the checksum for the header information.
Heads up, bestie 😭: the header checksum is the only built-in check here, so don't assume anything beyond it.
If you want authentication or integrity checking with this protocol, it's suggested that you append the authentication information to the Encapsulated Datagram 🔒. The type of authentication or integrity check in use would have to be included in the flow management protocol that distributes the flow information 🗝️.
G. Authors' Addresses 🖋️
Here's who wrote it, bestie 💜
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📦 where this page comes from
- ietf: rfc1241 1991-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms