Individual submission H. Uijterwaal Internet-Draft K. Petrusha Intended status: Standards Track RIPE NCC Expires: March 6, 2008 September 3, 2007 RPSL extensions for 32 bit AS Numbers draft-uijterwaal-rpsl-4byteas-ext-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies extensions to the RPSL language for dealing with 32 bit (4 byte) AS numbers. It also gives a list of RPSL attributes that will be affected by this change and that may require tools to be updated. Uijterwaal & Petrusha Expires March 6, 2008 [Page 1] Internet-Draft RPSL extensions for 32 bit AS Numbers September 2007 1. Introduction Four byte (32 bit) AS numbers (ASN32) are defined in [as4bytes]. This document does not specify a format to represent these numbers. A separate document [asn32rep] proposes to represent them as: . This format allows users to easily distinguish 16 and 32 bit ASN. RPSL (Routing Policy Specification Language) ([RFC2622] and [RFC4012]) uses the format "ASx" for an AS, with x a 1 to 5 digit number in the range 0 to 65535. RPSL was defined before the introduction of 32 bit AS numbers (ASN32). Deployment of ASN32 will start early 2007 [asn32d]. To use these numbers in RPSL, the RPSL standard will have to be updated to allow for ASN32. This document defines the necessary extensions to the RPSL standard. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Proposal The terms "2-byte only AS Numbers" and "4-byte AS numbers" are defined in [asn32rep]. Following this document, the field in [RFC2622] (section 2) will be replaced by: An is a string that can be either: * ASx, for 2-byte only AS numbers, or * ASy.z for 4-byte AS Numbers, with x and y using the same format as [asn32rep]. x, y and z are integer numbers in the range 0 to 65535. If y equals 0, it and the following "." MUST both be dropped. An application MAY accept a string with y equal to 0 as input. Similar, following [asn32rep] and [RFC2622], the definition of a community specification will be replaced by: An community specification is a string that can be either: Uijterwaal & Petrusha Expires March 6, 2008 [Page 2] Internet-Draft RPSL extensions for 32 bit AS Numbers September 2007 * x:N, for 2-byte only AS numbers, or * y.z:N for 4-byte AS Numbers, with x and y using the same format as [asn32rep]. x, y, z and N are integer numbers in the range 0 to 65535. If y equals 0, it and the following "." MUST both be dropped. An application MAY accept a string with y equal to 0 as input. No other changes to the RPSL standard will be made. 2.1. Background The proposed format ("ASx.y") for RPSL uses the same format for ASN32 as had been proposed for other representations of ASN32. This will allow for an easy conversion of data between RPSL-based tools and other tools. The format also has the advantage that the number of RPSL attributes will not change. Proposals based on the RPSL language extension mechanism will all result in adding a large number of new attributes to RPSL. Changing the format of existing attributes has the disadvantage that the code parsing RPSL data of existing tools will have to be reviewed and updated to allow for the new format. However, this is something that has to be done anyway when ASN32 are introduced, as it is a priori not clear whether code can handle ASN values larger than 2^16. 2.2. Examples AS3333 refers to the AS with identifier 3333. AS0.3333 refers to the same AS but this notation should not be used. An identifier of AS65536 is not valid, even though the identifier can be expressed in a 32 bit integer. This AS should be referred to as AS1.0. 3. RPSL Attributes affected by this change The following table lists RPSL attributes that will be affected by this change. It is intended as a check-list for developpers updating their tools. In this table: o A: the AS syntax used in this attribute has changed o C: the community value syntax used in this attribute has changed Uijterwaal & Petrusha Expires March 6, 2008 [Page 3] Internet-Draft RPSL extensions for 32 bit AS Numbers September 2007 +--------------+-------------+----+-----------+ | Object-type | Attribute | AS | Community | +--------------+-------------+----+-----------+ | route: | aggr-bndry | A | | | | aggr-mtd | A | | | | components | A | C | | | inject | A | C | | | member-of | A | | | | origin | A | | | route6: | aggr-bndry | A | | | | aggr-mtd | A | | | | components | A | C | | | inject | A | C | | | member-of | A | | | | origin | A | | | aut-num: | aut-num | A | | | | default | A | C | | | export | A | C | | | import | A | C | | | mp-default | A | C | | | mp-export | A | C | | | mp-import | A | C | | | member-of | A | | | as-set: | as-set | A | | | | members | A | | | inet-rtr: | local-as | A | | | | interface | A | C | | | ifaddr | A | C | | | peer | A | | | | mp-peer | A | | | | member-of | A | | | filter-set: | filter-set | A | | | | filter | A | C | | | mp-filter | A | C | | rtr-set: | rtr-set | A | | | | members | A | | | | mp-members | A | | | route-set: | route-set | A | | | | members | A | | | | mp-members | A | | | peering-set: | peering-set | A | | | | mp-peering | A | | | | peering | A | | | as-block: | as-block | A | | +--------------+-------------+----+-----------+ Uijterwaal & Petrusha Expires March 6, 2008 [Page 4] Internet-Draft RPSL extensions for 32 bit AS Numbers September 2007 4. Security Considerations Many systems will treat strings "xxx.yyy" as real number values and convert this internally to floating point numbers. One must take care that this will not happen. Systems may use unsigned 16-bit integers for the internal representation of AS numbers. It should be checked that tools internally use (at least) an unsigned 32-bit number for ASN. Parsing ASN32 based communities attributes will result in longer byte strings. It should be checked that tools internally have sufficient memory allocated to store these strings. One possibility is to use the extensions to the 8 octet AS Extended Communities [RFC4360] proposed in A DRAFT THAT HAS EXPIRED BUT WILL BE REVIVED. 5. IANA Considerations None. (This section may be removed on publication as an RFC.) 6. Acknowledgements The authors would like to thank James Aldridge, Denis Walker and Rene Wilhelm for their feedback on this draft. 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [as4bytes] Uijterwaal & Petrusha Expires March 6, 2008 [Page 5] Internet-Draft RPSL extensions for 32 bit AS Numbers September 2007 Chen, E. and Q. Vohra, "BGP Support for Four-octet AS Number Space (draft-ietf-idr-as4bytes, work in progress).". [asn32rep] Michaelson, G., "Canonical representation of 4-byte AS- numbers (draft-michaelson-4byte-as-representation, work in progress).". 7.2. Informative references [asn32d] Huston, G., "4-byte AS Number Policy (RIPE PDP 2005-12).". Authors' Addresses Henk Uijterwaal RIPE NCC Singel 258 1016 AB Amsterdam NL Phone: +31 20 535 4444 Email: henk@ripe.net Katie Petrusha RIPE NCC Singel 258 1016 AB Amsterdam NL Phone: +31 20 535 4444 Email: katie@ripe.net Uijterwaal & Petrusha Expires March 6, 2008 [Page 6] Internet-Draft RPSL extensions for 32 bit AS Numbers September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Uijterwaal & Petrusha Expires March 6, 2008 [Page 7]