idnits 2.17.1 draft-berger-l3vpn-ip-tunnels-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 24, 2007) is 6029 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4020 (Obsoleted by RFC 7120) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Category: Standards Track Ron Bonica (Juniper Networks) 3 Expiration Date: April 24, 2008 Russ White (Cisco Systems) 5 October 24, 2007 7 BGP/IP VPNs: BGP and CE-Based Virtual Private Networks 9 draft-berger-l3vpn-ip-tunnels-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 24, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 41 This memo describes a routing architecture that is most applicable to 42 Customer Edge (CE)-based Virtual Private Networks (VPNs). 44 In this architecture, customer devices use BGP to exchange VPN routes 45 with one another. The BGP UPDATES include a new attribute that 46 identifies the endpoint of a tunnel that can be used to reach a 47 particular VPN prefix. The encapsulation strategy described in this 48 memo is more flexible than that described in RFC 4364. In this 49 architecture, the edge router can encapsulate the original datagram 50 twice, as in RFC 4364. In this case, the inner header provides VPN 51 context and the outer header identifies the tunnel between edge 52 routers. Alternatively, the edge router can encapsulate the original 53 datagram only once, with the tunnel providing both VPN context and 54 identifying a tunnel to the remote edge router. 56 Contents 58 1 Introduction .............................................. 3 59 1.1 Conventions used in this document ......................... 4 60 2 VPN Route Distribution .................................... 4 61 2.1 Address Families .......................................... 4 62 2.2 IP VPN-IPv4 NLRI and IP VPN-IPv6 NLRI Encoding ............ 4 63 2.2.1 BGP/IP VPN - Network Address of Next Hop .................. 5 64 2.2.2 BGP/IP VPN Prefix Information ............................. 8 65 2.3 BGP Capability Negotiation ................................ 10 66 3 Forwarding ................................................ 10 67 4 Security Considerations ................................... 11 68 5 IANA Considerations ....................................... 12 69 5.1 BGP/IP VPN SAFI ........................................... 12 70 5.2 BGP/IP VPN Tunnel Types .................................. 12 71 5.3 BGP/IP VPN Tunnel Parameter Subobject Types .............. 13 72 6 References ................................................ 13 73 6.1 Normative References ...................................... 13 74 6.2 Informative References .................................... 14 75 7 Acknowledgments ........................................... 15 76 8 Authors' Addresses ........................................ 15 77 Full Copyright Statement .................................. 15 78 Intellectual Property ..................................... 16 80 1. Introduction 82 [RFC4110] provides a taxonomy for Layer 3 Virtual Private Networks 83 (VPNs). All VPNs share the following characteristics: 85 - Customer enclaves are connected to a Service Provider (SP) 86 network 87 - Customer enclaves are assigned to a Virtual Routing and 88 Forwarding (VRF) Instance 89 - Customers can communicate within the VRF 90 - Customers cannot communicate across VRF boundaries 91 - Addressing is unique only within the VRF 92 - VPN routing environments are isolated from one another 93 - VPN routing environments are isolated from the service provider 94 routing environment 95 - Tunnels (MPLS, GRE, IPSec) connect customer enclaves to one 96 another across the SP network 98 [RFC4110] divides VPNs into two classes. These are: 100 - Provider Edge (PE)-based VPNs 101 - Customer Edge (CE)-based VPNs 103 In a PE-based VPN, SP tunnels connect PE routers to one another. 104 BGP/MPLS IP VPNs, see [RFC4364] and [RFC4659], leverages this 105 architecture, using BGP to exchange VPN routes among PE routers. The 106 BGP advertisements specify tunnel endpoint as the BGP next-hop for 107 the VPN route. Therefore, SP interior routers need not carry VPN 108 routes. 110 In a CE-based VPN, tunnels connect CE routers to one another. 111 Therefore, the routing architecture used in BGP/MPLS IP VPNs is not 112 applicable. BGP/MPLS IP VPNs are also not applicable when MPLS is not 113 supported. This memo describes a routing architecture similar to the 114 routing architecture used in BGP/MPLS IP VPNs that is applicable to 115 CE-based VPNs. We refer to the approach described in this document as 116 "BGP/IP VPNs". 118 In this architecture, customer devices use BGP to exchange VPN routes 119 with one another. The BGP UPDATES include a new attribute that 120 identifies the endpoint of a tunnel that can be used to reach a 121 particular VPN prefix. 123 The encapsulation strategy described in this memo is more flexible 124 than that used in BGP/MPLS IP VPNs. In this architecture, the CE 125 router can encapsulate the original datagram twice, as in BGP/MPLS IP 126 VPNs. In this case, the inner header provides VPN context and the 127 outer header identifies the tunnel between CE routers. Alternatively, 128 the CE router can encapsulate the original datagram only once, with 129 the tunnel providing both VPN context and identifying a tunnel to the 130 remote CE. 132 1.1. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. VPN Route Distribution 140 BGP/IP VPNs use much the same mechanisms as [RFC4364] and [RFC4659] 141 to support VPN route distribution. The specific mechanism differs 142 only in that no MPLS labels are required. This Section is modeled 143 after Section 4 of [RFC4364] and Section 3 of [RFC4659] and borrows 144 from those sources. 146 2.1. Address Families 148 This document reuses the VPN-IPv4 and VPN-IPv6 address families 149 specified in [RFC4364] and [RFC4659]. Different BGP encoding is used 150 for these families as MPLS labels are not used. This document adds 151 the prefix "IP" to the names of the address families, i.e., "IP VPN- 152 IPv4" and "IP VPN-IPv6", to identify the different encoding. 154 2.2. IP VPN-IPv4 NLRI and IP VPN-IPv6 NLRI Encoding 156 As with BGP/MPLS IP VPNs, BGP/IP VPN information is carried in the 157 Multiprotocol Reachable and Unreachable Network Layer Reachability 158 Information (NLRIs) introduced in [RFC4760]. Unlike BGP/MPLS IP 159 VPNs, the BGP/IP VPN encoding of the VPN-IPv4 and VPN-IPv6 address 160 families provide tunnel related information (rather than MPLS 161 labels). This difference is reflected in the use of new formats in 162 the "Network Address of Next Hop" and "Network Layer Reachability 163 Information" NLRI fields. In all other respects, including 164 formatting and processing, BGP/IP VPN route distribution is identical 165 to BGP/MPLS VPN route distribution. This includes the encoding of 166 the Route Distinguishers (RD) in prefixes and Route Target (RT) 167 Attributes in extended communities. 169 The use of BGP/IP VPN related NLRI formats is indicated by the SAFI 170 value TBA (by IANA). The address family of a VPN route determines 171 the type of IP VPN NLRI which, as typical, is indicated by the AFI. 173 IPv4 VPN routes MUST be encoded in an IP VPN-IPv4 NLRI with an AFI of 174 1. IPv6 VPN routes MUST be encoded in an IP VPN-IPv6 NLRI with an AFI 175 of 2. With the exception of the "Network Address of Next Hop" and 176 "Network Layer Reachability Information" NLRI fields, both types of 177 NLRIs MUST be encoded as defined in [RFC4364] (for the IP VPN-IPv4 178 NLRI) and in [RFC4659] (for the IP VPN-IPv4 NLRI). 180 2.2.1. BGP/IP VPN - Network Address of Next Hop 182 With IP VPN NLRIs, the Network Address of Next Hop NLRI field carries 183 the IP address and related tunnel parameters that should be used to 184 reach a particular VPN route. The IP address is the address to be 185 used by receiving routers as the destination tunnel end-point 186 address. Tunnel parameters indicate the type of tunnel supported by 187 the advertising router for the particular route. Tunnel parameters 188 may optionally indicate tunnel specific information, e.g, destination 189 port or other tunnel identifying information. The format of the 190 Network Address of Next Hop field used in BGP/IP VPN route 191 distribution is: 193 +---------------------------+ 194 | Tunnel Flags (1 octet) | 195 +---------------------------+ 196 | Tunnel Type (1 octet) | 197 +---------------------------+ 198 | Tunnel Address (variable) | 199 +---------------------------+ 200 | Tunnel Params. (variable) | 201 +---------------------------+ 203 The use and meaning of these fields are as follows: 205 Tunnel Flags: (Bit Field) 207 The following flags are defined: 209 0 1 2 3 4 5 6 7 210 +-+-+-+-+-+-+-+-+ 211 |V| Reserved | 212 +-+-+-+-+-+-+-+-+ 214 Version (V): 216 The Version bit is used to indicate the IP version of the 217 Tunnel Address field. The flag MUST be cleared, i.e., zero 218 (0), when the tunnel end-point address carried in the Tunnel 219 Address field is an IPv4 address. The flag MUST be set, 220 i.e., one (1), when the Tunnel Address field carries an IPv6 221 address. 223 Tunnel Type: (Unsigned Integer) 225 This field indicates the type of tunnel that should be used to 226 transport data associated with the advertised VPN route. Note 227 that the mechanisms related to establishment and management of 228 tunnels are outside the scope of this document. The following 229 Type values are defined: 231 Value Type 232 ----- ---------------------------------------- 233 0 Reserved 234 1 Generic Route Encapsulation (GRE) [RFC1701] 235 2 IP-in-IP [RFC2003] 236 3 IP Authentication Header in the Tunnel-mode (AH) 237 [RFC4301] 238 4 IP Encapsulating Security Payload in the Tunnel-mode 239 (ESP) [RFC4303] 240 5 Reserved (contact authors) 242 Tunnel Address: 244 The Tunnel Address field contains the destination tunnel end- 245 point IP address that SHOULD be used to reach the advertised 246 VPN route. The type of address and the size of the field can 247 be determined by examining the V-bit. When the V-bit is not 248 set, i.e., zero (0), the Tunnel Address field MUST contain a 249 4-octet IPv4 address. When the V-bit is set, i.e., one (1), 250 the Tunnel Address field MUST contain a 16-octet IPv6 address. 252 Tunnel Parameters: 254 The Tunnel Parameters field contains a series of variable- 255 length data items called Tunnel Parameter, or TP, subobjects. 256 Each TP subobject has the following format: 258 +---------------------------+ 259 | TP Type (1 octet) | 260 +---------------------------+ 261 | TP Length (1 octet) | 262 +---------------------------+ 263 | TP Contents (variable) | 264 +---------------------------+ 266 The use and meaning of these fields are as follows: 268 Tunnel Parameter (TP) Type: (Unsigned Integer) 270 This field indicates the type of tunnel parameters 271 contained in the TP subobject. Two value ranges are 272 defined. The first range is used for parameters that are 273 independent of any particular tunneling technology and 274 are shared across all Tunnel Type field values. The 275 second range is specific to, and only has meaning in the 276 context of a particular Tunnel Type field values, i.e., 277 identified by the tuple . The 278 value ranges are as followed: 280 Range Use 281 ------- ---------------------------------------- 282 0-63 Common tunnel parameters (Applies to all 283 Tunnel Types) 284 64-127 Tunnel Type (technology) specific tunnel 285 parameters 286 128-255 Reserved 288 TP Type one (1) is defined below in Section 2.2.1.1. 290 Tunnel Parameter (TP) Length: (Unsigned Integer) 292 The TP Length field contains of the total length of the 293 tunnel parameters subobject in octets, including the TP 294 Type and TP Length fields. The TP Length field MUST be 295 equal to or greater than 2. 297 Tunnel Parameter (TP) Contents: 299 The actual information carried in the subobject. 301 Subobjects with TP subobject types that are not recognized by a 302 receiver SHOULD be silently ignored. 304 2.2.1.1. Alternate Address Tunnel Parameter (AA-TP) Subobject 306 The Alternate Address Tunnel Parameter (AA-TP) Subobject is used to 307 provide an additional destination tunnel end-point IP address. When 308 this subobject is present, the address provided in the subobject 309 along with the address provided in the next hop Tunnel Address field 310 and any other AA-TP Subobjects SHOULD be used as "equal cost" next 311 hops. Multiple AA-TP Subobjects MAY be included in a NLRI Next Hop. 312 The format of the AA-TP Subobject is: 314 +---------------------------+ 315 | TP Type (=1) | 316 +---------------------------+ 317 | TP Length (=6 or =18) | 318 +---------------------------+ 319 | AA (variable) | 320 +---------------------------+ 322 The use and meaning of these fields are as follows: 324 TP Type: 326 The AA-TP Subobject may be used with any type of tunnel and 327 MUST use the TP Type of 1. 329 TP Length: 331 Per the definition of TP Length, see above, this field is set 332 to the length of the AA field in octets plus 2. TP Length MUST 333 be set to 6 when the V bit is not set, i.e. zero (0), and MUST 334 be set to 18 when the V bit is set, i.e., one (1). 336 Alternate Address (AA): 338 The Alternate Address (AA) field contains an address of the 339 type identified by the V bits in the Tunnel Flags field. The 340 field MUST contain an IPv4 address when the V bit is not set 341 (0), and an IPv6 address when the V bit is set (1). 343 2.2.2. BGP/IP VPN Prefix Information 345 BGP/IP VPN Prefix Information parallels the label mapping information 346 used in BGP/MPLS VPNs, and the general definition and processing of 347 BGP/IP VPN Prefix Information follows [RFC3107]. As with label 348 mapping information tunnel, BGP/IP VPN Prefix Information is carried 349 as part of an NLRI in the Multiprotocol Extensions attributes. 351 2.2.2.1. BGP/IP VPN Prefix Route Information Encoding 353 The Network Layer Reachability information is encoded as one or more 354 triples of the form . The Next Hop 355 Token corresponds to the Network Address of Next Hop field of the 356 NRLI. Prefix contains the reachable VPN route. When a router 357 advertises the same Prefix with multiple NLRI Next Hop fields, the 358 advertiser uses different Next Hop Tokens for each next hop. This 359 allows the router to independently withdraw each advertised route. 361 The format of the BGP/IP VPN Prefix Route Information is: 363 +---------------------------+ 364 | Length (1 octet) | 365 +---------------------------+ 366 | NH Token (1 octet) | 367 +---------------------------+ 368 | Prefix (variable) | 369 +---------------------------+ 371 The use and meaning of these fields are as follows: 373 Length: (Unsigned Integer) 375 The Length field indicates the length in bits of the address 376 prefix. The size of the Length and NH Token fields MUST NOT be 377 included. 379 Next Hop (NH) Token: (Unsigned Integer) 381 An identifier that within the scope of the advertising router 382 uniquely identifies the contents of the Network Address of Next 383 Hop field associated with this route. All routes advertised 384 with the same Next Hop field SHOULD have the same NH Token 385 value. Routes advertised with different Next Hop field values 386 MUST have different value NH Tokens. Note, zero (0) is a valid 387 NH Token field value. 389 Prefix: 391 This field contains the IP VPN prefix that is being advertised. 392 Both unicast and multicast prefixes MAY be carried in this 393 field. 395 The format of this field is the same as defined in [RFC4364]. 396 The [RFC4364] definition is based on the following definition 397 from [RFC3107]: "The Prefix field contains address prefixes 398 followed by enough trailing bits to make the end of the field 399 fall on an octet boundary. Note that the value of trailing 400 bits is irrelevant." Additionally, per [RFC4364], the Prefix 401 field includes an 8 octet RD. 403 The length of the Prefix field can be determined by examining 404 the V-bit. When the V-bit is not set, i.e., zero (0), the 405 Prefix field is a 12 octet quantity which MUST contain an 406 8-octet RD followed by a 4-octet IPv4 address. When the V-bit 407 is set, i.e., one (1), the Prefix field is a 24-octet quantity 408 which MUST contain an 8-octet RD followed by a 16-octet IPv6 409 address. 411 2.2.2.2. Advertising Multiple Routes to a Destination 413 A BGP speaker may maintain (and advertise to its peers) more than one 414 route to a given destination. Each of these routes can be advertised 415 using separate NLRIs with different Network Address of Next Hops, or 416 via the AA-TP Subobject defined above in Section 2.2.1.1. When 417 routes are advertised with different NLRI Next Hops, the routes will 418 have different NH Tokens. Routes, with independent NH Tokens, may be 419 independently withdrawn. When the AA-TP Subobject is used, all next 420 hops included in the same advertisement will share the same NLRI Next 421 Hop field and will be covered under the same NH Token and, therefore, 422 can only be withdrawn as a group. 424 2.3. BGP Capability Negotiation 426 In order for two edge routers to exchange IP VPN-IPv4 and VPN-IPv6 427 NLRIs, they MUST use BGP Capabilities Negotiation to ensure that they 428 both are capable of properly processing such NLRIs. This is done as 429 specified in [RFC4760] and [RFC3392], by using capability code 1 430 (multiprotocol BGP), with AFI and SAFI values as specified above, 431 Section 2.2.1 and 2.2.2. 433 3. Forwarding 435 This Section is modeled after Section 5 of [RFC4364] and Section 4 of 436 [RFC4659] and borrows from those sources. 438 When an edge router receives an IP packet from a CE device, the edge 439 router MUST choose a particular VRF in which to look up the packet's 440 destination address. This choice is typically based on the packet's 441 ingress attachment circuit. The router MUST then look for a best 442 match for the packet's destination IP address within the VRF. 444 If the packet's next hop is reached directly over a VRF attachment 445 circuit (see definition in [RFC4364]) from the processing edge router 446 (i.e., the packet's egress attachment circuit is on the same edge 447 router as its ingress attachment circuit), then the packet MUST be 448 sent on the egress attachment circuit. 450 If the ingress and egress attachment circuits are on the same edge 451 router, but are associated with different VRFs, and if the route that 452 best matches the destination address in the ingress attachment 453 circuit's VRF is an aggregate of several routes in the egress 454 attachment circuit's VRF, it may be necessary to look up the packet's 455 destination address in the egress VRF as well. 457 If the packet's next hop is NOT reached through a VRF attachment 458 circuit, then the packet must travel at least one hop through the 459 backbone. The packet thus has a "BGP VPN Next Hop", which will have 460 been advertised per Section 2.2. The packet must then be tunneled to 461 the BGP VPN Next Hop. 463 The packet MUST be encapsulated in a tunnel according to the type 464 specified in the NLRI Next Hop of the advertised route. The 465 encapsulated packet MUST then be forwarded as a standard IP packet. 466 As previously mentioned, the specifics of tunnel establishment are 467 outside the scope of this document. 469 When the packet arrives at the destination tunnel end-point, it will 470 be at the BGP VPN Next Hop. The BGP VPN Next Hop MUST strip the 471 tunnel encapsulation, and MUST identify how the received packet is to 472 be forwarded. The tunnel destination address will typically indicate 473 the outgoing VRF. In this case, the packet's original IP destination 474 address MUST be looked up in a particular VRF before being forwarded 475 to a CE device. In other cases, the tunnel's destination address 476 will determine the packet's egress attachment circuit. In this case, 477 a lookup (e.g., ARP) may still need to be done in order to determine 478 the packet's data link header on that attachment circuit. 480 4. Security Considerations 482 This section borrows from Section 11 of [RFC4659]. The extensions 483 defined in this document allow [RFC4271] to propagate reachability 484 information about IPv4 and IPv6 VPN routes. Propagation of VPN 485 routes within BGP is already defined in [RFC4364] and [RFC4659]. 487 Security considerations for the transport of IPv4 and IPv6 488 reachability information using BGP are discussed in [RFC4271] and 489 [RFC2545], respectively, and are equally applicable for the 490 extensions described in this document. 492 The extensions described in this document for offering VPNs over IP 493 tunnels use the same BGP based route distribution approach as the 494 approach described in [RFC4364] and [RFC4659]. Therefore, the same 495 security considerations apply with regards to Control Plane security, 496 and edge router and P device security as described in [RFC4364], 497 Section 13. 499 This document uses IP based tunnel technologies to support data plane 500 transport. Consequently, the security considerations of those tunnel 501 technologies apply. This document defines support for GRE [RFC1701], 502 IP-in-IP [RFC2003] and IPsec AH [RFC4301] and ESP [RFC4303]. The 503 security considerations from those documents apply to the data plane 504 aspects of this document. 506 5. IANA Considerations 508 IANA is requested to administer assignment of new namespaces and new 509 values for namespaces defined in this document and reviewed in this 510 section. 512 5.1. BGP/IP VPN SAFI 514 Upon approval of this document, the IANA will make the assignment in 515 the Subsequence Address Family Identifiers (SAFI) registry located at 516 http://www.iana.org/assignments/safi-namespace: 518 Value Description Reference 519 ----- ----------- --------- 520 141* BGP/IP VPN address [This document] 522 (*) Suggested value. 524 5.2. BGP/IP VPN Tunnel Types 526 Upon approval of this document, the IANA will establish a new 527 registry called the "BGP/IP VPN Tunnel Types registry". This 528 registry should be established with the following initial values. 530 Value Type 531 ----- ---------------------------------------- 532 0 Reserved 533 1 Generic Route Encapsulation (GRE) [RFC1701] 534 2 IP-in-IP [RFC2003] 535 3 IP Authentication Header in the Tunnel-mode (AH) 536 [RFC4301] 537 4 IP Encapsulating Security Payload in the Tunnel-mode 538 (ESP) [RFC4303] 539 5 Reserved 541 Future assignments are to be made using either the IETF Consensus 542 process defined in [RFC2434], or the Early IANA Allocation process 543 defined in [RFC4020]. Reserved values MUST NOT be reassigned without 544 permission of the authors of this document. 546 5.3. BGP/IP VPN Tunnel Parameter Subobject Types 548 Upon approval of this document, the IANA will establish a new 549 registry called the "BGP/IP VPN Tunnel Parameter Subobject Types 550 registry". The assignable values are broken down into the following 551 ranges: 553 Range Use 554 ------- ------------------------------------------------------ 555 0-63 Common tunnel parameters (Applies to all Tunnel Types) 556 64-127 Tunnel Type (technology) specific tunnel parameters 557 128-255 Reserved 559 This registry should be established with the following initial 560 values: 562 Value Tunnel Parameter (TP) Type 563 ----- -------------------------------------------- 564 0 Reserved 565 1 Alternate Address Tunnel Parameter Subobject 567 Assignments in the range of 64-127 MUST be made in the context of a 568 particular BGP/IP VPN Tunnel Type, see Section 5.3, i.e., assignments 569 take the form of . 571 Future assignments in the range of 0-127 are to be made using either 572 the IETF Consensus process defined in [RFC2434], or the Early IANA 573 Allocation process defined in [RFC4020]. Assignments in the range of 574 128-255 require Standards Action, which may impact how subsequent 575 allocations within this range are to be made. 577 6. References 579 6.1. Normative References 581 [RFC3392] Chandra, R. and J. Scudder, "Capabilities 582 Advertisement with BGP-4", RFC 3392, November 2002. 584 [RFC4271] Rekhter, Y., Ed. et al, "A Border Gateway Protocol 4 585 (BGP-4)", RFC 4271, January 2006. 587 [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private 588 Networks (VPNs)", RFC 4364, February 2006. 590 [RFC4659] De Clercq, J., et al, "BGP-MPLS IP Virtual Private 591 Network (VPN) Extension for IPv6 VPN", RFC 4659, 592 September 2006. 594 [RFC4760] Bates, T. Y., Chandra, R., D. Katz, and , Rekhter, 595 "Multiprotocol Extensions for BGP-4", RFC 4760, 596 January 2007. 598 6.2. Informative References 600 [BGP-VPN] Ould-Brahim, H., et al, "BGP/VPN: VPN Information 601 Discovery for Network-based VPNs", Work in progress, 602 July 2000. 604 [RFC1701] Hanks, S., Li, T., Traina, P., "Generic Routing 605 Encapsulation (GRE)", RFC 1701, October 1994. 607 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 608 October 1996. 610 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 611 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 612 October 1998. 614 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 615 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 616 March 1999. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels," RFC 2119. 621 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information 622 in BGP-4", RFC 3107, May 2001. 624 [RFC4110] Callon, R., Suzuki, M., "A Framework for Layer 3 625 Provider-Provisioned Virtual Private Networks 626 (PPVPNs)", RFC 4110, July 2005. 628 [RFC4301] Kent, S., Seo, K., "Security Architecture for 629 the Internet Protocol", RFC 4301, December 2005. 631 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)" 632 RFC 4303, December 2005. 634 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 635 Standards Track Code Points", BCP 100, RFC 4020, 636 February 2005. 638 7. Acknowledgments 640 This work has similarities to [BGP-VPN], but does not draw from that 641 work. Several sections of this document are modeled after and use 642 text from [RFC4364] and [RFC4659]. The very useful ASCII drawing 643 tool JavE (www.jave.de) was used to create Figures 1 and 2. 645 8. Authors' Addresses 647 Lou Berger 648 LabN Consulting, L.L.C. 649 Phone: +1-301-468-9228 650 Email: lberger@labn.net 652 Ronald P. Bonica 653 Juniper Networks 654 2251 Corporate Park Drive 655 Herndon, VA 20171 656 USA 657 Email: rbonica@juniper.net 659 Russ White 660 Cisco Systems 661 Email: riw@cisco.com 663 Full Copyright Statement 665 Copyright (C) The IETF Trust (2007). 667 This document is subject to the rights, licenses and restrictions 668 contained in BCP 78, and except as set forth therein, the authors 669 retain all their rights. 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 674 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 675 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Intellectual Property 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at ietf- 701 ipr@ietf.org. 703 Acknowledgement 705 Funding for the RFC Editor function is provided by the IETF 706 Administrative Support Activity (IASA). 708 Generated on: Wed Oct 24 15:59:02 EDT 2007