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 5681 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.