-
Notifications
You must be signed in to change notification settings - Fork 2
/
ChangeLog
319 lines (240 loc) · 14.5 KB
/
ChangeLog
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
ChangeLog from useofrplinfo from 31 to 41:
Changelog from v31 to 32: [https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-32.txt]
Section 2:
- Definition of "RPL Leaf" added.
- Definition of "RPL-aware-node (RAN)" added.
- Correction of RAL and RUL.
Section 4.1:
- Added a subsection: Updates to RFC6550: Advertise External Routes with Non-Storing Mode Signaling.
Section 4.4:
- Updated Figure 5 changed from "IPv6-in-IPv6 6LoRH" to IP-in-IP 6LoRH.
Section 5:
- Clarification added: "6LBR has direct access to Internet and is the root of the DODAG"
- Assumption deleted: The leaf can be a router 6LR or a host, both indicated as 6LN
- Assumptions added:
*In the uses cases, we assume that the RAL supports IP-in-IP encapsulation.
* In the uses cases, we dont assume that the RUL supports IP-in-IP encapsulation.
Section 7:
-Figure 7 changed:
* RUL to root from root to hop or root
* RUL to Int from root to hop or root
* Int to RUL from root to hop or root
* Int to RUL from hop to 6LR
* RUL to RUL from hop to 6LR
- Changes as well on these cases to reflect the change.
Section 14.1
- Added a normative reference to RFC8504
- Nits fixed in the whole Document.
Changelog from v32 to 33: [https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-33.txt]
Abstract:
-Changed RPL Option Type to RPI Option Type.
Introduction:
-Clarification added about RPI.
Section 2:
- RPI definition added.
Section 4.2:
-Clarification added about RPI.
- Text deleted: A network which is switching from straight 6LoWPAN compression mechanism to those described in [RFC8138]
will experience a flag day in the data compression anyway, and if possible this change can be deployed at the same time.
Section 4.3:
-Added clarification that the DODAG Configuration Option might indicate something different when MOP > 7.
-Text added: "If the flag is received with a value zero (which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI Option Type (0x63) value.
If the flag is received with a value of 1, then the option value for the RPL Option MUST be set to 0x23".
Nits fixed in the whole document.
Changelog from v33 to 34:[https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-34.txt]
Introduction:
- Text added: " ...In the other direction, for traffic coming from an external target into the LLN, the parent (6LR) that
injects the traffic always encapsulates to the root..."
Section 7:
-Hop-by-hop deleted from table and cases.
-Figure 7 changed:
*RUL to root from hop or root to root
*RUL to Int from hop or root to root
*RUL to RAL from RAL to root/RAL
*RUL to RUL from 6LR to root/6LR
-Changes in the mentioned case's sections to reflect the deletion of hop-by-hop cases.
-Changed on all tables: "Modified headers" row moved from fifth to third row.
Section 7.3.2:
- Change in the case from RAL to RUL in order to reflect the common parent is the root (6LBR)
Section 7.3.3:
-Change in the case from RUL to RAL in order to reflect the common parent is the root (6LBR)
Nits fixed in the whole document.
Changelog from v34 to 35:[https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-35.txt]
Section 7:
- Figure 7 changed:
* RUL to RAL: changed from root/RAL to root
* RUL to RUL: changed from root/RAL to root
Section 8:N-SM
- Introduction of "may" cases that involves the optional IPv6-in-IPv6 encapsulation.
-Thereby text added:" The term "may(up)" refers that the IPv6-in-IPv6 header may
be necessary in the upwards direction. The term "must(up)" refers
that the IPv6-in-IPv6 header must be present in the upwards
direction. The term "must(down)" refers that the IPv6-in-IPv6 header
must be present in the downward direction."
-Figure 14: modified -cases:
* RAL to Int: IPv6-in-IPv6 column changed from "No" to "may(up)" and IP-in-IP dst column to root.
* RAL to RAL: IPv6-in-IPv6 column changed from "must" to "may(up) and must (down)" and IP-in-IP dst column from root/RAL
to root for up and RAL for down.
* RAL to RUL: IPv6-in-IPv6 column changed from "must" to "may(up) and must (down)" and IP-in-IP dst column from root/6LR
to root for up and 6LR for down.
* RUL to RAL: IPv6-in-IPv6 column changed from "must" to "must(up) and must (down)" and IP-in-IP dst column from root/RAL
to root for up and RAL for down.
* RUL to RUL: IPv6-in-IPv6 column changed from "must" to "must(up) and must (down)" and IP-in-IP dst column from root/6LR
to root for up and 6LR for down.
- Changed in the mentioned cases such as update description and add extra tabl, in order to reflect the optional
encapsulation.
Nits fixed.
Changelog from v35 to 36:[https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-36.txt]
RFC Editor nits fixed.
Changelog from v36 to 37:[https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-37.txt]
Section 4.3:
- Clarification added in case of node reboot.
Section 6:
- Two assumptions added:
* For traffic leaving a RUL, if the RUL adds an opaque RPI then the description of the RAL applies.
* The description for RALs applies to RAN in general.
Section 7:
- Text added:" In each case, 6LR_i represents the intermediate routers from source to destination. "1 <= i <= n",
n is the number of routers (6LR) that
the packet goes through from source (6LN) to destination"
- Figure 7: cases modified:
* root to RUL: IPv6-in-IPv6 column changed from "No" to "must" and IPv6-in-IPv6 dst column from "No" to "6LR".
* RAL to Int: IPv6-in-IPv6 column changed from "No" to "may" and IPv6-in-IPv6 dst column from "No" to "root".
* RAL to RUL: IPv6-in-IPv6 column changed from "No" to "must(down)" and IPv6-in-IPv6 dst column from "No" to "6LR".
* RUL to RAL: IPv6-in-IPv6 column changed from "must" to "must(up)/must(down)" and IPv6-in-IPv6 dst column from "root" to
"root" going up and RAL doing down.
* RUL to RUL: IPv6-in-IPv6 column changed from "must" to "must(up)/must(down)" and IPv6-in-IPv6 dst column from "root" to
"root" going up and 6LR doing down.
-Changed in the mentioned cases (descriptions and tables) to reflect the modifications in Figure 7.
Nits fixed.
Changelog from v37 to 38: [https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-38.txt]
Section 2:
-Hop-by-Hop re-encapsulation definition deleted.
Section 4:
-Text deleted: "IP-in-IP encapsulation MAY be avoided for Root to RUL communication if the RUL is known to process
the packets as forwarded by the parent 6LR without decapsulation."
Section 4.3:
-Text deleted:"This means that the non-storing mode case can avoid ever using Hop-by-Hop re-encapsulation headers
for traffic originating from the root to the leaves."
Section 7:
- Added text referring one case in SM that RH3 can be used: "However, there is one
scenario (from the root to the RUL in SM) where the RH3 can be used to indicate the RUL (Figure 11)."
Figure 7, RAL to RUL case modified:
-"IPv6-in-IPv6 column changed from "must(down)" to "No(up)/must(down)" and IPv6-in-IPv6 dst column keeps "6LR".
Section 7.1.3: SM -Example of Flow from Root to RUL:
-Text added:"IP-in-IP encapsulation MAY be avoided for Root to RUL communication.
In SM, it can be replaced by a loose SRH header that indicates the
RUL, in which case the packet is routed to the 6LR as a normal SM
operation, then the 6LR forwards to the RUL based on the SRH, and the
RUL ignores both the consumed SRH and the RPI, as in Non-Storing
Mode." Figure 11 added to reflect this case.
Section 8.3.1:
- Text added:"Note that in the Modified headers row, going up in each 6LR_ia only the
RPI1 is changed. Going down, in each 6LR_id the IPv6 header is
swapped with the SRH so both are changed alongside with the RPI2." and figure modified.
Nit fixed, tables(figures) aligned to ascii format
Changelog from v38 to 39:
https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-39.txt
Section 2: Flag day definition modified as follows:
-Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type.
Section 4.1
-"may have been learned through as a host route or may have been" changed to "may have been learned through an external
routing protocol or may have been"
Section 5:
-"DAC and efficient-ND only to participate in the network [RFC6775]. In the document these leaves (G and J)
are also referred to as an IPv6 node." changed to "DAC and 6LoWPAN ND only to participate in the network [RFC8505].
In the document these leaves (G and J) are also referred to as a RUL."
Section 6:
-"A corollary is that an RH3 or RPL Option can only be removed by an intermediate router if it is placed in an encapsulating
IPv6 Header, which is addressed TO the intermediate router.
When it does so, the whole..." changed to
"A corollary is that an intermediate router can remove an RH3 or RPL Option only if it is placed in an
encapsulating IPv6 Header that is addressed TO this intermediate router. When doing the above, the whole... "
-"The earlier examples are more extensive to make sure that the process is clear, while later examples are more concise."
changed to "Throughout the following subsections, the examples are described in more details in the first subsections,
and more concisely in the later ones."
-"The uses cases are delineated based on the following requirements:" changed to
"The uses cases are delineated based on the following IPV6 and RPL mandates:"
Section 7:
-"If the IPv6-in-IPv6 header is needed, the column shows "must"." changed to "and the destination is N/A (Not Applicable).
If the IPv6-in-IPv6 header is needed, the column shows "must"".
-"to indicate the RUL (Figure 11)." changed to " to point at the RUL (Figure 11)."
-Figure 7 changed from No to N/A, and
*RAL to RUL | No(up) | 6LR to
*RAL to RUL | No(up) | N/A
Section 7.1.3:
-" The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header.
The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).
The 6LR parent of the RUL removes the header and sends the packet to the RUL" changed to
"The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and prepend an RPI.
The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).
The 6LR parent of the RUL removes the header and sends the packet to the RUL. "
-Figure 10: IP6-IP6 added in untouched headers.
-SRH changed to RH3
-Figure 11: RH3 added in untouched headers.
Section 7.1.4:
-"When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), the 6LR_1 will insert an RPI,
encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the root (Node A).
The root removes the header and processes the packet." changed to
"When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the 6LR_1 will insert encapsulate the packet
in an IPv6-in-IPv6 header and prepend an RPI. The IPv6-in-IPv6 header is addressed to the root (Node A).
The root removes the header and processes the packet."
-Figure 12: IP6-IP6 added in untouched headers.
Section 7.2.1:
-Deleted: No IPv6-in-IPv6 header is required.
-Added text: "Note that the RPI is modified by 6LBR to set the SenderRank to zero in case that it is not already zero."
-Figure 13: RPI moved from untouched headers to modified headers.
-Figure 14: IP6-IP6 added in untouched Headers
Section 7.3.2:
-"Node F (RAL)--> Node D --> Node B--> Node E --> Node G (RUL)" changed to "Node F (RAL)--> Node D --> Node B--> Node A
-->Node B --> Node E --> Node G (RUL)".
-"The root removes the RPI1 and inserts an RPI2 encapsulated to the 6LR parent of the RUL, which
removes the RPI2 before pasing the packet to the RUL." changed to "The root does not removes the RPI1 (the root cannot
remove an RPI if there is no encapsulation). The root inserts an RPI2 encapsulated to the 6LR parent of the RUL, which
removes the RPI2 before pasing the packet to the RUL."
Section 7.3.4.
-Deleted: "The RPI is ignored at the RUL dst node."
Section 8.1.3:
-IPv6 node, which does not understand the RPI, changed to RUL, which does not understand the RPI,
Section 8.1.4:
-"...packets from the IPv6 node." changed to "packets from the RUL"
Section 8.2.1:
-Figure 27: RPI is moved from untouched headers to modified headers.
Section 8.2.3:
"6LR_i are the intermediate routers" changed to "6LR_i represents the intermediate routers from source to destination,"
Section 8.3.1.:
"It should be able to remove the RPI..." changed to "It removes the RPI..."
Section 9:
-(in either mode) changed to (in storing or non-storing mode)
Section 10:
-"In case that a node join to a network that only process 0x63, it would produce a flag day as was mentioned previously.
Indicating the new RPI in the DODAG Configuration option Flag is a way to avoid the flag day in a network.
It is recommended that a network process bothoptions to enable interoperability " changed to "
As mentioned previously, indicating the new RPI in the DODAG Configuration option flag is a way to avoid
the flag day (lack of interoperation) in a network using 0x63 as the RPI Option Type value.
It is suggested that RPL implementations accept both 0x63 and 0x23 RPI Option type values when processing the header
to enable interoperability."
ChangeLog v39 to v40:
nits fixed in Section 5, Section 7.1.4, Section 7.3.2
ChangeLog v40 to v41:
Section1: Introduction updated
Section 4.3: Updates to RFC6550: Subsection added "Configuration Options and Mode of Operation"
Section 4.4: added " For a MOP value of 7, a node SHOULD assume that the RPI 0x23 option is enabled."
Figure 22 case root to RUL updated IPv6-in-IPv6 field, from must to No.
Section 8.2.1: Non-SM: Example of Flow from RAL to Internet added: "Having the RAL information about the RPL domain, it may encapsulate to the root when the destination is not in the RPL domain of the RAL."
8.2.3. Non-SM: Example of Flow from RUL to Internet: nits fixed.
8.3.2. Non-SM: Example of Flow from RAL to RUL: nits fixed.
Section 11: IANA Considerations, added:
"11.2. Changes to DODAG Configuration Options Flags
This document changes the name of the "DODAG Configuration Option
Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP 0..6".
11.3. Change MOP value 7 to Reserved
This document changes the allocation status of the Mode of Operation
(MOP) [ianamop] from Unassigned to Reserved. This change is in
support of future work related to capabilities."
ChangeLog v41 to v42:
Section added: 4.1.2. Configuration Options and Mode of Operation
Added in Section 6: "The 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags."
Security Considerations updated For traffic leaving a RUL
Nits fixed