idnits 2.17.1 draft-ietf-softwire-encaps-safi-05.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 114 has weird spacing: '...through a tun...' == Line 143 has weird spacing: '...ulation attri...' == Line 150 has weird spacing: '...uld ask wheth...' == Line 151 has weird spacing: '... simply attac...' == Line 153 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 (February 04, 2009) is 5553 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-05 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: August 2009 5 Eric Rosen 6 Cisco Systems, Inc. 8 February 04, 2009 10 BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute 12 draft-ietf-softwire-encaps-safi-05.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 August 04, 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 .............................. 8 79 4.2 Protocol Type sub-TLV .............................. 9 80 4.3 Color sub-TLV ...................................... 9 81 4.3.1 Color Extended Community ........................... 9 82 4.4 Tunnel Type Selection .............................. 10 83 4.5 BGP Encapsulation Extended Community ............... 11 84 5 Capability advertisement ........................... 12 85 6 Error Handling ..................................... 12 86 7 Security Considerations ............................ 12 87 8 IANA Considerations ................................ 12 88 9 Acknowledgements ................................... 13 89 10 Normative References ............................... 13 90 11 Informative References ............................. 14 91 12 Authors' Addresses ................................. 14 93 1. Specification of requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 Consider the case of a router R1 forwarding an IP packet P. Let D be 102 P's IP destination address. R1 must look up D in its forwarding 103 table. Suppose that the "best match" route for D is route Q, where Q 104 is a BGP-distributed route whose "BGP next hop" is router R2. And 105 suppose further that the routers along the path from R1 to R2 have 106 entries for R2 in their forwarding tables, but do NOT have entries 107 for D in their forwarding tables. For example, the path from R1 to R2 108 may be part of a "BGP-free core", where there are no BGP-distributed 109 routes at all in the core. Or, as in [Softwires-Mesh-Frame-work], D 110 may be an IPv4 address while the intermediate routers along the path 111 from R1 to R2 may support only IPv6. 113 In cases such as this, in order for R1 to properly forward packet P, 114 it must encapsulate P, and send P "through a tunnel" to R2. For 115 example, R1 may encapsulate P using GRE, L2TPv3, IP-in-IP, etc., 116 where the destination IP address of the encapsulation header is the 117 address of R2. 119 In order for R1 to encapsulate P for transport to R2, R1 must know 120 what encapsulation protocol to use for transporting what sorts of 121 packets to R2. R1 must also know how to fill in the various fields of 122 the encapsulation header. With certain encapsulation types, this 123 knowledge may be acquired by default or through manual configuration. 124 Other encapsulation protocols have fields such as session id, key, or 125 cookie which must be filled in. It would not be desirable to require 126 every BGP speaker to be manually configured with the encapsulation 127 information for every one of its BGP next hops. 129 In this draft, we specify a way in which BGP itself can be used by a 130 given BGP speaker to tell other BGP speakers, "if you need to 131 encapsulate packets to be sent to me, here's the information you need 132 to properly form the encapsulation header". A BGP speaker signals 133 this information to other BGP speakers by using a distinguished SAFI 134 value, the Encapsulation SAFI. The encapsulation SAFI can be used 135 with the AFI for IPv4 or with the AFI for IPv6. The IPv4 AFI is used 136 when the encapsulated packets are to be sent using IPv4; the IPv6 AFI 137 is used when the encapsulated packets are to be sent using IPv6. 139 In a given BGP update, the Network Layer Reachability Information 140 (NLRI) of the encapsulation SAFI consists of the IP address (in the 141 family specified by the AFI) of the originator of that update. The 142 encapsulation information is specified in one or more BGP "tunnel 143 encapsulation attributes" (specified herein). These attributes 144 specify the encapsulation protocols that may be used, as well as 145 specifying whatever additional information (if any) is needed in 146 order to properly use those protocols. Other attributes, e.g., 147 communities or extended communities, may also be included. 149 Since the encapsulation information is coded as a set of attributes, 150 one could ask whether a new SAFI is really required. After all, a 151 BGP speaker could simply attach the tunnel encapsulation attributes 152 to each prefix (like Q in our example) that it advertises. But with 153 that technique, any change in the encapsulation information would 154 cause a very large number of updates. Unless one really wants to 155 specify different encapsulation information for each prefix, it is 156 much better to have a mechanism in which a change in the 157 encapsulation information causes a BGP speaker to advertise only a 158 single update. Conversely, when prefixes get modified, the tunnel 159 encapsulation information need not be exchanged. 161 In this specification, a single SAFI is used to carry information for 162 all encapsulation protocols. One could have taken an alternative 163 approach of defining a new SAFI for each encapsulation protocol. 164 However, with the specified approach, encapsulation information can 165 pass transparently and automatically through intermediate BGP 166 speakers (e.g., route reflectors) that do not necessarily understand 167 the encapsulation information. This works because the encapsulation 168 attribute is defined as an optional transitive attribute. New 169 encapsulations can thus be added without the need to reconfigure any 170 intermediate BGP system. If adding a new encapsulation required using 171 a new SAFI, the information for that encapsulation would not pass 172 through intermediate BGP systems unless those systems were 173 reconfigured to support the new SAFI. 175 For encapsulation protocols where no encapsulation information needs 176 to be signaled (such as GRE without key), the egress router MAY still 177 want to specify the protocol to use for transporting packets from the 178 ingress router. This draft specifies a new BGP extended community 179 that can be attached to UPDATE messages that carry payload prefixes 180 for this purpose. 182 3. Encapsulation NLRI Format 184 The NLRI, defined below, is carried in BGP UPDATE messages [RFC4271] 185 using BGP multiprotocol extensions [RFC4760] with an AFI of 1 or 2 186 (IPv4 or IPv6) [IANA-AF] and a SAFI value to be assigned by IANA 187 (called as Encapsulation SAFI). 189 The NLRI is encoded in a format as defined in section 5 of [RFC4760] 190 (a 2-tuple of the form ). The value field is 191 structured as follows: 193 +-----------------------------------------------+ 194 | Endpoint address (Variable) | 195 +-----------------------------------------------+ 197 - Endpoint Address: This field identifies the BGP speaker 198 originating the update. It is typically one of the interface 199 addresses configured at the router. The length of the endpoint 200 address is dependent on the AFI being advertised. If the AFI is 201 set to IPv4 (1), the the endpoint address is a 4-octet IPv4 202 address whereas if the AFI is set to IPv6 (2), the endpoint 203 address is a 16-octet IPv6 address. 205 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 206 attribute with Encapsulation SAFI MUST also carry the BGP mandatory 207 attributes: ORIGIN, AS_PATH, and LOCAL_PREF (for IBGP neighbors) as 208 defined in [RFC4271]. In addition, such an update message can also 209 contain any of the BGP optional attributes, like Community or 210 Extended Community attribute to influence an action on the receiving 211 speaker. 213 When a BGP speaker advertises the Encapsulation NLRI via BGP, it uses 214 its own address as the BGP nexthop in the MP_REACH_NLRI or 215 MP_UNREACH_NLRI attribute. The nexthop address is set based on the 216 AFI in the attribute. For example, if the AFI is set to IPv4 (1), 217 the nexthop is encoded as a 4-byte IPv4 address. If the AFI is set to 218 IPv6 (2), the nexthop is encoded as a 16-byte IPv6 address of the 219 router. On the receiving router, the BGP nexthop of such an update 220 message is validated by performing a recursive route lookup operation 221 in the routing table. 223 Bestpath selection of Encapsulation NLRIs is governed by the decision 224 process outlined in section 9.1 of [RFC4271]. The encapsulation data 225 carried through other attributes in the message are to be used by the 226 receiving router only if the NLRI has a bestpath. 228 4. Tunnel Encapsulation Attribute 230 Tunnel Encapsulation attribute is an optional transitive attribute 231 that is composed of a set of Type-Length-Value (TLVs) encodings. The 232 type code of the attribute is to be assigned by IANA. Each TLV 233 contains information corresponding to a particular tunnel technology. 234 The TLV is structured as follows: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Tunnel Type (2 Octets) | Length (2 Octets) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 | Value | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Tunnel Type (2 octets): It identifies the type of the tunneling 247 technology being signaled. This document defines the following types: 249 - 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 IP-in-IP or 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 For interoperability, a speaker supporting encapsulation SAFI MUST 471 implement the Encapsulation extended community. 473 5. Capability advertisement 475 A BGP speaker that wishes to exchange tunnel endpoint information 476 must use the Multiprotocol Extensions Capability Code as defined in 477 [RFC4760], to advertise the corresponding (AFI, SAFI) pair. 479 6. Error Handling 481 When a BGP speaker encounters an error while parsing the tunnel 482 encapsulation attribute, the speaker MUST treat the UPDATE as a 483 withdrawl of existing routes to the included encapsulation SAFI 484 NLRIs, or discard the UPDATE if no such routes exist. A log entry 485 should be raised for local analysis. 487 7. Security Considerations 489 Security considerations applicable to Softwires can be found in the 490 mesh framework [Softwires-Mesh-Frame-work]. In general, security 491 issues of the tunnel protocols signalled through encapsulation SAFI 492 are inherited. 494 If a third party is able to modify any of the information that is 495 used to form encapsulation headers, or to choose a tunnel type, or to 496 choose a particular tunnel for a particular payload type, user data 497 packets may end up getting misrouted, misdelivered, and/or dropped. 499 8. IANA Considerations 501 IANA shall assign a value from the "Subsequent Address Family" 502 Registry, in the "Standards Action" range, to be called 503 "Encapsulation SAFI", with this document as the reference. 505 IANA shall assign a value from the "BGP Path Attributes" Registry, to 506 be called "Tunnel Encapsulation Attribute", with this document as the 507 reference. 509 IANA shall assign two new values from the "BGP Opaque Extended 510 Community" type Registry. Both are from the transitive range. The 511 first new value is called "Color Extended Community", and the second 512 is called "Encapsulation Extended Community". This document is the 513 reference for both assignments. 515 IANA shall set up a registry for "BGP Tunnel Encapsulation Attribute 516 Tunnel Types". This is a registry of two-octet values (0-65535), to 517 be assigned on a first-come, first-serve basis. The initial 518 assignments shall be as follows: 520 Tunnel Name Type 521 --------------- ----- 522 L2TPv3 over IP 1 523 GRE 2 524 IP in IP 7 526 IANA shall set up a registry for "BGP Tunnel Encapsulation 527 Attribute Sub-TLVs". This is a registry of one-octet values 528 (0-255), to be assigned on a "standards action/early allocation" 529 basis. This document is the reference. The initial assignments are: 531 Sub-TLV name Type 532 ------------- ----- 533 Encapsulation 1 534 Protocol type 2 535 Color 4 537 9. Acknowledgements 539 This specification builds on prior work by Gargi Nalawade, Ruchi 540 Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, and 541 Chris Metz. The current authors wish to thank all these authors for 542 their contribution. 544 The authors would like to thank John Scudder, Robert Raszuk, Keyur 545 Patel, Chris Metz, Yakov Rekhter, Carlos Pignataro, and Brian 546 Carpenter for their valuable comments and suggestions. 548 10. Normative References 550 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 551 Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006. 553 [RFC4760] Bates et al, "Multiprotocol Extensions for BGP-4," RFC 554 4760, January 2007. 556 [RFC4360] Sangli, S., Tappan D., and Rekhter Y., "BGP Extended 557 Communities Attribute," RFC 4360, February 2006. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels," March 1997. 562 [RFC3931] Lau, J., Townsley, M., and Goyret, I., "Layer Two Tunneling 563 Protocol - Version 3 (L2TPv3)," RFC 3931, March 2005. 565 [RFC2784] Farinacci et al, "Generic Routing Encapsulation (GRE)," RFC 566 2784, March 2000. 568 [RFC2890] Dommety, G. "Key and Sequence Number Extensions to GRE," 569 RFC 2890, September 2000. 571 [RFC2003] Perkins, C. "IP Encapsulation within IP," RFC 2003, October 572 1996. 574 [RFC4213] Nordmark, E. and Gilligan, R., "Basic Transition Mechanisms 575 for IPv6 Hosts and Routers," RFC 4213, October 2005. 577 11. Informative References 579 [IANA-AF] "Address Family Numbers," Reachable from 580 http://www.iana.org/numbers.html. 582 [Softwires-Mesh-Frame-work] Wu, J. et al, "Softwire Mesh Framework," 583 draft-ietf-softwire-mesh-framework-05.txt, September 2008. 585 12. Authors' Addresses 587 Pradosh Mohapatra 588 Cisco Systems, Inc. 589 170 Tasman Drive 590 San Jose, CA, 95134 591 Email: pmohapat@cisco.com 593 Eric Rosen 594 Cisco Systems, Inc. 595 1414 Massachusetts Avenue 596 Boxborough, MA, 01719 597 E-mail: erosen@cisco.com