idnits 2.17.1 draft-ietf-idr-bgp-ipv6-rt-constrain-00.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 == 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: Route targets can then be expressed as prefixes, where, for instance, a prefix would encompass all route target extended communities assigned by a given Global Administrator [RFC4360] and [RFC5701]. Alternatively, route target prefixes could be aggregated however if done so, then only the Local Administrator field of the Route Target can be aggregated. Route Target Type and the Global Administrator Route Target fields MUST not be aggregated. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 13, 2011) is 4694 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) == Unused Reference: 'RFC4271' is defined on line 175, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group K. Patel 3 Internet-Draft R. Raszuk 4 Intended status: Standards Track Cisco Systems 5 Expires: December 15, 2011 M. Djernaes 6 Juniper Networks 7 J. Dong 8 M. Chen 9 Huawei Technologies Co., Ltd. 10 June 13, 2011 12 IPv6 Extensions for Route Target Distribution 13 draft-ietf-idr-bgp-ipv6-rt-constrain-00.txt 15 Abstract 17 The current route target distribution specification described in 18 RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes. 19 The IPv6 specific Route Target extended community is defined in 20 RFC5701 as length of 20 bytes. Since the current specification only 21 supports prefixes of maximum length of 12 bytes, the lack of an IPv6 22 specific Route Target reachability information may be a problem when 23 an operator wants to use this application in a pure IPv6 environment. 24 This document defines an extension that allows BGP to exchange longer 25 length IPv6 Route Target prefixes. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 15, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 75 2. BGP IPV6 Constrained Route Target Capability . . . . . . . . . 4 76 3. IPV6 Constrained Route Target NLRI Advertisements . . . . . . . 4 77 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 85 1. Introduction 87 The current constrained route distribution specification defined in 88 [RFC4684] supports prefixes with a fixed maximum length of 12 bytes. 89 The prefix length needs to be extended to support the IPv6 specific 90 Route Target extended community defined in [RFC5701] which is 20 91 bytes in length. 93 This document defines an extension to the current constrained route 94 distribution specification that allows BGP speakers to distribute 95 longer length Route Target prefixes. A new BGP capability known as 96 BGP IPv6 Constrained Route Target capabiltiy is defined as part of 97 extension that allows an exchange of longer length Route Target 98 prefixes. BGP speakers that do not exchange this capability MUST use 99 Route Target NLRIs of maximum length of 12 bytes. In this way, the 100 current extension would preserve the backward compatibility with 101 [RFC4684]. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. BGP IPV6 Constrained Route Target Capability 111 The "BGP IPV6 Constrained Route Target Capability" is a new BGP 112 capability [RFC5492]. The Capability code for this capability is 113 specified in the IANA Considersations section of this document. The 114 Capability length field of this capability is zero. 116 By advertising this capability to a peer, a BGP speaker conveys to 117 the peer that the speaker support the longer length Route Target 118 prefixes and the related procedures described in this document. 120 3. IPV6 Constrained Route Target NLRI Advertisements 122 Route Target membership NLRI is advertised in BGP UPDATE messages 123 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in 124 [RFC4760]. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI 125 is a prefix of 0 to 24 octets, encoded as defined in Section 4 of 126 [RFC4760] for all the constrain route distribution. 128 This prefix is structured as follows: 130 +-------------------------------+ 131 | origin as (4 octets) | 132 +-------------------------------+ 133 | route target (8 or 20 octets)| 134 ~ ~ 135 | | 136 +-------------------------------+ 138 Except for the default route target, which is encoded as a zero- 139 length prefix, the minimum prefix length is 32 bits. 141 Route targets can then be expressed as prefixes, where, for instance, 142 a prefix would encompass all route target extended communities 143 assigned by a given Global Administrator [RFC4360] and [RFC5701]. 144 Alternatively, route target prefixes could be aggregated however if 145 done so, then only the Local Administrator field of the Route Target 146 can be aggregated. Route Target Type and the Global Administrator 147 Route Target fields MUST not be aggregated. 149 The default route target can be used to indicate to a peer the 150 willingness to receive all VPN route advertisements such as, for 151 instance, the case of a route reflector speaking to one of its PE 152 router clients. 154 4. Acknowledgements 156 The authors would like to thank Pedro Marques, John Scudder, Alton Lo 157 and Zhengqiang Li for discussions and review. 159 5. IANA Considerations 161 This document defined the IPV6 Constrained Route Target Capability 162 for BGP. The Capability code needs to be assigned by the IANA. 164 6. Security Considerations 166 This extension to [RFC4684] does not change the underlying security 167 issues inherent in the existing BGP and [RFC4684]. 169 7. References 170 7.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 176 Protocol 4 (BGP-4)", RFC 4271, January 2006. 178 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 179 Communities Attribute", RFC 4360, February 2006. 181 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 182 R., Patel, K., and J. Guichard, "Constrained Route 183 Distribution for Border Gateway Protocol/MultiProtocol 184 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 185 Private Networks (VPNs)", RFC 4684, November 2006. 187 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 188 with BGP-4", RFC 5492, February 2009. 190 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 191 Attribute", RFC 5701, November 2009. 193 7.2. Informative References 195 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 196 "Multiprotocol Extensions for BGP-4", RFC 4760, 197 January 2007. 199 Authors' Addresses 201 Keyur Patel 202 Cisco Systems 203 170 W. Tasman Drive 204 San Jose, CA 95134 205 USA 207 Email: keyupate@cisco.com 208 Robert Raszuk 209 Cisco Systems 210 170 W. Tasman Drive 211 San Jose, CA 95134 212 USA 214 Email: raszuk@cisco.com 216 Martine Djernaes 217 Juniper Networks 218 1194 N. Mathilda Avenue 219 Sunnyvale, CA 94089 220 USA 222 Email: mdjernaes@juniper.net 224 Jie Dong 225 Huawei Technologies Co., Ltd. 226 Huawei Building, No.3 Xinxi Rd. 227 Hai-Dian District, Beijing 100085 228 P.R. China 230 Email: jie.dong@huawei.com 232 Mach(Guoyi) Chen 233 Huawei Technologies Co., Ltd. 234 Huawei Building, No.3 Xinxi Rd. 235 Hai-Dian District, Beijing 100085 236 P.R. China 238 Email: mach.chen@huawei.com