Network Working Group F. Parent Internet-Draft Viagenie Expires: April 17, 2002 October 17, 2001 IPv6 Routing Policies using RPSL draft-parent-rpsl-ipv6-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 April 17, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes the definitions and extensions required in RPSL [1] in order to be able to define IPv6 routing policies. Defining RPSL for IPv6 is an important step to build an IPv6 Internet Routing Registry. Parent Expires April 17, 2002 [Page 1] Internet-Draft RPSL-IPv6 October 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 Address and Prefix Representation in RPSL . . . . . . . . 4 3. Using IPv6 in RPSL classes . . . . . . . . . . . . . . . . . . 6 3.1 aut-num . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 route . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 route-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 as-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 inet-rtr . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 filter-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7 peering-set . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Using route vs using ipv6-site Objects . . . . . . . . . . . . 9 5. Tunnels and Native IPv6 Links . . . . . . . . . . . . . . . . 10 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 Parent Expires April 17, 2002 [Page 2] Internet-Draft RPSL-IPv6 October 2001 1. Introduction This draft documents the required information and extensions in RPSL to be able to specify an IPv6 routing policy. This document assumes that it is not required to build a seperate Internet Routing Registry (IRR) infrastructure from the existing IPv4 IRR. Extensions to existing RPSL object are introduced to allow the definitions of IPv6 routing policies, and maintain backward compatibility. It should be noted that work is underway in the RIPE RPSLng task force to investigate and define extensions to RPSL to include IPv6 and IPv4/IPv6 multicast. The current version of this document focuses on IPv6 unicast, but this document will be evolving within the work currently underway in this area. RFC 2622 [1] defines RPSL using IPv4 prefixes and addresses. Fortunately, RPSL was defined to be extensible such that new features can be added. Section 10 in RFC 2622 provides guidelines for extending RPSL, such as adding a new routing protocol or new features to the existing protocols. Section 2 in RFC 2622 defines the usage of IPv4 addresses and prefixes in RPSL. Since defining RPSL for IPv6 routing policies requires defining the usage of IPv6 addresses inside object attributes, Section 2 in RFC2622 needs to be extended to describe IPv6 usage. Section 2 describes the usage of IPv6 addresses inside RPSL. Introducing IPv6 has an impact on certain classes, most notably in the aut-num class. Section 3 enumerates the current RPSL classes and defines the new attributes, when necessary, to support IPv6. Parent Expires April 17, 2002 [Page 3] Internet-Draft RPSL-IPv6 October 2001 2. IPv6 Address and Prefix Representation in RPSL This section is based on Section 2 in RFC 2622 [1] and takes much of the wording from that section. This section extends the IP address, prefix and range definitions in order to include IPv6. It should be noted that IPv6 prefixes has been in usage in RPSL for quite some time. For example, the 6bone registry [3] uses the ipv6- site and inet6num objects that contains IPv6 prefixes in their attributes. The following IP address representations are added or extended: , and An IPv6 address is represented as a sequence of hexadecimal groups delimited with ":" representing a 128 bit address. The textual representation can be compressed using the "::" syntax. A full description of the address syntax can be found in Section 2.2 of RFC2373 [2] An address prefix is represented as an IP address followed by the character slash "/" followed by an integer in the range appropriate for the IP version (from 0 to 32 for IPv4 and from 0 to 128 for IPv6). The following are valid IPv6 prefixes: 3ffe:ffff:c18::/48, 2002::/16; and the following IPv6 prefixes are invalid: 3ffe:ffff:c18/48 (incomplete IPv6 address), fec0::1/130 (prefix length out of bound). An address prefix range is an address prefix followed by an optional range operator. The range operators are: ^- is the exclusive more specifics operator; it stands for the more specifics of the address prefix excluding the address prefix itself. For example, 2001::/16^- contains all the more specifics of 2001::/16 excluding 2001::/16. ^+ is the inclusive more specifics operator; it stands for the more specifics of the address prefix including the address prefix itself. For example, 2001::/16^+ contains all the more specifics of 2001::/16 including 2001::/16. ^n where n is an integer, stands for all the length n specifics of the address prefix. For example, 3ffe:ffff::/24^48 contains all the more specifics of 3ffe:ffff::/24 which are of length 48 such as 3ffe:ffff:c18::/48. ^n-m where n and m are integers, stands for all the length n to length m specifics of the address prefix. For example, Parent Expires April 17, 2002 [Page 4] Internet-Draft RPSL-IPv6 October 2001 3ffe:ffff::/24^24-48 contains all the more specifics of 3ffe:ffff::/24 which are of length 24 to 48 such as 3ffe:ffff:c18::/48 and 3ffe:ffff:c00::/40. Parent Expires April 17, 2002 [Page 5] Internet-Draft RPSL-IPv6 October 2001 3. Using IPv6 in RPSL classes 3.1 aut-num The aut-num class is used to define the automonous system routing policies. (Show aut-num class template here) In order to be able to specify IPv6 routing policies, IPv6 needs to be supported in aut-num attributes (import, export, default). As an example, the aut-num import attribute can use an explicit IPv6 prefix as follows: import: from AS2 accept { 2001:410::/35 } Such an statement defines clearly the goal of that attribute: accept IPv6 prefix advertisement 2001:410::/35 from AS2. Using the definitions in Section 2, this type of IPv6 policy can be unambiguously defined. But routing policies inside aut-num are often defined in term of a relationship to other autonomous systems, as the following example shows. import: from AS3701 accept ANY export: to AS3701 announce AS3582 Since there is no reference to the IP protocol used, an ambiguity arises when introducing IPv6: Does the above mean import and export both IPv4 and IPv6 ? If the IPv4 and IPv6 routing policies are to be kept distinct, we need some identifier to distinguish between address families. It is proposed to define new attributes inside aut-num: import6, export6, default6. These would allow to unambiguously specify which address family is being specified inside the policy. import: from AS3701 accept ANY import6: from AS3702 accept ANY export: to AS3701 announce AS3582 export6: to AS3702 announce AS3582 The advantage of using new attributes inside aut-num for IPv6 policies is that the backward compatibility with IPv4 IRR is assured. If the new attribute is not understood by an IPv4 only software, it is simply ignored. Parent Expires April 17, 2002 [Page 6] Internet-Draft RPSL-IPv6 October 2001 Another approach would be to introduce a new keyword inside the current import, export and default attributes in order to specify the address family that the statement applies to. Such an approach would closely match the current multiprotocol BGP implementation and would scale better to support address families other that IPv6 unicast. The import, export attributes use objects such as peering and filter. These classes must be defined to support IPv6. 3.2 route This class specifies a route originated by an autonomous system. (Show route class template here) Using the definitions in Section 2, the route attribute can specify IPv6 prefixes. The following route object is an example: route: 3ffe:b00::/24 origin: AS10566 The route class contains other attributes that use an IP address or prefix: Section 8 in RFC2622 describes the aggregation attributes used in the route class. It remains to be further explored how/if these attributes will be used in IPv6. 3.3 route-set A route-set allows the definition of a group of prefixes under a common name. Using the definitions in Section 2, the members attribute can new specify IPv6 prefixes. (Show route-set class template here) route-set: rs-viagenie members: 3ffe:b00::/24, 2001:410:800::/48 3.4 as-set 3.5 inet-rtr TO BE DONE 3.6 filter-set TO BE DONE Parent Expires April 17, 2002 [Page 7] Internet-Draft RPSL-IPv6 October 2001 3.7 peering-set TO BE DONE Parent Expires April 17, 2002 [Page 8] Internet-Draft RPSL-IPv6 October 2001 4. Using route vs using ipv6-site Objects The ipv6-site class (draft-ietf-ngtrans-6bone-registry-xx.txt [3]) contains information similar to the route class: o AS of the site o Route prefixes which are exported by the site to the outside world o Information related to the type of IPv6 connectivity (tunnel or native links) The ipv6-site class offers the similar information to what is available in a route class, but with some important differences: o the prefix attribute is optional in ipv6-site (whereas it is mandatory inside the route class). o the prefix attribute can appear multiple times in ipv6-site (similar to a route-set). o ipv6-site does not offer indirect membership as offered by the route and route-set classes. o route class offers aggregation attributes. TO BE COMPLETED Parent Expires April 17, 2002 [Page 9] Internet-Draft RPSL-IPv6 October 2001 5. Tunnels and Native IPv6 Links TO BE DONE Parent Expires April 17, 2002 [Page 10] Internet-Draft RPSL-IPv6 October 2001 6. Security considerations TBD Parent Expires April 17, 2002 [Page 11] Internet-Draft RPSL-IPv6 October 2001 7. Acknowledgments TBD Parent Expires April 17, 2002 [Page 12] Internet-Draft RPSL-IPv6 October 2001 References [1] 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. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] Kessens, D., "The 6bone registry", draft-ietf-ngtrans-6bone-registry-xx.txt, internet-draft, Jan 2001. Author's Address Florent Parent Viagenie 2875 boul. Laurier, bur 300 Ste-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Florent.Parent@viagenie.qc.ca Parent Expires April 17, 2002 [Page 13] Internet-Draft RPSL-IPv6 October 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Parent Expires April 17, 2002 [Page 14]