idnits 2.17.1 draft-ietf-v6ops-rfc3330-for-ipv6-00.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 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 251. 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 (March 20, 2007) is 6246 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 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 March 20, 2007 5 Expires: September 21, 2007 7 Special-Use IPv6 Addresses 8 draft-ietf-v6ops-rfc3330-for-ipv6-00.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 September 21, 2007. 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 Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 52 2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3 53 2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 54 2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 55 2.5. Documentation Prefix . . . . . . . . . . . . . . . . . . . 3 56 2.6. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.7. Teredo . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.8. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.9. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 Intellectual Property and Copyright Statements . . . . . . . . . . 7 68 1. Introduction 70 This document describes the global and other specialized IPv6 address 71 blocks.It does not address IPv6 address space assigned to operators 72 and users through the Regional Internet Registries. These 73 descriptions are useful for route and IP filtering, for documentation 74 and other purposes. 76 The document is structured by address types. 78 Some tips about filtering are given, but are not mandatory to 79 implement. 81 2. Address Types 83 2.1. Node-scoped Unicast 85 ::1/128 is the loopback address [RFC4291]. 87 ::/128 is the unspecified address [RFC4291]. 89 The node-scoped unicast addresses should not be advertised and should 90 be filtered out when received. 92 2.2. IPv4-Mapped Addresses 94 ::FFFF:0:0/96 is the IPv4-mapped addresses [RFC4291]. IPv4-mapped 95 addresses should not be advertised and should be filtered out when 96 received. 98 2.3. Link-scoped Unicast 100 fe80::/10 are the link-local unicast[RFC4291] addresses.Link-local 101 addresses should not be advertised and should be filtered out when 102 received. 104 2.4. Site-scoped Unicast 106 fc00::/7 are the unique-local addresses [RFC4193]. Unique-local 107 addresses should not be adverstied on the public Internet. 109 2.5. Documentation Prefix 111 The 2001:0db8::/32 are the documentation addresses [RFC3849]. They 112 are used for documentation purposes such as user manuals, RFCs, etc. 113 Documentation addresses should not be advertised and should be 114 filtered out when received. 116 2.6. 6to4 118 2002::/16 are the 6to4 addresses [RFC4291][RFC3056]. The 6to4 119 addresses may be advertised when the site is running a 6to4 relay or 120 offering a 6to4 transit service. However, the provider of this 121 service should be aware of the implications of running such 122 service[RFC3964], which includes some specific filtering rules for 123 6to4. 125 2.7. Teredo 127 2001::/32 are the Teredo addresses [RFC4380]. The Teredo addresses 128 may be advertised when the site is running a Teredo relay or offering 129 a Teredo transit service. 131 2.8. 6bone 133 5f00::/8 were the addresses of the first instance of the 6bone 134 experimental network [RFC1897]. 136 3ffe::/16 were the addresses of the second instance of the 6bone 137 experimental network [RFC2471]. 139 Both 5f00::/8 and 3ffe::/16 were returned to IANA [RFC3701]. These 140 addresses are subject to future allocation, similar to current 141 unallocated address space. These addresses should not be advertised 142 and should be filtered out when received until they are reallocated. 144 2.9. Default Route 146 ::/0 is the default unicast route address. 148 2.10. Multicast 150 ff00::/8 are multicast addresses [RFC4291]. They have a 4 bits scope 151 in the address field. Only addresses having the 'E' value in the 152 scope field are of global scope, all other values are local or 153 reserved. Therefore, only ffXe:: routes may be advertised outside a 154 site, where X may be any value. 156 Multicast routes must not appear in unicast routing tables. 158 3. Security Considerations 160 This document list addresses and guidelines associated with them. 161 The guidelines should improve the security of networks by the 162 filtering of invalid routing prefixes. 164 4. IANA Considerations 166 This document has no actions for IANA. 168 5. Acknowledgements 170 Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, 171 Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, 172 Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian 173 Carpenter, Mark Smith, Kevin Loch and Alain Durand have provided 174 input and suggestions to this document. 176 6. Informative References 178 [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address 179 Allocation", RFC 1897, January 1996. 181 [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 182 Allocation", RFC 2471, December 1998. 184 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 185 via IPv4 Clouds", RFC 3056, February 2001. 187 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 188 Allocation) Phaseout", RFC 3701, March 2004. 190 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 191 Reserved for Documentation", RFC 3849, July 2004. 193 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 194 6to4", RFC 3964, December 2004. 196 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 197 Addresses", RFC 4193, October 2005. 199 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 200 Architecture", RFC 4291, February 2006. 202 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 203 Network Address Translations (NATs)", RFC 4380, 204 February 2006. 206 Author's Address 208 Marc Blanchet 209 Viagenie 211 Email: Marc.Blanchet@viagenie.ca 213 Full Copyright Statement 215 Copyright (C) The IETF Trust (2007). 217 This document is subject to the rights, licenses and restrictions 218 contained in BCP 78, and except as set forth therein, the authors 219 retain all their rights. 221 This document and the information contained herein are provided on an 222 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 223 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 224 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 225 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 226 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 227 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 229 Intellectual Property 231 The IETF takes no position regarding the validity or scope of any 232 Intellectual Property Rights or other rights that might be claimed to 233 pertain to the implementation or use of the technology described in 234 this document or the extent to which any license under such rights 235 might or might not be available; nor does it represent that it has 236 made any independent effort to identify any such rights. Information 237 on the procedures with respect to rights in RFC documents can be 238 found in BCP 78 and BCP 79. 240 Copies of IPR disclosures made to the IETF Secretariat and any 241 assurances of licenses to be made available, or the result of an 242 attempt made to obtain a general license or permission for the use of 243 such proprietary rights by implementers or users of this 244 specification can be obtained from the IETF on-line IPR repository at 245 http://www.ietf.org/ipr. 247 The IETF invites any interested party to bring to its attention any 248 copyrights, patents or patent applications, or other proprietary 249 rights that may cover technology that may be required to implement 250 this standard. Please address the information to the IETF at 251 ietf-ipr@ietf.org. 253 Acknowledgment 255 Funding for the RFC Editor function is provided by the IETF 256 Administrative Support Activity (IASA).