Network Working Group F. Parent Internet-Draft Viagenie Expires: July 10, 2002 January 9, 2002 RPSL extensions for IPv6 and Multicast Routing Policies draft-parent-multiprotocol-rpsl-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 July 10, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the definitions and extensions required in RPSL [1] in order to be able to define IPv6 and multicast routing policies. Defining RPSL for IPv6 is an important step to build an IPv6 Internet Routing Registry. Parent Expires July 10, 2002 [Page 1] Internet-Draft RPSLng January 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Using new address families in RPSL objects . . . . . . . . . . 3 2.1 route class . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 route-set class . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 peering-set class . . . . . . . . . . . . . . . . . . . . . . 5 2.4 aut-num . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 inet-rtr . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6 filter-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Security considerations . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Parent Expires July 10, 2002 [Page 2] Internet-Draft RPSLng January 2002 1. Introduction This draft documents the required information and extensions in RPSL to be able to specify an IPv6 and multicast 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 and multicast routing policies. 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. 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. This document describes the usage of IPv6 and multicast addresses in RPSL routing policies. This has an impact on many classes, most notably in the aut-num class. This proposal tries to minimize the number of new classes and attributes, and be as generic as possible. The changes proposed will not be limited to support IPv6 and multicast, but can later be used to support new address families. 2. Using new address families in RPSL objects Section 2 in RFC 2622 [1]defines the usage of IPv4 unicast addresses and prefixes in RPSL. This document introduces IPv6 addresses and prefixes in RPSL. The textual representation of an IPv6 address or prefix in RPSL attributes should follow the syntax described in section 2.2 of RFC2373 [2]. The new address families introduced in RPSL need to be identified such that they can be unambiguously used in the correct context by some tools. Currently, all IP addresses in RPSL objects are assumed to be IPv4 unicast addresses. A new syntax is introduced to specify an IP address inside an RPSL attribute: [afi ] where: = enum[ipv4, ipv6, ipv4-multicast, ipv6-multicast] Parent Expires July 10, 2002 [Page 3] Internet-Draft RPSLng January 2002 (TBD: use RPSL dictionary style) The optional "afi" syntax identifies the address family. If this keyword is missing, ipv4 (unicast) is assumed such that the previous RPSL syntax is still valid. For IPv6 addresses, the "afi ipv6" keywords can be optional since the new software and tools can be expected to be able to differentiate between IPv4 and IPv6 addresses. This will make IPv6 less tedious to use. 2.1 route class Using the new address syntax, a route object is extended as follows: route: [afi ] The following two route objects represent the same thing: route: 10.0.0.0/8 origin: AS1 route: afi ipv4 10.0.0.0/6 origin: AS1 An IPv6 route object would be represented as follows: route: afi ipv6 3ffe:ffff::/28 origin: AS1 2.2 route-set class route-set: RS-peer1 members: [afi ] route-set: ipv6-martians members: afi ipv6 ff00::/8 members: afi ipv6 fe80::/10 members: afi ipv6 fec0::/10 members: afi ipv6 ::/96 Making the "afi ipv6" optional for ipv6 unicast addresses, the route- set can be simplified as follows: Parent Expires July 10, 2002 [Page 4] Internet-Draft RPSLng January 2002 route-set: ipv6-martians members: ff00::/8 members: fe80::/10 members: fec0::/10 members: ::/96 The new syntax allows mixed address families within the same route- set. This enables an autonomous system to specify the same routing policies for both IPv4 and IPv6 with minimal duplication of information. 2.3 peering-set class The peering-set object defines a set of peerings that are listed in its peering attributes. As described in Section 5.6 in RFC 2622 [1], the peering attribute can be expressed using IP addresses. The address family used in the peering attribute determines whether IPv4 or IPv6, for example, will be used to establish the peering session (Note that this is different from the address prefixes exchanged in that peering). Using the new address syntax defined earlier, the peering attribute is specified as follows: peering: [<[afi ] router-expression-1>] [at <[afi ] router-expression-2>] [afi ] specifies the IP protocol used for the actual peering. Acceptable values would be ipv4 or ipv6 Example: peering-set: AS1-v6 peering: AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2 2.4 aut-num The aut-num class is used to define the automonous system routing policies. The import and export attributes inside the aut-num class can specify the routing protocol, the peering type and the routing filters to be used by an autonomous system. The peering type defines the IP address of the routing peers, and thus the IP address family used to establish that peering (Section 2.3). RPSL supports multi-protocol routing protocol through the optional Parent Expires July 10, 2002 [Page 5] Internet-Draft RPSLng January 2002 "protocol" statement. This protocol syntax is extended to allow specification of the address-family and subsequent address family. This syntax is closely tied with the multi-protocol BGP definition. The RPSL dictionary must be extended to support a new protocol "afi" and "safi" attributes. These attributes define the address family (ipv4, ipv6) and subsequent address family (unicast, multicast) of the IP prefixes exchanged in the routing protocol. The initial RPSL dictionary, as defined in RFC2622 section 7.1 [1], is extended as follows: typedef: # Address family values # Currently defined: IPv4 and IPv6 afi_elm enum[ipv4, ipv6] typedef: # Subsequent address family values # Currently defined: unicast and multicast safi_elm enum[unicast, multicast] rp-attribute: afi operator=(afi_elm) rp-attribute: safi operator=(safi_elm) protocol: BGP4 # as number of the peer router MANDATORY asno(as_number) # enable flap damping OPTIONAL flap_damp() OPTIONAL flap_damp(integer[0,65535], # penalty per flap integer[0,65535], # penalty value for supression integer[0,65535], # penalty value for reuse integer[0,65535], # halflife in secs when up integer[0,65535], # halflife in secs when down integer[0,65535]) # maximum penalty # Optional address family attribute. Default is ipv4. OPTIONAL afi() # Optional subsequent address family attribute. Default is unicast. OPTIONAL safi() Parent Expires July 10, 2002 [Page 6] Internet-Draft RPSLng January 2002 Using the new protocol definition, the import and export attributes in an aut-num object can now be specified as follows: import: [protocol [afi(address-family) safi(subsequent-address-family)]] [into protocol ] from [action ] accept export: [protocol [afi(address-family)] safi(subsequent-address-family)]] [into protocol ] to [action ] announce address-family = ipv4|ipv6 subsequent-address-family = unicast|multicast As an example, the aut-num import attribute can specify IPv6 unicast route exchange (afi, safi) over an IPv6 peering session between the routing peers (peering): import: protocol BGP afi(ipv6), safi(unicast) from AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2 accept AS1:RS-PROVIDER The import statement defines that BGP peering to exchange IPv6 (afi) unicast (safi) prefixes. The BGP peering session will be done over IPv6 as specified by the peers The same example as above, but using the AS1-v6 peering object defined in Section 2.3: import: protocol BGP afi(ipv6), safi(unicast) from AS1-v6 accept AS1:RS-PROVIDER 2.5 inet-rtr TBD 2.6 filter-set TBD Parent Expires July 10, 2002 [Page 7] Internet-Draft RPSLng January 2002 3. Security considerations TBD 4. Acknowledgments This document has benefited from discussion and contributions from the following people: Cengiz Alaettinoglu, Larry J. Blunk, Marc Blanchet, David Kessens, Bart Peirens, Mark Prior. 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", 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 July 10, 2002 [Page 8] Internet-Draft RPSLng January 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 July 10, 2002 [Page 9]