1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
|
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 8190 Juniper Networks
BCP: 153 M. Cotton
Updates: 6890 PTI
Category: Best Current Practice B. Haberman
ISSN: 2070-1721 Johns Hopkins University
L. Vegoda
ICANN
June 2017
Updates to the Special-Purpose IP Address Registries
Abstract
This memo updates the IANA IPv4 and IPv6 Special-Purpose Address
Registries to address issues raised by the definition of a "global"
prefix. It also corrects several errors in registry entries to
ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8190.
Bonica, et al. Best Current Practice [Page 1]
^L
RFC 8190 Special-Purpose Address Registries June 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definition of Globally Reachable . . . . . . . . . . . . 3
2.2. Updates to the IPv4 Special-Purpose Address Registry . . 4
2.3. Updates to the IPv6 Special-Purpose Address Registry . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Normative References . . . . . . . . . . . . . . . . . . 5
4.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Bonica, et al. Best Current Practice [Page 2]
^L
RFC 8190 Special-Purpose Address Registries June 2017
1. Introduction
In order to support new protocols and practices, the IETF
occasionally reserves an address block for a special purpose. For
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to
represent the local (i.e., "this") network. Likewise, [RFC4291]
reserves an IPv6 address block (fe80::/10) for link-local unicast
addresses.
Several issues have been raised with the documentation of some of the
special-purpose address blocks in [RFC6890]. Specifically, the
definition of "global" provided in [RFC6890] was misleading as it
slightly differed from the generally accepted definition of "global
scope" (i.e., the ability to forward beyond the boundaries of an
administrative domain, described as "global unicast" in the IPv6
addressing architecture [RFC4291]).
This memo updates the definition of "global" from [RFC6890] for the
IPv4 and IPv6 Special-Purpose Address Registries, augments the fields
contained within the registries in order to address the confusion
raised by the definition of "global", and corrects some errors in
some of the entries in the Special-Purpose Address Registries.
This memo updates [RFC6890].
2. IANA Considerations
2.1. Definition of Globally Reachable
[RFC6890] defined the term "global" without taking into consideration
the multiple uses of the term. Specifically, IP addresses can be
global in terms of allocation scope as well as global in terms of
routing/reachability. To address this ambiguity, the use of the term
"global" defined in [RFC6890] is replaced with "globally reachable".
The following definition replaces the definition of "global" in the
IANA Special-Purpose Address Registries:
o Globally Reachable - A boolean value indicating whether an IP
datagram whose destination address is drawn from the allocated
special-purpose address block is forwardable beyond a specified
administrative domain.
The same relationship between the value of "Destination" and the
values of "Forwardable" and "Global" described in [RFC6890] holds for
"Globally Reachable". If the value of "Destination" is FALSE, the
values of "Forwardable" and "Globally Reachable" must also be FALSE.
Bonica, et al. Best Current Practice [Page 3]
^L
RFC 8190 Special-Purpose Address Registries June 2017
The "Global" columns in the IPv4 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv4-special-registry) and the
IPv6 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv6-special-registry) have
been renamed to "Globally Reachable".
2.2. Updates to the IPv4 Special-Purpose Address Registry
o Limited Broadcast prefix (255.255.255.255/32) - The Reserved-by-
Protocol value has changed from False to True. This change was
made to align the registry with reservation of the limited
broadcast address with Section 7 of [RFC919].
2.3. Updates to the IPv6 Special-Purpose Address Registry
The following changes to the "IPv6 Special-Purpose Address Registry"
involved the insertion of two new footnotes. These additions
required that the footnotes be renumbered.
o TEREDO prefix (2001::/32) - The Globally Reachable value has
changed from False to "N/A [2]". The [2] footnote now states:
* See Section 5 of [RFC4380] for details.
o EID Space for LISP (2001:5::/32) - All footnotes have been
incremented by 1.
o 6to4 (2002::/16) - All footnotes have been incremented by 1.
o Unique-Local (fc00::/7) - The Globally Reachable value has changed
from False to "False [7]". The [7] footnote now states:
* See [RFC4193] for more details on the routability of Unique-
Local addresses. The Unique-Local prefix is drawn from the
IPv6 Global Unicast Address range but is specified as not
globally routed.
3. Security Considerations
This document does not raise any security issues beyond those
discussed in [RFC6890].
Bonica, et al. Best Current Practice [Page 4]
^L
RFC 8190 Special-Purpose Address Registries June 2017
4. References
4.1. Normative References
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
4.2. Informative References
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<http://www.rfc-editor.org/info/rfc919>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
Acknowledgements
Brian Carpenter and C.M. Heard provided useful comments on initial
draft versions of this document. Daniel Migault provided an in-depth
review that helped strengthen the text within the document. Amanda
Baber and Sabrina Tanamal asked questions which resulted in the
authors simplifying the document.
Bonica, et al. Best Current Practice [Page 5]
^L
RFC 8190 Special-Purpose Address Registries June 2017
Authors' Addresses
Ronald Bonica
Juniper Networks
Email: rbonica@juniper.net
Michelle Cotton
PTI, an affiliate of ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Phone: +1-424-254-5300
Email: michelle.cotton@iana.org
Brian Haberman
Johns Hopkins University
Email: brian@innovationslab.net
Leo Vegoda
ICANN
Email: leo.vegoda@icann.org
Bonica, et al. Best Current Practice [Page 6]
^L
|
