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
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6554 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 D. Culler
UC Berkeley
V. Manral
Hewlett Packard Co.
March 2012
<span class="h1">An IPv6 Routing Header for Source Routes with</span>
<span class="h1">the Routing Protocol for Low-Power and Lossy Networks (RPL)</span>
Abstract
In Low-Power and Lossy Networks (LLNs), memory constraints on routers
may limit them to maintaining, at most, a few routes. In some
configurations, it is necessary to use these memory-constrained
routers to deliver datagrams to nodes within the LLN. The Routing
Protocol for Low-Power and Lossy Networks (RPL) can be used in some
deployments to store most, if not all, routes on one (e.g., the
Directed Acyclic Graph (DAG) root) or a few routers and forward the
IPv6 datagram using a source routing technique to avoid large routing
tables on memory-constrained routers. This document specifies a new
IPv6 Routing header type for delivering datagrams within a RPL
routing domain.
Status of This Memo
This is an Internet Standards Track document.
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
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6554">http://www.rfc-editor.org/info/rfc6554</a>.
<span class="grey">Hui, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Requirements Language ......................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Overview ........................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Format of the RPL Routing Header ................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. RPL Router Behavior .............................................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Generating Source Routing Headers ..........................<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Processing Source Routing Headers ..........................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. Source Routing Attacks ....................................<a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. ICMPv6 Attacks ............................................<a href="#page-12">12</a>
<a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. Acknowledgements ...............................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Routing Protocol for Low-Power and Lossy Networks (RPL) is a
distance vector IPv6 routing protocol designed for Low-Power and
Lossy Networks (LLNs) [<a href="./rfc6550" title=""RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"">RFC6550</a>]. Such networks are typically
constrained in resources (limited communication data rate, processing
power, energy capacity, memory). In particular, some LLN
configurations may utilize LLN routers where memory constraints limit
nodes to maintaining only a small number of default routes and no
other destinations. However, it may be necessary to utilize such
memory-constrained routers to forward datagrams and maintain
reachability to destinations within the LLN.
<span class="grey">Hui, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
To utilize paths that include memory-constrained routers, RPL relies
on source routing. In one deployment model of RPL, more-capable
routers collect routing information and form paths to arbitrary
destinations within a RPL routing domain. However, a source routing
mechanism supported by IPv6 is needed to deliver datagrams.
This document specifies the Source Routing Header (SRH) for use
strictly between RPL routers in the same RPL routing domain. A RPL
routing domain is a collection of RPL routers under the control of a
single administration. The boundaries of routing domains are defined
by network management by setting some links to be exterior, or inter-
domain, links.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview</span>
The format of the SRH draws from that of the Type 0 Routing header
(RH0) [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]. However, the SRH introduces mechanisms to compact
the source route entries when all entries share the same prefix with
the IPv6 Destination Address of a packet carrying an SRH, a typical
scenario in LLNs using source routing. The compaction mechanism
reduces consumption of scarce resources such as channel capacity.
The SRH also differs from RH0 in the processing rules to alleviate
security concerns that led to the deprecation of RH0 [<a href="./rfc5095" title=""Deprecation of Type 0 Routing Headers in IPv6"">RFC5095</a>].
First, RPL routers implement a strict source route policy where each
and every IPv6 hop between the source and destination of the source
route is specified within the SRH. Note that the source route may be
a subset of the path between the actual source and destination and is
discussed further below. Second, an SRH is only used between RPL
routers within a RPL routing domain. RPL Border Routers, responsible
for connecting other RPL routing domains and IP domains that use
other routing protocols, do not allow datagrams already carrying an
SRH header to enter or exit a RPL routing domain. Third, a RPL
router drops datagrams that include multiple addresses assigned to
any interfaces on that router to avoid forwarding loops.
There are two cases that determine how to include an SRH when a RPL
router requires the use of an SRH to deliver a datagram to its
destination.
<span class="grey">Hui, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
1. If the SRH specifies the complete path from source to
destination, the router places the SRH directly in the datagram
itself.
2. If the SRH only specifies a subset of the path from source to
destination, the router uses IPv6-in-IPv6 tunneling [<a href="./rfc2473" title=""Generic Packet Tunneling in IPv6 Specification"">RFC2473</a>] and
places the SRH in the outer IPv6 header. Use of tunneling
ensures that the datagram is delivered unmodified and that ICMP
errors return to the source of the SRH rather than the source of
the original datagram.
In a RPL network, Case 1 occurs when both source and destination are
within a RPL routing domain and a single SRH is used to specify the
entire path from source to destination, as shown in the following
figure:
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
RPL Routing Domain
In the above scenario, datagrams traveling from source, S, to
destination, D, have the following packet structure:
+--------+---------+-------------//-+
| IPv6 | Source | IPv6 |
| Header | Routing | Payload |
| | Header | |
+--------+---------+-------------//-+
S's address is carried in the IPv6 header's Source Address field.
D's address is carried in the last entry of the SRH for all but the
last hop, when D's address is carried in the IPv6 header's
Destination Address field of the packet carrying the SRH.
In a RPL network, Case 2 occurs for all datagrams that have a source
and/or destination outside the RPL routing domain, as shown in the
following diagram:
<span class="grey">Hui, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) ------------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
In the scenarios above, R may indicate a RPL Border Router (when
connecting to other routing domains) or a RPL Router (when connecting
to hosts). The datagrams have the following structure when traveling
within the RPL routing domain:
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
Note that the outer header (including the SRH) is added and removed
by the RPL router.
Case 2 also occurs whenever a RPL router needs to insert a source
route when forwarding a datagram. One such use case with RPL is to
have all RPL traffic flow through a Border Router and have the Border
Router use source routes to deliver datagrams to their final
destination. When including the SRH using tunneled mode, the Border
Router would encapsulate the received datagram unmodified using IPv6-
in-IPv6 and include an SRH in the outer IPv6 header.
<span class="grey">Hui, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
+-----------------+
| |
| (S) -------\ |
| \ |
| (LBR)
| / |
| (D) <------/ |
| |
+-----------------+
RPL Routing Domain
In the above scenario, datagrams travel from S to D through the Low-
Power and Lossy Network Border Router (LBR). Between S and the LBR,
the datagrams are routed using the DAG built by the RPL and do not
contain an SRH. The LBR encapsulates received datagrams unmodified
using IPv6-in-IPv6 and the SRH is included in the outer IPv6 header.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Format of the RPL Routing Header</span>
The Source Routing Header has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header
immediately following the Routing header. Uses
the same values as the IPv6 Next Header field
[<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>].
Hdr Ext Len 8-bit unsigned integer. Length of the Routing
header in 8-octet units, not including the first
8 octets. Note that when Addresses[1..n] are
compressed (i.e., value of CmprI or CmprE is not
0), Hdr Ext Len does not equal twice the number
of Addresses.
<span class="grey">Hui, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
Routing Type 8-bit selector. Identifies the particular
Routing header variant. An SRH should set the
Routing Type to 3.
Segments Left 8-bit unsigned integer. Number of route segments
remaining, i.e., number of explicitly listed
intermediate nodes still to be visited before
reaching the final destination. The originator
of an SRH sets this field to n, the number of
addresses contained in Addresses[1..n].
CmprI 4-bit unsigned integer. Number of prefix octets
from each segment, except than the last segment,
(i.e., segments 1 through n-1) that are elided.
For example, an SRH carrying full IPv6 addresses
in Addresses[1..n-1] sets CmprI to 0.
CmprE 4-bit unsigned integer. Number of prefix octets
from the last segment (i.e., segment n) that are
elided. For example, an SRH carrying a full IPv6
address in Addresses[n] sets CmprE to 0.
Pad 4-bit unsigned integer. Number of octets that
are used for padding after Address[n] at the end
of the SRH.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Address[1..n] Vector of addresses, numbered 1 to n. Each
vector element in [1..n-1] has size (16 - CmprI)
and element [n] has size (16-CmprE). The
originator of an SRH places the next (first)
hop's IPv6 address in the IPv6 header's IPv6
Destination Address and the second hop's IPv6
address as the first address in Address[1..n]
(i.e., Address[1]).
The SRH shares the same basic format as the Type 0 Routing header
[<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]. When carrying full IPv6 addresses, the CmprI, CmprE, and
Pad fields are set to 0 and the only difference between the SRH and
Type 0 encodings is the value of the Routing Type field.
A common network configuration for a RPL routing domain is that all
routers within a RPL routing domain share a common prefix. The SRH
introduces the CmprI, CmprE, and Pad fields to allow compaction of
the Address[1..n] vector when all entries share the same prefix as
<span class="grey">Hui, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
the IPv6 Destination Address field of the packet carrying the SRH.
The CmprI and CmprE fields indicate the number of prefix octets that
are shared with the IPv6 Destination Address of the packet carrying
the SRH. The shared prefix octets are not carried within the Routing
header and each entry in Address[1..n-1] has size (16 - CmprI) octets
and Address[n] has size (16 - CmprE) octets. When CmprI or CmprE is
non-zero, there may exist unused octets between the last entry,
Address[n], and the end of the Routing header. The Pad field
indicates the number of unused octets that are used for padding.
Note that when CmprI and CmprE are both 0, Pad MUST carry a value of
0.
The SRH MUST NOT specify a path that visits a node more than once.
When generating an SRH, the source may not know the mapping between
IPv6 addresses and nodes. Minimally, the source MUST ensure that
IPv6 addresses do not appear more than once and the IPv6 Source and
Destination addresses of the encapsulating datagram do not appear in
the SRH.
Multicast addresses MUST NOT appear in an SRH or in the IPv6
Destination Address field of a datagram carrying an SRH.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. RPL Router Behavior</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Generating Source Routing Headers</span>
To deliver an IPv6 datagram to its destination, a router may need to
generate a new SRH and specify a strict source route. When the
router is the source of the original packet and the destination is
known to be within the same RPL routing domain, the router SHOULD
include the SRH directly within the original packet. Otherwise, the
router MUST use IPv6-in-IPv6 tunneling [<a href="./rfc2473" title=""Generic Packet Tunneling in IPv6 Specification"">RFC2473</a>] and place the SRH in
the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the
delivered datagram remains unmodified and that ICMPv6 errors
generated by an SRH are sent back to the router that generated the
SRH.
When using IPv6-in-IPv6 tunneling, in order to respect the IPv6 Hop
Limit value of the original datagram, a RPL router generating an SRH
MUST set the Segments Left to less than the original datagram's IPv6
Hop Limit value upon forwarding. In the case that the source route
is longer than the original datagram's IPv6 Hop Limit, only the
initial hops (determined by the original datagram's IPv6 Hop Limit)
should be included in the SRH. If the RPL router is not the source
of the original datagram, the original datagram's IPv6 Hop Limit
field is decremented before generating the SRH. After generating the
SRH, the RPL router decrements the original datagram's IPv6 Hop Limit
value by the SRH Segments Left value. Processing the SRH Segments
<span class="grey">Hui, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
Left and original datagram's IPv6 Hop Limit fields in this way
ensures that ICMPv6 Time Exceeded errors occur as would be expected
on more traditional IPv6 networks that forward datagrams without
tunneling.
To avoid fragmentation, it is desirable to employ MTU sizes that
allow for the header expansion (i.e., at least 1280 + 40 (outer IP
header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path
length for a given RPL network. To take advantage of this, however,
the communicating endpoints need to be aware of the MTU along the
path (i.e., through Path MTU Discovery). Unfortunately, the larger
MTU size may not be available on all links (e.g., 1280 octets on IPv6
Low-Power Wireless Personal Area Network (6LoWPAN) links). However,
it is expected that much of the traffic on these types of networks
consists of much smaller messages than the MTU, so performance
degradation through fragmentation would be limited.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Processing Source Routing Headers</span>
As specified in [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>], a routing header is not examined or
processed until it reaches the node identified in the Destination
Address field of the IPv6 header. In that node, dispatching on the
Next Header field of the immediately preceding header causes the
Routing header module to be invoked.
The function of the SRH is intended to be very similar to the Type 0
Routing header defined in [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]. After the routing header has
been processed and the IPv6 datagram resubmitted to the IPv6 module
for processing, the IPv6 Destination Address contains the next hop's
address. When forwarding an IPv6 datagram that contains an SRH with
a non-zero Segments Left value, if the IPv6 Destination Address is
not on-link, a router MUST drop the datagram and SHOULD send an ICMP
Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set
to 7 to the packet's Source Address. This ICMPv6 Code indicates that
the IPv6 Destination Address is not on-link and the router cannot
satisfy the strict source route requirement. When generating ICMPv6
error messages, the rules in <a href="./rfc4443#section-2.4">Section 2.4 of [RFC4443]</a> MUST be
observed.
To detect loops in the SRH, a router MUST determine if the SRH
includes multiple addresses assigned to any interface on that router.
If such addresses appear more than once and are separated by at least
one address not assigned to that router, the router MUST drop the
packet and SHOULD send an ICMP Parameter Problem, Code 0, to the
Source Address. While this loop check does add significant per-
packet processing overhead, it is required to mitigate bandwidth
exhaustion attacks that led to the deprecation of RH0 [<a href="./rfc5095" title=""Deprecation of Type 0 Routing Headers in IPv6"">RFC5095</a>].
<span class="grey">Hui, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
The following describes the algorithm performed when processing an
SRH:
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else {
compute n, the number of addresses in the Routing header, by
n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n
if Address[i] or the IPv6 Destination Address is multicast {
discard the packet
}
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
send an ICMP Parameter Problem (Code 0) and discard the
packet
}
else {
swap the IPv6 Destination Address and Address[i]
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
<span class="grey">Hui, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
RPL routers are responsible for ensuring that an SRH is only used
between RPL routers:
1. For datagrams destined to a RPL router, the router processes the
packet in the usual way. For instance, if the SRH was included
using tunneled mode and the RPL router serves as the tunnel
endpoint, the router removes the outer IPv6 header, at the same
time removing the SRH as well.
2. Datagrams destined elsewhere within the same RPL routing domain
are forwarded to the correct interface.
3. Datagrams destined to nodes outside the RPL routing domain are
dropped if the outermost IPv6 header contains an SRH not
generated by the RPL router forwarding the datagram.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Source Routing Attacks</span>
The RPL message security mechanisms defined in [<a href="./rfc6550" title=""RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"">RFC6550</a>] do not apply
to the RPL Source Route Header. This specification does not provide
any confidentiality, integrity, or authenticity mechanisms to protect
the SRH.
[<a id="ref-RFC5095">RFC5095</a>] deprecates the Type 0 Routing header due to a number of
significant attacks that are referenced in that document. Such
attacks include bypassing filtering devices, reaching otherwise
unreachable Internet systems, network topology discovery, bandwidth
exhaustion, and defeating anycast.
Because this document specifies that the SRH is only for use within a
RPL routing domain, such attacks cannot be mounted from outside a RPL
routing domain. As specified in this document, RPL routers MUST drop
datagrams entering or exiting a RPL routing domain that contain an
SRH in the IPv6 Extension headers.
Such attacks, however, can be mounted from within a RPL routing
domain. To mitigate bandwidth exhaustion attacks, this specification
requires RPL routers to check for loops in the SRH and drop datagrams
that contain such loops. Attacks that include bypassing filtering
devices and reaching otherwise unreachable Internet systems are not
as relevant in mesh networks since the topologies are, by their very
nature, highly dynamic. The RPL routing protocol is designed to
provide reachability to all devices within a RPL routing domain and
may utilize routes that traverse any number of devices in any order.
<span class="grey">Hui, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
Even so, these attacks and others (e.g., defeating anycast and
routing topology discovery) can occur within a RPL routing domain
when using this specification.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. ICMPv6 Attacks</span>
The generation of ICMPv6 error messages may be used to attempt
denial-of-service attacks by sending an error-causing SRH in back-to-
back datagrams. An implementation that correctly follows <a href="./rfc4443#section-2.4">Section 2.4
of [RFC4443]</a> would be protected by the ICMPv6 rate-limiting
mechanism.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document defines a new IPv6 Routing Type, the "RPL Source Route
Header", and has been assigned number 3 by IANA.
This document defines a new ICMPv6 Destination Unreachable Code,
"Error in Source Routing Header", and has been assigned number 7 by
IANA.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen
Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal
Thubert, Sean Turner, and Tim Winter for their comments and
suggestions that helped shape this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-RFC2473">RFC2473</a>] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", <a href="./rfc2473">RFC 2473</a>, December 1998.
[<a id="ref-RFC4443">RFC4443</a>] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>, March 2006.
[<a id="ref-RFC5095">RFC5095</a>] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", <a href="./rfc5095">RFC 5095</a>,
December 2007.
<span class="grey">Hui, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6554">RFC 6554</a> RPL Source Route Header March 2012</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC6550">RFC6550</a>] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", <a href="./rfc6550">RFC 6550</a>, March 2012.
Authors' Addresses
Jonathan W. Hui
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
USA
Phone: +408 424 1547
EMail: jonhui@cisco.com
JP. Vasseur
Cisco Systems
11, Rue Camille Desmoulins
Issy Les Moulineaux 92782
France
EMail: jpv@cisco.com
David E. Culler
UC Berkeley
465 Soda Hall
Berkeley, California 94720
USA
Phone: +510 643 7572
EMail: culler@cs.berkeley.edu
Vishwas Manral
Hewlett Packard Co.
19111 Pruneridge Ave.
Cupertino, California 95014
USA
EMail: vishwas.manral@hp.com
Hui, et al. Standards Track [Page 13]
</pre>
|
