idnits 2.17.1 draft-ietf-mpls-in-ip-or-gre-08.txt: 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: ---------------------------------------------------------------------------- == 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 482 has weird spacing: '...or work on en...' == Line 484 has weird spacing: '...or work on en...' -- 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 (June 2004) is 7227 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) == Missing Reference: 'RFC2460' is mentioned on line 137, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Unused Reference: 'RFC792' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC2463' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC3260' is defined on line 548, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tom Worster 3 Internet Draft 4 Expiration Date: December 2004 5 Yakov Rekhter 6 Juniper Networks, Inc. 8 Eric C. Rosen, editor 9 Cisco Systems, Inc. 11 June 2004 13 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) 15 draft-ietf-mpls-in-ip-or-gre-08.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Various applications of MPLS make use of label stacks with multiple 40 entries. In some cases, it is possible to replace the top label of 41 the stack with an IP-based encapsulation, thereby enabling the 42 application to run over networks which do not have MPLS enabled in 43 their core routers. This draft specifies two IP-based 44 encapsulations, MPLS-in-IP, and MPLS-in-GRE (Generic Routing 45 Encapsulation). Each of these is applicable in some circumstances. 47 Table of Contents 49 1 Specification of Requirements .......................... 2 50 2 Motivation ............................................. 2 51 3 Encapsulation in IP .................................... 3 52 4 Encapsulation in GRE ................................... 5 53 5 Common Procedures ...................................... 6 54 5.1 Preventing Fragmentation and Reassembly ................ 6 55 5.2 TTL or Hop Limit ....................................... 7 56 5.3 Differentiated Services ................................ 8 57 6 Applicability .......................................... 8 58 7 IANA Considerations .................................... 9 59 8 Security Considerations ................................ 9 60 8.1 Securing the Tunnel Using IPsec ........................ 9 61 8.2 In the Absence of IPsec ................................ 11 62 9 Acknowledgments ........................................ 12 63 10 Normative References ................................... 12 64 11 Informative References ................................. 13 65 12 Author Information ..................................... 13 66 13 Intellectual Property Notice ........................... 14 67 14 Copyright Notice ....................................... 15 69 1. Specification of Requirements 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119. 75 2. Motivation 77 In many applications of MPLS, packets traversing an MPLS backbone 78 carry label stacks with more than one label. As described in section 79 3.15 of [RFC3031], each label represents a Label Switched Path (LSP). 80 For each such LSP, there is a Label Switching Router (LSR) which is 81 the "LSP Ingress", and an LSR which is the "LSP Egress". If LSRs A 82 and B are the Ingress and Egress, respectively, of the LSP 83 corresponding to a packet's top label, then A and B are adjacent LSRs 84 on the LSP corresponding to the packet's second label (i.e., the 85 label immediately beneath the top label) 86 The purpose (or one of the purposes) of the top label is to get the 87 packet delivered from A to B, so that B can further process the 88 packet based on the second label. In this sense, the top label 89 serves as an encapsulation header for the rest of the packet. In 90 some cases the top label can be replaced, without loss of 91 functionality, by other sorts of encapsulation headers. For example, 92 the top label could be replaced by an IP header or a Generic Routing 93 Encapsulation (GRE) header. As the encapsulated packet would still 94 be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE 95 encapsulation. 97 With these encapsulations, it is possible for two LSRs that are 98 adjacent on an LSP to be separated by an IP network, even if that IP 99 network does not provide MPLS. 101 In order to use either of these encapsulations, the encapsulating LSR 102 must know: 104 - the IP address of the decapsulating LSR, and 106 - that the decapsulating LSR actually supports the particular 107 encapsulation. 109 This knowledge may be conveyed to the encapsulating LSR by manual 110 configuration, or by means of some discovery protocol. In 111 particular, if the tunnel is being used to support a particular 112 application, and that application has a setup or discovery protocol, 113 then this knowledge may be conveyed by the application's protocol. 114 The means of conveying this knowledge is outside the scope of the 115 current document. 117 3. Encapsulation in IP 119 MPLS-in-IP messages have the following format: 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | | 123 | IP Header | 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | | 127 | MPLS Label Stack | 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 | Message Body | 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 IP Header 136 This field contains an IPv4 or an IPv6 datagram header 137 as defined in [RFC791] or [RFC2460] respectively. The 138 source and destination addresses are set to addresses 139 of the encapsulating and decapsulating LSRs respectively. 141 MPLS Label Stack 142 This field contains an MPLS Label Stack as defined in 143 [RFC3032]. 145 Message Body 146 This field contains one MPLS message body. 148 The IPv4 Protocol Number field or the IPv6 Next Header field is set 149 to [value to be assigned by IANA], indicating an MPLS unicast packet. 150 (The use of the MPLS-in-IP encapsulation for MPLS multicast packets 151 is not supported by this specification.) 153 Following the IP header is an MPLS packet, as specified in [RFC3032]. 154 This encapsulation causes MPLS packets to be sent through "IP 155 tunnels". When a packet is received by the tunnel's receive 156 endpoint, the receive endpoint decapsulates the MPLS packet by 157 removing the IP header. The packet is then processed as a received 158 MPLS packet whose "incoming label" [RFC3031] is the topmost label of 159 the decapsulated packet. 161 4. Encapsulation in GRE 163 The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE 164 [RFC2784]. The packet then consists of an IP header (either IPv4 or 165 IPv6) followed by a GRE header followed by an MPLS label stack as 166 specified in [RFC3032]. The protocol type field in the GRE header 167 MUST be set to the Ethertype value for MPLS Unicast (0x8847) or 168 Multicast (0x8848). 170 This encapsulation causes MPLS packets to be sent through "GRE 171 tunnels". When a packet is received by the tunnel's receive endpoint, 172 the receive endpoint decapsulates the MPLS packet by removing the IP 173 header and the GRE header. The packet is then processed as a 174 received MPLS packet whose "incoming label" [RFC3031] is the topmost 175 label of the decapsulated packet. 177 [RFC2784] specifies an optional GRE checksum, and [RFC2890] specifies 178 optional GRE key, and sequence number fields. These optional fields 179 are not very useful for the MPLS-in-GRE encapsulation. The sequence 180 number and checksum fields are not needed, as there are no 181 corresponding fields in the native MPLS packets that are being 182 tunneled. The GRE key field is not needed for demultiplexing, as the 183 top MPLS label of the encapsulated packet is used for that purpose. 184 The GRE key field is sometimes considered to be a security feature, 185 functioning as a 32-bit cleartext password, but this is an extremely 186 weak form of security. In order to (a) facilitate high speed 187 implementations of the encapsulation/decapsulation procedures, and 188 (b) ensure interoperability, we require that all implementations be 189 able to operate correctly without these optional fields. 191 More precisely, an implementation of an MPLS-in-GRE decapsulator MUST 192 be able to correctly process packets without these optional fields. 193 It MAY be able to correctly process packets with these optional 194 fields. 196 An implementation of an MPLS-in-GRE encapsulator MUST be able to 197 generate packets without these optional fields. It MAY have the 198 capability to generate packets with these fields, but the default 199 state MUST be that packets are generated without these fields. The 200 encapsulator MUST NOT include any of these optional fields unless it 201 is known that the decapsulator can process them correctly. Methods 202 for conveying this knowledge are outside the scope of this 203 specification. 205 5. Common Procedures 207 Certain procedures are common to both the MPLS-in-IP and the MPLS- 208 in-GRE encapsulations. In the following, the encapsulator, whose 209 address appears in the IP source address field of the encapsulating 210 IP header, is known as the "tunnel head". The decapsulator, whose 211 address appears in the IP destination address field of the 212 decapsulating IP header, is known as the "tunnel tail". 214 In the case where IPv6 is being used (for either MPLS-in-IPv6 or 215 MPLS-in-GRE-in-IPv6), the procedures of [RFC2473] are generally 216 applicable. 218 5.1. Preventing Fragmentation and Reassembly 220 If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to 221 "ordinary" IP fragmentation), it would have to be be reassembled by 222 the tunnel tail before the contained MPLS packet could be 223 decapsulated. When the tunnel tail is a router, this is likely to be 224 undesirable; the tunnel tail may not have the ability or the 225 resources to perform reassembly at the necessary level of 226 performance. 228 Whether fragmentation of the tunneled packets is allowed MUST be 229 configurable at the tunnel head. The default value MUST be that 230 packets are not to be fragmented. The default value would only be 231 changed if it were known that the tunnel tail could perform the 232 reassembly function adequately. 234 THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY 235 IN THE CASE WHERE PACKETS ARE NOT TO BE FRAGMENTED. 237 Obviously, if packets are not to be fragmented, the tunnel head MUST 238 NOT fragment a packet before encapsulating it. 240 If IPv4 is being used, then the tunnel MUST set the DF bit. This 241 prevents intermediate nodes in the tunnel from performing 242 fragmentation. (If IPv6 is being used, intermediate nodes do not 243 perform fragmentation in any event.) 245 The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for 246 IPv4, or [RFC1981] for IPv6). 248 The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is 249 the minimum of (a) an administratively configured value, and, if 250 known, (b) the discovered Path MTU value minus the encapsulation 251 overhead. 253 If the tunnel head receives, for encapsulation, an MPLS packet whose 254 size exceeds the Tunnel MTU, that packet MUST be discarded. However, 255 silently dropping such packets may cause significant operational 256 problems; the originator of the packets will notice that his data is 257 not getting through, but he may not realize that it is large packets 258 that are the cause of packet loss. He may therefore continue sending 259 packets that are discarded. Path MTU discovery can help (if the 260 tunnel head sends back ICMP errors), but frequently there is 261 insufficient information available at the tunnel head to properly 262 identify the originating sender. To minimize problems, it is advised 263 that MTUs be engineered to be large enough in practice to avoid 264 fragmentation. 266 In some cases, the tunnel head receives, for encapsulation, an IP 267 packet, which it first encapsulates in MPLS and then encapsulates in 268 MPLS-in-IP or MPLS-in-GRE. If the source of the IP packet is 269 reachable from the tunnel head, and if the result of encapsulating 270 the packet in MPLS would be a packet whose size exceeds the Tunnel 271 MTU, then the value which the tunnel head SHOULD use for the purposes 272 of fragmentation and PMTU discovery outside the tunnel is the Tunnel 273 MTU value minus the size of the MPLS encapsulation. (That is, the 274 Tunnel MTU value minus the size of the MPLS encapsulation is the MTU 275 that needs to get reported in ICMP messages.) The packet will have 276 to be discarded but the tunnel head should send the IP source of the 277 discarded packet the proper ICMP error message as specified in 278 [RFC1191] or [RFC1981]. 280 5.2. TTL or Hop Limit 282 The tunnel head MAY place the TTL from the MPLS label stack into the 283 TTL field of the encapsulating IPv4 header or the Hop Limit field of 284 the encapsulating IPv6 header. The tunnel tail MAY place the TTL 285 from the encapsulating IPv4 header or the Hop Limit form the 286 encapsulating IPv6 header into the TTL field of the MPLS header, but 287 only if that does not cause the TTL value in the MPLS header to 288 become larger. 290 Whether such modifications are made, and the details of how they are 291 made, will depend on the configuration of the tunnel tail and the 292 tunnel head. 294 5.3. Differentiated Services 296 The procedures specified in this document enable an LSP to be sent 297 through an IP or GRE tunnel. [RFC2983] details a number of 298 considerations and procedures which need to be applied to properly 299 support the Differentiated Services Architecture in the presence of 300 IP-in-IP tunnels. These considerations and procedures also apply in 301 the presence of MPLS-in-IP or MPLS-in-GRE tunnels. 303 Accordingly, when a tunnel head is about to send an MPLS packet into 304 an MPLS-in-IP or MPLS-in-GRE tunnel, the setting of the DS field of 305 the encapsulating IPv4 or IPv6 header MAY be determined (at least 306 partially) by the "Behavior Aggregate" of the MPLS packet. Procedures 307 for determining the Behavior Aggregate of an MPLS packet are 308 specified in [RFC3270]. 310 Similarly, at the tunnel tail, the DS field of the encapsulating IPv4 311 or IPv6 header MAY be used to determine the Behavior Aggregate of the 312 encapsulated MPLS packet. [RFC3270] specifies the relation between 313 the Behavior Aggregate and the subsequent disposition of the packet. 315 6. Applicability 317 The MPLS-in-IP encapsulation is the more efficient, and would 318 generally be regarded as preferable, other things being equal. There 319 are however some situations in which the MPLS-in-GRE encapsulation 320 may be used: 322 - Two routers are "adjacent" over a GRE tunnel that exists for some 323 reason that is outside the scope of this document, and those two 324 routers need to send MPLS packets over that adjacency. As all 325 packets sent over this adjacency must have a GRE encapsulation, 326 the MPLS-in-GRE encapsulation is more efficient than the 327 alternative, which would be an MPLS-in-IP encapsulation which is 328 then encapsulated in GRE. 330 - Implementation considerations may dictate the use of MPLS-in-GRE. 331 For example, some hardware device might only be able to handle 332 GRE encapsulations in its fastpath. 334 7. IANA Considerations 336 The MPLS-in-IP encapsulation requires that IANA allocate an IP 337 Protocol Number, as described in section 3. No future IANA actions 338 will be required. The MPLS-in-GRE encapsulation does not require any 339 IANA action. 341 8. Security Considerations 343 The main security problem faced when using IP or GRE tunnels is the 344 possibility that the tunnel's receive endpoint will get a packet 345 which appears to be from the tunnel, but which was not actually put 346 into the tunnel by the tunnel's transmit endpoint. (I.e., the 347 specified encapsulations do not by themselves enable the decapsulator 348 to authenticate the encapsulator.) A second problem is the 349 possibility that the packet will be altered between the time it 350 enters the tunnel and the time it leaves the tunnel. (I.e., the 351 specified encapsulations do not by themselves assure the decapsulator 352 of the packet's integrity.) A third problem is the possibility that 353 the packet's contents will be seen while the packet is in transit 354 through the tunnel. (I.e., the specification encapsulations do not 355 ensure privacy.) How significant these issues are in practice depends 356 on the security requirements of the applications whose traffic is 357 being sent through the tunnel. E.g., lack of privacy for tunneled 358 packets is not a significant issue if the applications generating the 359 packets do not require privacy. 361 Because of the different potential security requirements, deployment 362 scenarios, and performance considerations of different applications 363 using the described encapsulation mechanism, this specification 364 defines IPsec support as OPTIONAL. Basic implementation requirements 365 if IPsec is implemented are described in section 8.1. If IPsec is not 366 implemented, additional mechanisms may need to be implemented and 367 deployed. Those are discussed in section 8.2. 369 8.1. Securing the Tunnel Using IPsec 371 All of these security issues can be avoided if the MPLS-in-IP or 372 MPLS-in-GRE tunnels are secured using IPsec. Implementation 373 requirements defined in this section apply if IPsec is implemented. 375 When using IPsec, the tunnel head and the tunnel tail should be 376 treated as the endpoints of a Security Association. For this 377 purpose, a single IP address of the tunnel head will be used as the 378 source IP address, and a single IP address of the tunnel tail will be 379 used as the destination IP address. The means by which each node 380 knows the proper address of the other is outside the scope of this 381 document. If a control protocol is used to set up the tunnels (e.g., 382 to inform one tunnel endpoint of the IP address of the other), the 383 control protocol MUST have an authentication mechanism, and this MUST 384 be used when setting up the tunnel. If the tunnel is set up 385 automatically as the result, e.g., of information distributed by BGP, 386 then the use of BGP's MD5-based authentication mechanism is 387 satisfactory. 389 The MPLS-in-IP or MPLS-in-GRE encapsulated packets should be 390 considered as originating at the tunnel head and as being destined 391 for the tunnel tail; IPsec transport mode SHOULD thus be used. 393 The IP header of the MPLS-in-IP packet becomes the outer IP header of 394 the resulting packet when IPsec transport mode is used by the tunnel 395 head to secure the MPLS-in-IP packet. This is followed by an IPsec 396 header followed by the MPLS label stack. The IPsec header needs to 397 set the payload type to MPLS by using the IP protocol number 398 specified in section 3. If IPsec transport mode is applied on a 399 MPLS-in-GRE packet, the GRE header follows the IPsec header. 401 At the tunnel tail, IPsec outbound processing recovers the contained 402 MPLS-in-IP/GRE packet. The tunnel tail then strips off the 403 encapsulating IP/GRE header to recover the MPLS packet, which is then 404 forwarded according to its label stack. 406 Recall that the tunnel tail and the tunnel head are LSP adjacencies, 407 which means that the topmost label of any packet sent through the 408 tunnel must be one which was distributed by the tunnel tail to the 409 tunnel head. The tunnel tail MUST know precisely which labels it has 410 distributed to the tunnel heads of IPsec-secured tunnels. Labels in 411 this set MUST NOT be distributed by the tunnel tail to any LSP 412 adjacencies other than those which are tunnel heads of IPsec-secured 413 tunnels. If an MPLS packet is received without an IPsec 414 encapsulation, and if its topmost label is in this set, then the 415 packet MUST be discarded. 417 An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide 418 authentication and integrity. (Note that the authentication and 419 integrity will apply to the entire MPLS packet, including the MPLS 420 label stack.) Thus, the implementation MUST support ESP will null 421 encryption. ESP with encryption MAY be supported if a source 422 requires confidentiality. If ESP is used, the tunnel tail MUST check 423 that the source IP address of any packet that is received on a given 424 SA is the one that is expected. 426 Key distribution may be done either manually, or automatically by 427 means of IKE [RFC2409]. Manual keying MUST be supported. If 428 automatic keying is implemented, IKE in main mode with preshared keys 429 MUST be supported. A particular application may escalate this 430 requirement and request implementation of automatic keying. 432 Manual key distribution is much simpler, but also less scalable, than 433 automatic key distribution. Which method of key distribution is 434 appropriate for a particular tunnel thus needs to be carefully 435 considered by the administrator (or pair of administrators) 436 responsible for the tunnel endpoints. If replay protection is 437 regarded as necessary for a particular tunnel, automatic key 438 distribution should be configured. 440 If the MPLS-in-IP encapsulation is being used, the selectors 441 associated with the SA would be the source and destination addresses 442 mentioned above, plus the IP protocol number specified in section 3. 443 If it is desired to separately secure multiple MPLS-in-IP tunnels 444 between a given pair of nodes, each tunnel must have unique pair of 445 IP addresses. 447 If the MPLS-in-GRE encapsulation is being used, the selectors 448 associated with the SA would be the the source and destination 449 addresses mentioned above, and the IP protocol number representing 450 GRE (47). If it is desired to separately secure multiple MPLS-in-GRE 451 tunnels between a given pair of nodes, each tunnel must have unique 452 pair of IP addresses. 454 8.2. In the Absence of IPsec 456 If the tunnels are not secured using IPsec, then some other method 457 should be used to ensure that packets are decapsulated and forwarded 458 by the tunnel tail only if those packets were encapsulated by the 459 tunnel head. If the tunnel lies entirely within a single 460 administrative domain, address filtering at the boundaries can be 461 used to ensure that no packet with the IP source address of a tunnel 462 endpoint or with the IP destination address of a tunnel endpoint can 463 enter the domain from outside. 465 However, when the tunnel head and the tunnel tail are not in the same 466 administrative domain, this may become difficult, and filtering based 467 on the destination address can even become impossible if the packets 468 must traverse the public Internet. 470 Sometimes only source address filtering (but not destination address 471 filtering) is done at the boundaries of an administrative domain. If 472 this is the case, the filtering does not provide effective protection 473 at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE 474 validates the IP source address of the packet. This document does not 475 require that the decapsulator validate the IP source address of the 476 tunneled packets, but it should be understood that failure to do so 477 presupposes that there is effective destination-based (or combination 478 of source-based and destination-based) filtering at the boundaries. 480 9. Acknowledgments 482 This specification combines prior work on encapsulating MPLS in IP, 483 by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew 484 G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in 485 GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current 486 authors wish to thank all these authors for their contribution. 488 Many people have made valuable comments and corrections, including 489 Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le 490 Feucheur, Allison Mankin, Thomas Narten, Pekka Savola, and Alex 491 Zinin. 493 10. Normative References 495 [RFC791] "Internet Protocol," J. Postel, Sep 1981 497 [RFC792] "Internet Control Message Protocol", J. Postel, Sept 1981 499 [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November 500 1990 502 [RFC1981] "Path MTU Discovery for IP version 6", J. McCann, S. 503 Deering, J. Mogul, August 1996 505 [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S. 506 Deering and R. Hinden, RFC 2460,Dec 1998 508 [RFC2463] "Internet Control Message Protocol (ICMPv6) for the 509 Internet Protocol Version 6 (IPv6) Specification", A. Conta, S. 510 Deering, December 1998 512 [RFC2473] "Generic Packet Tunneling in IPv6 Specification", A. Conta, 513 S. Deering, December 1998 515 [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, 516 S. Hanks, D. Meyer, P. Traina, March 2000 518 [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. 520 Viswanathan, R. Callon, January 2001 522 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. 523 Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001 525 11. Informative References 527 [RFC2401] "Security Architecture for the Internet Protocol", S. Kent, 528 R. Atkinson, November 1998 530 [RFC2402] "IP Authentication Header", S. Kent, R. Atkinson, November 531 1998 533 [RFC2406] "IP Encapsulating Security Payload (ESP)", S. Kent 534 R.Atkinson, November 1998 536 [RFC2409] "The Internet Key Exchange (IKE)", D. Harkins, D. Carrel, 537 November 1998 539 [RFC2475] "An Architecture for Differentiated Service", S. Blake, D. 540 Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998 542 [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, 543 August 2000 545 [RFC2983] "Differentiated Services and Tunnels", D. Black. October 546 2000 548 [RFC3260] "New Terminology and Clarifications for Diffserv", D. 549 Grossman, April 2002 551 [RFC3270] "Multiprotocol Label Switching (MPLS) Support of 552 Differentiated Services", F. Le Faucheur, L. Wu, B. Davie, S. Davari, 553 P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. May 2002 555 12. Author Information 557 Tom Worster 558 Email: fsb@thefsb.org 559 Yakov Rekhter 560 Juniper Networks, Inc. 561 1194 N. Mathilda Ave. 562 Sunnyvale, CA 94089 563 Email: yakov@juniper.net 565 Eric Rosen 566 Cisco Systems, Inc. 567 1414 Massachusetts Avenue 568 Boxborough, MA 01719 569 Email: erosen@cisco.com 571 13. Intellectual Property Notice 573 The IETF takes no position regarding the validity or scope of any 574 intellectual property or other rights that might be claimed to 575 pertain to the implementation or use of the technology described in 576 this document or the extent to which any license under such rights 577 might or might not be available; neither does it represent that it 578 has made any effort to identify any such rights. Information on the 579 IETF's procedures with respect to rights in standards-track and 580 standards-related documentation can be found in BCP-11. Copies of 581 claims of rights made available for publication and any assurances of 582 licenses to be made available, or the result of an attempt made to 583 obtain a general license or permission for the use of such 584 proprietary rights by implementors or users of this specification can 585 be obtained from the IETF Secretariat. 587 The IETF invites any interested party to bring to its attention any 588 copyrights, patents or patent applications, or other proprietary 589 rights which may cover technology that may be required to practice 590 this standard. Please address the information to the IETF Executive 591 Director. 593 14. Copyright Notice 595 "Copyright (C) The Internet Society (2004). All Rights Reserved. 597 This document and translations of it may be copied and furnished to 598 others, and derivative works that comment on or otherwise explain it 599 or assist in its implementation may be prepared, copied, published 600 and distributed, in whole or in part, without restriction of any 601 kind, provided that the above copyright notice and this paragraph are 602 included on all such copies and derivative works. However, this 603 document itself may not be modified in any way, such as by removing 604 the copyright notice or references to the Internet Society or other 605 Internet organizations, except as needed for the purpose of 606 developing Internet standards in which case the procedures for 607 copyrights defined in the Internet Standards process must be 608 followed, or as required to translate it into languages other than 609 English. 611 The limited permissions granted above are perpetual and will not be 612 revoked by the Internet Society or its successors or assigns. 614 This document and the information contained herein is provided on an 615 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 616 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 617 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 618 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 619 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."