idnits 2.17.1 draft-parent-rpsl-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 17, 2001) is 8226 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) ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) -- No information found for draft-ietf-ngtrans-6bone-registry-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Parent 2 Internet-Draft Viagenie 3 Expires: April 17, 2002 October 17, 2001 5 IPv6 Routing Policies using RPSL 6 draft-parent-rpsl-ipv6-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on April 17, 2002. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This document describes the definitions and extensions required in 38 RPSL [1] in order to be able to define IPv6 routing policies. 39 Defining RPSL for IPv6 is an important step to build an IPv6 Internet 40 Routing Registry. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. IPv6 Address and Prefix Representation in RPSL . . . . . . . . 4 46 3. Using IPv6 in RPSL classes . . . . . . . . . . . . . . . . . . 6 47 3.1 aut-num . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 48 3.2 route . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 49 3.3 route-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7 50 3.4 as-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 3.5 inet-rtr . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 3.6 filter-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 3.7 peering-set . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 4. Using route vs using ipv6-site Objects . . . . . . . . . . . . 9 55 5. Tunnels and Native IPv6 Links . . . . . . . . . . . . . . . . 10 56 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 57 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 62 1. Introduction 64 This draft documents the required information and extensions in RPSL 65 to be able to specify an IPv6 routing policy. 67 This document assumes that it is not required to build a seperate 68 Internet Routing Registry (IRR) infrastructure from the existing IPv4 69 IRR. Extensions to existing RPSL object are introduced to allow the 70 definitions of IPv6 routing policies, and maintain backward 71 compatibility. 73 It should be noted that work is underway in the RIPE RPSLng task 74 force to investigate and define extensions to RPSL to include IPv6 75 and IPv4/IPv6 multicast. The current version of this document 76 focuses on IPv6 unicast, but this document will be evolving within 77 the work currently underway in this area. 79 RFC 2622 [1] defines RPSL using IPv4 prefixes and addresses. 80 Fortunately, RPSL was defined to be extensible such that new features 81 can be added. Section 10 in RFC 2622 provides guidelines for 82 extending RPSL, such as adding a new routing protocol or new features 83 to the existing protocols. 85 Section 2 in RFC 2622 defines the usage of IPv4 addresses and 86 prefixes in RPSL. Since defining RPSL for IPv6 routing policies 87 requires defining the usage of IPv6 addresses inside object 88 attributes, Section 2 in RFC2622 needs to be extended to describe 89 IPv6 usage. Section 2 describes the usage of IPv6 addresses inside 90 RPSL. 92 Introducing IPv6 has an impact on certain classes, most notably in 93 the aut-num class. Section 3 enumerates the current RPSL classes and 94 defines the new attributes, when necessary, to support IPv6. 96 2. IPv6 Address and Prefix Representation in RPSL 98 This section is based on Section 2 in RFC 2622 [1] and takes much of 99 the wording from that section. This section extends the IP address, 100 prefix and range definitions in order to include IPv6. 102 It should be noted that IPv6 prefixes has been in usage in RPSL for 103 quite some time. For example, the 6bone registry [3] uses the ipv6- 104 site and inet6num objects that contains IPv6 prefixes in their 105 attributes. 107 The following IP address representations are added or extended: 108 , and 110 An IPv6 address is represented as a sequence of 111 hexadecimal groups delimited with ":" representing a 128 bit address. 112 The textual representation can be compressed using the "::" syntax. 113 A full description of the address syntax can be found in Section 2.2 114 of RFC2373 [2] 116 An address prefix is represented as an IP address 117 followed by the character slash "/" followed by an integer in the 118 range appropriate for the IP version (from 0 to 32 for IPv4 and from 119 0 to 128 for IPv6). The following are valid IPv6 prefixes: 120 3ffe:ffff:c18::/48, 2002::/16; and the following IPv6 prefixes are 121 invalid: 3ffe:ffff:c18/48 (incomplete IPv6 address), fec0::1/130 122 (prefix length out of bound). 124 An address prefix range is an address prefix 125 followed by an optional range operator. The range operators are: 127 ^- is the exclusive more specifics operator; it stands for the more 128 specifics of the address prefix excluding the address prefix itself. 129 For example, 2001::/16^- contains all the more specifics of 2001::/16 130 excluding 2001::/16. 132 ^+ is the inclusive more specifics operator; it stands for the more 133 specifics of the address prefix including the address prefix itself. 134 For example, 2001::/16^+ contains all the more specifics of 2001::/16 135 including 2001::/16. 137 ^n where n is an integer, stands for all the length n specifics of 138 the address prefix. For example, 3ffe:ffff::/24^48 contains all the 139 more specifics of 3ffe:ffff::/24 which are of length 48 such as 140 3ffe:ffff:c18::/48. 142 ^n-m where n and m are integers, stands for all the length n to 143 length m specifics of the address prefix. For example, 144 3ffe:ffff::/24^24-48 contains all the more specifics of 145 3ffe:ffff::/24 which are of length 24 to 48 such as 146 3ffe:ffff:c18::/48 and 3ffe:ffff:c00::/40. 148 3. Using IPv6 in RPSL classes 150 3.1 aut-num 152 The aut-num class is used to define the automonous system routing 153 policies. 155 (Show aut-num class template here) 157 In order to be able to specify IPv6 routing policies, IPv6 needs to 158 be supported in aut-num attributes (import, export, default). As an 159 example, the aut-num import attribute can use an explicit IPv6 prefix 160 as follows: 162 import: from AS2 accept { 2001:410::/35 } 164 Such an statement defines clearly the goal of that attribute: accept 165 IPv6 prefix advertisement 2001:410::/35 from AS2. Using the 166 definitions in Section 2, this type of IPv6 policy can be 167 unambiguously defined. 169 But routing policies inside aut-num are often defined in term of a 170 relationship to other autonomous systems, as the following example 171 shows. 173 import: from AS3701 accept ANY 174 export: to AS3701 announce AS3582 176 Since there is no reference to the IP protocol used, an ambiguity 177 arises when introducing IPv6: Does the above mean import and export 178 both IPv4 and IPv6 ? If the IPv4 and IPv6 routing policies are to be 179 kept distinct, we need some identifier to distinguish between address 180 families. 182 It is proposed to define new attributes inside aut-num: import6, 183 export6, default6. These would allow to unambiguously specify which 184 address family is being specified inside the policy. 186 import: from AS3701 accept ANY 187 import6: from AS3702 accept ANY 188 export: to AS3701 announce AS3582 189 export6: to AS3702 announce AS3582 191 The advantage of using new attributes inside aut-num for IPv6 192 policies is that the backward compatibility with IPv4 IRR is assured. 193 If the new attribute is not understood by an IPv4 only software, it 194 is simply ignored. 196 Another approach would be to introduce a new keyword inside the 197 current import, export and default attributes in order to specify the 198 address family that the statement applies to. Such an approach would 199 closely match the current multiprotocol BGP implementation and would 200 scale better to support address families other that IPv6 unicast. 202 The import, export attributes use objects such as peering and filter. 203 These classes must be defined to support IPv6. 205 3.2 route 207 This class specifies a route originated by an autonomous system. 209 (Show route class template here) 211 Using the definitions in Section 2, the route attribute can specify 212 IPv6 prefixes. The following route object is an example: 214 route: 3ffe:b00::/24 215 origin: AS10566 217 The route class contains other attributes that use an IP address or 218 prefix: Section 8 in RFC2622 describes the aggregation attributes 219 used in the route class. It remains to be further explored how/if 220 these attributes will be used in IPv6. 222 3.3 route-set 224 A route-set allows the definition of a group of prefixes under a 225 common name. Using the definitions in Section 2, the members 226 attribute can new specify IPv6 prefixes. 228 (Show route-set class template here) 230 route-set: rs-viagenie 231 members: 3ffe:b00::/24, 2001:410:800::/48 233 3.4 as-set 235 3.5 inet-rtr 237 TO BE DONE 239 3.6 filter-set 241 TO BE DONE 243 3.7 peering-set 245 TO BE DONE 247 4. Using route vs using ipv6-site Objects 249 The ipv6-site class (draft-ietf-ngtrans-6bone-registry-xx.txt [3]) 250 contains information similar to the route class: 252 o AS of the site 254 o Route prefixes which are exported by the site to the outside world 256 o Information related to the type of IPv6 connectivity (tunnel or 257 native links) 259 The ipv6-site class offers the similar information to what is 260 available in a route class, but with some important differences: 262 o the prefix attribute is optional in ipv6-site (whereas it is 263 mandatory inside the route class). 265 o the prefix attribute can appear multiple times in ipv6-site 266 (similar to a route-set). 268 o ipv6-site does not offer indirect membership as offered by the 269 route and route-set classes. 271 o route class offers aggregation attributes. 273 TO BE COMPLETED 275 5. Tunnels and Native IPv6 Links 277 TO BE DONE 279 6. Security considerations 281 TBD 283 7. Acknowledgments 285 TBD 287 References 289 [1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 290 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 291 Policy Specification Language (RPSL)", RFC 2622, June 1999. 293 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 294 Architecture", RFC 2373, July 1998. 296 [3] Kessens, D., "The 6bone registry", 297 draft-ietf-ngtrans-6bone-registry-xx.txt, internet-draft, Jan 2001. 299 Author's Address 301 Florent Parent 302 Viagenie 303 2875 boul. Laurier, bur 300 304 Ste-Foy, QC G1V 2M2 305 Canada 307 Phone: +1 418 656 9254 308 EMail: Florent.Parent@viagenie.qc.ca 310 Full Copyright Statement 312 Copyright (C) The Internet Society (2001). All Rights Reserved. 314 This document and translations of it may be copied and furnished to 315 others, and derivative works that comment on or otherwise explain it 316 or assist in its implementation may be prepared, copied, published 317 and distributed, in whole or in part, without restriction of any 318 kind, provided that the above copyright notice and this paragraph are 319 included on all such copies and derivative works. However, this 320 document itself may not be modified in any way, such as by removing 321 the copyright notice or references to the Internet Society or other 322 Internet organizations, except as needed for the purpose of 323 developing Internet standards in which case the procedures for 324 copyrights defined in the Internet Standards process must be 325 followed, or as required to translate it into languages other than 326 English. 328 The limited permissions granted above are perpetual and will not be 329 revoked by the Internet Society or its successors or assigns. 331 This document and the information contained herein is provided on an 332 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 333 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 334 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 335 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 336 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 338 Acknowledgement 340 Funding for the RFC Editor function is currently provided by the 341 Internet Society.