idnits 2.17.1 draft-ietf-v6ops-rfc3330-for-ipv6-02.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 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. 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 3, 2007) is 6047 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 3, 2007 5 Expires: April 5, 2008 7 Special-Use IPv6 Addresses 8 draft-ietf-v6ops-rfc3330-for-ipv6-02.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 5, 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. 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, Bob Hinden, Gert Doering and Niall O'Reilly have provided 190 input and suggestions to this 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 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 205 Allocation", RFC 2471, December 1998. 207 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 208 via IPv4 Clouds", RFC 3056, February 2001. 210 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 211 September 2002. 213 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 214 Allocation) Phaseout", RFC 3701, March 2004. 216 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 217 Reserved for Documentation", RFC 3849, July 2004. 219 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 220 6to4", RFC 3964, December 2004. 222 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 223 Addresses", RFC 4193, October 2005. 225 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 226 Network Address Translations (NATs)", RFC 4380, 227 February 2006. 229 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 230 IPv6 Address Block", RFC 4773, December 2006. 232 Author's Address 234 Marc Blanchet 235 Viagenie 236 2875 boul. Laurier, suite 1150 237 Quebec, QC G1V 2M2 238 Canada 240 Email: Marc.Blanchet@viagenie.ca 241 URI: http://www.viagenie.ca 243 Full Copyright Statement 245 Copyright (C) The IETF Trust (2007). 247 This document is subject to the rights, licenses and restrictions 248 contained in BCP 78, and except as set forth therein, the authors 249 retain all their rights. 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 254 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 255 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 256 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Intellectual Property 261 The IETF takes no position regarding the validity or scope of any 262 Intellectual Property Rights or other rights that might be claimed to 263 pertain to the implementation or use of the technology described in 264 this document or the extent to which any license under such rights 265 might or might not be available; nor does it represent that it has 266 made any independent effort to identify any such rights. Information 267 on the procedures with respect to rights in RFC documents can be 268 found in BCP 78 and BCP 79. 270 Copies of IPR disclosures made to the IETF Secretariat and any 271 assurances of licenses to be made available, or the result of an 272 attempt made to obtain a general license or permission for the use of 273 such proprietary rights by implementers or users of this 274 specification can be obtained from the IETF on-line IPR repository at 275 http://www.ietf.org/ipr. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at 281 ietf-ipr@ietf.org. 283 Acknowledgment 285 Funding for the RFC Editor function is provided by the IETF 286 Administrative Support Activity (IASA).