idnits 2.17.1 draft-uijterwaal-rpsl-4byteas-ext-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 295. 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 Copyright Line does not match the current year -- 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.) -- The document date (September 3, 2007) is 6079 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission H. Uijterwaal 3 Internet-Draft K. Petrusha 4 Intended status: Standards Track RIPE NCC 5 Expires: March 6, 2008 September 3, 2007 7 RPSL extensions for 32 bit AS Numbers 8 draft-uijterwaal-rpsl-4byteas-ext-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 6, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies extensions to the RPSL language for dealing 42 with 32 bit (4 byte) AS numbers. It also gives a list of RPSL 43 attributes that will be affected by this change and that may require 44 tools to be updated. 46 1. Introduction 48 Four byte (32 bit) AS numbers (ASN32) are defined in [as4bytes]. 49 This document does not specify a format to represent these numbers. 50 A separate document [asn32rep] proposes to represent them as: 52 . 55 This format allows users to easily distinguish 16 and 32 bit ASN. 57 RPSL (Routing Policy Specification Language) ([RFC2622] and 58 [RFC4012]) uses the format "ASx" for an AS, with x a 1 to 5 digit 59 number in the range 0 to 65535. RPSL was defined before the 60 introduction of 32 bit AS numbers (ASN32). 62 Deployment of ASN32 will start early 2007 [asn32d]. To use these 63 numbers in RPSL, the RPSL standard will have to be updated to allow 64 for ASN32. This document defines the necessary extensions to the 65 RPSL standard. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Proposal 73 The terms "2-byte only AS Numbers" and "4-byte AS numbers" are 74 defined in [asn32rep]. Following this document, the field in [RFC2622] (section 2) will be replaced by: 77 An is a string that can be either: 79 * ASx, for 2-byte only AS numbers, or 80 * ASy.z for 4-byte AS Numbers, with x and y using the same format 81 as [asn32rep]. 82 x, y and z are integer numbers in the range 0 to 65535. If y 83 equals 0, it and the following "." MUST both be dropped. An 84 application MAY accept a string with y equal to 0 as input. 86 Similar, following [asn32rep] and [RFC2622], the definition of a 87 community specification will be replaced by: 89 An community specification is a string that can be either: 91 * x:N, for 2-byte only AS numbers, or 92 * y.z:N for 4-byte AS Numbers, with x and y using the same format 93 as [asn32rep]. 94 x, y, z and N are integer numbers in the range 0 to 65535. If y 95 equals 0, it and the following "." MUST both be dropped. An 96 application MAY accept a string with y equal to 0 as input. 98 No other changes to the RPSL standard will be made. 100 2.1. Background 102 The proposed format ("ASx.y") for RPSL uses the same format for ASN32 103 as had been proposed for other representations of ASN32. This will 104 allow for an easy conversion of data between RPSL-based tools and 105 other tools. 107 The format also has the advantage that the number of RPSL attributes 108 will not change. Proposals based on the RPSL language extension 109 mechanism will all result in adding a large number of new attributes 110 to RPSL. 112 Changing the format of existing attributes has the disadvantage that 113 the code parsing RPSL data of existing tools will have to be reviewed 114 and updated to allow for the new format. However, this is something 115 that has to be done anyway when ASN32 are introduced, as it is a 116 priori not clear whether code can handle ASN values larger than 2^16. 118 2.2. Examples 120 AS3333 refers to the AS with identifier 3333. AS0.3333 refers to the 121 same AS but this notation should not be used. An identifier of 122 AS65536 is not valid, even though the identifier can be expressed in 123 a 32 bit integer. This AS should be referred to as AS1.0. 125 3. RPSL Attributes affected by this change 127 The following table lists RPSL attributes that will be affected by 128 this change. It is intended as a check-list for developpers updating 129 their tools. In this table: 131 o A: the AS syntax used in this attribute has changed 132 o C: the community value syntax used in this attribute has changed 133 +--------------+-------------+----+-----------+ 134 | Object-type | Attribute | AS | Community | 135 +--------------+-------------+----+-----------+ 136 | route: | aggr-bndry | A | | 137 | | aggr-mtd | A | | 138 | | components | A | C | 139 | | inject | A | C | 140 | | member-of | A | | 141 | | origin | A | | 142 | route6: | aggr-bndry | A | | 143 | | aggr-mtd | A | | 144 | | components | A | C | 145 | | inject | A | C | 146 | | member-of | A | | 147 | | origin | A | | 148 | aut-num: | aut-num | A | | 149 | | default | A | C | 150 | | export | A | C | 151 | | import | A | C | 152 | | mp-default | A | C | 153 | | mp-export | A | C | 154 | | mp-import | A | C | 155 | | member-of | A | | 156 | as-set: | as-set | A | | 157 | | members | A | | 158 | inet-rtr: | local-as | A | | 159 | | interface | A | C | 160 | | ifaddr | A | C | 161 | | peer | A | | 162 | | mp-peer | A | | 163 | | member-of | A | | 164 | filter-set: | filter-set | A | | 165 | | filter | A | C | 166 | | mp-filter | A | C | 167 | rtr-set: | rtr-set | A | | 168 | | members | A | | 169 | | mp-members | A | | 170 | route-set: | route-set | A | | 171 | | members | A | | 172 | | mp-members | A | | 173 | peering-set: | peering-set | A | | 174 | | mp-peering | A | | 175 | | peering | A | | 176 | as-block: | as-block | A | | 177 +--------------+-------------+----+-----------+ 179 4. Security Considerations 181 Many systems will treat strings "xxx.yyy" as real number values and 182 convert this internally to floating point numbers. One must take 183 care that this will not happen. 185 Systems may use unsigned 16-bit integers for the internal 186 representation of AS numbers. It should be checked that tools 187 internally use (at least) an unsigned 32-bit number for ASN. 189 Parsing ASN32 based communities attributes will result in longer byte 190 strings. It should be checked that tools internally have sufficient 191 memory allocated to store these strings. One possibility is to use 192 the extensions to the 8 octet AS Extended Communities [RFC4360] 193 proposed in A DRAFT THAT HAS EXPIRED BUT WILL BE REVIVED. 195 5. IANA Considerations 197 None. (This section may be removed on publication as an RFC.) 199 6. Acknowledgements 201 The authors would like to thank James Aldridge, Denis Walker and Rene 202 Wilhelm for their feedback on this draft. 204 7. References 206 7.1. Normative references 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 212 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 213 "Routing Policy Specification Language (RPSL)", RFC 2622, 214 June 1999. 216 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 217 "Routing Policy Specification Language next generation 218 (RPSLng)", RFC 4012, March 2005. 220 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 221 Communities Attribute", RFC 4360, February 2006. 223 [as4bytes] 224 Chen, E. and Q. Vohra, "BGP Support for Four-octet AS 225 Number Space (draft-ietf-idr-as4bytes, work in 226 progress).". 228 [asn32rep] 229 Michaelson, G., "Canonical representation of 4-byte AS- 230 numbers (draft-michaelson-4byte-as-representation, work in 231 progress).". 233 7.2. Informative references 235 [asn32d] Huston, G., "4-byte AS Number Policy (RIPE PDP 2005-12).". 237 Authors' Addresses 239 Henk Uijterwaal 240 RIPE NCC 241 Singel 258 242 1016 AB Amsterdam 243 NL 245 Phone: +31 20 535 4444 246 Email: henk@ripe.net 248 Katie Petrusha 249 RIPE NCC 250 Singel 258 251 1016 AB Amsterdam 252 NL 254 Phone: +31 20 535 4444 255 Email: katie@ripe.net 257 Full Copyright Statement 259 Copyright (C) The IETF Trust (2007). 261 This document is subject to the rights, licenses and restrictions 262 contained in BCP 78, and except as set forth therein, the authors 263 retain all their rights. 265 This document and the information contained herein are provided on an 266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 268 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 269 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 270 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 273 Intellectual Property 275 The IETF takes no position regarding the validity or scope of any 276 Intellectual Property Rights or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; nor does it represent that it has 280 made any independent effort to identify any such rights. Information 281 on the procedures with respect to rights in RFC documents can be 282 found in BCP 78 and BCP 79. 284 Copies of IPR disclosures made to the IETF Secretariat and any 285 assurances of licenses to be made available, or the result of an 286 attempt made to obtain a general license or permission for the use of 287 such proprietary rights by implementers or users of this 288 specification can be obtained from the IETF on-line IPR repository at 289 http://www.ietf.org/ipr. 291 The IETF invites any interested party to bring to its attention any 292 copyrights, patents or patent applications, or other proprietary 293 rights that may cover technology that may be required to implement 294 this standard. Please address the information to the IETF at 295 ietf-ipr@ietf.org. 297 Acknowledgment 299 Funding for the RFC Editor function is provided by the IETF 300 Administrative Support Activity (IASA).