-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-jadhav-roll-storing-rootack.xml
414 lines (392 loc) · 18.2 KB
/
draft-jadhav-roll-storing-rootack.xml
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
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6550.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-jadhav-roll-storing-rootack-latest" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Storing Root-ACK">RPL Storing Root-ACK</title>
<author fullname="Rahul Arvind Jadhav" initials="R.A." role="editor" surname="Jadhav">
<address>
<postal>
<street>Marathahalli</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2021" />
<area>Routing</area>
<workgroup>ROLL</workgroup>
<keyword>RPL, root, ack</keyword>
<abstract>
<t>
This document explains problems with DAO-ACK handling in RPL
Storing MOP and provides updates to RFC6550 to solve those
problems.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
RPL <xref target="RFC6550"/> specifies a proactive distance-vector
routing scheme designed for LLNs (Low Power and Lossy Networks).
RPL enables the network to be formed as a DODAG and
supports storing mode and non-storing mode of operations.
Non-storing mode allows reduced memory resource usage on the nodes
by allowing non-BR nodes to operate without managing a routing
table and involves use of source routing by the Root to direct the
traffic along a specific path. In storing mode of operation
the routing happens on hop-by-hop basis and intermediate routers
need to maintain routing tables.
</t>
<t>
DAO messaging helps to install downstream routing paths in the
DODAG. DAOs are generated on hop-by-hop basis. DAO may contain
multiple RPL Control Options. The Target Option identifies the
address prefix for which the route has to be installed and the
corresponding Transit Information Option identifies the parameters
(such as lifetime, freshness-counter, etc) for the target. The DAO
base object contains the 'K' flag indicating that a DAO-ACK is
sought by the sender. The DAO, DAO-ACK progresses on hop-by-hop
basis all the way till Root. In non-storing MOP, the DAO from the
target node is directly addressed to the Root and the Root responds
with a DAO-ACK indicating path establishment status. However, in
storing MOP, the DAO-ACK is immediately sent by the upstream parent.
Thus in case of storing MOP, the target node cannot rely on DAO-ACK
as an indication that the end to end (from the target node to Root)
path has been established.
</t>
<t>
This draft highlights various issues with RPL DAO-ACK handling in
Storing MOP. Section 4 of <xref
target="I-D.ietf-roll-rpl-observations"/> provides more context
to the problem statement. The draft provides requirements to solve
the issues and provides an updates to RFC6550 based on these
requirements.
</t>
<section title="Requirements Language and Terminology">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
MOP: Mode of Operation
</t>
<t>
NS-MOP: RPL Non-Storing Mode of Operation
</t>
<t>
S-MOP: RPL Storing Mode of Operation
</t>
<t>
Root-ACK: The Root-ACK syntax is same as DAO-ACK except that the
Root-ACK is addressed directly to the peer who owns the target
prefix. DAO-ACK in contrast is always sent using link-local IPv6
address in storing MOP.
</t>
<t>
DelayDAO: Section 9.5 of RFC6550 introduces a delay before the
DAO transmission is initiated.
</t>
<t>
TIO: (Transit Information Option) Section 6.7.8 of RFC6550. TIO
is an option usually carried in DAO message and augments control
information for the advertised Target.
</t>
<t>
RUL: (RPL Unaware Leaf)
<xref target="I-D.ietf-roll-unaware-leaves"/>
</t>
<t>
This document uses terminology described in <xref
target="RFC6550"/>.
</t>
</section>
</section>
<section title="Problems with DAO-ACK in Storing MOP" anchor="problems">
<t>
Consider the following topology for the subsequent description:
<figure align="center" anchor="sample_top" title="Sample
topology"> <artwork align="center"><![CDATA[
(Root)
|
|
|
(A)
/ \
/ \
/ \
(B) -(C)
| / |
| / |
| / |
(D)- (E)
\ ;
\ ;
\ ;
(F)
/ \
/ \
/ \
(G) (H)
]]></artwork> </figure>
</t>
<section title="End to End Path Establishment Indication">
<t>
Nodes need to know whether the end to end path till the Root
has been established before they can initiate application
traffic. In case of NS-MOP, the DAO is addressed to the Root
from the Target node and the Root sends DAO-ACK directly
addressed back to the target node. Thus in case of NS-MOP, the
node can make use of this DAO-ACK as an indication whether the
necessary routes have been installed. However, in case of
Storing MOP, the DAO/DAO-ACK signaling happens at every hop.
<figure align="center" anchor="nsmop_dao" title="NS-MOP
DAO/DAO-ACK handling"> <artwork align="center"><![CDATA[
Non-Storing MOP
| D ======== B ======== A ======== (Root)
| ---------------DAO------------>
| <-----------DAO-ACK------------
|
V
time
]]></artwork> </figure>
<figure align="center" anchor="smop_dao" title="Storing MOP
DAO/DAO-ACK handling"> <artwork align="center"><![CDATA[
Storing MOP
| D ======== B ======== A ======== (Root)
| ---DAO--->
| <-DAO-ACK-
| ---DAO--->
| <-DAO-ACK-
| ---DAO--->
| <-DAO-ACK-
V
time
]]></artwork> </figure>
</t>
<t>
Note that in Storing-MOP, the DAO/DAO-ACK signaling happens on
hop-by-hop basis and a DelayDAO timer is used
before intermediate 6LRs generate the DAO. This
would mean that the DAO reaching the Root may take
several seconds. The target node should not generate the
application traffic unless the end to end path is established.
</t>
<t>
Consider <xref target="sample_top"/>, when node D sends a DAO,
the node B receives the DAO and instantly sends back DAO-ACK.
Node B then subsequently generates the DAO with Target as Node
D and sends it to node A. The DAO with Target as Node D may
take time (since the DAO is scheduled with DelayDAO timer by
every node) to finally reach the Root at which point the end to
end path is established. There is no way for node D to know
when the end to end path is established. This information is
needed for node D to initiate its application traffic.
Initiating application traffic prior to this might almost
certainly lead to application packet retries causing congestion
in the network.
</t>
</section>
<section title="Target node is unaware if it needs to retry the DAO">
<t>
It is possible that the intermediate 6LR goes down while
attempting to generate DAO on behalf of the target node. In
this case, the target node has no way of knowing to retry the
DAO, in which case the route installation may not happen until
the target node's DAO lifetime expires.
</t>
<t>
Consider <xref target="sample_top"/>, assume that node A was
generating DAO with Target node D and sending it to Root.
Node A reboots before attempting to send DAO to Root. Node A
has already sent DAO-ACK downstream to node B. In this case,
the target node D is not aware that sending DAO has failed
somewhere upstream. Note that as per RFC6550 upstream DAO is
scheduled based on DelayDAO but DAO-ACK is sent
instantaneously on DAO reception from downstream node.
</t>
</section>
<section title="RPL node acting as router for RULs">
<t>
An RPL node may act as a router for RPL unware leaves as
described in <xref target='I-D.ietf-roll-unaware-leaves'/>.
Ideally an RPL node should start accepting RULs solicitation
only after making sure that it has established itself in the
network first. In Storing-MOP, there is no way to ascertain
this.
</t>
</section>
</section>
<section title="Requirements for Root-ACK handling in Storing MOP">
<t>
Following are the requirements:
<list style="hanging">
<t hangText="Indicate end to end path establishment">
The Target node must know when to initiate the application
traffic based on end to end path establishment.
</t>
<t hangText="Handle multiple targets in DAOs">
A DAO message may contain multiple Target Options. The
Root-ACK mechanism must handle multiple targets in DAO.
</t>
<t hangText="Handle DAOs with address prefix">
RPL DAO Target Option may contain an address prefix i.e.,
not the full address.
</t>
<t hangText="Provide suitable way for target node to retry">
The Target node must have a way to know and retry the DAO
in case the DAO transmission fails enroute.
</t>
<t hangText="Backward compatible with current DAO-ACK">
The current per hop DAO-ACK must function as it is. Legacy
nodes should be able to operate without any changes.
</t>
</list>
</t>
</section>
<section title="Root-ACK from Root">
<t>
The draft defines a way for the RPL Root to send the Root-ACK back
directly addressed to the Target node. The Target node can receive
the Root-ACK directly thus getting an indication that the end to end
path till the Root has been successfully established. The Root-ACK
uses the same syntax and message code as DAO-ACK. The only
difference is that the Root-ACK is directly addressed to the Target
node who owns the advertised prefix in the Target Option.
</t>
<section title="Transit Information Option update in DAO message"
anchor="transit_opt_changes">
<t>
The Target node indicates that it wishes to receive Root-ACK
directly from Root by setting the newly defined 'K' flag in
Transit Information Option.
</t>
<t> <figure align="center" anchor="transit_info_with_k"
title="Updated Transit Information Option (New K flag
added)"> <artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Option Length |E|I|K| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure>
</t>
<t>
The K flag indicates that the Root of the RPLInstance MUST send
a Root-ACK directly to the target node.
</t>
</section>
<section title="Root sends Root-ACK addressed to Target">
<t>
On receiving a DAO with Transit Information Option with 'K'
flag set, the Root MUST respond with a Root-ACK immediately to
the address extracted from the corresponding Target Option.
</t>
<t>
The Root-ACK MUST contain the Transit Information Option with
parameters copied from the DAO's Transit Information Option
based on which this Root-ACK was generated. The PathSequence in
the Transit Information Option helps the Target node to
identify for which DAO it generated it has received the
Root-ACK. The DAOSequence in the base Root-ACK(DAO-ACK) base
object is ignored by the Target node.
</t>
</section>
<!--
<section title="Handling RPL Unaware Leaves (RULs)">
<t>
<xref target='I-D.ietf-roll-unaware-leaves'/>
extends RFC6550 to provide RPL routing services to RULs that
do not directly participate to RPL. A RUL node also faces the
same problems as discussed in <xref target="problems"/>.
</t>
<t>
Section 9 of <xref target="I-D.ietf-roll-unaware-leaves"/>
explains the first registration flow for an RUL node. RUL
sends an NS(EARO)
</t>
</section>
-->
</section>
<!-- <section anchor="Acknowledgements" title="Acknowledgements">
</section> -->
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to allocate bit 2 from the Transit Information
Option Flags registry for the 'K' flag (<xref
target="transit_opt_changes"/>).
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This node introduces a new flag in response to which the Root of
the DODAG would send a Root-ACK which serves as an indication for
the target node that the end to end route/path is established. The
Root-ACK indication eventually would be used by the end node for
application layer processing such as initiating the application
traffic. A malicious node could generate the Root-ACK pre-maturely
i.e, before the end-to-end path is established and cause the
application to do some processing pre-maturely. However, the
application layer would always account for application layer
failures and thus shouldn't result in any security issues. This
could result in more control overhead which is currently the case
where nodes do not support this specification.
</t>
<t>
A malicious 6LR or 6LN could set the 'K' flag indicating the Root
to send a Root-ACK. The Root would generate a Root-ACK for the
indicated target. The Root need not keep any additional state for
handling the 'K' flag.
</t>
<t>
This document assumes that the security mechanisms as defined in
<xref target="RFC6550"/> are followed, which means that all the
nodes are part of the RPL network because they have the required
credentials. A non-secure RPL network needs to take into
consideration the risks highlighted in this section as well as
those highlighted in <xref target="RFC6550"/>.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC6550;
<?rfc include='reference.I-D.ietf-roll-unaware-leaves.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-roll-rpl-observations.xml'?>
</references>
</back>
</rfc>