RFC 2983

Differentiated Services and Tunnels

📅 published October 2000, from ietf

Differentiated Services and Tunnels 🎀

okay so bestie, this one is by D. Black from EMC Corporation, and it's an Informational RFC from October 2000 💅. It's part of the Network Working Group series, and its header doesn't list anything it obsoletes or updates, so it's standing on its own ✨. It's all about how Differentiated Services (diffserv) plays with IP tunnels, and honestly it's giving main character energy 🦋

Status of this Memo

ngl the status part is short but important 🙈 This memo is here to provide information for the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract

okay so this doc looks at how Differentiated Services (diffserv) (RFC 2474, RFC 2475) interacts with IP tunnels of all different shapes and sizes 🧚 The diffserv architecture discussion of tunnels in RFC 2475 gives tunnel designers and implementers not enough guidance, which is literally why this doc exists 😭

So it lays out two conceptual models for how diffserv and Internet Protocol (IP) tunnels interact, and then uses them to figure out the configurations and combinations of functionality that can come out of that. A big question is how and where it makes sense to do diffserv traffic conditioning when there's tunnel encapsulation and decapsulation going on 👀 It also proposes a few simple mechanisms that keep tunnels from making the diffserv traffic conditioning model way more complicated than it already is. And the bit about IPSec tunnels is important: security considerations for them limit what functionality is possible in some circumstances 🔥

1. Conventions used in this document 💅

okay so an IP tunnel wraps IP traffic inside another IP header as it goes through the tunnel 🎀 Having those two IP headers is the thing that defines an IP tunnel, although there can be extra headers tucked in between the two IP headers too. The inner IP header belongs to the original traffic, and an outer IP header gets attached and detached at the tunnel endpoints.

Here's the lowkey important part: intermediate network nodes between the endpoints usually only look at the outer IP header. So diffserv-capable intermediate nodes only access and modify the DSCP field in the outer IP header 🦋 The terms "tunnel" and "IP tunnel" are used interchangeably in this doc, so don't get confused if you see both 💖

This doc isn't looking at tunnels that aren't IP tunnels (so, ones with no encapsulating IP header) just to keep things simple ✨ That means it skips things like MPLS paths and "tunnels" made by encapsulating in layer 2 (link) headers. The conceptual models and approach here might still be useful for understanding how diffserv works with those, though 🌈

This analysis treats tunnels as unidirectional 🧚 A bi-directional tunnel is basically two unidirectional tunnels carrying traffic in opposite directions between the same endpoints, which is kind of iconic. A tunnel is made of:

  • an ingress, where traffic enters the tunnel and gets encapsulated by adding the outer IP header,
  • an egress, where traffic exits the tunnel and gets decapsulated by removing the outer IP header, and
  • intermediate nodes, which the tunneled traffic passes through between the ingress and egress.

The doc doesn't make any assumptions about routing and forwarding of tunnel traffic. In particular, it assumes neither the presence nor the absence of route pinning in any form 🙈

2. Diffserv and Tunnels Overview 🌸

Tunnels range from simple IP-in-IP tunnels [RFC 2003] all the way to more complex multi-protocol tunnels, like IP in PPP in L2TP in IPSec transport mode [RFC 1661, RFC 2401, RFC 2661]. Wild, right? 💀

The most general tunnel setup is one where the tunnel is not end-to-end. That means the ingress and egress nodes aren't the source and destination nodes for the traffic in the tunnel, so the tunnel might carry traffic with multiple sources and destinations 🫶 But if the ingress node is the end-to-end source of all traffic in the tunnel, you get a simplified configuration that a lot of this doc's analysis and guidance applies to. Same deal if the egress node is the end-to-end destination ✨

A primary concern for differentiated services is the use of the Differentiated Services Code Point (DSCP) in the IP header [RFC 2474, RFC 2475] 👑 The diffserv architecture lets intermediate nodes examine and change the DSCP value, which can mean the DSCP value in the outer IP header gets modified between tunnel ingress and egress 😭 When a tunnel is not end-to-end, there are situations where it might be useful to propagate the DSCP and/or some of the information it carries to the outer IP header on ingress and/or back to the inner IP header on egress 🧚

Right now, tunnel implementers are kind of stuck, because [RFC 2475] offers incomplete guidance 💔 Guideline G.7 in Section 3 is an example of this. Some PHB specifications followed it by explicitly specifying the PHBs that may be used in the outer IP header for tunneled traffic. Honestly that's overly restrictive 🙅‍♀️ For example, if a specification requires the same PHB in both the inner and outer IP headers, then traffic that conforms to that spec can't be tunneled across domains or networks that don't support that PHB 🍓

A more flexible approach that should be used instead is to describe the behavioral properties of a PHB that matter for preserving when traffic is tunneled, and then let the outer IP header be marked in any fashion that's enough to preserve those properties 🌈

This doc proposes doing traffic conditioning in series with tunnel ingress or egress processing, instead of in parallel 💅 This doesn't create any additional paths that transmit information across a tunnel endpoint, since all diffserv information lives in the DSCPs in the IP headers. The IPSec architecture [RFC 2401] requires this to preserve security properties at the egress of IPSec tunnels, but the approach also keeps diffserv traffic conditioning blocks from getting messy by adding out-of-band inputs 🔥 As a result, the last sentence of Guideline G.7 in Section 3 of [RFC 2475] becomes moot, because there are no tunnel egress diffserv components that have access to both the inner and outer DSCPs 🙈

Another win: this traffic conditioning approach doesn't add any extra restrictions on where diffserv domain boundaries go relative to traffic conditioning and tunnel encapsulation/decapsulation components ✨ One interesting kind of setup has a diffserv domain boundary that passes through (divides) a network node. That boundary can be split to make a DMZ-like region between the domains, and that region holds the tunnel encapsulation or decapsulation processing 🧚 Diffserv traffic conditioning is not appropriate for that DMZ-like region, because traffic conditioning is part of the operation and management of diffserv domains 💖

3. Conceptual Models for Diffserv Tunnels 🦋

okay so this analysis introduces two conceptual traffic conditioning models for IP tunnels. It starts from an initial discussion that assumes a fully diffserv-capable network ✨ Setups where that's not the case get covered in Section 3.2 👀

3.1 Conceptual Models for Fully DS-capable Configurations 💅

The first model is a uniform model 🎀 It treats IP tunnels as artifacts of the end-to-end path from a traffic conditioning standpoint. Tunnels might be necessary to get traffic to its destination(s), but they have no significant impact on traffic conditioning 🌸 In this model, any packet has exactly one DS Field used for traffic conditioning at any point, and that's the DS Field in the outermost IP header. Any others get ignored 🙈

Implementations of this model copy the DSCP value to the outer IP header at encapsulation, and copy the outer header's DSCP value to the inner IP header at decapsulation 🫶 Using this model means IP tunnels can be configured without regard to diffserv domain boundaries, because diffserv traffic conditioning functionality isn't affected by the presence of IP tunnels 🧚

The second model is a pipe model 🌈 It treats an IP tunnel as hiding the nodes between its ingress and egress, so those nodes don't participate fully in traffic conditioning. In this model, a tunnel egress node uses the traffic conditioning information conveyed from the tunnel ingress by the DSCP value in the inner header, and ignores (i.e., discards) the DSCP value in the outer header 💅 The pipe model can't completely hide traffic conditioning inside the tunnel, though, because the effects of dropping and shaping at intermediate tunnel nodes may still be visible at the tunnel egress and beyond 😭

The pipe model has traffic conditioning consequences when the ingress and egress nodes are in different diffserv domains 👑 In that case, the egress node must perform traffic conditioning so that the traffic leaving the tunnel has DSCP values that are acceptable to the egress diffserv domain (see Section 6 of the diffserv architecture [RFC 2475]) 🔥 An inter-domain TCA (Traffic Conditioning Agreement) between the diffserv domains with the tunnel ingress and egress nodes may be used to reduce or eliminate egress traffic conditioning 🎀 Complete elimination of egress traffic conditioning needs the diffserv domains at ingress and egress to have compatible service provisioning policies for the tunneled traffic, and they have to support all of the PHB groups and DSCP values used for that traffic in a consistent fashion 🙈 Some virtual private network tunnels are examples of this. It can be useful to see those tunnels as linking the diffserv domains at their endpoints into one diffserv region, by making the tunnel endpoints virtually contiguous even if intermediate network nodes physically separate them ✨

The pipe model also fits situations where the DSCP itself carries information through the tunnel 🦋 For example, if transit between two domains goes over a path that uses the EF PHB [RFC 2598], then the drop precedence information in the AF PHB DSCP values [RFC 2597] will get lost unless something is done to preserve it. An IP tunnel is one possible way to preserve it 🧚 A path that crosses one or more non-diffserv domains between its DS-capable endpoints might see a similar information loss if no tunnel is used, because of the limited set of DSCP codepoints that are compatible with those domains 💀

3.2 Considerations for Partially DS-capable Configurations

Okay so, what if only some of the boxes in the tunnel are DS-capable? 🫶 Let's go through it.

If only the tunnel egress node is DS-capable, [RFC 2475] requires the egress node to do any edge traffic conditioning the diffserv domain needs for tunneled traffic coming in from outside the domain. If the egress node wouldn't otherwise be a DS edge node, one way to get this done is to condition traffic at a suitable upstream DS edge node inside the tunnel, then copy the DSCP value from the outer IP header into the inner IP header during decapsulation. This applies the uniform model to the part of the tunnel inside the egress node's diffserv domain. ✨

A second option is to throw away the outer DSCP value during decapsulation 🗑️. That shrinks the traffic conditioning problem and requirements down to those of an ordinary DS ingress node. This applies the pipe model to the part of the tunnel inside the egress node's diffserv domain, so the adjacent upstream node for DSCP marking purposes becomes the tunnel ingress node, not the intermediate tunnel node right before the egress. Main character energy, honestly 👑

If only the tunnel ingress node is DS-capable, [RFC 2475] requires that traffic coming out of the tunnel be compatible with the network at the tunnel egress. If decapsulation throws away the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable ingress node is obligated to set the inner header's DSCP to a value that works with the network at the tunnel egress. A bunch of existing tunnel implementations use the value 0 (DSCP of 000000) for this 💖. If the egress network implements IP precedence as specified in [RFC 791], then some or all of the eight class selector DSCP codepoints defined in [RFC 2474] may be usable too. Other DSCP codepoints besides the class selectors aren't generally suitable here, because correct operation would usually need diffserv functionality at the DS-incapable tunnel egress node. Not the vibe 😭

4. Ingress Functionality ✨

As we saw in Section 3 above, this analysis assumes that diffserv functionality and/or out-of-band communication paths are not run in parallel with tunnel encapsulation processing. That gives us three possible spots for traffic conditioning relative to tunnel encapsulation. Here's the diagram showing how IP headers flow through encapsulation 🦋:

                                        +--------- [2 - Outer] -->>
                                       /
                                      /
   >>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>

Traffic conditioning at [1 - Before] is logically separate from the tunnel, since encapsulation doesn't affect it. That means tunnel designs and specs should allow it 🌸. Traffic conditioning at [2 - Outer] can interact with tunnel protocols that are sensitive to packet reordering, so those tunnels may need to limit what happens at [2 - Outer], as discussed further in Section 5.1. If reordering isn't a concern, no extra restrictions should be necessary. Even so, conditioning at [2 - Outer] may be responsible for remarking traffic so it's compatible with the next diffserv domain the tunneled traffic enters.

Now [3 - Inner] is the tricky one 😩. It needs functionality that reaches inside the packet to work on the inner IP header. That's impossible for IPSec tunnels and any other tunnels that are encrypted or use cryptographic integrity checks. So conditioning at [3 - Inner] usually has to happen as part of encapsulation, which makes both the encapsulation and the conditioning implementations more complicated 🙈. Most of the time, you can get what you want by combining conditioners at the other two locations, which can be specified and implemented independently of encapsulation.

There is one exception where [3 - Inner] conditioning is necessary 🚨. That's when the DS-incapable tunnel egress throws away the outer IP header during decapsulation, so the DSCP in the inner IP header has to be compatible with the egress network. Setting the inner DSCP to 0 during encapsulation covers most of these cases, and the class selector DSCP codepoints are useful here too, since they're valid for networks that support IP precedence [RFC 791].

The table below sums up the relationships you can get among the before (B), outer (O), and inner (I) DSCP values, and where the traffic conditioning logic goes 📋.

Relationship       Traffic Conditioning Location(s)
------------       --------------------------------
B  = I  = O        No traffic conditioning required
B != I  = O        [1 - Before]
B  = I != O        [2 - Outer]
B  = O != I        Limited support as part of encapsulation:
                     I can be set to 000000 or possibly one of
                     the class selector code points.
B != I != O        Some combination of the above three scenarios.

A mix of [1 - Before] and [2 - Outer] works for lots of the cases in the last two rows, and it may be a better bet than putting stuff at [3 - Inner] 💜. Heads up though: you might still need traffic conditioning for things like rate and burst control even when the DSCP values don't change 💅.

4.1 Ingress DSCP Selection and Reordering

Sometimes it's necessary or just desirable to limit which DS behavior aggregates use an IP tunnel that's sensitive to packet reordering inside the tunnel 🌀. The diffserv architecture lets packets get reordered when they belong to behavior aggregates that are allowed to be reordered relative to each other. For example, reordering is allowed between behavior aggregates marked with different Class Selector DSCPs [RFC 2474]. IPSec [RFC 2401] and L2TP [RFC 2661] are two examples of reordering-sensitive tunnels. If IPSec's anti-replay support is configured, audit events get generated when reordering goes past certain levels, and those audit events can point to possible security issues 🚩. L2TP can be configured to restore the ingress ordering of packets at the tunnel egress. That not only undoes any differentiation that came from reordering inside the tunnel, it can also hurt the traffic, for example by adding latency 😬. The uniform model can't be fully applied to these tunnels, because mixing traffic from different behavior aggregates arbitrarily can cause these unwanted interactions.

The simplest way to dodge reordering problems with reordering-sensitive tunnel protocols and features is to just not use those protocols or features. But that's often not desirable, or even possible. When you do use them, you can avoid the interactions by making sure the aggregated flows through the tunnel are marked at [2 - Outer] so they form a single ordered aggregate. That means the PHBs used share an ordering constraint that stops packets from being reordered. ✨ Tunnel protocol specs should say whether and under what circumstances a tunnel should be restricted to a single ordered aggregate, and what happens if you deviate from that restriction. For the IPSec and L2TP examples above, the specs should restrict each tunnel to a single ordered aggregate when reordering-sensitive protocol features are configured. They may also choose to restrict all tunnels, to avoid surprises when protocol features change or the tunneled traffic mix changes 🎀.

Diffserv implementations should not try to look inside these tunnels to provide reordering-based differentiation to the encapsulated microflows 🙅‍♀️. If you do want reordering-based differentiation inside such tunnels, you should use multiple parallel tunnels between the same endpoints. That way, reordering can happen among packets in different tunnels while each individual tunnel still has no packet reordering. Lowkey genius 🧠.

For IPSec and related security protocols, using one tunnel for multiple ordered aggregates gives you no cryptographic advantage over using multiple tunnels. Any traffic analysis that multiple tunnels make possible can also be done using the DSCPs in the outer headers of traffic in a single tunnel 🔐. In general, you should weigh the extra resources needed for multiple tunnels (like cryptographic contexts) and the impact on network management before deciding whether and where to deploy them 📊.

4.2 Tunnel Selection

How a tunnel behaves matters a lot when you're deciding what traffic should use it 🧐. That decision involves the service provisioning policies of all the participating domains, not just the PHBs and DSCPs marked on the traffic at [2 - Outer]. For example, tunneling EF PHB traffic through a Default PHB tunnel is generally a bad idea 🙅‍♀️. It can be okay, though, if the EF traffic is the only traffic using that tunnel and the tunnel is provisioned well enough to keep the behavioral characteristics the EF PHB needs 💖.

Service provisioning policies are responsible for preventing mismatches, like sending EF traffic through an under-provisioned Default tunnel 🚫. When there are multiple parallel tunnels with different behavioral characteristics, service provisioning policies also decide which flows should use which tunnels 🗺️. One possibility is a coarse version of the uniform tunnel model, where the inner DSCP value picks the tunnel that forwards the traffic using a behavior aggregate compatible with the traffic's PHB. Chef's kiss 👩‍🍳💋

5. Egress Functionality ✨

okay so, back to [Section 3](#), this whole analysis is built on the idea that diffserv functionality and out-of-band communication paths are NOT run in parallel with tunnel encapsulation processing 🧚 That gives us three possible spots for traffic conditioners, relative to tunnel decapsulation. Here's the flow of IP headers through decapsulation:

   >>----[5 - Outer]-------------+
                                  \
                                   \
   >>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>

Traffic conditioning at [5 - Outer] and [6 - After] is basically its own separate thing from the tunnel 💅 Decapsulation doesn't change it at all. So tunnel designs and specs should allow diffserv traffic conditioning in those two spots. You can think of it as independent of the tunnel: [5 - Outer] is conditioning that happens before tunnel egress, and [6 - After] is conditioning that happens after decapsulation. 🎀

BUT there's an important exception ⚠️ The tunnel's configuration (like having no traffic conditioning at tunnel ingress) and/or the diffserv domains involved might mean that ALL traffic leaving a tunnel has to go through diffserv traffic conditioning, so the tunnel egress node can meet its diffserv edge node responsibilities. Tunnel designers are strongly encouraged to add the ability to require that every packet leaving a tunnel goes through traffic conditioning, so that the traffic leaving the node fits the egress node's diffserv domain. Smart move, honestly 🙈

Heads up: [4 - Inner] is the awkward one. Using it for traffic conditioning means reaching inside the packet to mess with the inner IP header. Unlike the [3 - Inner] case for encapsulation, nothing needs to happen at [4- Inner], because diffserv traffic conditioning can just be tacked onto the end of decapsulation (aka, done at [6 - After]). 🍓

5.1 Egress DSCP Selection

Getting rid of the parallel functionality and data paths during decapsulation causes a potential loss of information 😭 As the diagram shows, decapsulation squishes two DSCP values into one, so information gets lost in the most general case, even if you allow arbitrary functionality. And allowing arbitrary functionality creates a structural problem too: the DSCP from the outer IP header would have to be fed in as an out-of-band input to the traffic conditioning block at [6 - After], which makes the whole traffic conditioning model way messier. Not it. 💀

So the simpler move is to statically pick either the inner or the outer DSCP value at decapsulation. That's the recommended approach, and it leaves full traffic conditioning flexibility to [5 - Outer] and/or [6 - After] ✨ Tunnels should support static selection of one or the other DSCP value at tunnel egress. The reason this works is that usually only one of the two DSCP values actually carries useful info. The tunnel's conceptual model is a strong hint for which one: the outer DSCP usually has the good stuff for tunnels based on the uniform model, and the inner DSCP usually has it for tunnels based on the pipe model. IPSec tunnels are usually based on the pipe model, and for security reasons they are currently required to select the inner DSCP value. They should not be set up to select the outer DSCP value unless someone has done an adequate security analysis of the risks and implications first 🔒

5.2 Egress DSCP Selection Case Study

Okay, this subsection is a sanity check on the egress DSCP selection approach we just talked about 🧠 Picking one DSCP statically might not cut it when BOTH DSCPs are carrying info that matters for traffic conditioning.

Here's an example: say the two domains at the tunnel endpoints use different AF groups [RFC 2597], and there's an intermediate domain along the tunnel that uses RFC 791 IP precedences, which gets transited by setting the DSCP to zero. Here's the IP header flow diagram, where I is the tunnel ingress node, E is the tunnel egress node, and the vertical lines are domain boundaries. The node on the left-hand vertical line sets the DSCP in the outer header to 0 so it stays compatible with the middle domain 🌈

                        |                   |
                  +-----|-------------------|------+
                 /      |                   |       \
   >>-----------I-------|-------------------|--------E---------->>
                        |                   |
      Ingress DS Domain        RFC 791         Egress DS domain
                            IP Precedence
                                Domain

In this case, the DS edge node for the egress domain (the node on the right-hand vertical line) can pick the right AF group (e.g., with an MF classifier), but it can't rebuild the drop precedence info that got removed from the outer header when it went through the RFC 791 domain. It CAN make new info through metering and marking, though 🦋 The original drop precedence info is still preserved in the inner IP header's DSCP, and it could be combined at the tunnel egress with the AF class selection from the outer IP header's DSCP. BUT, reusing the original drop precedence info instead of making new drop precedence markings doesn't really justify the extra complexity. Making both DSCP values available to traffic conditioning at [6 - After] would add that complexity to tunnel egress traffic conditioners, and it's just not worth it for that small gain 💅

6. Diffserv and Protocol Translators ✨

Okay, next up is protocol translators, including ones that use the Stateless IP/ICMP Translation Algorithm [RFC 2765] 🦋 These translators are NOT tunnels, because they don't add or remove a second IP header to or from packets (unlike IPv6 over IPv4 tunnels [RFC 1933]). So they don't raise the same concerns about info moving between inner and outer IP headers. The main way translators interact with diffserv is that the translation boundary is likely to ALSO be a diffserv domain boundary. For example, the IPv4 and IPv6 domains might have different policies for traffic conditioning and DSCP usage. So translators like this should allow diffserv edge node processing, including traffic conditioning, both before and after the translation processing 🫶

7. Security Considerations 🔐

The security considerations for the diffserv architecture discussed in [RFC 2474, RFC 2475] apply when tunnels are present, so buckle up 😭 One of the requirements is that a tunnel egress node in the interior of a diffserv domain is the DS ingress node for traffic leaving the tunnel, and it's responsible for doing the appropriate traffic conditioning. The main security implication is that traffic conditioning has to deal with theft and denial-of-service threats that traffic leaving the tunnel poses to the diffserv domain. ⚠️

The IPSec architecture [RFC 2401] adds another restriction on tunnel egress processing: the outer header is to be discarded UNLESS the properties of the traffic conditioning to be applied are known and have been adequately analyzed for security vulnerabilities. This covers both the [5 - Outer] and [6 - After] traffic conditioning blocks on the tunnel egress node, if they're present. It may also involve traffic conditioning done by an upstream DS-edge node, which is the DS domain ingress node for the encapsulated tunneled traffic. Serious business, bestie 🖤

8. References 📚

  • [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
  • [RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
  • [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597. June 1999.
  • [RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
  • [RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
  • [RFC 2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.

9. Acknowledgments 🙏

Some of this material is based on discussions with Brian Carpenter, and especially his presentation on this topic to the diffserv WG during the summer 1999 IETF meeting in Oslo 🇳🇴 Credit is also due to a bunch of people working on tunnel specifications who discovered limitations of the diffserv architecture [RFC 2475] in the area of tunnels. Their patience with how long it's taken to sort out these issues is hugely appreciated 🥹 Finally, this material benefited from discussions within the diffserv WG, both in meetings and on the mailing list. The contributions of everyone in those discussions are gratefully acknowledged 💜

10. Author's Address 📮

   David L. Black
   EMC Corporation
   42 South St.
   Hopkinton, MA   01748

   Phone: +1 (508) 435-1000 x75140
   EMail: black_david@emc.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

okay so the legal bit is important, bestie 🫶 The Internet Society owns the copyright. You're allowed to copy this document and share it with other people, no cap. You can also write derivative works that comment on it, explain it, or help people implement it, and publish and distribute those too, in whole or in part, with no real restrictions. The one condition is that the copyright notice and this paragraph have to stay on every copy and every derivative work 📜

What you can't do is modify this document itself. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed), or when you need to translate it into a language other than English 🌍

These permissions are perpetual, which means the Internet Society and its successors or assigns can't take them back. Forever and ever 💅✨

The document and everything in it is provided "AS IS" 🎀 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Basically they're not promising it'll work for everything, so read carefully 👀

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶 Someone has to pay for the people keeping all these documents tidy, and right now that's the Internet Society. Iconic behind-the-scenes work 👑

📦 where this page comes from