idnits 2.17.1 draft-ietf-l3vpn-v6-ext-communities-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4360], [RFC2119]), 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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.) -- 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Juniper Networks 4 Expiration Date: June 2009 5 Intended Status: Proposed Standard 7 IPv6 Address Specific BGP Extended Communities Attribute 9 draft-ietf-l3vpn-v6-ext-communities-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright and License Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 This document may contain material from IETF Documents or IETF 43 Contributions published or made publicly available before November 44 10, 2008. The person(s) controlling the copyright in some of this 45 material may not have granted the IETF Trust the right to allow 46 modifications of such material outside the IETF Standards Process. 47 Without obtaining an adequate license from the person(s) controlling 48 the copyright in such materials, this document may not be modified 49 outside the IETF Standards Process, and derivative works of it may 50 not be created outside the IETF Standards Process, except to format 51 it for publication as an RFC or to translate it into languages other 52 than English. 54 Abstract 56 Current specifications of BGP Extended Communities [RFC4360] support 57 IPv4 Address Specific Extended Community, but do not support IPv6 58 Address Specific Extended Community. The lack of IPv6 Address 59 Specific Extended Community may be a problem when an application uses 60 IPv4 Address Specific Extended Community, and one wants to use this 61 application in a pure IPv6 environment. This document defines a new 62 BGP attribute, IPv6 Address Specific Extended Community that 63 addresses this problem. The IPv6 Address Specific Extended Community 64 is similar to the IPv4 Address Specific Extended Community, except 65 that it carries an IPv6 address rather than an IPv4 address. 67 Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 1. Introduction 75 Current specifications of BGP Extended Communities [RFC4360] support 76 IPv4 Addres Specific Extended Community, but do not support IPv6 77 Address Specific Extended Community. The lack of IPv6 Address 78 Specific Extended Community may be a problem when an application uses 79 IPv4 Address Specific Extended Community, and one wants to use this 80 application in a pure IPv6 environment. 82 Because the BGP Extended Community attribute defines each BGP 83 Extended Community as being 8 octets long, it is not possible to 84 define the IPv6 Specific Extended Community using the existing BGP 85 Extended Community attribute [RFC4360]. Therefore this document 86 defines a new BGP attribute, IPv6 Address Specific Extended Community 87 that has structure similar to the IPv4 Address Specific Extended 88 Community, and thus could be used in a pure IPv6 environment as a 89 replacement of the IPv4 Address Specific Extended Community. 91 2. IPv6 Address Specific BGP Extended Communities Attribute 93 The IPv6 Address Specific Extended Communities Attribute is a 94 transitive optional BGP attribute [BGP-4]. The attribute consists of 95 a set of "IPv6 Address Specific extended communities". All routes 96 with the IPv6 Address Specific Extended Communities attribute belong 97 to the communities listed in the attribute. 99 Just like all other BGP extended communities, the IPv6 Address 100 Specific extended community supports multiple Sub-types. 102 Each IPv6 Address Specific extended community is encoded as a twenty 103 octets quantity, as follows: 105 0 1 2 3 106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | 0x00 or 0x40 | Sub-Type | Global Administrator | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Global Administrator (cont.) | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Global Administrator (cont.) | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Global Administrator (cont.) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Global Administrator (cont.) | Local Administrator | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 The first high-order octet indicates whether a particular Sub-type of 121 this community is transitive across ASes (0x00), or not (0x40). The 122 second high-order octet of this extended type is used to indicate 123 Sub-types. The Sub-types are the same as for IPv4 Address Specific 124 extended community. 126 Global Administrator field: 16 octets 128 This field contains an IPv6 unicast address assigned by one of 129 the Internet registries. 131 Local Administrator: 2 octets 133 The organization which has been assigned the IPv6 address in 134 the Global Administrator field, can encode any information in 135 this field. The format and meaning of this value encoded in 136 this field should be defined by the sub-type of the community. 138 3. IANA Considerations 140 This document defines a new BGP attribute, called IPv6 Address Spe- 141 cific Extended Community. 143 This document defines a class of extended communities called IPv6 144 Address Specific extended community for which the IANA is to create 145 and maintain a registry entitled "IPv6 Address Specific Extended Com- 146 munity". Future assignment are to be made using the "First Come 147 First Served" policy defined in [RFC5226]. The Type values for the 148 transitive communities of the IPv6 Address Specific Extended Commu- 149 nity class are 0x0000-0x00ff, and for the non-transitive communities 150 of that class are 0x4000-0x40ff. Assignments consist of a name and 151 the value. 153 This document makes the following assignments for the IPv6 Address 154 Specific extended community types: 156 Name Type Value 157 ---- -------------- 158 IPv6 address specific Route Target 0x0002 159 IPv6 address specific Route Origin 0x0003 161 4. Security Considerations 163 All the security considerations for BGP Extended Communities apply 164 here. 166 5. Acknowledgements 168 Many thanks to Michael Lundberg and Emre Ertekin for their review and 169 comments. 171 6. Normative References 173 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 174 (BGP-4)", RFC 4271, January 2006 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 180 Considerations Section in RFCs", RFC5226, May 2008. 182 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Com- 183 munities Attribute", RFC 4360, February 2006. 185 7. Non-normative References 187 8. Author Information 189 Yakov Rekhter 190 Juniper Networks, Inc. 191 e-mail: yakov@juniper.net