idnits 2.17.1 draft-ietf-v6ops-rfc3330-for-ipv6-04.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 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. 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 : ---------------------------------------------------------------------------- == There are 1 instance 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 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 (January 15, 2008) is 5918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1897 (Obsoleted by RFC 2471) -- Obsolete informational reference (is this intentional?): RFC 2471 (Obsoleted by RFC 3701) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 4773 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 12 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: Informational January 15, 2008 5 Expires: July 18, 2008 7 Special-Use IPv6 Addresses 8 draft-ietf-v6ops-rfc3330-for-ipv6-04.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 July 18, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes the global and other specialized IPv6 address 42 blocks. It does not address IPv6 address space assigned to operators 43 and users through the Regional Internet Registries. These 44 descriptions are useful for route and IP filtering, for documentation 45 and other purposes. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Address Blocks . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 52 2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3 53 2.3. IPv4-compatible Addresses . . . . . . . . . . . . . . . . . 3 54 2.4. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 55 2.5. Unique-Local . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.6. Documentation Prefix . . . . . . . . . . . . . . . . . . . 4 57 2.7. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.8. Teredo . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.9. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.10. ORCHID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.11. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.12. IANA Special Purpose IPv6 Address Block . . . . . . . . . . 5 63 2.13. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Intellectual Property and Copyright Statements . . . . . . . . . . 8 73 1. Introduction 75 This document describes the global and other specialized IPv6 address 76 blocks.It does not address IPv6 address space assigned to operators 77 and users through the Regional Internet Registries. These 78 descriptions are useful for route and IP filtering, for documentation 79 and other purposes. 81 The document is structured by address types. The document format is 82 similar to [RFC3330]. 84 Some tips about filtering are given, but are not mandatory to 85 implement. 87 The addresses listed in this document must not be hard coded into 88 implementations. 90 2. Address Blocks 92 2.1. Node-scoped Unicast 94 ::1/128 is the loopback address [RFC4291]. 96 ::/128 is the unspecified address [RFC4291]. 98 Addresses within this block should not appear on the public Internet. 100 2.2. IPv4-Mapped Addresses 102 ::FFFF:0:0/96 are the IPv4-mapped addresses [RFC4291]. Addresses 103 within this block should not appear on the public Internet. 105 2.3. IPv4-compatible Addresses 107 ::ipv4-address/96 are the IPv4-compatible addresses [RFC4291]. These 108 addresses are deprecated and should not appear on the public 109 Internet. 111 2.4. Link-scoped Unicast 113 fe80::/10 are the link-local unicast [RFC4291] addresses. Addresses 114 within this block should not appear on the public Internet. 116 2.5. Unique-Local 118 fc00::/7 are the unique-local addresses [RFC4193]. Addresses within 119 this block should not appear by default on the public Internet. 121 Procedure for advertising these addresses are further described in 122 [RFC4193]. 124 2.6. Documentation Prefix 126 The 2001:db8::/32 are the documentation addresses [RFC3849]. They 127 are used for documentation purposes such as user manuals, RFCs, etc. 128 Addresses within this block should not appear on the public Internet. 130 2.7. 6to4 132 2002::/16 are the 6to4 addresses [RFC3056]. The 6to4 addresses may 133 be advertised when the site is running a 6to4 relay or offering a 134 6to4 transit service. However, the provider of this service should 135 be aware of the implications of running such service[RFC3964], which 136 include some specific filtering rules for 6to4. IPv4 addresses 137 disallowed in 6to4 prefixes are listed in section 5.3.1 of [RFC3964]. 139 2.8. Teredo 141 2001::/32 are the Teredo addresses [RFC4380]. The Teredo addresses 142 may be advertised when the site is running a Teredo relay or offering 143 a Teredo transit service. 145 2.9. 6bone 147 5f00::/8 were the addresses of the first instance of the 6bone 148 experimental network [RFC1897]. 150 3ffe::/16 were the addresses of the second instance of the 6bone 151 experimental network [RFC2471]. 153 Both 5f00::/8 and 3ffe::/16 were returned to IANA [RFC3701]. These 154 addresses are subject to future allocation, similar to current 155 unallocated address space. Addresses within this block should not 156 appear on the public Internet until they are reallocated. 158 2.10. ORCHID 160 2001:10::/28 are ORCHID addresses [RFC4843]. These addresses are 161 used as identifiers and are not routable at the IP layer. Addresses 162 within this block should not appear on the public Internet. 164 2.11. Default Route 166 ::/0 is the default unicast route address. 168 2.12. IANA Special Purpose IPv6 Address Block 170 An IANA registry (iana-ipv6-special-registry) is set [RFC4773] for 171 Special Purpose IPv6 address blocks assignments used for experiments 172 and other purposes. Addresses within this registry should be 173 reviewed for Internet routing considerations. 175 2.13. Multicast 177 ff00::/8 are multicast addresses [RFC4291]. They have a 4 bits scope 178 in the address field where only some value are of global scope 179 [RFC4291]. Only addresses with global scope in this block may appear 180 on the public Internet. 182 Multicast routes must not appear in unicast routing tables. 184 3. Security Considerations 186 This document lists addresses and guidelines associated with them. 187 The guidelines should improve the security of networks by the 188 filtering of invalid routing prefixes. 190 4. IANA Considerations 192 To ensure consistency and to provide cross-referencing for the 193 benefit of the community, IANA is requested to insert the following 194 paragraph in the header of the iana-ipv6-special registry. 196 "Other special IPv6 addresses requiring specific considerations for 197 global routing are listed in RFCXXXX." 199 NOTE TO RFC EDITOR and IANA: replace RFCXXXX by the assigned RFC 200 number of this document. 202 5. Acknowledgements 204 Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, 205 Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, 206 Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian 207 Carpenter, Mark Smith, Kevin Loch, Alain Durand, Jim Bound, Peter 208 Sherbin, Bob Hinden, Gert Doering, Niall O'Reilly, Mark Townsley and 209 Jari Arkko have provided input and suggestions to this document. 211 6. References 212 6.1. Normative References 214 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 215 Architecture", RFC 4291, February 2006. 217 6.2. Informative References 219 [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address 220 Allocation", RFC 1897, January 1996. 222 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 223 Allocation", RFC 2471, December 1998. 225 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 226 via IPv4 Clouds", RFC 3056, February 2001. 228 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 229 September 2002. 231 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 232 Allocation) Phaseout", RFC 3701, March 2004. 234 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 235 Reserved for Documentation", RFC 3849, July 2004. 237 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 238 6to4", RFC 3964, December 2004. 240 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 241 Addresses", RFC 4193, October 2005. 243 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 244 Network Address Translations (NATs)", RFC 4380, 245 February 2006. 247 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 248 IPv6 Address Block", RFC 4773, December 2006. 250 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 251 for Overlay Routable Cryptographic Hash Identifiers 252 (ORCHID)", RFC 4843, April 2007. 254 Author's Address 256 Marc Blanchet 257 Viagenie 258 2600 boul. Laurier, suite 625 259 Quebec, QC G1V 4W5 260 Canada 262 Email: Marc.Blanchet@viagenie.ca 263 URI: http://www.viagenie.ca 265 Full Copyright Statement 267 Copyright (C) The IETF Trust (2008). 269 This document is subject to the rights, licenses and restrictions 270 contained in BCP 78, and except as set forth therein, the authors 271 retain all their rights. 273 This document and the information contained herein are provided on an 274 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 275 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 276 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 277 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 278 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 279 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 Intellectual Property 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be 290 found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org. 305 Acknowledgment 307 Funding for the RFC Editor function is provided by the IETF 308 Administrative Support Activity (IASA).