idnits 2.17.1 draft-blanchet-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 248. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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. 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 (March 5, 2006) is 6599 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) ** Downref: Normative reference to an Informational RFC: RFC 1987 ** Obsolete normative reference: RFC 2471 (Obsoleted by RFC 3701) ** Downref: Normative reference to an Informational RFC: RFC 2772 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3701 ** Downref: Normative reference to an Informational RFC: RFC 3849 ** Downref: Normative reference to an Informational RFC: RFC 3964 Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 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 Expires: September 6, 2006 March 5, 2006 6 IPv6 Routing Policies Guidelines 7 draft-blanchet-v6ops-routing-guidelines-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 6, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Guidelines on how to handle IPv6 routes are needed for operators of 41 networks, either providers or enterprises. This document is a 42 followup on RFC2772 work but for the production IPv6 Internet. 43 RFC2772 becomes historic. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 50 2.2. Compatibility Addresses . . . . . . . . . . . . . . . . . . 3 51 2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 52 2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 53 2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3 54 2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4 55 2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.5.3. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 4 60 3. RPSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Document Status . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 8 68 1. Introduction 70 To maintain stability, efficiency and scalability of the IPv6 71 Internet, guidelines for routing policies are needed for operators 72 deploying IPv6 networks. Prior experience on IPv6 routing guidelines 73 on the 6bone[RFC2772], practical deployment of the IPv6 internet and 74 IPv6 specifications were used as input to this document. 76 This document first describes the different types of addresses and 77 then summarizes the suggested policies in RPSL. 79 2. Address Types 81 2.1. Node-scoped Unicast 83 The node-scoped unicast addresses[RFC3513] such as the loopback 84 (::1/128), the unspecified (::/128) must not be advertised in an IGP 85 or EGP and should be filtered out when received. 87 2.2. Compatibility Addresses 89 IPv4-mapped addresses (::FFFF:0:0/96)[RFC3513] must not be advertised 90 and should be filtered out. 92 2.3. Link-scoped Unicast 94 The link-scoped unicast[RFC3513] routes (fe80::/16) must not be 95 advertised in an IGP or EGP and should be filtered out when received. 97 2.4. Site-scoped Unicast 99 The site-scoped unicast routes (fc00::/7) may be advertised in an 100 IGP. It must not be advertised in an EGP connected to the global 101 Internet and should be filtered out when received. However, it may 102 be advertised in an EGP between two networks sharing a private 103 interconnect, but must not be advertised outside the scope of these 104 networks. When advertised in an EGP, these routes should be of 105 length /48. 107 2.5. Global Unicast 109 The global unicast routes (2000::/3)[RFC3513] may be advertised in an 110 IGP or EGP. A minimal EGP routing policy should filter out routes 111 that exceed a maximum length. Determining the maximum length of a 112 global Internet route is outside the scope of this document. 114 A finer EGP routing policy may use only the allocated address space 115 from IANA to registry as specified in 116 http://www.iana.org/assignments/ipv6-unicast-address-assignments. 117 This would result in better filtering since the non-allocated 118 prefixes will be filtered out. 120 An even finer EGP routing policy may use only the assigned address 121 space from registries to providers as available in the registry 122 databases. This would result in the best filtering since the non- 123 assigned prefixes will be filtered out. However, this requires the 124 synchronization of the filters with the registry databases. 126 2.5.1. Documentation Prefix 128 The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes 129 and must not be advertised in an IGP or EGP and should be filtered 130 out when received. 132 2.5.2. 6to4 134 The 6to4 prefix (2002::/16) may be advertised in an IGP or EGP, when 135 the site is running a 6to4 relay. However, the provider of this 136 service should be aware of the implications of running such 137 service[RFC3964], which includes some specific filtering rules for 138 6to4. 140 2.5.3. 6bone 142 The 6bone experimental network used some experimental allocations, 143 such as 5f00::/8[RFC1987] and 3ffe::/16[RFC2471] that were later 144 returned to IANA[RFC3701]. These prefixes should not be advertised 145 in an EGP unless IANA reallocates them subsequently. 147 2.6. Default Route 149 The default unicast route (::) may be advertised in an IGP. In an 150 EGP, it may be only advertised to the downstream but must not be 151 advertised in the core. 153 2.7. Multicast 155 Multicast addresses (ff00::/8)[RFC3513] have a scope in the address 156 field. In the multicast routing, the routes should be announced 157 according to the scope, similar to unicast routes. Multicast routes 158 must not appear in unicast routing tables. 160 2.8. Unknown addresses 162 Any non listed address above must not be advertised and should be 163 filtered out. 165 3. RPSL 167 The Route Policy Specification Language(RPSL)[RFC4012] used in route 168 registries supports the policies described in this document and 169 should be considered to manage route policies. 171 The following RPSL code implements the policies described in this 172 document. 174 TBD: RPSL code to fill 176 4. Document Status 178 This document should be a BCP. This document should put RFC 2772 as 179 historic. 181 5. Security Considerations 183 TBD. 185 6. Acknowledgements 187 Florent Parent, Pekka Savola and Tim Chown have provided input and 188 suggestions to this document. 190 7. References 192 [RFC1987] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching 193 Liaw, F., Lyon, T., and G. Minshall, "Ipsilon's General 194 Switch Management Protocol Specification Version 1.1", 195 RFC 1987, August 1996. 197 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 198 Allocation", RFC 2471, December 1998. 200 [RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing 201 Guidelines", RFC 2772, February 2000. 203 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 204 (IPv6) Addressing Architecture", RFC 3513, April 2003. 206 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 207 Allocation) Phaseout", RFC 3701, March 2004. 209 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 210 Reserved for Documentation", RFC 3849, July 2004. 212 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 213 6to4", RFC 3964, December 2004. 215 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 216 "Routing Policy Specification Language next generation 217 (RPSLng)", RFC 4012, March 2005. 219 Author's Address 221 Marc Blanchet 222 Viagenie 224 Email: Marc.Blanchet@viagenie.ca 226 Intellectual Property Statement 228 The IETF takes no position regarding the validity or scope of any 229 Intellectual Property Rights or other rights that might be claimed to 230 pertain to the implementation or use of the technology described in 231 this document or the extent to which any license under such rights 232 might or might not be available; nor does it represent that it has 233 made any independent effort to identify any such rights. Information 234 on the procedures with respect to rights in RFC documents can be 235 found in BCP 78 and BCP 79. 237 Copies of IPR disclosures made to the IETF Secretariat and any 238 assurances of licenses to be made available, or the result of an 239 attempt made to obtain a general license or permission for the use of 240 such proprietary rights by implementers or users of this 241 specification can be obtained from the IETF on-line IPR repository at 242 http://www.ietf.org/ipr. 244 The IETF invites any interested party to bring to its attention any 245 copyrights, patents or patent applications, or other proprietary 246 rights that may cover technology that may be required to implement 247 this standard. Please address the information to the IETF at 248 ietf-ipr@ietf.org. 250 Disclaimer of Validity 252 This document and the information contained herein are provided on an 253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 255 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 256 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 257 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 260 Copyright Statement 262 Copyright (C) The Internet Society (2006). This document is subject 263 to the rights, licenses and restrictions contained in BCP 78, and 264 except as set forth therein, the authors retain all their rights. 266 Acknowledgment 268 Funding for the RFC Editor function is currently provided by the 269 Internet Society.