idnits 2.17.1 draft-ietf-l3vpn-mvpn-infra-addrs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (July 6, 2011) is 4649 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 informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Rahul Aggarwal 3 Internet Draft Juniper Networks, Inc. 4 Intended Status: Proposed Standard 5 Updates: draft ietf-l3vpn-2547bis-mcast-bgp-08.txt Eric C. Rosen 6 Expires: January 6, 2012 Cisco Systems, Inc. 8 July 6, 2011 10 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN 12 draft-ietf-l3vpn-mvpn-infra-addrs-05.txt 14 Abstract 16 To provide Multicast VPN (MVPN) service, Provider Edge routers 17 originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") 18 BGP routes; they also originate unicast VPN routes that carry MVPN- 19 specific attributes. These routes encode addresses from the 20 customer's address space, as well as addresses from the provider's 21 address space. These two address spaces are independent, and the 22 address family (IPv4 or IPv6) of the two spaces may or may not be the 23 same. These routes always contain an "address family" field that 24 specifies whether the customer addresses are IPv4 addresses or 25 whether they are IPv6 addresses. However, there is no field that 26 explicitly specifies the address family of the provider addresses. 27 To ensure interoperability, this document specifies that provider 28 IPv4 addresses are always encoded in these update messages as four- 29 octet addresses, and that the distinction between IPv4 and IPv6 is 30 signaled solely by the length of the address field. Specific cases 31 are explained in detail. This document updates draft-ietf- 32 l3vpn-2547bis-mcast-bgp-08.txt. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Copyright and License Notice 57 Copyright (c) 2011 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1 Introduction .......................................... 4 73 1.1 Specification of requirements ......................... 4 74 1.2 Acronyms Used in this Document ........................ 4 75 1.3 IPv4 and IPv6 Addresses in MCAST-VPN Routes ........... 5 76 2 PE Addresses in MCAST-VPN Routes ...................... 6 77 3 VRF Route Import Extended Community ................... 7 78 4 PMSI Tunnel Attributes in I-PMSI A-D Routes ........... 7 79 4.1 Relationship to AFI Value ............................. 7 80 4.2 Relationship to Next Hop Address Family ............... 8 81 5 IANA Considerations ................................... 8 82 6 Security Considerations ............................... 8 83 7 Acknowledgments ....................................... 8 84 8 Authors' Addresses .................................... 9 85 9 Normative References .................................. 9 86 10 Informational References .............................. 9 87 1. Introduction 89 1.1. Specification of requirements 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 1.2. Acronyms Used in this Document 97 This document uses a number of acronyms, mostly taken directly from 98 the BGP and VPN specifications. 100 - A-D Route: Auto-Discovery Route [MVPN] 102 - AFI: Address Family Identifier [BGP-MP] 104 - AS: Autonomous System [BGP] 106 - I-PMSI: Inclusive PMSI [RFC4364] 108 - MCAST-VPN: Multicast Virtual Private Network [MVPN-BGP] 110 - MP_REACH_NLRI: Multiprotocol Reachable NLRI [BGP-MP] 112 - MP_UNREACH_NLRI; Multiprotocol Unreachable NLRI [BGP-MP] 114 - PMSI: Provider Multicast Service Interface [MVPN] 116 - NLRI: Network Layer Reachability Information [BGP] 118 - PE: Provider Edge [RFC4364] 120 - S-PMSI: Selective PMSI [RFC4364] 122 - SAFI: Subsequent Address Field Identifier [BGP-MP] 124 - SP: Service Provider 126 1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes 128 [MVPN-BGP] defines a new set of BGP route types that are used by SPs 129 to provide Multicast Virtual Private Network service to their 130 customers. These routes have a newly defined BGP NLRI, the "MCAST- 131 VPN" NLRI. MCAST-VPN NLRI is carried in the NLRI field of the 132 MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP]. The 133 SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to 134 identify the NLRI as being an MCAST-VPN NLRI. 136 When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has 137 the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2. 138 AFI 1 indicates that any customer multicast addresses occurring in 139 the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2 140 indicates that any such addresses are IPv6 addresses. 142 However, some of the MCAST-VPN routes also contain addresses of PE 143 routers in the SP network. An SP with an IPv4 network may provide 144 MVPN service for customers that use IPv6, and an SP with an IPv6 145 network may provide MVPN service for customers that use IPv4. 146 Therefore the address family of the PE addresses MUST NOT be inferred 147 from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI 148 attribute. 150 The purpose of this document is to make it clear that whenever a PE 151 address occurs in an MCAST-VPN route (whether in the NLRI or in an 152 attribute), the IP address family of that address is determined by 153 the length of the address (a length of 4 octets for IPv4 addresses, a 154 length of 16 octets for IPv6 addresses), NOT by the AFI field of the 155 route. 157 In particular, if a SP with an IPv4 core network is providing 158 MVPN/IPv6 service to a customer, the PE addresses in the MCAST-VPN 159 routes will be four-octet IPv4 routes, even though the AFI of those 160 routes will have the value 2. 162 Some previous specifications (e.g., [RFC4659] and [RFC4798]) have 163 taken a different approach, requiring that in any routes containing 164 IPv6 or VPN-IPv6 customer addresses, the IPv4 PE addresses be 165 represented as IPv6-mapped IPv4 addresses [RFC4291]. This document 166 does not use that approach. Rather, this specification uses the 167 approach adopted in [RFC4684] and [RFC5549]. The MCAST-VPN routes 168 contain enough information to enable the IP address family of the PE 169 addresses to be inferred from the address lengths. 171 [MVPN-BGP] also defines an attribute, the "VRF Route Import Extended 172 Community", that is attached to unicast VPN-IPv4 or VPN-IPv6 routes. 173 This extended community contains a PE address, and this document 174 specifies how to encode an IPv6 address in this attribute, 175 independent of whether the attribute is attached to a VPN-IPv4 route 176 or a VPN-IPv6 route. 178 This document also clarifies an issue with respect to the 179 significance of the Address Family field of an Intra-AS I-PMSI A-D 180 route that carries a PMSI Tunnel Attribute. 182 2. PE Addresses in MCAST-VPN Routes 184 PE addresses occur in MCAST-VPN routes in the following places: 186 1. "Network Address of Next Hop" field in the MP_REACH_NLRI 187 attribute, as defined in section 3 of [BGP-MP]. This field is 188 preceded by a "length of next hop address" field. Hence it is 189 always clear whether the address is an IPv4 address (length is 190 4) or an IPv6 address (length is 16). If the length of next 191 hop address is neither 4 nor 16, the MP_REACH_NLRI attribute 192 MUST be considered to be "incorrect", and MUST be handled as 193 specified in section 7 of [BGP-MP]. 195 2. "Intra-AS I-PMSI A-D route", defined in section 4.1 of [MVPN- 196 BGP]. All MCAST-VPN routes begin with a one-octet route type 197 field, followed by a one-octet "NLRI length" field. In the 198 Intra-AS I-PMSI A-D route, the length is followed by an 8-octet 199 RD, which is then followed by the "Originating Router's IP 200 Address" field. The length of this field (4 octets for IPv4 or 201 16 octets for IPv6 can thus be inferred from the NLRI length 202 field (which will be either 12 or 24, respectively). If the 203 inferred length of the "Originating Router's IP Address" field 204 is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be 205 considered to be "incorrect", and MUST be handled as specified 206 in section 7 of [BGP-MP]. 208 3. "S-PMSI A-D Route", defined in section 4.3 of [MVPN-BGP]. In 209 this route, the "NLRI length" field is followed by an 8-octet 210 RD, a variable length "multicast source" field, a variable 211 length "multicast group" field, and an "Originating Router's IP 212 Address" field. The two variable length fields have their own 213 length fields. From these two length fields and the NLRI 214 length field, one can compute the length of the "Originating 215 Router's IP Address" field, which again is either 4 for IPv4 or 216 16 for IPv6. If the computed length of the "Originating 217 Router's IP Address" field is neither 4 nor 16, the 218 MP_REACH_NLRI attribute MUST be considered to be "incorrect", 219 and MUST be handled as specified in section 7 of [BGP-MP]. 221 4. "Leaf A-D Route", defined in section 4.4 of [MVPN-BGP]. In 222 this route, the "NLRI length" field is following by a variable 223 length "route key", which is followed by the "Originating 224 Router's IP Address" field. The Route Key has its own length 225 field. From the NLRI length and the route key length, one can 226 compute the length of the "Originating Router's IP Address" 227 field. If the computed length of the "Originating Router's IP 228 Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute 229 MUST be considered to be "incorrect", and MUST be handled as 230 specified in section 7 of [BGP-MP]. 232 3. VRF Route Import Extended Community 234 The "VRF Route Import Extended Community", specified in [MVPN-BGP], 235 is an attribute carried by unicast VPN-IPv4 or VPN-IPv6 routes. It 236 is an "IPv4 Address Specific Extended Community" of type "VRF Route 237 Import"; hence it can only carry an IPv4 address. To carry an IPv6 238 address, an "IPv6 Address Specific Extended Community" [RFC5701], of 239 type "VRF Route Import", must be used. A codepoint for this type of 240 extended community will be allocated by IANA. 242 4. PMSI Tunnel Attributes in I-PMSI A-D Routes 244 When a PMSI Tunnel Attribute occurs in an I-PMSI A-D route originated 245 by a particular PE or ASBR, it identifies a tunnel that the PE/ASBR 246 uses by default for carrying the multicast traffic of a particular 247 customer MVPN. The proper encoding and interpretation of the PMSI 248 Tunnel attribute is affected by both the AFI and "Network Address of 249 Next Hop" fields. 251 4.1. Relationship to AFI Value 253 When the PMSI Tunnel Attribute occurs in a BGP Update message with a 254 MP_REACH_NLRI attribute whose AFI is 1, the meaning is that the 255 identified tunnel is used by default to carry IPv4 MVPN traffic for a 256 particular customer MVPN. When the PMSI Tunnel Attribute occurs in a 257 BGP Update message with a MP_REACH_NLRI attribute whose AFI is 2, the 258 meaning is that the identified tunnel is used by default to carry 259 IPv6 MVPN traffic for a particular customer MVPN. To assign both 260 IPv4 and IPv6 MVPN traffic to an I-PMSI tunnel, two I-PMSI A-D routes 261 MUST be used, one whose MP_REACH_NLRI has an AFI of 1, and one whose 262 MP_REACH_NLRI has an AFI of 2. To use the same tunnel for both IPv4 263 and IPv6 traffic, the same value of the PMSI Tunnel attribute can be 264 used in each route. 266 4.2. Relationship to Next Hop Address Family 268 If the "Network Address of Next Hop" field in the MP_REACH_NLRI 269 attribute contains an IPv4 address, then any IP addresses appearing 270 in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be 271 IPv4 addresses. 273 If the "Network Address of Next Hop" field in the MP_REACH_NLRI 274 attribute contains an IPv6 address, then any IP addresses appearing 275 in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be 276 IPv6 addresses. 278 If these conditions are not met, the PMSI Tunnel Attribute MUST be 279 handled as a "malformed" PMSI Tunnel Attribute, as specified in 280 section 5 [MVPN-BGP]. 282 5. IANA Considerations 284 IANA is requested to assign a codepoint for "VRF Route Import" in the 285 "IPv6 Address Specific Extended Community" registry. The codepoint 286 should be assigned from the "transitive communities" portion of the 287 namespace. We suggest assignment of the value 0x000b (to correspond 288 to the value that is already assigned for "VRF Route Import" in the 289 "IPv4 Address Specific Extended Community" registry). The references 290 should be to this document and to [MVPN-BGP]. 292 6. Security Considerations 294 This document does not raise any security considerations beyond those 295 raised by [MVPN-BGP]. 297 7. Acknowledgments 299 The authors wish to thank Dongling Duan, Keyur Patel, Yakov Rekhter, 300 and Karthik Subramanian. 302 8. Authors' Addresses 304 Rahul Aggarwal 305 Juniper Networks 306 1194 North Mathilda Ave. 307 Sunnyvale, CA 94089 308 Email: rahul@juniper.net 310 Eric C. Rosen 311 Cisco Systems, Inc. 312 1414 Massachusetts Avenue 313 Boxborough, MA, 01719 314 E-mail: erosen@cisco.com 316 9. Normative References 318 [BGP] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 4 319 (BGP-4)", Y. Rekhter, T. Li, S. Hares, RFC 4271, January 2006 321 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra, 322 D. Katz, Y. Rekhter, RFC 4760, January 2007 324 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP 325 VPNs", draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 327 [MVPN-BGP], "BGP Encodings and Procedures for Multicast in MPLS/BGP 328 IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter, 329 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, October 2009 331 [RFC2119] "Key words for use in RFCs to Indicate Requirement 332 Levels.", Bradner, March 1997 334 10. Informational References 336 [RFC4291] "IP Version 6 Addressing Architecture", R. Hinden, S. 337 Deering, RFC 4291, February 2006. 339 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", E. Rosen, Y. 340 Rekhter, RFC4364, February 2006 342 [RFC4659] "BGP-MPLS IP Virtual Private Network (VPN) Extension for 343 IPv6 VPN", J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. RFC 344 4659, September 2006 346 [RFC4798] "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 347 Edge Routers (6PE)", J. De Clercq, D. Ooms, S. Prevost, F. Le 348 Faucheur. RFC 4798, February 2007 350 [RFC4684] "Constrained Route Distribution for Border Gateway 351 Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol 352 (IP) Virtual Private Networks (VPNs)", P. Marques, R. Bonica, L. 353 Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. RFC 4684 November 354 2006 356 [RFC5549] "Advertising IPv4 Network Layer Reachability Information 357 with an IPv6 Next Hop" F. Le Faucheur, E. Rosen. RFC 5549, May 2009 359 [RFC5701] "IPv6 Address Specific BGP Extended Community Attribute" Y. 360 Rekhter. RFC 5701, November 2009