idnits 2.17.1 draft-nalawade-kapoor-tunnel-safi-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 560), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 554. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '.... The egress PE MUST advertise all tu...' RFC 2119 keyword, line 106: '...n. The egress PE MAY advertise one or...' RFC 2119 keyword, line 107: '...for the Tunnel SAFI MUST never be sent...' RFC 2119 keyword, line 115: '...P SSA Attribute, MUST contain at least...' RFC 2119 keyword, line 116: '...odes for this SAFI. It MAY contain one...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Length - A 2 Octet field that specifies the length of the L2TPv3 attribute in octets. The value contained in this Length field MUST not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus the total length of any prior TLVs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Length - A 2 Octet field that specifies the length of the mGRE information in octets. The value contained in this Length field MUST not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus the total length of any prior TLVs. (This doesn't make sense to me. What's the relationship between TLV's?) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Length - A 2 Octet field that specifies the length of the IPSec information in octets. The value contained in this Length field MUST not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus the total length of any prior TLVs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Length A 2 Octet field that specifies the length of the MPLS TLV in octets. The value contained in this Length field MUST not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus the total length of any prior TLVs. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP-TUN' is mentioned on line 110, but not defined == Missing Reference: 'BGP-MP' is mentioned on line 381, but not defined == Unused Reference: 'BGP-CAP' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'MULTI-BGP' is defined on line 503, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' -- Unexpected draft version: The latest known version of draft-ietf-idr-rfc2842bis is -01, but you're referring to -02. -- No information found for draft-nalawade-kapoor-idr-bgp-ssa - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-SSA' == Outdated reference: A later version (-10) exists of draft-ietf-idr-rfc2858bis-02 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Gargi Nalawade 3 Internet Draft Ruchi Kapoor 4 Expires: January 2006 Dan Tappan 5 Scott Wainner 7 Cisco Systems 9 Tunnel SAFI 11 draft-nalawade-kapoor-tunnel-safi-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The architecture of an MPLS VPN solution relies on the establishment 39 of two layers of reachability information. The first is the 40 association of a prefix, interface, or route table to a VPNv4 label 41 that is used on the egress PE to delineate a Virtual Route Forwarding 42 table. The second is the association of the next-hop to reach the 43 egress PE. By default, the MPLS VPN establishes an LSP tunnel from 44 the ingress PE to the egress PE. A requirement exists to establish 45 an IP tunnel between the ingress and egress PE in lieu of an LSP. 46 The egress PE's tunnel capability needs to be distributed to all the 47 potential ingress PE's as well as the attributes of the tunnel. The 48 tunnel end-point discovery may occur within and across Autonomous 49 Systems. BGP is the logical protocol of choice that is widely 50 deployed for MPLS VPN solutions and can carry this information in a 51 synchronized manner. This document defines how BGP speakers can 52 convey Tunnel end-point reachability information. 54 1. Introduction 56 Two end-points of a tunnel need to agree upon the end-point 57 information and its binding to a network address at the remote point. 58 Normally, this information can be manually shared and statically 59 configured when the number of tunnels to manage is relatively small. 60 In the case of a network such as an MPLS VPN where there is a need 61 for a tunnel between every ingress and egress PE, the number of 62 tunnel end-points that need to be exchanged and maintained grows 63 dramatically as the network becomes large. The egress PE already 64 defines reachability information for the private routing information 65 as well as the NLRI of the PE itself. This information is 66 distributed via MP-BGP to any number of potential ingress PE. The 67 extent of distribution of egress PE's NLRI and next-hop is unknown by 68 the egress PE; therefore, egress PE cannot feasibly know the tunnel 69 attributes for any potential ingress PE unless the egress PE assigns 70 these attributes. The egress PE needs to advertise it's capability 71 to receive tunneled packets, the types of tunnels supported, the 72 preference for the various tunnel methods, and the attributes 73 associated with the tunnels. The tunnel information then needs to be 74 distributed and maintained using MP-BGP such that every potential 75 ingress PE knows the appropriate tunnel method and attributes of the 76 egress PE. The tunnel capabilities are uniquely defined for a given 77 PE and may or may not correlate with the capabilities of any other 78 potential ingress PE. For this reason, the ingress PE may select the 79 most appropriate tunneling mechanism based on the compability of the 80 tunnel capabilities between the ingress and egress PE's and their 81 preferences. 83 2. The Tunnel SAFI 85 This document defines a new BGP SAFI called the Tunnel SAFI. The 86 [IANA-AFI] [IANA-SAFI] value pair used to identify this 87 SAFI are- AFI=1, SAFI=64, for the IPv4 Tunnel AFI; and AFI=2, SAFI=64 88 for the IPv6 Tunnel AFI. 90 For BGP Speakers supporting [BGP-4], the tunnel end point address 91 will be carried as an NLRI in the MP_REACH attribute for the Tunnel 92 SAFI. 94 The NLRI will be encoded as a 2-octet Identifier followed by the NLRI 95 format as specified by the respective AFI. The Identifier will 96 identify the tunnel end point being advertised. This Identifier 97 enables multiple tunnel end-points to share the same network address, 98 thus conserving the number of addresses needed to be configured by 99 the operator on each of the Tunnel-endpoints. 101 3. BGP Attribute 103 The BGP SSA Attribute [BGP-SSA] will be used to carry the Tunnel 104 end-point information. The egress PE may support one or more tunnel 105 methods. The egress PE MUST advertise all tunnel types for which it 106 will support tunnel termination. The egress PE MAY advertise one or 107 more tunnel types. And update for the Tunnel SAFI MUST never be sent 108 without the BGP SSA Attribute. 110 As defined in [BGP-TUN], the first bit of the TYPE field in the BGP 111 SAFI-Specific Attribute is the 'transitive bit'. If the bit value is 112 1, implies that this tunnel is transitive. If the bit value is 0, it 113 implies this specific tunnel is not transitive. 115 The Value Field of the BGP SSA Attribute, MUST contain at least one 116 of the following valid Type codes for this SAFI. It MAY contain one 117 or more TLVs with these Type codes. 119 Type 1: L2TPv3 Tunnel information 121 Type 2: mGRE Tunnel information 123 Type 3: IPSec Tunnel information 125 Type 4: MPLS Tunnel information 127 Type 5: L2TPv3 in IPSEC Tunnel information 129 Type 6: mGRE in IPSEC Tunnel information 131 3.1. L2TPv3 Tunnel information TLV 133 The L2TPv3 Tunnel Information TLV has a type value of 1. The value 134 part of the L2TPv3 Tunnel Information Type contains the following : 136 - Preference (2 Octets) 137 - Flags (1 Octet) 138 - Cookie Length (1 Octet) 139 - Session ID (4 Octets) 140 - Cookie (Variable) 142 The L2TPv3 Tunnel Information TLV looks as follows : 144 0 1 145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |T| Type = 0x01 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Length (2 octets) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Preference (2 octets) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |S| Flags | Cookie Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Session ID (4 Octets) | 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 | Cookie (Variable) | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 where 165 Length - A 2 Octet field that specifies the length of the L2TPv3 166 attribute in octets. The value contained in this Length field MUST 167 not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus 168 the total length of any prior TLVs. 170 Preference - A 2 Octet field containing a Preference associated with 171 the TLV. The Preference value indicates a preferred ordering of 172 tunneling encapsulations according to the sender (i.e. egress PE). 173 The recipient of the information SHOULD take the sender's preference 174 into account in selecting which encapsulation it will use. A higher 175 value indicates a higher preference. 177 Flags - A 1 Octet field containing flag-bits. The leftmost bit 178 indicates whether Sequence numbering is to be used or not. The 179 remaining bits are reserved for future use. 181 Cookie Length - is a 1 Octet field that contains the length of the 182 Variable length Cookie. 184 Session ID - A 4 Octet field containing a non-zero identifier for a 185 session. The Session ID is used to delineate services on the egress 186 PE. The support for a service such as MPLS VPN MUST have at least 187 one Session ID assigned. Multiple Session ID's may be assigned for 188 the same service instance. The primary motivation for assigning 189 multiple Session ID's for the same service instance is provide a 190 graceful transition when changing cookie values. The egress PE can 191 receive both Session ID's with their unqiue Cookie value thus 192 allowing a graceful roll-over from an old Session ID and Cookie to a 193 new Session ID and Cookie. Alternatively, multiple service instances 194 may be distributed across multiple processes in order to scale. Each 195 service instance may be assigned a unique Session ID and Cookie and 196 advertised by BGP such that packets received from the ingress PE are 197 directed to the appropriate service instance on the egress PE. 199 Cookie - Cookie is a variable length (maximum 64 bits), value used by 200 L2TPv3 to check the association of a received data message with the 201 session identified by the Session ID. The Cookie value is tightly 202 coupled with the Session ID. Upon the generation of a Session ID by 203 the egress PE, the associated Cookie MAY be generated such that 204 packets received by the egress PE from an ingress PE can be quickly 205 validated for proper service context. 207 The default value of the Length Field for the L2TPv3 Tunnel 208 information TLV is between 8 and 16 bytes, depending on the length of 209 the Cookie field specified in Cookie length. If the length of the TLV 210 is greater than that value, the subsequent portion of the Value field 211 contains one or more sub-TLVs as defined in [BGP-SSA]. 213 3.2. mGRE Tunnel Information TLV 215 The mGRE Tunnel Information Type has a Type 2. The value part of the 216 mGRE Tunnel Information Type contains the following : 218 - Preference (2 Octets) 219 - Flags (1 Octet) 220 - mGRE Key (0 or 4 Octets) 222 The mGRE Tunnel Information TLV looks as follows : 224 0 1 225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |T| Type = 0x02 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Length (2 octets) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Preference (2 octets) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |S|K| Flags | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | mGRE Key (4 Octets) | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Length - A 2 Octet field that specifies the length of the mGRE 240 information in octets. The value contained in this Length field MUST 241 not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus 242 the total length of any prior TLVs. (This doesn't make sense to me. 243 What's the relationship between TLV's?) 245 Preference - A 2 Octet field containing a Preference associated with 246 the TLV. The Preference value indicates a preferred ordering of 247 tunneling encapsulations according to the sender (i.e. egress PE). 248 The recipient of the information (i.e. ingress PE) SHOULD take the 249 sender's preference into account in selecting which encapsulation it 250 will use. A higher value indicates a higher preference. 252 Flags - A 1 Octet field containing flag-bits. The leftmost bit 253 indicates whether Sequence numbering is to be used or not. The 2nd 254 bit Indicates whether an mGRE Key is present or not. The Remaining 255 bits are reserved for future use. 257 Reserved - A 1 Octet field reserved for future use 259 mGRE Key - A 4 Octet field containing an optional mGRE Key. The key 260 value may be generated by the egress PE and advertised by the egress 261 PE to any potential ingress PE. In this case, the key value has 262 unidirectional relevance from all viable ingress PE's to the egress 263 PE. Alternatively, the key value may be statically configured such 264 that all ingress and egress PE's use the same key value. 266 If the Length field of the TLV contains a value greater than 3 Octets 267 plus the value specified in the Key Length, the subsequent portion of 268 the Value field contains one or more sub-TLVs as defined by [BGP- 269 SSA]. 271 3.3. IPSec Tunnel Information TLV 273 The IPSec Tunnel Information Type has a Type 3. The value part of 274 the IPSec Tunnel Information Type contains the following : 276 - Preference (2 Octets) 277 - Flags (1 Octet) 278 - IKE ID Type (1 Octets) 279 - IKE ID Length (2 Octets) 280 - IKE Identifier (Variable) 282 The IPSec Tunnel Information TLV looks as follows : 284 0 1 285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |T| Type = 0x02 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Length (2 octets) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Preference (2 octets) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Flags | IKE_ID Type | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | IKE_LNG (2 Octets) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | IKE Identifier (Variable) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Length - A 2 Octet field that specifies the length of the IPSec 301 information in octets. The value contained in this Length field MUST 302 not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus 303 the total length of any prior TLVs. 305 Preference - A 2 Octet field containing a Preference associated with 306 the TLV. The Preference value indicates a preferred ordering of 307 tunneling encapsulations according to the sender. The recipient of 308 the information SHOULD take the sender's preference into account in 309 selecting which encapsulation it will use. A higher value indicates a 310 higher preference. 312 Flags - A 1 Octet field containing flag-bits. 314 IKE_ID Type - This 1 Octet field identifies the type of IKE 315 Identifier used by the egress PE 317 IKE_LNG - This 2 Octet field indicates the length of the IKE 318 Identifier. 320 IKE Identifier - A variable length field containing an IKE Identifier 321 of the egress PE. 323 If the Length field of the TLV contains a value greater than 11 324 Octets plus the value specified in the Key Length, the subsequent 325 portion of the Value field contains one or more sub-TLVs as defined 326 by [BGP-SSA]. 328 3.4. MPLS TLV 330 The MPLS TLV has a Type 4. The value part of the MPLS TLV contains 331 the following : 333 - Preference (2 Octets) 334 - Flags (1 Octet) 336 The MPLS Tunnel Information TLV looks as follows : 338 0 1 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |T| Type = 0x02 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Length (2 octets) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Preference (2 octets) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Flags | 348 +-+-+-+-+-+-+-+-+ 350 Length A 2 Octet field that specifies the length of the MPLS TLV in 351 octets. The value contained in this Length field MUST not exceed the 352 total length of the BGP SSA [BGP-SSA] Attribute minus the total 353 length of any prior TLVs. 355 Preference A 2 Octet field containing a Preference associated with 356 the TLV. The Preference value indicates a preferred ordering of 357 tunneling encapsulations according to the sender. The recipient of 358 the information SHOULD take the sender's preference into account in 359 selecting which encapsulation it will use. A higher value indicates a 360 higher preference. 362 Flags - A 1 Octet field containing flag-bits. 364 3.5. L2TPv3 in IPSEC TLV 366 When the value in the Type field is 5, the Value portion of the 367 SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an 368 L2TPv3 TLV. 370 3.5. mGRE in IPSEC TLV 372 When the value in the Type field is 6, the Value portion of the 373 SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an 374 mGRE TLV. 376 4. Capability Advertisement 378 A BGP speaker MAY participate in the distribution of the IPv4-Tunnel 379 SAFI or IPv6-Tunnel SAFI information. A BGP speaker that wishes to 380 exchange the IPv4-Tunnel SAFI or the IPv6 Tunnel SAFI, MUST use the 381 MP_EXT Capability Code as defined in [BGP-MP], to advertise the 382 corresponding (AFI, SAFI) pair. 384 5. Operation 386 A BGP Speaker that receives the Capability for the IPv4-Tunnel SAFI 387 or the IPv6-Tunnel SAFI, MAY advertise the IPv4-Tunnel SAFI or IPv6- 388 Tunnel SAFI prefixes to that peer. 390 The BGP SSA Attribute is defined only to be used in UPDATE messages 391 for the IPv4 tunnel SAFI or the IPv6 Tunnel SAFI. If the BGP SSA 392 Attribute is received in an UPDATE message for any other AFI/SAFI, it 393 MUST be ignored. 395 If a BGP Speaker receives an unrecognized Transitive Tunnel TLV as 396 part of the BGP SSA Attribute, it MUST accept it and propagate it to 397 other peers. 399 6. Deployment Considerations 401 In order for the Tunnels to come up between two end-points, the BGP 402 Speakers advertising the Tunnel end-points using the IPv4/IPv6 Tunnel 403 SAFI, MUST exchange at least one common encapsulation option. 405 7. Applicability 407 7.1. IPSec Tunnels Applicability 409 IPSec protection of IP routed packets requires the establishment of 410 an IPSec proxy that specifies the source and destination range of 411 addresses that require protection. The synchronization of the IPSec 412 proxy and the viability of the path to the destination IP address 413 range has been a persistent problem in the deploy of IPSec solutions. 414 The IPSec proxy must be associated with an IKE end-point identifier. 415 IPSec is inherently a tunneling protocol; however, it has no means of 416 synchronizing the viability of the destination path in the IPSec 417 proxy. One approach to synchronizing the IPSec proxy, the IKE end- 418 point and the path viability is to leverage BGP Tunnel SAFI. The BGP 419 protocol provides a means of distributing the destination address 420 range of the IPSec proxy via the NLRI. The IKE end-point identifier 421 may be consistent with the BGP next-hop and may be specified by the 422 TLVs in the BGP SSA Attribute [BGP-SSA] 423 in the BGP Tunnel SAFI. An IPSec end-point that receives a BGP 424 announcement may qualify the update and use the NLRI prefix as the 425 destination range in the IPSec proxy. The IPSec end-point may learn 426 the remote peer's IKE identity that is defined by the next-hop 427 attribute of the Tunnel SAFI. The route viability is Inherently 428 conveyed via the BGP protocol. The combination of the traditional IP 429 NLRI and the Tunnel NLRI allows IPSec to automatically establish the 430 connection attributes required to protect IP traffic between the two 431 end-points. 433 7.2. IP Tunnels Applicability 435 Multiprotocol Label Switching (MPLS) VPN introduced a peer-to-peer 436 model that enables large scale IP VPN implementations. Traditional 437 MPLS VPNs rely on an MPLS transport network to implement this peer- 438 to-peer model. 'MPLS VPN over IP Tunnels' reuses the same 439 functionality, but replaces the MPLS transport with an IP transport. 440 VPN traffic is carried by an IP tunnel instead of an MPLS Label 441 Switched Path (LSP). The VPN customer receives the same service 442 experience regardless of the transport choice used by the service 443 provider. 445 MPLS VPN uses the same mechanisms for VPN route distribution 446 regardless of the backbone transport choice (IP or MPLS). Customer 447 edge (CE) devices exchange routing information with the provider edge 448 (PE) devices using BGP or an Interior Gateway Protocol (IGP) 449 protocol. This routing information is exchanged between PEs using 450 Multi-Protocol BGP (MP-BGP). VPN routing information is carried by 451 MP-BGP as VPNv4 addresses. As part of this VPN route exchange, PEs 452 learn the nexthop (egress PE) and a VPN label to be associated with 453 each VPN route. 455 Before proper VPNv4 BGP next hop resolution can take place, each PE 456 needs to know which other PEs (i.e. Tunnel endpoints) are reachable 457 via the IP tunnel. 459 The Tunnel SAFI update messages provide a means of distributing the 460 Tunnel endpoint address as the NLRI in the Tunnel SAFI UPDATE. The 461 Tunnel endpoint address should be consistent with the BGP next-hop in 462 the VPNv4 update messages. This information is used to determine 463 which IP tunnel needs to be used for which VPNv4 prefixes. 465 In addition, each PE needs to know the tunnel attributes (used to 466 define this tunnel) that other PEs expect, so VPN packets can be 467 encapsulated appropriately. Manual configuration of this information 468 is not scalable, as the number of PEs increases. A PE that receives 469 the Tunnel SAFI update may use the tunnel NLRI prefix and the tunnel 470 attributes specified by the other end, and try and establish a tunnel 471 to that endpoint. PEs take advantage of the existing MP-BGP 472 infrastructure to distribute tunnel endpoint information. The Tunnel 473 SAFI UPDATE message is used to signal tunnel attribute and endpoint 474 information amongst PEs. And thus tunnel endpoint discovery is 475 accomplished using MP-BGP updates. 477 8. Security Considerations 479 This extension to BGP does not change the underlying security issues. 481 9. Acknowledgements 483 We would like to thank Jim Guichard, Francois LeFaucher for their 484 contribution. We would like to thank Arjun Sreekantiah, Shyam Suri, 485 Chandrashekhar Appanna, John Scudder and Mark Townsley for their 486 comments and suggestions. 488 10. References 490 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers 492 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace 494 [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol 495 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005. 497 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 498 BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. 500 [BGP-SSA] Kapoor R., Nalawade G., "BGPv4 SAFI-Specific Attribute", 501 draft-nalawade-kapoor-idr-bgp-ssa-01.txt, work in progress. 503 [MULTI-BGP] Bates et al, "Multiprotocol Extensions for BGP-4", draft- 504 ietf-idr-rfc2858bis-02.txt, work in progress. 506 11. Authors' Addresses 508 Gargi Nalawade 509 Cisco Systems, Inc 510 170 West Tasman Drive 511 San Jose, CA 95134 512 mailto:gargi@cisco.com 514 Ruchi Kapoor 515 Cisco Systems, Inc 516 170 West Tasman Drive 517 San Jose, CA 95134 518 mailto:ruchi@cisco.com 520 Dan Tappan 521 Cisco Systems, Inc 522 170 West Tasman Drive 523 San Jose, CA 95134 524 mailto:tappan@cisco.com 526 Scott Wainner 527 Cisco Systems, Inc 528 13600 Dulles Technology Drive 529 Herndon, VA 20171 530 mailto:swainner@cisco.com 532 12. Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementors or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights which may cover technology that may be required to practice 553 this standard. Please address the information to the IETF Executive 554 Director. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at ietf- 560 ipr@ietf.org. 562 13. Full Copyright Statement 564 Copyright (C) The Internet Society (2005). This document is subject 565 to the rights, licenses and restrictions contained in BCP 78, and 566 except as set forth therein, the authors retain all their rights." 568 "This document and the information contained herein are provided on 569 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 570 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 571 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 572 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 573 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 576 14. Expiration Date 578 This memo is filed as , and 579 expires January, 2006.