idnits 2.17.1 draft-ietf-v6ops-routing-guidelines-01.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 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. 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 : ---------------------------------------------------------------------------- ** 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.) 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 (February 26, 2007) is 6241 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 1897 (Obsoleted by RFC 2471) ** Obsolete normative reference: RFC 2471 (Obsoleted by RFC 3701) ** Downref: Normative reference to an Informational RFC: RFC 3849 Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Standards Track February 26, 2007 5 Expires: August 30, 2007 7 IPv6 Routing Policies Guidelines 8 draft-ietf-v6ops-routing-guidelines-01.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 August 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Guidelines on how to manage and filter IPv6 routes are needed for 42 operators of networks, either providers or enterprises. It describes 43 IPv6 routes from the protocol point of view. It does not discuss 44 operational or policy issues such as the maximum length of prefixes 45 to filter. This document is a followup on RFC2772 work but for the 46 production IPv6 Internet. RFC2772 is obsoleted. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 53 2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3 54 2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 55 2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 56 2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3 57 2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4 58 2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.5.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.5.4. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5 64 3. Implementing routing policies . . . . . . . . . . . . . . . . . 5 65 4. RPSL Implementation . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Intellectual Property and Copyright Statements . . . . . . . . . . 8 74 1. Introduction 76 To maintain stability, efficiency and scalability of the IPv6 77 Internet, guidelines for routing policies are needed for operators 78 deploying IPv6 networks. Prior experience on IPv6 routing guidelines 79 on the 6bone[RFC2772], practical deployment of the IPv6 internet and 80 IPv6 specifications were used as input to this document. 82 This document first describes the different types of addresses and 83 then summarizes the suggested policies in RPSL. 85 "Advertisement" in this document refers to the prefix advertisement, 86 not the next-hop. 88 2. Address Types 90 2.1. Node-scoped Unicast 92 The node-scoped unicast addresses[RFC4291] such as the loopback 93 (::1/128), the unspecified (::/128) must not be advertised in an IGP 94 or EGP and should be filtered out when received. 96 2.2. IPv4-Mapped Addresses 98 IPv4-mapped addresses (::FFFF:0:0/96) [RFC4291] must not be 99 advertised and should be filtered out. 101 2.3. Link-scoped Unicast 103 The link-scoped unicast[RFC4291] routes (fe80::/10) must not be 104 advertised in an IGP or EGP and should be filtered out when received. 106 2.4. Site-scoped Unicast 108 The site-scoped unicast routes, known as Unique-local[RFC4193], 109 (fc00::/7) may be advertised in an IGP. It must not be advertised in 110 an EGP connected to the global Internet and should be filtered out 111 when received. However, it may be advertised in an EGP between two 112 networks sharing a private interconnect, but must not be advertised 113 outside the scope of these networks. When advertised in an EGP, 114 these routes should be of length /48 or smaller. 116 2.5. Global Unicast 118 The global unicast routes (2000::/3) [RFC4291] may be advertised in 119 an IGP or EGP. 121 A minimal EGP routing policy should filter out routes that exceed a 122 maximum length. Determining the maximum length of a global Internet 123 route is outside the scope of this document. 125 A finer EGP routing policy may use only the allocated address space 126 from IANA to registries as specified in 127 http://www.iana.org/assignments/ipv6-unicast-address-assignments. 128 This would result in better filtering since the non-allocated 129 prefixes will be filtered out. 131 An even finer EGP routing policy may use only the assigned address 132 space from registries to providers as available in the registries 133 databases. This would result in the best filtering since the non- 134 assigned prefixes will be filtered out. However, this requires the 135 synchronization of the filters with the registries databases. 137 2.5.1. Documentation Prefix 139 The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes 140 and must not be advertised in an IGP or EGP and should be filtered 141 out when received. 143 2.5.2. 6to4 145 The 6to4[RFC4291][RFC3056] prefix (2002::/16) may be advertised in an 146 IGP or EGP, when the site is running a 6to4 relay or offering a 6to4 147 transit service. However, the provider of this service should be 148 aware of the implications of running such service[RFC3964], which 149 includes some specific filtering rules for 6to4. 151 2.5.3. Teredo 153 The Teredo[RFC4380] prefix (2001::/32) may be advertised in an IGP or 154 EGP, when the site is running a Teredo relay or offering a Teredo 155 transit service. 157 2.5.4. 6bone 159 The 6bone experimental network used some experimental allocations, 160 such as 5f00::/8[RFC1897] and 3ffe::/16[RFC2471] that were later 161 returned to IANA[RFC3701]. These prefixes should not be advertised 162 in an EGP unless IANA reallocates them subsequently. 164 2.6. Default Route 166 The default unicast route (::) may be advertised in an IGP. It must 167 not be advertised in an EGP unless it has been requested by the 168 recipient. 170 2.7. Multicast 172 Multicast addresses (ff00::/8) [RFC4291] have a 4 bits scope in the 173 address field. Only addresses having the 'E' value in the scope 174 field are of global scope, all other values are local or reserved. 175 Therefore, only ffXe:: routes may be advertised outside an 176 organisation network, where X may be any value. 178 Multicast routes must not appear in unicast routing tables. 180 2.8. Unknown addresses 182 Any non listed address above must not be advertised and should be 183 filtered out. Future work might reserve additional address space for 184 protocol use which might require specific routing guidelines. The 185 reader should refer to newer versions of the normative references in 186 this document to verify the existence of newer protocol address 187 space. 189 3. Implementing routing policies 191 This document focuses on protocol addresses and their use in the 192 networks. It does not discuss any allocation policies and their 193 impact on the routing policies, such as /48 Micro-allocations for 194 infrastructure providers or maximum length of a unicast prefix. As 195 such, to implement a complete routing policy, one should augment 196 these guidelines with the current registry allocation policies and by 197 appropriate ingress filtering techniques[RFC3704]. 199 4. RPSL Implementation 201 The Route Policy Specification Language(RPSL) [RFC4012] used in route 202 registries supports the policies described in this document and 203 should be considered to manage route policies. 205 The following RPSL code implements the policies described in this 206 document. This code should be considered as an example and should be 207 adapted to the target usage. 209 route-set: rs-exclude 210 mp-members: ::1/128, ::/128, ::ffff:0:0/96^+, fe80::/10^+, 211 2001:0db8::/32^+ 213 route-set: rs-ula 214 mp-members: fc00::/7^+ 216 route-set: rs-global-unicast 217 mp-members: 2000::/3^+ 219 route-set: rs-6to4 220 mp-members: 2002::/16^+ 222 route-set: rs-teredo 223 mp-members: 2001::/32^+ 225 filter-set: fltr-v6egp 226 mp-filter: NOT (rs-exclude AND rs-ula) AND rs-global-unicast 228 filter-set: fltr-v6igp 229 mp-filter: NOT rs-exclude AND rs-global-unicast 231 5. Security Considerations 233 This document list guidelines that should improve the security of 234 networks by the filtering of invalid routing prefixes. 236 6. Acknowledgements 238 Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, 239 Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, 240 Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian 241 Carpenter, Mark Smith and Kevin Loch have provided input and 242 suggestions to this document. 244 7. References 246 7.1. Normative References 248 [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address 249 Allocation", RFC 1897, January 1996. 251 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 252 Allocation", RFC 2471, December 1998. 254 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 255 via IPv4 Clouds", RFC 3056, February 2001. 257 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 258 Reserved for Documentation", RFC 3849, July 2004. 260 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 261 "Routing Policy Specification Language next generation 262 (RPSLng)", RFC 4012, March 2005. 264 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 265 Addresses", RFC 4193, October 2005. 267 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 268 Architecture", RFC 4291, February 2006. 270 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 271 Network Address Translations (NATs)", RFC 4380, 272 February 2006. 274 7.2. Informative References 276 [RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing 277 Guidelines", RFC 2772, February 2000. 279 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 280 Allocation) Phaseout", RFC 3701, March 2004. 282 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 283 Networks", BCP 84, RFC 3704, March 2004. 285 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 286 6to4", RFC 3964, December 2004. 288 Author's Address 290 Marc Blanchet 291 Viagenie 293 Email: Marc.Blanchet@viagenie.ca 295 Full Copyright Statement 297 Copyright (C) The IETF Trust (2007). 299 This document is subject to the rights, licenses and restrictions 300 contained in BCP 78, and except as set forth therein, the authors 301 retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Intellectual Property 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org. 335 Acknowledgment 337 Funding for the RFC Editor function is provided by the IETF 338 Administrative Support Activity (IASA).