idnits 2.17.1 draft-ietf-diffserv-tunnels-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2474,RFC-2475], [RFC-2475]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To avoid such complications, we adopt the simpler approach of statically selecting either the inner or outer DSCP value at decapsulation, leaving the full generality of traffic conditioning functionality to be implemented at [5 - Outer] and/or [6 - After]. Tunnels SHOULD support static selection of one or the other value at tunnel egress. The rationale for this approach is that of the two DSCP values, usually only one of them contains useful information, with the other being of little value, and the conceptual model used for the tunnel provides a strong indication as to which one contains the useful information. In general, the outer DSCP value contains the useful information for tunnels based on the uniform model, and the inner DSCP value contains the useful information for tunnels based on the pipe model. IPsec tunnels are usually based on the pipe model, and for security reasons MUST default to selecting the outer DSCP value and SHOULD not select the inner DSCP value in the absence of an adequate security analysis of the resulting risks and implications. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services WG D. Black 2 INTERNET-DRAFT EMC Corporation 3 Document: draft-ietf-diffserv-tunnels-00.txt February 2000 5 Differentiated Services and Tunnels 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance 10 with all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 A revised version of this draft document will be submitted to the 29 RFC editor as a Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested. This 31 document will expire before September, 2000. 33 Distribution of this draft is unlimited. 35 1. Abstract 37 This draft considers the interaction of Differentiated Services 38 (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. 39 The discussion of tunnels in the diffserv architecture [RFC-2475] 40 has been found to provide insufficient guidance to tunnel designers 41 and implementers. With the aim of providing such guidance, this 42 document describes two conceptual models for the interaction of 43 diffserv with IP tunnels and employs them to explore the resulting 44 configurations and combinations of functionality. An important 45 consideration is how and where it is appropriate to perform diffserv 46 traffic conditioning in the presence of tunnel encapsulation and 47 decapsulation. A few simple mechanisms are also proposed that limit 48 the complexity that tunnels would otherwise add to the diffserv 49 traffic conditioning model; these mechanisms are also generally 50 useful in situations where more general traffic conditioning is 51 inappropriate or unavailable. Security considerations for IPsec 52 tunnels may place limits on possible functionality in some 53 circumstances. 55 2. Conventions used in this document 57 An IP tunnel encapsulates IP traffic in another IP header as it 58 passes through the tunnel; the presence of these two IP headers is a 59 defining characteristic of IP tunnels. The inner IP header is that 60 of the original traffic; an outer IP header is attached and detached 61 at tunnel endpoints. In general, intermediate network nodes between 62 tunnel endpoints operate solely on the outer IP header, and hence 63 diffserv-capable intermediate nodes can only access and modify the 64 DSCP field in the outer IP header (e.g., for an encrypted tunnel, 65 interior nodes cannot access the inner IP header). The terms 66 "tunnel" and "IP tunnel" are used interchangeably in this document. 67 For simplicity, we do not consider issues raised by tunnels other 68 than IP tunnels (i.e., where there is no encapsulating IP header), 69 such as MPLS paths and "tunnels" formed by encapsulation in layer 2 70 (link) headers. 72 This document considers tunnels to be unidirectional; bi-directional 73 tunnels are composed of two unidirectional tunnels carrying traffic 74 in opposite directions between the same pair of tunnel endpoints. A 75 tunnel consists of an ingress where traffic enters the tunnel and is 76 encapsulated by the addition of the outer IP header, an egress where 77 traffic exits the tunnel and is decapsulated by the removal of the 78 outer IP header, and intermediate nodes through which tunneled 79 traffic passes between the ingress and egress. This document does 80 not make any assumptions about routing and forwarding of tunnel 81 traffic, and in particular neither requires nor forbids any form of 82 route pinning. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in [RFC-2119]. 88 Text in square brackets labeled "Author's note:" (e.g., [Author's 89 note: this is a note from the author.]) is editorial in nature and 90 will be addressed in a future version of this document. 92 3. Diffserv and Tunnels Overview 94 Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003] 95 to complex multi-protocol tunnels, such as IP in PPP in L2TP in 96 IPsec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most 97 general tunnel configuration is one in which the tunnel is not end- 98 to-end, i.e., the ingress and egress nodes are not the source and 99 destination nodes for traffic carried by the tunnel. If the ingress 100 or egress nodes do coincide with the end-to-end source or 101 destination, the result is a simplified configuration to which much 102 of the analysis and recommendations in this document are applicable. 104 A primary concern for differentiated services is the use of the 105 Differentiated Services Code Point (DSCP) in the IP header; see 106 [RFC-2474, RFC-2475] for more extensive descriptions of the DSCP 107 field and the diffserv architecture. The diffserv architecture 108 permits intermediate nodes to examine and change the value of the 109 DSCP, which may result in the DSCP value in the outer IP header 110 being modified between tunnel ingress and egress. When a tunnel is 111 not end-to-end, there are circumstances in which it may be desirable 112 to propagate the DSCP and/or some of the information that it 113 contains to the outer IP header on ingress and/or back to inner IP 114 header on egress. The current situation facing tunnel implementers 115 is that [RFC-2475] offers some incomplete guidance, and guideline 116 G.7 for PHB specification in Section 3 of that RFC is based on over- 117 simplified assumptions about how tunnels are deployed with respect 118 to DS domain boundaries. The EF PHB specification [RFC-2598] may be 119 too specific (in 20/20 hindsight) because its requirement to use EF 120 in the outer header of tunneled EF packets (based on guideline G.7) 121 is unworkable in domains that do not support EF, and excludes other 122 techniques for conditioning tunneled EF traffic. 124 This document proposes an approach in which traffic conditioning is 125 performed in series with tunnel ingress or egress processing, not in 126 parallel. This approach does not create any additional paths that 127 transmit information across a tunnel endpoint, as all diffserv 128 information is contained in the DSCPs in the IP headers. The IPsec 129 architecture [RFC-2401] requires that this be the case to preserve 130 security properties at the egress of IPsec tunnels, but this 131 approach also avoids introducing out-of-band inputs to diffserv 132 traffic conditioner blocks, which would complicate them. Diffserv 133 domain boundaries can then be positioned as appropriate for the set 134 of traffic conditioning blocks and tunnel processing modules. One 135 configuration of interest involves a diffserv domain boundary that 136 passes through (i.e., divides) a network node; it is acceptable to 137 split such a boundary to create a DMZ-like region between the 138 domains that contains the tunnel ingress or egress processing. 139 Diffserv traffic conditioning is not appropriate for such a DMZ-like 140 region, as that traffic conditioning is part of the operation and 141 management of one or more diffserv domains. 143 4. Conceptual Models for Diffserv Tunnels 145 There are two important conceptual traffic conditioning models for 146 IP tunnels. For clarity, the initial discussion of these models 147 assumes a fully diffserv-capable network. Configurations in which 148 this is not the case are taken up in Section 4.2. 150 4.1 Conceptual Models for Fully DS-capable Configurations 152 The first conceptual model is a uniform model that views IP tunnels 153 as artifacts of the end to end path from a traffic conditioning 154 standpoint; tunnels may be necessary mechanisms to get traffic to 155 its destination(s), but have no significant impact on traffic 156 conditioning. In this model, any packet has exactly one DS Field 157 that is used for traffic conditioning at any point, namely the DS 158 Field in the outermost IP header; any others are ignored. 159 Implementations of this model copy the DSCP value to the outer IP 160 header at encapsulation and copy the outer header's DSCP value to 161 the inner IP header at decapsulation. Use of this model allows IP 162 tunnels to be configured without regard to diffserv domain 163 boundaries because diffserv traffic conditioning functionality is 164 not impacted by the presence of IP tunnels. 166 The second conceptual model is a pipe model that views an IP tunnel 167 as hiding the nodes between its ingress and egress so that they do 168 not participate fully in traffic conditioning. In this model, a 169 tunnel egress node uses traffic conditioning information conveyed 170 from the tunnel ingress by the DSCP value in the inner header, and 171 ignores (i.e., discards) the DSCP value in the outer header. This 172 model cannot completely hide traffic conditioning within the tunnel, 173 as the effects of dropping and shaping at intermediate tunnel nodes 174 may be visible at the tunnel egress and beyond. This model is 175 particularly appropriate to configurations in which the ingress and 176 egress nodes belong to the same diffserv domain but the IP tunnel 177 may pass through other domains; virtual private networks (VPNs) may 178 be configured in this fashion. In this class of configurations, the 179 DSCP values from the ingress node are valid at the egress node 180 because both nodes are in the same diffserv domain. Other uses of 181 the pipe model (i.e., for configurations in which the tunnel ingress 182 and egress nodes are not in the same diffserv domain) SHOULD employ 183 an inter-domain TCA (Traffic Conditioning Agreement) between the 184 diffserv domains containing the tunnel ingress and egress nodes in 185 order to specify the required egress traffic conditioning. 187 The pipe conceptual model is also appropriate for situations in 188 which the DSCP carries information that is within the tunnel. For 189 example, if transit between two domains is purchased via a tunnel 190 that uses the EF PHB [RFC-2598], the drop precedence information in 191 the AF PHB DSCP values [RFC-2597] will be destroyed unless something 192 is done to preserve it; an IP tunnel is one possible preservation 193 mechanism. A tunnel that crosses one or more non-diffserv domains 194 between its DS-capable endpoints may experience a similar 195 information destruction phenomenon due to the limited set of DSCP 196 codepoints that are compatible with such domains. 198 4.2 Considerations for Partially DS-capable Configurations 200 If only the tunnel egress node is DS-capable, [RFC-2475] requires 201 the egress node to perform any edge traffic conditioning needed by 202 the diffserv domain for tunneled traffic entering from outside the 203 domain. If the egress node would not otherwise be a DS edge node, 204 one way to meet this requirement is to perform edge traffic 205 conditioning at an appropriate upstream DS edge node or nodes within 206 the tunnel, and copy the DSCP value from the outer IP header to the 207 inner IP header as part of tunnel decapsulation processing. A 208 second alternative discards the outer DSCP value as part of 209 decapsulation processing, reducing the resulting traffic 210 conditioning problem and requirements to those of an ordinary DS 211 ingress node. This employs the pipe model of a tunnel and hence the 212 adjacent upstream node for DSCP marking purposes is the tunnel 213 ingress node, not the immediately upstream intermediate tunnel node. 215 If only the tunnel ingress node is DS-capable, [RFC-2475] requires 216 that traffic emerging from the tunnel be compatible with the network 217 at the tunnel egress. If tunnel decapsulation processing discards 218 the outer header's DSCP value without changing the inner header's 219 DSCP value, then the DS-capable tunnel ingress node MUST set the 220 inner header's DSCP to a value compatible with the network at tunnel 221 egress. The value 0 (DSCP of 000000) is used for this purpose by a 222 number of existing tunnel implementations. If the egress network 223 implements IP precedence as specified in [RFC-791], then some or all 224 of the eight class selector DSCP codepoints defined in [RFC-2474] 225 are usable. DSCP codepoints other than the class selectors SHOULD 226 NOT be used for this purpose, as correct operation under these 227 circumstances involves diffserv functionality at the DS-incapable 228 tunnel egress node. 230 5. Ingress Functionality 232 As described in Section 3 above, this draft is based on an approach 233 in which diffserv functionality and/or out-of-band communication 234 paths are not placed in parallel with tunnel encapsulation 235 processing. This model allows three possible locations for traffic 236 conditioners with respect to tunnel encapsulation processing, as 237 shown in the following diagram that depicts the flow of IP headers 238 through tunnel encapsulation: 239 +--------- [2 - Outer] -->> 240 / 241 / 242 >>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->> 244 Traffic conditioning at [1 - Before] and [2 - Outer] is logically 245 separate from the tunnel, as it is not impacted by the presence of 246 tunnel encapsulation. Tunnel designs and specifications SHOULD 247 permit diffserv traffic conditioning at these locations. Such 248 conditioning can be performed by standard diffserv traffic 249 conditioning components, such as [Author's note: TBD based on 250 further diffserv WG efforts], and can be viewed as independent of 251 the tunnel (e.g., [1 - Before] can be viewed as separate traffic 252 conditioning that takes place prior to tunnel ingress). 254 In contrast, the [3 - Inner] location SHOULD NOT be utilized for 255 traffic conditioning because it requires functionality that reaches 256 inside the packet to operate on the inner IP header. This is 257 difficult in general, and is impossible for IPsec tunnels and any 258 other tunnels that are encrypted or employ cryptographic integrity 259 checks. Hence traffic conditioning at [3 - Inner] can only be 260 performed as part of tunnel encapsulation processing, complicating 261 both the encapsulation and traffic conditioning implementations. In 262 many cases, the desired functionality can be achieved via a 263 combination of traffic conditioners in the other two locations, both 264 of which can be specified and implemented independently of tunnel 265 encapsulation processing 267 An exception for which traffic conditioning functionality is 268 necessary at [3 - Inner] occurs when the tunnel egress is not DS- 269 capable and discards the outer IP header. Setting the inner DSCP to 270 0 as part of encapsulation addresses most of these cases, and 271 implementations MAY support setting the inner DSCP to one of the 272 class selector DCSP codepoint values, as these are valid for 273 networks that support IP precedence. This level of functionality 274 (set the DSCP to one of the class selector codepoint values) is also 275 generally appropriate for other traffic conditioning locations in 276 configurations that do not support more general traffic conditioning 277 at those locations. 279 The following table summarizes the achievable relationships among 280 the Before (B), outer (O), and inner (I) DSCP values and the 281 corresponding locations of traffic conditioning logic. 283 Relationship Traffic Conditioning Location(s) 284 ------------ -------------------------------- 285 B = I = O No traffic conditioning required 286 B != I = O [1 - Before] 287 B = I != O [2 - Outer] 288 B = O != I Limited support as part of encapsulation: 289 I can be set to 000000 or possibly one of 290 the class selector code points. 291 B != I != O Some combination of the above three cases. 293 A combination of [1 - Before] and [2 - Outer] is applicable in many 294 cases that fit one of the last two lines of the table, and this 295 combination is RECOMMENDED in preference to deploying functionality 296 at [3 - Inner]. Implementers are cautioned that traffic 297 conditioning may still be required for purposes such as rate and 298 burst control even if DSCP values are not changed. 300 [Author's note: Is the above table useful?] 302 6. Egress Functionality 304 As described in Section 3 above, this draft is based on an approach 305 in which diffserv functionality and/or out-of-band communication 306 paths are not placed in parallel with tunnel encapsulation 307 processing. This allows three possible locations for traffic 308 conditioners with respect to tunnel decapsulation processing, as 309 shown in the following diagram that depicts the flow of IP headers 310 through tunnel encapsulation: 312 >>----[5 - Outer]-------------+ 313 \ 314 \ 315 >>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->> 316 Traffic conditioning at [5 - Outer] and [6 - After] is logically 317 separate from the tunnel, as it is not impacted by the presence of 318 tunnel decapsulation. Tunnel designs and specifications SHOULD 319 permit diffserv traffic conditioning at these locations. Such 320 conditioning can be performed by standard diffserv traffic 321 conditioning components, such as [Author's note: TBD based on 322 further diffserv WG efforts], and can be viewed as independent of 323 the tunnel (e.g., [6 - After] can be viewed as separate traffic 324 conditioning that takes place after tunnel egress). An important 325 exception is that the configuration of a tunnel (e.g., the absence 326 of traffic conditioning at tunnel ingress) and/or the diffserv 327 domains involved may require that all traffic exiting a tunnel pass 328 through diffserv traffic conditioning to fulfill the diffserv edge 329 node traffic conditioning responsibilities of the tunnel egress 330 node. Tunnel specifications SHOULD include the ability to require 331 that all traffic exiting a tunnel pass through diffserv traffic 332 conditioning. 334 In contrast, the [4 - Inner] location SHOULD NOT be employed for 335 traffic conditioning because it requires reaching inside the packet 336 to operate on the inner IP header. Unlike the [3 - Inner] case for 337 encapsulation, there is no need for functionality to be performed 338 here, as diffserv traffic conditioning can be appended to the tunnel 339 decapsulation (i.e., performed at [6 - After]). 341 6.1 Egress DSCP Selection 343 The elimination of parallel functionality and data paths from 344 decapsulation causes a potential loss of information. As shown in 345 the diagram in Section 6, decapsulation combines and reduces two 346 DSCP values to one DSCP value, losing information in the most 347 general case, even if arbitrary functionality is allowed. Beyond 348 this, allowing arbitrary functionality poses a structural problem, 349 namely that the DSCP value from the outer IP header would have to be 350 presented as an out-of-band input to the traffic conditioning block 351 at [6 - After], complicating the traffic conditioning model. 353 To avoid such complications, we adopt the simpler approach of 354 statically selecting either the inner or outer DSCP value at 355 decapsulation, leaving the full generality of traffic conditioning 356 functionality to be implemented at [5 - Outer] and/or [6 - After]. 357 Tunnels SHOULD support static selection of one or the other value at 358 tunnel egress. The rationale for this approach is that of the two 359 DSCP values, usually only one of them contains useful information, 360 with the other being of little value, and the conceptual model used 361 for the tunnel provides a strong indication as to which one contains 362 the useful information. In general, the outer DSCP value contains 363 the useful information for tunnels based on the uniform model, and 364 the inner DSCP value contains the useful information for tunnels 365 based on the pipe model. IPsec tunnels are usually based on the 366 pipe model, and for security reasons MUST default to selecting the 367 outer DSCP value and SHOULD not select the inner DSCP value in the 368 absence of an adequate security analysis of the resulting risks and 369 implications. 371 6.2 Egress DSCP Selection Case Study 373 As a sanity check on the simpler approach proposed above (i.e., in 374 Section 6), this subsection considers a situation in which a more 375 complex approach might be required. Statically choosing a single 376 DSCP value is a poor match to situations in which both DSCPs are 377 carrying information that is needed to perform traffic conditioning 378 (i.e., at [6 - After]) correctly. 380 As an example, we consider a situation in which two different AF 381 groups [RFC-2597] are being used by the two domains at the tunnel 382 endpoints, and there is an intermediate domain along the tunnel that 383 uses RFC 791 IP precedences that is transited by setting the DSCP to 384 zero. This situation is shown in the following IP header flow 385 diagram where I is the tunnel ingress node, E is the tunnel egress 386 node and the vertical lines are domain boundaries. The node at the 387 left-hand vertical line sets the DSCP in the outer header to 0 in 388 order to obtain compatibility with the middle domain: 390 | | 391 +-----|-------------------|------+ 392 / | | \ 393 >>-----------I-------|-------------------|--------E---------->> 394 | | 395 Ingress DS Domain RFC 791 Egress DS domain 396 IP Precedence 397 Domain 399 In this situation, the DS edge node for the egress domain (i.e., the 400 node at the right-hand vertical line) can select the appropriate AF 401 group (e.g., via an MF classifier), but cannot reconstruct the drop 402 precedence information that was removed from the outer header when 403 it transited the RFC 791 domain (although it can construct new 404 information via metering and marking). The original drop precedence 405 information is preserved in the inner IP header's DSCP, and could be 406 combined with the AF class selection communicated via the outer IP 407 header's DSCP. The marginal benefit of being able to reuse the 408 original drop precedence information as opposed to constructing new 409 drop precedence markings does not appear to justify the additional 410 complexity that would be introduced into tunnel egress traffic 411 conditioners. 413 [Author's note: Last sentence is an open issue for WG discussion.] 415 7. Diffserv and Protocol Translators 417 A related issue involves protocol translators, of which a specific 418 example are those employing the Stateless IP/ICMP Translation 419 Algorithm [RFC-2765]. These translators are not tunnels because 420 they do not add or remove a second IP header to/from packets (e.g., 421 in contrast to IPv6 over IPv4 tunnels [RFC-1933]) and hence do not 422 raise concerns of information propagation between inner and outer IP 423 headers. The primary interaction between translators and diffserv 424 is that the translation boundary is likely to also be a diffserv 425 domain boundary (e.g., the IPv4 and IPv6 domains may have different 426 policies for traffic conditioning and DSCP usage), and hence such 427 translators SHOULD permit the insertion of diffserv edge node 428 processing (i.e., including traffic conditioning) both before and 429 after the translation processing. 431 8. Security Considerations 433 The security considerations for the diffserv architecture discussed 434 in [RFC-2474, RFC-2475] apply when tunnels are present; readers are 435 referred to those documents for further information. One of the 436 requirements noted there is that a tunnel egress node in the 437 interior of a diffserv domain is the DS ingress node for traffic 438 exiting the tunnel, and is responsible for performing appropriate 439 traffic conditioning. The primary security implication is that the 440 traffic conditioning is responsible for dealing with theft- and 441 denial-of-service threats posed to the diffserv domain by traffic 442 exiting from the tunnel. The IPsec architecture [RFC-2401] places a 443 further restriction on tunnel egress processing; the outer header 444 MUST be discarded unless the properties of the traffic conditioning 445 that will be applied are known and have been adequately analyzed for 446 security vulnerabilities. This includes both the [5 - Outer] and 447 [6 - After] traffic conditioning blocks on the tunnel egress node, 448 if present, and may involve traffic conditioning performed by an 449 upstream DS-edge node that is the DS domain ingress node for the 450 encapsulated tunneled traffic. 452 9. References 454 [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September 455 1981. 457 [RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51, 458 RFC 1661, July 1994. 460 [RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for 461 IPv6 Hosts and Routers", RFC 1933, April 1996. 463 [RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003, 464 October 1996. 466 [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate 467 Requirement Levels", RFC 2119, March 1997. 469 [RFC-2401] S. Kent and R. Atkinson, "Security Architecture for the 470 Internet Protocol", RFC 2401, November 1998. 472 [RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition 473 of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 474 Headers", RFC 2474, December 1998. 476 [RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 477 W. Weiss, "An Architecture for Differentiated Services", RFC 2475, 478 December 1998. 480 [RFC-2597] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, 481 "Assured Forwarding PHB Group", RFC 2597. June 1999. 483 [RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited 484 Forwarding PHB", RFC 2598, June 1999. 486 [RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 487 and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 488 August 1999. 490 [RFC-2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm 491 (SIIT)", RFC 2765. February, 2000. 493 [Author's note: This needs to be extended by additional tunnel RFC 494 references. The references section of the Tunnel MIB RFC (RFC 2667) 495 provides a good starting point.] 497 10. Acknowledgments 499 Some of this material is based on discussions with Brian Carpenter, 500 and in particular his presentation on this topic to the diffserv WG 501 during the summer 1999 IETF meeting in Oslo. Credit is also due to 502 a people working on tunnel specifications [Author's note: names may 503 appear here in a future version] who have discovered limitations of 504 the diffserv architecture RFC (2475) in the area of tunnels. Their 505 kind patience with the time it has taken to address this set of 506 issues has been greatly appreciated. Finally, this material has 507 benefited from discussions within the diffserv WG, and the 508 contributions of participants in those discussions are gratefully 509 acknowledged. 511 11. Author's Address 513 David L. Black 514 EMC Corporation 515 42 South St. 516 Hopkinton, MA 01748 517 Phone: +1 (508) 435-1000 x75140 518 Email: black_david@emc.com