idnits 2.17.1 draft-ietf-idr-bgp-ipv6-rt-constrain-12.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5701], [RFC4684]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 date (April 26, 2018) is 2191 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) == Missing Reference: 'RFC 4684' is mentioned on line 19, but not defined == Unused Reference: 'RFC4271' is defined on line 171, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft Arrcus, Inc. 4 Intended status: Standards Track R. Raszuk 5 Expires: October 28, 2018 Bloomberg LP 6 M. Djernaes 7 Juniper Networks 8 J. Dong 9 M. Chen 10 Huawei Technologies 11 April 26, 2018 13 IPv6 Extensions for Route Target Distribution 14 draft-ietf-idr-bgp-ipv6-rt-constrain-12 16 Abstract 18 The current route target distribution specification as described in 19 [RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes. 20 The IPv6 specific Route Target extended community is defined in [RFC 21 5701] as length of 20 bytes. Since the current specification only 22 supports prefixes of maximum length of 12 bytes, the lack of an IPv6 23 specific Route Target reachability information may be a problem when 24 an operator wants to use this application in a pure IPv6 environment. 25 This document defines an extension that allows BGP to exchange longer 26 length IPv6 Route Target prefixes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted 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). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 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." 48 This Internet-Draft will expire on October 28, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. BGP IPv6 Constrained Route Target Capability . . . . . . . . 3 69 3. IPv6 Constrained Route Target NLRI Advertisements . . . . . . 3 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 75 7.2. Informative References . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 78 1. Introduction 80 The current constrained route distribution specification defined in 81 [RFC4684] supports prefixes with a maximum length of 12 bytes. The 82 prefix length needs to be extended to support the IPv6 specific Route 83 Target extended community defined in [RFC5701] which is 20 bytes in 84 length. This document defines an extension to the current 85 constrained route distribution specification that allows BGP speakers 86 to distribute longer length Route Target prefixes. A new BGP 87 capability known as BGP IPv6 Constrained Route Target capability is 88 defined as part of extension that allows an exchange of longer length 89 Route Target prefixes. BGP speakers that do not exchange this 90 capability MUST use Route Target NLRIs of maximum length of 12 bytes. 91 In this way, the current extension would preserve the backward 92 compatibility with [RFC4684]. 94 2. BGP IPv6 Constrained Route Target Capability 96 The "BGP IPv6 Constrained Route Target Capability" is a new BGP 97 capability [RFC5492]. The Capability code for this capability is 98 specified in the IANA Considerations section of this document. The 99 Capability length field of this capability is zero. 101 By advertising this capability to a peer, a BGP speaker conveys to 102 the peer that the speaker support the longer length Route Target 103 prefixes and the related procedures described in this document. 105 3. IPv6 Constrained Route Target NLRI Advertisements 107 Route Target membership NLRI is advertised in BGP UPDATE messages 108 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in 109 [RFC4760]. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI 110 is a prefix of 0 to 24 octets, encoded as defined in Section 4 of 111 [RFC4760] for all the constrained route distribution. 113 This prefix is structured as follows: 115 +-------------------------------+ 116 | origin as (4 octets) | 117 +-------------------------------+ 118 | route target (8 or 20 octets)| 119 ~ ~ 120 | | 121 +-------------------------------+ 123 Except for the default route target, which is encoded as a zero- 124 length prefix, the minimum prefix length is 32 bits. As the origin- 125 AS field cannot be interpreted as a prefix. 127 Route targets can then be expressed as prefixes, where, for instance, 128 a prefix would encompass all route target extended communities 129 assigned by a given Global Administrator [RFC4360] and [RFC5701]. 130 Alternatively, route target prefixes could be aggregated however if 131 done so, then only the Local Administrator field of the Route Target 132 can be aggregated. Route Target Type and the Global Administrator 133 Route Target fields MUST not be aggregated. 135 The default route target can be used to indicate to a peer the 136 willingness to receive all VPN route advertisements such as, for 137 instance, the case of a route reflector speaking to one of its PE 138 router clients. 140 4. IANA Considerations 142 IANA is requested to assign one new code point for "IPv6 Constrained 143 Route Target Capability" from the "First Come First Served" range of 144 BGP "Capability Codes" registry. 146 +-------+------------------------------------------+----------------+ 147 | Value | Description | Reference | 148 +-------+------------------------------------------+----------------+ 149 | TBA | IPv6 Constrained Route Target Capability | [this document]| 150 +-------+------------------------------------------+----------------+ 152 5. Security Considerations 154 This extension to [RFC4684] does not change the underlying security 155 issues inherent in the existing BGP and [RFC4684]. 157 6. Acknowledgements 159 The authors would like to thank Pedro Marques, John Scudder, Alton Lo 160 and Zhenqiang Li for discussions and review. 162 7. References 164 7.1. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, 168 DOI 10.17487/RFC2119, March 1997, 169 . 171 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 172 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 173 DOI 10.17487/RFC4271, January 2006, 174 . 176 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 177 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 178 February 2006, . 180 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 181 R., Patel, K., and J. Guichard, "Constrained Route 182 Distribution for Border Gateway Protocol/MultiProtocol 183 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 184 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 185 November 2006, . 187 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 188 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 189 2009, . 191 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 192 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 193 . 195 7.2. Informative References 197 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 198 "Multiprotocol Extensions for BGP-4", RFC 4760, 199 DOI 10.17487/RFC4760, January 2007, 200 . 202 Authors' Addresses 204 Keyur Patel 205 Arrcus, Inc. 206 USA 208 Email: keyur@arrcus.com 210 Robert Raszuk 211 Bloomberg LP 212 731 Lexington Ave 213 New York City, NY 10022 214 USA 216 Email: robert@raszuk.net 218 Martin Djernaes 219 Juniper Networks 220 1194 N. Mathilda Avenue 221 Sunnyvale, CA 94089 222 USA 224 Email: mdjernaes@juniper.net 225 Jie Dong 226 Huawei Technologies 227 Huawei Campus, No.156 Beiqing Rd. 228 Beijing 100095 229 China 231 Email: jie.dong@huawei.com 233 Mach(Guoyi) Chen 234 Huawei Technologies 235 Huawei Campus, No.156 Beiqing Rd. 236 Beijing 100095 237 China 239 Email: mach.chen@huawei.com