idnits 2.17.1 draft-ietf-softwire-encaps-safi-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 577. 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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 42 has weird spacing: '...reement betwe...' == Line 100 has weird spacing: '...through a tun...' == Line 128 has weird spacing: '...ulation attri...' == Line 135 has weird spacing: '...uld ask wheth...' == Line 136 has weird spacing: '... simply attac...' == (5 more instances...) -- 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 1, 2008) is 5808 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-04 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pradosh Mohapatra 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: December 2008 5 Eric Rosen 6 Cisco Systems, Inc. 8 June 1, 2008 10 BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute 12 draft-ietf-softwire-encaps-safi-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 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 In certain situations, transporting a packet from one BGP speaker to 40 another, the BGP next hop, requires that the packet be encapsulated 41 by the first BGP speaker and decapsulated by the second. To support 42 these situations, there needs to be some agreement between the two 43 BGP speakers with regard to the "encapsulation information", i.e., 44 the format of the encapsulation header as well as the contents of 45 various fields of the header. 47 The encapsulation information need not be signaled for all 48 encapsulation types. In the cases where the signaling is required 49 (such as L2TPv3, GRE with key), This draft specifies a method by 50 which BGP speakers can signal encapsulation information to each 51 other. The signaling is done by sending BGP updates using the 52 "Encapsulation SAFI" and IPv4 or IPv6 AFI. In the cases where no 53 encapsulation information needs to be signaled (such as GRE without 54 key), this draft specifies a BGP extended community that can be 55 attached to UPDATE messages that carry payload prefixes to indicate 56 the encapsulation protocol type to be used. 58 Table of Contents 60 1 Specification of requirements ...................... 2 61 2 Introduction ....................................... 3 62 3 Encapsulation NLRI Format .......................... 4 63 4 Tunnel Encapsulation Attribute ..................... 5 64 4.1 Encapsulation sub-TLV .............................. 7 65 4.2 Protocol Type sub-TLV .............................. 8 66 4.3 Color sub-TLV ...................................... 9 67 4.3.1 Color Extended Community ........................... 9 68 4.4 Tunnel Type Selection .............................. 9 69 4.5 BGP Encapsulation Extended Community ............... 10 70 5 Capability advertisement ........................... 11 71 6 Security Considerations ............................ 11 72 7 IANA Considerations ................................ 11 73 8 Acknowledgements ................................... 12 74 9 Normative References ............................... 12 75 10 Authors' Addresses ................................. 13 76 11 Full Copyright Statement ........................... 13 77 12 Intellectual Property .............................. 13 79 1. Specification of requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Introduction 87 Consider the case of a router R1 forwarding an IP packet P. Let D be 88 P's IP destination address. R1 must look up D in its forwarding 89 table. Suppose that the "best match" route for D is route Q, where Q 90 is a BGP-distributed route whose "BGP next hop" is router R2. And 91 suppose further that the routers along the path from R1 to R2 have 92 entries for R2 in their forwarding tables, but do NOT have entries 93 for D in their forwarding tables. For example, the path from R1 to R2 94 may be part of a "BGP-free core", where there are no BGP-distributed 95 routes at all in the core. Or, as in [Softwires-Mesh-Frame-work], D 96 may be an IPv4 address while the intermediate routers along the path 97 from R1 to R2 may support only IPv6. 99 In cases such as this, in order for R1 to properly forward packet P, 100 it must encapsulate P, and send P "through a tunnel" to R2. For 101 example, R1 may encapsulate P using GRE, L2TPv3, IP-in-IP, etc., 102 where the destination IP address of the encapsulation header is the 103 address of R2. 105 In order for R1 to encapsulate P for transport to R2, R1 must know 106 what encapsulation protocol to use for transporting what sorts of 107 packets to R2. R1 must also know how to fill in the various fields of 108 the encapsulation header. With certain encapsulation types, this 109 knowledge may be acquired by default or through manual configuration. 110 Other encapsulation protocols have fields such as session id, key, or 111 cookie which must be filled in. It would not be desirable to require 112 every BGP speaker to be manually configured with the encapsulation 113 information for every one of its BGP next hops. 115 In this draft, we specify a way in which BGP itself can be used by a 116 given BGP speaker to tell other BGP speakers, "if you need to 117 encapsulate packets to be sent to me, here's the information you need 118 to properly form the encapsulation header". A BGP speaker signals 119 this information to other BGP speakers by using a distinguished SAFI 120 value, the Encapsulation SAFI. The encapsulation SAFI can be used 121 with the AFI for IPv4 or with the AFI for IPv6. The IPv4 AFI is used 122 when the encapsulated packets are to be sent using IPv4; the IPv6 AFI 123 is used when the encapsulated packets are to be sent using IPv6. 125 In a given BGP update, the NLRI of the encapsulation SAFI consists of 126 the IP address (in the family specified by the AFI) of the originator 127 of that update. The encapsulation information is specified in one or 128 more BGP "tunnel encapsulation attributes" (specified herein). These 129 attributes specify the encapsulation protocols that may be used, as 130 well as specifying whatever additional information (if any) is needed 131 in order to properly use those protocols. Other attributes, e.g., 132 communities or extended communities, may also be included. 134 Since the encapsulation information is coded as a set of attributes, 135 one could ask whether a new SAFI is really required. After all, a 136 BGP speaker could simply attach the tunnel encapsulation attributes 137 to each prefix (like Q in our example) that it advertises. But with 138 that technique, any change in the encapsulation information would 139 cause a very large number of updates. Unless one really wants to 140 specify different encapsulation information for each prefix, it is 141 much better to have a mechanism in which a change in the 142 encapsulation information causes a BGP speaker to advertise only a 143 single update. Conversely, when prefixes get modified, the tunnel 144 encapsulation information need not be exchanged. 146 In this specification, a single SAFI is used to carry information for 147 all encapsulation protocols. One could have taken an alternative 148 approach of defining a new SAFI for each encapsulation protocol. 149 However, with the specified approach, encapsulation information can 150 pass transparently and automatically through intermediate BGP 151 speakers (e.g., route reflectors) that do not necessarily understand 152 the encapsulation information. This works because the encapsulation 153 attribute is defined as an optional transitive attribute. New 154 encapsulations can thus be added without the need to reconfigure any 155 intermediate BGP system. If adding a new encapsulation required using 156 a new SAFI, the information for that encapsulation would not pass 157 through intermediate BGP systems unless those systems were 158 reconfigured to support the new SAFI. 160 For encapsulation protocols where no encapsulation information needs 161 to be signaled (such as GRE without key), the egress router MAY still 162 want to specify the protocol to use for transporting packets from the 163 ingress router. This draft specifies a new BGP extended community 164 that can be attached to UPDATE messages that carry payload prefixes 165 for this purpose. 167 3. Encapsulation NLRI Format 169 The NLRI, defined below, is carried in BGP UPDATE messages [RFC4271] 170 using BGP multiprotocol extensions [RFC4760] with an AFI of 1 or 2 171 (IPv4 or IPv6) [IANA-AF] and a SAFI value to be assigned by IANA 172 (called as Encapsulation SAFI). 174 The NLRI is encoded in a format as defined in section 5 of [RFC4760] 175 (a 2-tuple of the form ). The value field is 176 structured as follows: 178 +-----------------------------------------------+ 179 | Endpoint address (Variable) | 180 +-----------------------------------------------+ 182 - Endpoint Address: This field identifies the BGP speaker 183 originating the update. It is typically one of the interface 184 addresses configured at the router. The length of the endpoint 185 address is dependent on the AFI being advertised. If the AFI is 186 set to IPv4 (1), the the endpoint address is a 4-octet IPv4 187 address whereas if the AFI is set to IPv6 (2), the endpoint 188 address is a 16-octet IPv6 address. 190 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 191 with Encapsulation SAFI MUST also carry the BGP mandatory attributes: 192 ORIGIN, AS_PATH, and LOCAL_PREF (for IBGP neighbors) as defined in 193 [RFC4271]. In addition, such an update message can also contain any 194 of the BGP optional attributes, like Community or Extended Community 195 attribute to influence an action on the receiving speaker. 197 When a BGP speaker advertises the Encapsulation NLRI via BGP, it uses 198 its own address as the BGP nexthop in the MP_REACH_NLRI or 199 MP_UNREACH_NLRI attribute. The nexthop address is set based on the 200 AFI in the attribute. For example, if the AFI is set to IPv4 (1), 201 the nexthop is encoded as a 4-byte IPv4 address. If the AFI is set to 202 IPv6 (2), the nexthop is encoded as a 16-byte IPv6 address of the 203 router. On the receiving router, the BGP nexthop of such an update 204 message is validated by performing a recursive route lookup operation 205 in the routing table. 207 Bestpath selection of Encapsulation NLRIs is governed by the decision 208 process outlined in section 9.1 of [RFC4271]. The encapsulation data 209 carried through other attributes in the message are to be used by the 210 receiving router only if the NLRI has a bestpath. 212 4. Tunnel Encapsulation Attribute 214 Tunnel Encapsulation attribute is an optional transitive attribute 215 that is composed of a set of TLVs. The type code of the attribute is 216 to be assigned by IANA. Each TLV contains information corresponding 217 to a particular tunnel technology. The TLV is structured as follows: 219 0 1 2 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Tunnel Type (2 Octets) | Length (2 Octets) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 225 | Value | 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Tunnel Type (2 octets): It identifies the type of the tunneling 230 technology being signaled. This document defines the following types: 232 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 234 - GRE [RFC2784]: Tunnel Type = 2 236 Unknown types are to be ignored and skipped upon receipt. 238 Length (2 octets): the total number of octets of the Value field. 240 Value (variable): The value is comprised of multiple sub-TLV's. Each 241 sub-TLV consists of three fields: a one-octet type, one-octet length, 242 and zero or more octets of value. The sub-TLV is structured as 243 follows: 245 +-----------------------------------+ 246 | Sub-TLV Type (1 Octet) | 247 +-----------------------------------+ 248 | Sub-TLV Length (1 Octet) | 249 +-----------------------------------+ 250 | Sub-TLV Value (Variable) | 251 | | 252 +-----------------------------------+ 254 Sub-TLV Type (1 octet): Each sub-TLV type defines a certain property 255 about the tunnel TLV that contains this sub-TLV. The following are 256 the types defined in this document: 258 - Encapsulation: sub-TLV type = 1 260 - Protocol type: sub-TLV type = 2 262 - Color: sub-TLV type = 3 264 When the TLV is being processed by a BGP speaker that will be 265 performing encapsulation, any unknown sub-TLVs MUST be ignored and 266 skipped. However if the TLV is understood, the entire TLV MUST NOT be 267 ignored just because it contains an unknown sub-TLV. 269 Sub-TLV Length (1 octet): the total number of octets of the sub-TLV 270 value field. 272 Sub-TLV Value (variable): Encodings of the value field depend on the 273 sub-TLV type as enumerated above. The following sub-sections define 274 the encoding in detail. 276 4.1. Encapsulation sub-TLV 278 The syntax and semantics of the encapsulation sub-TLV is determined 279 by the tunnel type of the TLV that contains this sub-TLV. 281 When the tunnel type of the TLV is L2TPv3-over-IP, the following is 282 the structure of the value field of the encapsulation sub-TLV: 284 0 1 2 3 285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Session ID (4 octets) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 | Cookie (Variable) | 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 * Session ID: a non-zero 4-octet value locally assigned by the 295 advertising router that serves as a lookup key in the incoming 296 packet's context. 298 * Cookie: an optional, variable length (encoded in octets - 0 to 8 299 octets) value used by L2TPv3 to check the association of a 300 received data message with the session identified by the Session 301 ID. Generation and usage of the cookie value is as specified in 302 [RFC3931]. 304 The length of the cookie is not encoded explicitly, but can be 305 calculated as: (sub-TLV length - 4). 307 When the tunnel type of the TLV is GRE, the following is the 308 structure of the value field of the encapsulation sub-TLV: 310 0 1 2 3 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | GRE Key (4 octets) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 * GRE Key: A 4 octet field [RFC2890] that is generated by the 317 advertising router. The actual method by which the key is 318 obtained is beyond the scope of the document. The key is inserted 319 into the GRE encapsulation header of the payload packets sent by 320 ingress routers to the advertising router. It is intended to be 321 used for identifying extra context information about the received 322 payload. 324 Note that the key is optional. Unless a key value is being 325 advertised, the GRE encapsulation sub-TLV MUST NOT be present. 327 4.2. Protocol Type sub-TLV 329 The protocol type sub-TLV MAY be encoded to indicate the type of the 330 payload packets that will be encapsulated with the tunnel parameters 331 being signaled in the TLV. The value field of the sub-TLV contains a 332 2-octet protocol type that is one of the types defined in [IANA-AF] 333 as ETHER TYPEs. 335 For example, if we want to use three L2TPv3 sessions, one carrying 336 IPv4 packets, one carrying IPv6 packets, and one carrying MPLS 337 packets, the egress router will include three TLVs of L2TPv3 338 encapsulation type, each specifying a different session id and a 339 different payload type. The protocol type sub-TLV for these will be 340 IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and 341 MPLS (protocol type = 0x8847) respectively. This informs the ingress 342 routers of the appropriate encapsulation information to use with each 343 of the given protocol types. Insertion of the specified session id at 344 the ingress routers allows the egress to process the incoming packets 345 correctly, according to their protocol type. 347 Inclusion of this sub-TLV depends on the tunnel type. It MUST be 348 encoded for L2TPv3 tunnel type. On the other hand, the protocol type 349 sub-TLV is not required for GRE tunnels. 351 4.3. Color sub-TLV 353 The color sub-TLV MAY be encoded as a way to color the corresponding 354 tunnel TLV. The value field of the sub-TLV contains an extended 355 community that is defined as follows: 357 4.3.1. Color Extended Community 359 The color extended community is an opaque extended community 360 [RFC4360] with the following encoding: 362 0 1 2 3 363 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | 0x03 | TBD | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Color Value | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 The value of the high-order octet of the extended Type Field is 0x03, 371 which indicates it is transitive. The value of the low-order octet of 372 the extended type field for this community is TBD. The Color value is 373 user defined and configured locally on the routers. The same color 374 extended community can then be attached to the UPDATE messages that 375 contain payload prefixes. This way, the BGP speaker can express the 376 fact that it expects the packets corresponding to these payload 377 prefixes to be received with a particular tunnel encapsulation 378 header. 380 4.4. Tunnel Type Selection 382 A BGP speaker may include multiple tunnel TLVs in the tunnel 383 attribute. The receiving speaker MAY have local policies defined to 384 choose different tunnel types for different sets/types of payload 385 prefixes received from the same BGP speaker. For instance, if a BGP 386 speaker includes both L2TPv3 and GRE tunnel types in the tunnel 387 attribute and it also advertises IPv4 and IPv6 prefixes, the ingress 388 router may have local policy defined to choose L2TPv3 for IPv4 389 prefixes (provided the protocol type received in the tunnel attribute 390 matches) and GRE for IPv6 prefixes. 392 Additionally, the Encapsulation SAFI UPDATE message can contain a 393 color sub-TLV for some or all of the tunnel TLVs. The BGP speaker 394 SHOULD then attach a color extended community to payload prefixes to 395 select the appropriate tunnel types. 397 In a multi-vendor deployment that has routers supporting different 398 tunneling technologies, including color sub-TLV to the Encapsulation 399 SAFI UPDATE message can serve as a classification mechanism (for 400 example, set A of routers for GRE and set B of routers for L2TPv3). 401 The ingress router can then choose the encapsulation data 402 appropriately while sending packets to an egress router. 404 If a BGP speaker originates an update for prefix P with color C and 405 with itself as the next hop, then it MUST also originate an encaps- 406 SAFI update which contains the color C. 408 Suppose that a BGP speaker receives an update for prefix P with color 409 C, that the BGP decision procedure has selected the route in that 410 update as the best route to P, that the next hop is node N, but that 411 an encapsulation SAFI update originating from node N containing color 412 C has not been received. In this case, no route to P will be 413 installed in the forwarding table unless and until the corresponding 414 encapsulation SAFI update is received, or the BGP decision process 415 selects a different route. 417 Suppose that a BGP speaker receives an "uncolored" update for prefix 418 P, with next hop N, and that the BGP speaker has also received an 419 encapsulation SAFI originated by N, specifying one or more 420 encapsulations that may or may not be colored. In this case, the 421 choice of encapsulation is a matter of local policy. The only 422 "default policy" necessary is to choose one of the encapsulations 423 supported by the speaker. 425 4.5. BGP Encapsulation Extended Community 427 We define a BGP opaque extended community that can be attached to BGP 428 UPDATE messages to indicate the encapsulation protocol to be used for 429 sending packets from an ingress router to an egress router. 430 Considering our example from the "Introduction" section, R2 MAY 431 include this extended community specifying a particular tunnel type 432 to be used in the UPDATE message that carries route Q to R1. This is 433 useful if there are no explicit encapsulation information to be 434 signaled using the encap SAFI for a tunneling protocol (such as GRE 435 without key). 437 0 1 2 3 438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | 0x03 | TBD | Reserved | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Reserved | Tunnel Type | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 The value of the high-order octet of the extended type field is 0x03, 446 which indicates it's transitive. The value of the low-order octet of 447 the extended type field is TBD. 449 The last two octets of the value field encode a tunnel type as 450 defined in this document. 452 5. Capability advertisement 454 A BGP speaker that wishes to exchange tunnel endpoint information 455 must use the Multiprotocol Extensions Capability Code as defined in 456 [RFC4760], to advertise the corresponding (AFI, SAFI) pair. 458 6. Security Considerations 460 Security considerations applicable to Softwires can be found in the 461 mesh framework [Softwires-Mesh-Frame-work]. In general, security 462 issues of the tunnel protocols signalled through encapsulation SAFI 463 are inherited. 465 If a third party is able to modify any of the information that is 466 used to form encapsulation headers, or to choose a tunnel type, or to 467 choose a particular tunnel for a particular payload type, user data 468 packets may end up getting misrouted, misdelivered, and/or dropped. 470 7. IANA Considerations 472 This document defines a new NLRI format, called Encapsulation NLRI, 473 to be carried in BGP using multiprotocol extensions. It is to be 474 assigned its own SAFI. 476 This document defines a new BGP optional transitive attribute type, 477 called Tunnel Encapsulation attribute and two new opaque extended 478 community sub-types. These values are to be assigned by IANA. 480 This document introduces Tunnel TLVs and sub-TLVs. The type space for 481 both of these should be set up by IANA as a registry of 2-octet 482 tunnel types and 1-octet sub-TLV types. These should be assigned on a 483 first-come- first-serve basis. 485 8. Acknowledgements 487 This specification builds on prior work by Gargi Nalawade, Ruchi 488 Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, and 489 Chris Metz. The current authors wish to thank all these authors for 490 their contribution. 492 The authors would like to thank John Scudder, Robert Raszuk, Keyur 493 Patel, Chris Metz, Yakov Rekhter, and Carlos Pignataro for their 494 valuable comments and suggestions. 496 9. Normative References 498 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 499 Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006. 501 [RFC4760] Bates et al, "Multiprotocol Extensions for BGP-4," RFC 502 4760, January 2007. 504 [RFC4360] Sangli, S., Tappan D., and Rekhter Y., "BGP Extended 505 Communities Attribute," RFC 4360, February 2006. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels," March 1997. 510 [RFC3931] Lau, J., Townsley, M., and Goyret, I., "Layer Two Tunneling 511 Protocol - Version 3 (L2TPv3)," RFC 3931, March 2005. 513 [RFC2784] Farinacci et al, "Generic Routing Encapsulation (GRE)," RFC 514 2784, March 2000. 516 [RFC2890] Dommety, G. "Key and Sequence Number Extensions to GRE," 517 RFC 2890, September 2000. 519 [IANA-AF] "Address Family Numbers," Reachable from 520 http://www.iana.org/numbers.html. 522 [Softwires-Mesh-Frame-work] Wu, J. et al, "Softwire Mesh Framework," 523 draft-ietf-softwire-mesh-framework-04.txt, March 2008. 525 10. Authors' Addresses 527 Pradosh Mohapatra 528 Cisco Systems, Inc. 529 170 Tasman Drive 530 San Jose, CA, 95134 531 Email: pmohapat@cisco.com 533 Eric Rosen 534 Cisco Systems, Inc. 535 1414 Massachusetts Avenue 536 Boxborough, MA, 01719 537 E-mail: erosen@cisco.com 539 11. Full Copyright Statement 541 Copyright (C) The IETF Trust (2008). 543 This document is subject to the rights, licenses and restrictions 544 contained in BCP 78, and except as set forth therein, the authors 545 retain all their rights. 547 This document and the information contained herein are provided on an 548 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 549 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 550 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 551 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 552 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 553 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 12. Intellectual Property 557 The IETF takes no position regarding the validity or scope of any 558 Intellectual Property Rights or other rights that might be claimed to 559 pertain to the implementation or use of the technology described in 560 this document or the extent to which any license under such rights 561 might or might not be available; nor does it represent that it has 562 made any independent effort to identify any such rights. Information 563 on the procedures with respect to rights in RFC documents can be 564 found in BCP 78 and BCP 79. 566 Copies of IPR disclosures made to the IETF Secretariat and any 567 assurances of licenses to be made available, or the result of an 568 attempt made to obtain a general license or permission for the use of 569 such proprietary rights by implementers or users of this 570 specification can be obtained from the IETF on-line IPR repository at 571 http://www.ietf.org/ipr. 573 The IETF invites any interested party to bring to its attention any 574 copyrights, patents or patent applications, or other proprietary 575 rights that may cover technology that may be required to implement 576 this standard. Please address the information to the IETF at ietf- 577 ipr@ietf.org.