idnits 2.17.1 draft-ietf-softwire-encaps-safi-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors Copyright Line does not match the current year == Line 113 has weird spacing: '...through a tun...' == Line 142 has weird spacing: '...ulation attri...' == Line 149 has weird spacing: '...uld ask wheth...' == Line 150 has weird spacing: '... simply attac...' == Line 152 has weird spacing: '... change in th...' == (7 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 (December 18, 2008) is 5579 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) == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-04 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 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: June 2009 5 Eric Rosen 6 Cisco Systems, Inc. 8 December 18, 2008 10 BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute 12 draft-ietf-softwire-encaps-safi-04.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 19, 2009. 37 Copyright Notice 39 Copyright (c) 2008 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 In certain situations, transporting a packet from one Border Gateway 52 Protocol (BGP) speaker to another, the BGP next hop, requires that 53 the packet be encapsulated by the first BGP speaker and decapsulated 54 by the second. To support these situations, there needs to be some 55 agreement between the two BGP speakers with regard to the 56 "encapsulation information", i.e., the format of the encapsulation 57 header as well as the contents of various fields of the header. 59 The encapsulation information need not be signaled for all 60 encapsulation types. In the cases where the signaling is required 61 (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3), Generic 62 Routing Encapsulation (GRE) with key), this draft specifies a method 63 by which BGP speakers can signal encapsulation information to each 64 other. The signaling is done by sending BGP updates using the 65 "Encapsulation Subsequent Address Family Identifier (SAFI)" and IPv4 66 or IPv6 Address Family Identifier (AFI). In the cases where no 67 encapsulation information needs to be signaled (such as GRE without 68 key), this draft specifies a BGP extended community that can be 69 attached to BGP UPDATE messages that carry payload prefixes to 70 indicate the encapsulation protocol type to be used. 72 Table of Contents 74 1 Specification of requirements ...................... 3 75 2 Introduction ....................................... 3 76 3 Encapsulation NLRI Format .......................... 5 77 4 Tunnel Encapsulation Attribute ..................... 6 78 4.1 Encapsulation sub-TLV .............................. 7 79 4.2 Protocol Type sub-TLV .............................. 8 80 4.3 Color sub-TLV ...................................... 9 81 4.3.1 Color Extended Community ........................... 9 82 4.4 Tunnel Type Selection .............................. 9 83 4.5 BGP Encapsulation Extended Community ............... 10 84 5 Capability advertisement ........................... 11 85 6 Security Considerations ............................ 11 86 7 IANA Considerations ................................ 11 87 8 Acknowledgements ................................... 12 88 9 Normative References ............................... 13 89 10 Informative References ............................. 13 90 11 Authors' Addresses ................................. 13 92 1. Specification of requirements 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 Consider the case of a router R1 forwarding an IP packet P. Let D be 101 P's IP destination address. R1 must look up D in its forwarding 102 table. Suppose that the "best match" route for D is route Q, where Q 103 is a BGP-distributed route whose "BGP next hop" is router R2. And 104 suppose further that the routers along the path from R1 to R2 have 105 entries for R2 in their forwarding tables, but do NOT have entries 106 for D in their forwarding tables. For example, the path from R1 to R2 107 may be part of a "BGP-free core", where there are no BGP-distributed 108 routes at all in the core. Or, as in [Softwires-Mesh-Frame-work], D 109 may be an IPv4 address while the intermediate routers along the path 110 from R1 to R2 may support only IPv6. 112 In cases such as this, in order for R1 to properly forward packet P, 113 it must encapsulate P, and send P "through a tunnel" to R2. For 114 example, R1 may encapsulate P using GRE, L2TPv3, IP-in-IP, etc., 115 where the destination IP address of the encapsulation header is the 116 address of R2. 118 In order for R1 to encapsulate P for transport to R2, R1 must know 119 what encapsulation protocol to use for transporting what sorts of 120 packets to R2. R1 must also know how to fill in the various fields of 121 the encapsulation header. With certain encapsulation types, this 122 knowledge may be acquired by default or through manual configuration. 123 Other encapsulation protocols have fields such as session id, key, or 124 cookie which must be filled in. It would not be desirable to require 125 every BGP speaker to be manually configured with the encapsulation 126 information for every one of its BGP next hops. 128 In this draft, we specify a way in which BGP itself can be used by a 129 given BGP speaker to tell other BGP speakers, "if you need to 130 encapsulate packets to be sent to me, here's the information you need 131 to properly form the encapsulation header". A BGP speaker signals 132 this information to other BGP speakers by using a distinguished SAFI 133 value, the Encapsulation SAFI. The encapsulation SAFI can be used 134 with the AFI for IPv4 or with the AFI for IPv6. The IPv4 AFI is used 135 when the encapsulated packets are to be sent using IPv4; the IPv6 AFI 136 is used when the encapsulated packets are to be sent using IPv6. 138 In a given BGP update, the Network Layer Reachability Information 139 (NLRI) of the encapsulation SAFI consists of the IP address (in the 140 family specified by the AFI) of the originator of that update. The 141 encapsulation information is specified in one or more BGP "tunnel 142 encapsulation attributes" (specified herein). These attributes 143 specify the encapsulation protocols that may be used, as well as 144 specifying whatever additional information (if any) is needed in 145 order to properly use those protocols. Other attributes, e.g., 146 communities or extended communities, may also be included. 148 Since the encapsulation information is coded as a set of attributes, 149 one could ask whether a new SAFI is really required. After all, a 150 BGP speaker could simply attach the tunnel encapsulation attributes 151 to each prefix (like Q in our example) that it advertises. But with 152 that technique, any change in the encapsulation information would 153 cause a very large number of updates. Unless one really wants to 154 specify different encapsulation information for each prefix, it is 155 much better to have a mechanism in which a change in the 156 encapsulation information causes a BGP speaker to advertise only a 157 single update. Conversely, when prefixes get modified, the tunnel 158 encapsulation information need not be exchanged. 160 In this specification, a single SAFI is used to carry information for 161 all encapsulation protocols. One could have taken an alternative 162 approach of defining a new SAFI for each encapsulation protocol. 163 However, with the specified approach, encapsulation information can 164 pass transparently and automatically through intermediate BGP 165 speakers (e.g., route reflectors) that do not necessarily understand 166 the encapsulation information. This works because the encapsulation 167 attribute is defined as an optional transitive attribute. New 168 encapsulations can thus be added without the need to reconfigure any 169 intermediate BGP system. If adding a new encapsulation required using 170 a new SAFI, the information for that encapsulation would not pass 171 through intermediate BGP systems unless those systems were 172 reconfigured to support the new SAFI. 174 For encapsulation protocols where no encapsulation information needs 175 to be signaled (such as GRE without key), the egress router MAY still 176 want to specify the protocol to use for transporting packets from the 177 ingress router. This draft specifies a new BGP extended community 178 that can be attached to UPDATE messages that carry payload prefixes 179 for this purpose. 181 3. Encapsulation NLRI Format 183 The NLRI, defined below, is carried in BGP UPDATE messages [RFC4271] 184 using BGP multiprotocol extensions [RFC4760] with an AFI of 1 or 2 185 (IPv4 or IPv6) [IANA-AF] and a SAFI value to be assigned by IANA 186 (called as Encapsulation SAFI). 188 The NLRI is encoded in a format as defined in section 5 of [RFC4760] 189 (a 2-tuple of the form ). The value field is 190 structured as follows: 192 +-----------------------------------------------+ 193 | Endpoint address (Variable) | 194 +-----------------------------------------------+ 196 - Endpoint Address: This field identifies the BGP speaker 197 originating the update. It is typically one of the interface 198 addresses configured at the router. The length of the endpoint 199 address is dependent on the AFI being advertised. If the AFI is 200 set to IPv4 (1), the the endpoint address is a 4-octet IPv4 201 address whereas if the AFI is set to IPv6 (2), the endpoint 202 address is a 16-octet IPv6 address. 204 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 205 attribute with Encapsulation SAFI MUST also carry the BGP mandatory 206 attributes: ORIGIN, AS_PATH, and LOCAL_PREF (for IBGP neighbors) as 207 defined in [RFC4271]. In addition, such an update message can also 208 contain any of the BGP optional attributes, like Community or 209 Extended Community attribute to influence an action on the receiving 210 speaker. 212 When a BGP speaker advertises the Encapsulation NLRI via BGP, it uses 213 its own address as the BGP nexthop in the MP_REACH_NLRI or 214 MP_UNREACH_NLRI attribute. The nexthop address is set based on the 215 AFI in the attribute. For example, if the AFI is set to IPv4 (1), 216 the nexthop is encoded as a 4-byte IPv4 address. If the AFI is set to 217 IPv6 (2), the nexthop is encoded as a 16-byte IPv6 address of the 218 router. On the receiving router, the BGP nexthop of such an update 219 message is validated by performing a recursive route lookup operation 220 in the routing table. 222 Bestpath selection of Encapsulation NLRIs is governed by the decision 223 process outlined in section 9.1 of [RFC4271]. The encapsulation data 224 carried through other attributes in the message are to be used by the 225 receiving router only if the NLRI has a bestpath. 227 4. Tunnel Encapsulation Attribute 229 Tunnel Encapsulation attribute is an optional transitive attribute 230 that is composed of a set of Type-Length-Value (TLVs) encodings. The 231 type code of the attribute is to be assigned by IANA. Each TLV 232 contains information corresponding to a particular tunnel technology. 233 The TLV is structured as follows: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Tunnel Type (2 Octets) | Length (2 Octets) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 | Value | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Tunnel Type (2 octets): It identifies the type of the tunneling 246 technology being signaled. This document defines the following types: 248 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 250 - GRE [RFC2784]: Tunnel Type = 2 252 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 254 Unknown types are to be ignored and skipped upon receipt. 256 Length (2 octets): the total number of octets of the Value field. 258 Value (variable): The value is comprised of multiple sub-TLV's. Each 259 sub-TLV consists of three fields: a one-octet type, one-octet length, 260 and zero or more octets of value. The sub-TLV is structured as 261 follows: 263 +-----------------------------------+ 264 | Sub-TLV Type (1 Octet) | 265 +-----------------------------------+ 266 | Sub-TLV Length (1 Octet) | 267 +-----------------------------------+ 268 | Sub-TLV Value (Variable) | 269 | | 270 +-----------------------------------+ 272 Sub-TLV Type (1 octet): Each sub-TLV type defines a certain property 273 about the tunnel TLV that contains this sub-TLV. The following are 274 the types defined in this document: 276 - Encapsulation: sub-TLV type = 1 278 - Protocol type: sub-TLV type = 2 280 - Color: sub-TLV type = 4 282 When the TLV is being processed by a BGP speaker that will be 283 performing encapsulation, any unknown sub-TLVs MUST be ignored and 284 skipped. However if the TLV is understood, the entire TLV MUST NOT be 285 ignored just because it contains an unknown sub-TLV. 287 Sub-TLV Length (1 octet): the total number of octets of the sub-TLV 288 value field. 290 Sub-TLV Value (variable): Encodings of the value field depend on the 291 sub-TLV type as enumerated above. The following sub-sections define 292 the encoding in detail. 294 4.1. Encapsulation sub-TLV 296 The syntax and semantics of the encapsulation sub-TLV is determined 297 by the tunnel type of the TLV that contains this sub-TLV. 299 When the tunnel type of the TLV is L2TPv3-over-IP, the following is 300 the structure of the value field of the encapsulation sub-TLV: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Session ID (4 octets) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 | Cookie (Variable) | 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 * Session ID: a non-zero 4-octet value locally assigned by the 313 advertising router that serves as a lookup key in the incoming 314 packet's context. 316 * Cookie: an optional, variable length (encoded in octets - 0 to 8 317 octets) value used by L2TPv3 to check the association of a 318 received data message with the session identified by the Session 319 ID. Generation and usage of the cookie value is as specified in 320 [RFC3931]. 322 The length of the cookie is not encoded explicitly, but can be 323 calculated as: (sub-TLV length - 4). 325 When the tunnel type of the TLV is GRE, the following is the 326 structure of the value field of the encapsulation sub-TLV: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | GRE Key (4 octets) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 * GRE Key: A 4 octet field [RFC2890] that is generated by the 335 advertising router. The actual method by which the key is 336 obtained is beyond the scope of the document. The key is inserted 337 into the GRE encapsulation header of the payload packets sent by 338 ingress routers to the advertising router. It is intended to be 339 used for identifying extra context information about the received 340 payload. 342 Note that the key is optional. Unless a key value is being 343 advertised, the GRE encapsulation sub-TLV MUST NOT be present. 345 4.2. Protocol Type sub-TLV 347 The protocol type sub-TLV MAY be encoded to indicate the type of the 348 payload packets that will be encapsulated with the tunnel parameters 349 being signaled in the TLV. The value field of the sub-TLV contains a 350 2-octet protocol type that is one of the types defined in [IANA-AF] 351 as ETHER TYPEs. 353 For example, if we want to use three L2TPv3 sessions, one carrying 354 IPv4 packets, one carrying IPv6 packets, and one carrying MPLS 355 packets, the egress router will include three TLVs of L2TPv3 356 encapsulation type, each specifying a different session id and a 357 different payload type. The protocol type sub-TLV for these will be 358 IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and 359 MPLS (protocol type = 0x8847) respectively. This informs the ingress 360 routers of the appropriate encapsulation information to use with each 361 of the given protocol types. Insertion of the specified session id at 362 the ingress routers allows the egress to process the incoming packets 363 correctly, according to their protocol type. 365 Inclusion of this sub-TLV depends on the tunnel type. It MUST be 366 encoded for L2TPv3 tunnel type. On the other hand, the protocol type 367 sub-TLV is not required for GRE tunnels. 369 4.3. Color sub-TLV 371 The color sub-TLV MAY be encoded as a way to color the corresponding 372 tunnel TLV. The value field of the sub-TLV contains an extended 373 community that is defined as follows: 375 4.3.1. Color Extended Community 377 The color extended community is an opaque extended community 378 [RFC4360] with the following encoding: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 0x03 | TBD | Reserved | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Color Value | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 The value of the high-order octet of the extended Type Field is 0x03, 389 which indicates it is transitive. The value of the low-order octet of 390 the extended type field for this community is TBD. The Color value is 391 user defined and configured locally on the routers. The same color 392 extended community can then be attached to the UPDATE messages that 393 contain payload prefixes. This way, the BGP speaker can express the 394 fact that it expects the packets corresponding to these payload 395 prefixes to be received with a particular tunnel encapsulation 396 header. 398 4.4. Tunnel Type Selection 400 A BGP speaker may include multiple tunnel TLVs in the tunnel 401 attribute. The receiving speaker MAY have local policies defined to 402 choose different tunnel types for different sets/types of payload 403 prefixes received from the same BGP speaker. For instance, if a BGP 404 speaker includes both L2TPv3 and GRE tunnel types in the tunnel 405 attribute and it also advertises IPv4 and IPv6 prefixes, the ingress 406 router may have local policy defined to choose L2TPv3 for IPv4 407 prefixes (provided the protocol type received in the tunnel attribute 408 matches) and GRE for IPv6 prefixes. 410 Additionally, the Encapsulation SAFI UPDATE message can contain a 411 color sub-TLV for some or all of the tunnel TLVs. The BGP speaker 412 SHOULD then attach a color extended community to payload prefixes to 413 select the appropriate tunnel types. 415 In a multi-vendor deployment that has routers supporting different 416 tunneling technologies, including color sub-TLV to the Encapsulation 417 SAFI UPDATE message can serve as a classification mechanism (for 418 example, set A of routers for GRE and set B of routers for L2TPv3). 419 The ingress router can then choose the encapsulation data 420 appropriately while sending packets to an egress router. 422 If a BGP speaker originates an update for prefix P with color C and 423 with itself as the next hop, then it MUST also originate an encaps- 424 SAFI update which contains the color C. 426 Suppose that a BGP speaker receives an update for prefix P with color 427 C, that the BGP decision procedure has selected the route in that 428 update as the best route to P, that the next hop is node N, but that 429 an encapsulation SAFI update originating from node N containing color 430 C has not been received. In this case, no route to P will be 431 installed in the forwarding table unless and until the corresponding 432 encapsulation SAFI update is received, or the BGP decision process 433 selects a different route. 435 Suppose that a BGP speaker receives an "uncolored" update for prefix 436 P, with next hop N, and that the BGP speaker has also received an 437 encapsulation SAFI originated by N, specifying one or more 438 encapsulations that may or may not be colored. In this case, the 439 choice of encapsulation is a matter of local policy. The only 440 "default policy" necessary is to choose one of the encapsulations 441 supported by the speaker. 443 4.5. BGP Encapsulation Extended Community 445 We define a BGP opaque extended community that can be attached to BGP 446 UPDATE messages to indicate the encapsulation protocol to be used for 447 sending packets from an ingress router to an egress router. 448 Considering our example from the "Introduction" section, R2 MAY 449 include this extended community specifying a particular tunnel type 450 to be used in the UPDATE message that carries route Q to R1. This is 451 useful if there are no explicit encapsulation information to be 452 signaled using the encap SAFI for a tunneling protocol (such as GRE 453 without key). 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | 0x03 | TBD | Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Reserved | Tunnel Type | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 The value of the high-order octet of the extended type field is 0x03, 464 which indicates it's transitive. The value of the low-order octet of 465 the extended type field is TBD. 467 The last two octets of the value field encode a tunnel type as 468 defined in this document. 470 5. Capability advertisement 472 A BGP speaker that wishes to exchange tunnel endpoint information 473 must use the Multiprotocol Extensions Capability Code as defined in 474 [RFC4760], to advertise the corresponding (AFI, SAFI) pair. 476 6. Security Considerations 478 Security considerations applicable to Softwires can be found in the 479 mesh framework [Softwires-Mesh-Frame-work]. In general, security 480 issues of the tunnel protocols signalled through encapsulation SAFI 481 are inherited. 483 If a third party is able to modify any of the information that is 484 used to form encapsulation headers, or to choose a tunnel type, or to 485 choose a particular tunnel for a particular payload type, user data 486 packets may end up getting misrouted, misdelivered, and/or dropped. 488 7. IANA Considerations 490 IANA shall assign a value from the "Subsequent Address Family" 491 Registry, in the "Standards Action" range, to be called 492 "Encapsulation SAFI", with this document as the reference. 494 IANA shall assign a value from the "BGP Path Attributes" Registry, to 495 be called "Tunnel Encapsulation Attribute", with this document as the 496 reference. 498 IANA shall assign two new values from the "BGP Opaque Extended 499 Community" type Registry. Both are from the transitive range. The 500 first new value is called "Color Extended Community", and the second 501 is called "Encapsulation Extended Community". This document is the 502 reference for both assignments. 504 IANA shall set up a registry for "BGP Tunnel Encapsulation Attribute 505 Tunnel Types". This is a registry of two-octet values (0-65535), to 506 be assigned on a first-come, first-serve basis. The initial 507 assignments shall be as follows: 509 Tunnel Name Type 510 --------------- ----- 511 L2TPv3 over IP 1 512 GRE 2 513 IP in IP 7 515 IANA shall set up a registry for "BGP Tunnel Encapsulation 516 Attribute Sub-TLVs". This is a registry of one-octet values 517 (0-255), to be assigned on a "standards action/early allocation" 518 basis. This document is the reference. The initial assignments are: 520 Sub-TLV name Type 521 ------------- ----- 522 Encapsulation 1 523 Protocol type 2 524 Color 4 526 8. Acknowledgements 528 This specification builds on prior work by Gargi Nalawade, Ruchi 529 Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, and 530 Chris Metz. The current authors wish to thank all these authors for 531 their contribution. 533 The authors would like to thank John Scudder, Robert Raszuk, Keyur 534 Patel, Chris Metz, Yakov Rekhter, Carlos Pignataro, and Brian 535 Carpenter for their valuable comments and suggestions. 537 9. Normative References 539 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 540 Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006. 542 [RFC4760] Bates et al, "Multiprotocol Extensions for BGP-4," RFC 543 4760, January 2007. 545 [RFC4360] Sangli, S., Tappan D., and Rekhter Y., "BGP Extended 546 Communities Attribute," RFC 4360, February 2006. 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels," March 1997. 551 [RFC3931] Lau, J., Townsley, M., and Goyret, I., "Layer Two Tunneling 552 Protocol - Version 3 (L2TPv3)," RFC 3931, March 2005. 554 [RFC2784] Farinacci et al, "Generic Routing Encapsulation (GRE)," RFC 555 2784, March 2000. 557 [RFC2890] Dommety, G. "Key and Sequence Number Extensions to GRE," 558 RFC 2890, September 2000. 560 [RFC2003] Perkins, C. "IP Encapsulation within IP," RFC 2003, October 561 1996. 563 [RFC4213] Nordmark, E. and Gilligan, R., "Basic Transition Mechanisms 564 for IPv6 Hosts and Routers," RFC 4213, October 2005. 566 10. Informative References 568 [IANA-AF] "Address Family Numbers," Reachable from 569 http://www.iana.org/numbers.html. 571 [Softwires-Mesh-Frame-work] Wu, J. et al, "Softwire Mesh Framework," 572 draft-ietf-softwire-mesh-framework-04.txt, March 2008. 574 11. Authors' Addresses 576 Pradosh Mohapatra 577 Cisco Systems, Inc. 578 170 Tasman Drive 579 San Jose, CA, 95134 580 Email: pmohapat@cisco.com 581 Eric Rosen 582 Cisco Systems, Inc. 583 1414 Massachusetts Avenue 584 Boxborough, MA, 01719 585 E-mail: erosen@cisco.com