idnits 2.17.1 draft-ietf-v6ops-rfc3330-for-ipv6-03.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 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 5, 2007) is 6045 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 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 October 5, 2007 5 Expires: April 7, 2008 7 Special-Use IPv6 Addresses 8 draft-ietf-v6ops-rfc3330-for-ipv6-03.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 April 7, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.11. IANA Special Purpose IPv6 Address Block . . . . . . . . . . 4 62 2.12. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Intellectual Property and Copyright Statements . . . . . . . . . . 7 72 1. Introduction 74 This document describes the global and other specialized IPv6 address 75 blocks.It does not address IPv6 address space assigned to operators 76 and users through the Regional Internet Registries. These 77 descriptions are useful for route and IP filtering, for documentation 78 and other purposes. 80 The document is structured by address types. The document format is 81 similar to [RFC3330]. 83 Some tips about filtering are given, but are not mandatory to 84 implement. 86 2. Address Blocks 88 2.1. Node-scoped Unicast 90 ::1/128 is the loopback address [RFC4291]. 92 ::/128 is the unspecified address [RFC4291]. 94 Addresses within this block should not appear on the public Internet. 96 2.2. IPv4-Mapped Addresses 98 ::FFFF:0:0/96 is the IPv4-mapped addresses [RFC4291]. Addresses 99 within this block should not appear on the public Internet. 101 2.3. IPv4-compatible Addresses 103 ::ipv4-address/96 is the IPv4-compatible addresses [RFC4291]. These 104 addresses are deprecated and should not appear on the public 105 Internet. 107 2.4. Link-scoped Unicast 109 fe80::/10 are the link-local unicast[RFC4291] addresses.Addresses 110 within this block should not appear on the public Internet. 112 2.5. Unique-Local 114 fc00::/7 are the unique-local addresses [RFC4193]. Addresses within 115 this block should not appear by default on the public Internet. 116 Procedure of advertising these addresses are further described in 117 [RFC4193]. 119 2.6. Documentation Prefix 121 The 2001:db8::/32 are the documentation addresses [RFC3849]. They 122 are used for documentation purposes such as user manuals, RFCs, etc. 123 Addresses within this block should not appear on the public Internet. 125 2.7. 6to4 127 2002::/16 are the 6to4 addresses [RFC4291][RFC3056]. The 6to4 128 addresses may be advertised when the site is running a 6to4 relay or 129 offering a 6to4 transit service. However, the provider of this 130 service should be aware of the implications of running such 131 service[RFC3964], which includes some specific filtering rules for 132 6to4. IPv4 addresses disallowed in 6to4 prefixes are listed in 133 section 5.3.1 of [RFC3964]. 135 2.8. Teredo 137 2001::/32 are the Teredo addresses [RFC4380]. The Teredo addresses 138 may be advertised when the site is running a Teredo relay or offering 139 a Teredo transit service. 141 2.9. 6bone 143 5f00::/8 were the addresses of the first instance of the 6bone 144 experimental network [RFC1897]. 146 3ffe::/16 were the addresses of the second instance of the 6bone 147 experimental network [RFC2471]. 149 Both 5f00::/8 and 3ffe::/16 were returned to IANA [RFC3701]. These 150 addresses are subject to future allocation, similar to current 151 unallocated address space. Addresses within this block should not 152 appear on the public Internet until they are reallocated. 154 2.10. Default Route 156 ::/0 is the default unicast route address. 158 2.11. IANA Special Purpose IPv6 Address Block 160 An IANA registry (iana-ipv6-special-registry) is set[RFC4773] for 161 Special Purpose IPv6 address blocks assignments used for experiments 162 and other purposes. Addresses within this registry should be 163 reviewed for Internet routing considerations. 165 2.12. Multicast 167 ff00::/8 are multicast addresses [RFC4291]. They have a 4 bits scope 168 in the address field where only some value are of global scope 169 [RFC4291]. Only addresses with global scope in this block may appear 170 on the public Internet. 172 Multicast routes must not appear in unicast routing tables. 174 3. Security Considerations 176 This document list addresses and guidelines associated with them. 177 The guidelines should improve the security of networks by the 178 filtering of invalid routing prefixes. 180 4. IANA Considerations 182 This document has no actions for IANA. 184 5. Acknowledgements 186 Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, 187 Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, 188 Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian 189 Carpenter, Mark Smith, Kevin Loch, Alain Durand, Jim Bound, Peter 190 Sherbin, Bob Hinden, Gert Doering and Niall O'Reilly have provided 191 input and suggestions to this document. 193 6. References 195 6.1. Normative References 197 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 198 Architecture", RFC 4291, February 2006. 200 6.2. Informative References 202 [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address 203 Allocation", RFC 1897, January 1996. 205 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 206 Allocation", RFC 2471, December 1998. 208 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 209 via IPv4 Clouds", RFC 3056, February 2001. 211 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 212 September 2002. 214 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 215 Allocation) Phaseout", RFC 3701, March 2004. 217 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 218 Reserved for Documentation", RFC 3849, July 2004. 220 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 221 6to4", RFC 3964, December 2004. 223 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 224 Addresses", RFC 4193, October 2005. 226 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 227 Network Address Translations (NATs)", RFC 4380, 228 February 2006. 230 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 231 IPv6 Address Block", RFC 4773, December 2006. 233 Author's Address 235 Marc Blanchet 236 Viagenie 237 2875 boul. Laurier, suite 1150 238 Quebec, QC G1V 2M2 239 Canada 241 Email: Marc.Blanchet@viagenie.ca 242 URI: http://www.viagenie.ca 244 Full Copyright Statement 246 Copyright (C) The IETF Trust (2007). 248 This document is subject to the rights, licenses and restrictions 249 contained in BCP 78, and except as set forth therein, the authors 250 retain all their rights. 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, THE IETF TRUST AND 255 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 256 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 257 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 260 Intellectual Property 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org. 284 Acknowledgment 286 Funding for the RFC Editor function is provided by the IETF 287 Administrative Support Activity (IASA).