idnits 2.17.1 draft-ietf-idr-as-documentation-reservation-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 151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 175. 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 4, 2008) is 5677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing G. Huston 3 Internet-Draft October 4, 2008 4 Intended status: Informational 5 Expires: April 7, 2009 7 AS Number Reservation for Documentation Use 8 draft-ietf-idr-as-documentation-reservation-00 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, 2009. 35 Abstract 37 To reduce the likelihood of conflict and confusion when relating 38 documented examples to deployed systems, two blocks of Autonomous 39 System numbers (ASNs) are reserved for use in examples in RFCs, 40 books, documentation, and the like. This document describes the 41 reservation of two blocks of ASNs as reserved numbers for use in 42 documentation. 44 1. Introduction 46 To reduce the likelihood of conflict and confusion when relating 47 documented examples to deployed systems, two blocks of Autonomous 48 System numbers (ASNs) are reserved for use in examples in RFCs, 49 books, documentation, and the like. This document describes the 50 reservation of two blocks of ASNs as reserved numbers for use in 51 documentation. 53 The problems such conflicts may cause have already been encountered 54 with IPv4 addresses where literal use of documented examples in a 55 production environment causes address and routing conflicts with 56 existing services. Since private use ASNs already have a context of 57 use in deployed networks, these ASNs cannot be used in many example 58 situations. In making an explicit allocation of a set of AS numbers 59 reserved for documentation use, it is intended that any such 60 operational problems may be avoided in the future. 62 Similar considerations have been applied to IPv4 addresses 63 [IANA.IPv4], IPv6 addresses [RFC3849], and domain names names 64 [RFC2606], and reservations have been made for similar purposes. 66 2. ASNs for Documentation Use 68 To allow documentation to accurately describe deployment examples, 69 the use of public or private-use AS numbers is inappropriate, and a 70 reserved block of AS numbers is required. This ensures that 71 documentation does not clash with public or private use AS numbers in 72 deployed networks, and mitigates the risks to operational integrity 73 of the network through inappropriate use of documentation to perform 74 literal configuration of routing elements on production systems. 76 To allow for examples relating to the transition to use of 32-bit AS 77 numbers to be correctly described a reservation of two blocks of AS 78 numbers is proposed in this document. One reserved block of 16 79 contiguous AS numbers is to lie in the range of numbers that can be 80 expressed as a 16-bit AS number value (i.e. values less than 65536), 81 and a second reserved block of 16 contiguous AS numbers is to lie in 82 the range of numbers that can only be expressed as 32-bit AS numbers 83 (values greater than 65535). 85 3. Operational Implications 87 This assignment implies that BGP operational configurations should 88 not peer with neighboring ASes that are numbered from this reserved 89 AS number set. 91 4. IANA Considerations 93 [Note to IANA, not for publication: The IANA may wish to consider 94 reserving the AS numbers 64496 - 64511 and 65536-65551 (1.0 - 1.15 95 using "asdot" notation) for this purpose.] 97 IANA is requested to reserve a contiguous block of 16 Autonomous 98 System numbers from the unallocated number range within the "16-bit" 99 number set, 1 - 64512, and to reserve a contiguous block of 16 100 Autonomous System numbers from the "32-bit" number set, 65536 - 101 4294967294, and documentation this reservation in the IANA AS Number 102 Registry [IANA.AS]. 104 5. Security Considerations 106 AS number reservations do not have any direct impact on Internet 107 infrastructure security. 109 6. Acknowledgements 111 The author acknowledges the work of Tomoya Yoshida, Gaurab Upadhaya 112 and Philip Smith in authoring a policy proposal that was submitted to 113 the APNIC Policy Process in 2008 relating to the reservation of AS 114 numbers for documentation purposes. 116 7. Informative References 118 [IANA.AS] IANA, "Autonomous System (AS) Numbers", Sep 2008, 119 . 121 [IANA.IPv4] 122 IANA, "IPv4 Global Unicast Address Assignments", Sep 2008, 123 . 125 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 126 Names", BCP 32, RFC 2606, June 1999. 128 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 129 Reserved for Documentation", RFC 3849, July 2004. 131 Author's Address 133 Geoff Huston 135 Email: gih@apnic.net 137 Full Copyright Statement 139 Copyright (C) The IETF Trust (2008). 141 This document is subject to the rights, licenses and restrictions 142 contained in BCP 78, and except as set forth therein, the authors 143 retain all their rights. 145 This document and the information contained herein are provided on an 146 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 147 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 148 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 149 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 150 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 151 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 153 Intellectual Property 155 The IETF takes no position regarding the validity or scope of any 156 Intellectual Property Rights or other rights that might be claimed to 157 pertain to the implementation or use of the technology described in 158 this document or the extent to which any license under such rights 159 might or might not be available; nor does it represent that it has 160 made any independent effort to identify any such rights. Information 161 on the procedures with respect to rights in RFC documents can be 162 found in BCP 78 and BCP 79. 164 Copies of IPR disclosures made to the IETF Secretariat and any 165 assurances of licenses to be made available, or the result of an 166 attempt made to obtain a general license or permission for the use of 167 such proprietary rights by implementers or users of this 168 specification can be obtained from the IETF on-line IPR repository at 169 http://www.ietf.org/ipr. 171 The IETF invites any interested party to bring to its attention any 172 copyrights, patents or patent applications, or other proprietary 173 rights that may cover technology that may be required to implement 174 this standard. Please address the information to the IETF at 175 ietf-ipr@ietf.org.