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
|
<pre>Network Working Group P. Savola
Request for Comments: 3627 CSC/FUNET
Category: Informational September 2003
<span class="h1">Use of /127 Prefix Length Between Routers Considered Harmful</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
In some cases, the operational decision may be to use IPv6 /127
prefix lengths, especially on point-to-point links between routers.
Under certain situations, this may lead to one router claiming both
addresses due to subnet-router anycast being implemented. This
document discusses the issue and offers a couple of solutions to the
problem; nevertheless, /127 should be avoided between two routers.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-ADDRARCH">ADDRARCH</a>] defines Subnet-router anycast address: in a subnet prefix
of n bits, the last 128-n bits are all zero. It is meant to be in
use of any one router in the subnet.
Even though having prefix length longer than /64 is forbidden by
[<a href="#ref-ADDRARCH" title=""IP Version 6 (IPv6) Addressing Architecture"">ADDRARCH</a>] <a href="#section-2.4">section 2.4</a> for non-000/3 unicast prefixes, using /127
prefix length has gained a lot of operational popularity; it seems
like that these prefix lengths are being used heavily in point-to-
point links. The operational practise has often been to use the
least amount of address space especially in the presence of a large
number of point-to-point links; it may be unlikely that all of these
links would start to use /64's. Using /127 has also other
operational benefits: you always know which address the other end
uses, and there is no "ping-pong" [<a href="#ref-PINGPONG" title=""Avoiding ping-pong packets on point-to-point links"">PINGPONG</a>] problem with older ICMP
implementations (fixed now in [<a href="#ref-ICMPv3" title=""Internet Control Message Protocol (ICMPv6)"">ICMPv3</a>]).
<span class="grey">Savola Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3627">RFC 3627</a> /127 Prefix Length Considered Harmful September 2003</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Scope of this Memo</span>
This memo does not advocate the use of long prefixes, but brings up
problems for those that do want to use them, for one reason or
another.
Detailed discussion on what is the "right" solution is out of the
scope; it is not the goal of this memo to try to find the "best"
addressing solution for everyone.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problem with /127 and Two Routers</span>
Note that this problem does not exist between a router and a host,
assuming the PREFIX::0/127 address is assigned to the router.
Using /127 can be especially harmful on a point-to-point link when
Subnet-router anycast address is implemented. Consider the following
sequence of events:
1. Router A and Router B are connected by a point-to-point link.
2. Neither has anything configured or set up on this link.
3. 3ffe:ffff::1/127 address is added to Router A; now it performs
Duplicate Address Detection (DAD) [<a href="#ref-NDISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">NDISC</a>] for 3ffe:ffff::1.
Router A also adds the Subnet-router anycast address
3ffe:ffff::0/127. (DAD is not performed for anycast addresses.)
4. Now Router B has been planned and configured to use
3ffe:ffff::0/127 as its unicast IPv6 address, but adding it will
fail DAD, and Router B does not have any address.
Similar scenarios also happen during router reboots, crashes and
such.
The usability of subnet-router anycast address between two routers on
a point-to-point link is very questionable, but it is still a
mandated feature of [<a href="#ref-ADDRARCH" title=""IP Version 6 (IPv6) Addressing Architecture"">ADDRARCH</a>]. Workarounds for this are presented
in the next section.
As of yet, this kind of unexpected behavior hasn't been seen at large
perhaps because the Subnet-router anycast address hasn't been
implemented or too widely used.
<span class="grey">Savola Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3627">RFC 3627</a> /127 Prefix Length Considered Harmful September 2003</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Solutions</span>
1. One could use /64 for subnets, including point-to-point links.
2. One could use only link-local addresses, but that may make network
maintenance and debugging impractical at least in bigger networks;
for example, "traceroute" can only return a list of nodes on the
path, not the links which would have been used.
3. Failing that, /126 does not have this problem, and it can be used
safely on a point-to-point link (e.g., using the 2nd and the 3rd
address for unicast). This is analogous to using /30 for IPv4.
Using two /128 addresses is also one, though often cumbersome,
approach. Naturally, not much would be lost if even a shorter
prefix was used, e.g., /112 or /120.
The author feels that if /64 cannot be used, /112, reserving the
last 16 bits for node identifiers, has probably the least amount
of drawbacks (also see <a href="#section-3">section 3</a>).
4. [<a href="#ref-ADDRARCH" title=""IP Version 6 (IPv6) Addressing Architecture"">ADDRARCH</a>] could be revised to state that Subnet-router anycast
address should not be used if the prefix length of the link is not
/64 (or even longer than /120). This does not seem like a good
approach, as we should avoid making assumptions about prefix
lengths in the specifications, to maintain future flexibility.
Also, in some cases, it might be usable to have a Subnet-router
anycast address in some networks with a longer prefix length.
A more conservative (implementation) approach would be not using
Subnet-router anycast addresses in subnets with a prefix length of
/127 if there are only two routers on the link: this can be
noticed with [<a href="#ref-NDISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">NDISC</a>] 'Router' bit in Neighbor Advertisement
messages. However, this seems to overload the functionality of
'R' bit, so it does not look like a good approach in the long run.
5. It's also possible to improve implementations: if /127 is used on
a point-to-point link, never claim two addresses. This has the
drawback that even if the router using the combined unicast and
anycast address is down, the packets to subnet-router anycast
address will be lost as the other cannot claim the address. This
approach might lead to unpredictability which would be hard to
trace when debugging problems. However, this would normally be an
issue only when the Subnet-router anycast address is used from
outside of the link; usually, this cannot be done reliably as the
prefix length or EUI64 u/g bits cannot be known for certain.
There are other problems with an address being anycast and unicast
<span class="grey">Savola Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3627">RFC 3627</a> /127 Prefix Length Considered Harmful September 2003</span>
too: use of it as a source address, whether to use unicast or
anycast semantics in [<a href="#ref-NDISC" title=""Neighbor Discovery for IP Version 6 (IPv6)"">NDISC</a>], and others: allowing this behavior
would seem to only add a lot of complexity to the implementations.
1) is definitely the best solution, wherever it is possible. 2) may
be usable in some scenarios, but in larger networks (where the most
often the desire would be to use longer prefix length) it may be
deemed very impractical. There are some situations where one of
these may not be an option; then an operational work-around for this
operational problem, that is 3), appears to be the best course of
action. This is because it may be very difficult to know whether all
implementations implement some checks, like ones described in 4) or
5).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Other Problems with Long Prefixes</span>
These issues are not specific to /127.
One should note that [<a href="#ref-ADDRARCH" title=""IP Version 6 (IPv6) Addressing Architecture"">ADDRARCH</a>] specifies universal/local bits (u/g),
which are the 70th and 71st bits in any address from non-000/3 range.
When assigning prefixes longer than 64 bits, these should be taken
into consideration; in almost every case, u should be 0, as the last
64 bits of a long prefix is very rarely unique. 'G' is still
unspecified, but defaults to zero. Thus, all prefixes with u or g=1
should be avoided.
[<a id="ref-MIPV6">MIPV6</a>] specifies "Mobile IPv6 Home-Agents" anycast address which is
used for Home Agent Discovery. In consequence, 7 last bits of have
been reserved in [<a href="#ref-ANYCAST" title=""Reserved IPv6 Subnet Anycast Addresses"">ANYCAST</a>] of every non-000/3 non-multicast address,
similar to [<a href="#ref-ADDRARCH" title=""IP Version 6 (IPv6) Addressing Architecture"">ADDRARCH</a>]. Thus, at least /120 would seem to make sense.
However, as the sender must know the destination's prefix length,
this "reserved anycast addresses" mechanism is only applicable when
the sender knows about the link and expects that there is a service
it needs there. In the case of e.g., /126 between routers, the only
to node to be found on this link would be the other router, so the
mechanism does not seem useful. At least, Mobile IPv6 Home Agent
Discovery should not be performed if the prefix length is longer than
/120.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-ADDRARCH">ADDRARCH</a>] Hinden, R. and S. Deering, "IP Version 6 (IPv6)
Addressing Architecture", <a href="./rfc3513">RFC 3513</a>, April 2003.
[<a id="ref-ANYCAST">ANYCAST</a>] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", <a href="./rfc2526">RFC 2526</a>, March 1999.
<span class="grey">Savola Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3627">RFC 3627</a> /127 Prefix Length Considered Harmful September 2003</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-NDISC">NDISC</a>] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December
1998.
[<a id="ref-MIPV6">MIPV6</a>] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", Work in Progress.
[<a id="ref-ICMPv3">ICMPv3</a>] Conta, A., Deering, S., "Internet Control Message
Protocol (ICMPv6)", Work in Progress.
[<a id="ref-PINGPONG">PINGPONG</a>] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong
packets on point-to-point links", Work in Progress.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Beyond those already existing in other specifications, solution 4)
might lead to denial of service in the case that one router is down:
the packet to subnet-router anycast address would be lost.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Thanks to Robert Elz and many others on the IPv6 Working Group for
discussion, and Alain Durand for pointing out [<a href="#ref-ADDRARCH" title=""IP Version 6 (IPv6) Addressing Architecture"">ADDRARCH</a>] requirements
for prefix lengths. Charles Perkins pointed out MIPv6 HA
requirements. Randy Bush and Ole Troan commented on the document
extensively, and Erik Nordmark pointed out issues with u-bit.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Author's Address</span>
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
<span class="grey">Savola Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3627">RFC 3627</a> /127 Prefix Length Considered Harmful September 2003</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Savola Informational [Page 6]
</pre>
|
