idnits 2.17.1 draft-ietf-v6ops-rfc3330-for-ipv6-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 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. 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 (July 9, 2007) is 6126 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 2373 (Obsoleted by RFC 3513) -- 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 (==), 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 July 9, 2007 5 Expires: January 10, 2008 7 Special-Use IPv6 Addresses 8 draft-ietf-v6ops-rfc3330-for-ipv6-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 January 10, 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 [RFC2373]. 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. 134 2.8. Teredo 136 2001::/32 are the Teredo addresses [RFC4380]. The Teredo addresses 137 may be advertised when the site is running a Teredo relay or offering 138 a Teredo transit service. 140 2.9. 6bone 142 5f00::/8 were the addresses of the first instance of the 6bone 143 experimental network [RFC1897]. 145 3ffe::/16 were the addresses of the second instance of the 6bone 146 experimental network [RFC2471]. 148 Both 5f00::/8 and 3ffe::/16 were returned to IANA [RFC3701]. These 149 addresses are subject to future allocation, similar to current 150 unallocated address space. Addresses within this block should not 151 appear on the public Internet until they are reallocated. 153 2.10. Default Route 155 ::/0 is the default unicast route address. 157 2.11. IANA Special Purpose IPv6 Address Block 159 An IANA registry (iana-ipv6-special-registry) is set[RFC4773] for 160 Special Purpose IPv6 address blocks assignments used for experiments 161 and other purposes. Addresses within this registry should be 162 reviewed for Internet routing considerations. 164 2.12. Multicast 166 ff00::/8 are multicast addresses [RFC4291]. They have a 4 bits scope 167 in the address field where only some value are of global scope 168 [RFC4291]. Only addresses with global scope in this block may appear 169 on the public Internet. 171 Multicast routes must not appear in unicast routing tables. 173 3. Security Considerations 175 This document list addresses and guidelines associated with them. 176 The guidelines should improve the security of networks by the 177 filtering of invalid routing prefixes. 179 4. IANA Considerations 181 This document has no actions for IANA. 183 5. Acknowledgements 185 Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, 186 Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, 187 Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian 188 Carpenter, Mark Smith, Kevin Loch, Alain Durand, Jim Bound, Peter 189 Sherbin and Bob Hinden have provided input and suggestions to this 190 document. 192 6. References 194 6.1. Normative References 196 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 197 Architecture", RFC 4291, February 2006. 199 6.2. Informative References 201 [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address 202 Allocation", RFC 1897, January 1996. 204 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 205 Architecture", RFC 2373, July 1998. 207 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 208 Allocation", RFC 2471, December 1998. 210 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 211 via IPv4 Clouds", RFC 3056, February 2001. 213 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 214 September 2002. 216 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 217 Allocation) Phaseout", RFC 3701, March 2004. 219 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 220 Reserved for Documentation", RFC 3849, July 2004. 222 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 223 6to4", RFC 3964, December 2004. 225 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 226 Addresses", RFC 4193, October 2005. 228 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 229 Network Address Translations (NATs)", RFC 4380, 230 February 2006. 232 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 233 IPv6 Address Block", RFC 4773, December 2006. 235 Author's Address 237 Marc Blanchet 238 Viagenie 239 2875 boul. Laurier, suite 1150 240 Quebec, QC G1V 2M2 241 Canada 243 Email: Marc.Blanchet@viagenie.ca 244 URI: http://www.viagenie.ca 246 Full Copyright Statement 248 Copyright (C) The IETF Trust (2007). 250 This document is subject to the rights, licenses and restrictions 251 contained in BCP 78, and except as set forth therein, the authors 252 retain all their rights. 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 257 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 258 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 259 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Intellectual Property 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the procedures with respect to rights in RFC documents can be 271 found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at 284 ietf-ipr@ietf.org. 286 Acknowledgment 288 Funding for the RFC Editor function is provided by the IETF 289 Administrative Support Activity (IASA).