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
|
<pre>Internet Research Task Force (IRTF) H. Kruse
Request for Comments: 7122 Ohio University
Category: Experimental S. Jero
ISSN: 2070-1721 Purdue University
S. Ostermann
Ohio University
March 2014
<span class="h1">Datagram Convergence Layers for</span>
<span class="h1">the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol</span>
<span class="h1">and Licklider Transmission Protocol (LTP)</span>
Abstract
This document specifies the preferred method for transporting Delay-
and Disruption-Tolerant Networking (DTN) protocol data over the
Internet using datagrams. It covers convergence layers for the
Bundle Protocol (<a href="./rfc5050">RFC 5050</a>), as well as the transportation of segments
using the Licklider Transmission Protocol (LTP) (<a href="./rfc5326">RFC 5326</a>). UDP and
the Datagram Congestion Control Protocol (DCCP) are the candidate
datagram protocols discussed. UDP can only be used on a local
network or in cases where the DTN node implements explicit congestion
control. DCCP addresses the congestion control problem, and its use
is recommended whenever possible. This document is a product of the
Delay-Tolerant Networking Research Group (DTNRG) and represents the
consensus of the DTNRG.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Research Task
Force (IRTF). The IRTF publishes the results of Internet-related
research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the
Delay-Tolerant Networking Research Group of the Internet Research
Task Force (IRTF). Documents approved for publication by the IRSG
are not a candidate for any level of Internet Standard; see <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/rfc7122">http://www.rfc-editor.org/info/rfc7122</a>.
<span class="grey">Kruse, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
Copyright Notice
Copyright (c) 2014 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. General Recommendation . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Recommendations for Implementers . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. How and Where to Deal with Fragmentation . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1.1">3.1.1</a>. DCCP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1.2">3.1.2</a>. UDP . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Bundle Protocol over a Datagram Convergence Layer . . . . <a href="#page-6">6</a>
<a href="#section-3.2.1">3.2.1</a>. DCCP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2.2">3.2.2</a>. UDP . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. LTP over Datagrams . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. DCCP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3.2">3.3.2</a>. UDP . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Keep-Alive Option . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.5">3.5</a>. Checksums . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.5.1">3.5.1</a>. DCCP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.5.2">3.5.2</a>. UDP . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.6">3.6</a>. DCCP Congestion Control Modules . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<span class="grey">Kruse, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
DTN communication protocols include the Bundle Protocol described in
<a href="./rfc5050">RFC 5050</a> [<a href="./rfc5050" title=""Bundle Protocol Specification"">RFC5050</a>], which provides transmission of application data
blocks ("bundles") through optional intermediate custody transfer,
and the Licklider Transmission Protocol (LTP) -- LTP Motivation
[<a href="./rfc5325" title=""Licklider Transmission Protocol - Motivation"">RFC5325</a>], LTP Specification [<a href="./rfc5326" title=""Licklider Transmission Protocol - Specification"">RFC5326</a>], and LTP Security [<a href="./rfc5327" title=""Licklider Transmission Protocol - Security Extensions"">RFC5327</a>] --
which can be used to transmit bundles reliably and efficiently over a
point-to-point link. It is often desirable to test these protocols
over Internet Protocol links. "Delay Tolerant Networking TCP
Convergence Layer Protocol" [<a href="#ref-CLAYER" title=""Delay Tolerant Networking TCP Convergence Layer Protocol"">CLAYER</a>] defines a method for
transporting bundles over TCP. This document specifies the preferred
method for transmitting either bundles or LTP blocks across the
Internet using datagrams in place of TCP. Figure 1 shows the general
protocol layering described in the DTN documents. DTN Applications
interact with the Bundle Protocol Layer, which in turn uses a
Convergence Layer to prepare a bundle for transmission. The
Convergence Layer will typically rely on a lower-level protocol to
carry out the transmission.
+-----------------------------------------+
| |
| DTN Application |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Bundle Protocol (BP) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Convergence Layer Adapter (CL) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Local Data-Link Layer (Transport) |
| |
+-----------------------------------------+
Figure 1: Generic Protocol Stack for DTN
This document provides guidance for implementation of the two
protocol stacks illustrated in Figure 2. In Figure 2(a), the
Convergence Layer Adapter is UDP or DCCP for direct transport of
<span class="grey">Kruse, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
bundles over the Internet. In Figure 2(b), the Convergence Layer
Adapter is LTP, which then uses UDP or DCCP as the local data-link
layer.
+-------------+ +-------------+
| | | |
| DTN App | | DTN App |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| BP | | BP |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| UDP/DCCP | | LTP |
| | | |
+-------------+ +-------------+
+-------------+
| |
| UDP/DCCP |
| |
+-------------+
(a) (b)
Figure 2: Protocol Stacks Addressed in this Document
<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">RFC 2119</a> [<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>. General Recommendation</span>
In order to utilize DTN protocols across the Internet, whether for
testing purposes or as part of a larger network path, it is necessary
to encapsulate them into a standard Internet Protocol so that they
travel easily across the Internet. This is particularly true for
LTP, which provides no endpoint addressing. This encapsulation
choice needs to be made carefully in order to avoid redundancy, since
DTN protocols may provide their own reliability mechanisms.
Congestion control is vital to the continued functioning of the
Internet, particularly for situations where data will be sent at
arbitrarily fast data rates. The Bundle Protocol delegates provision
<span class="grey">Kruse, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
of reliable delivery and, implicitly, congestion control to the
convergence layer used (<a href="./rfc5050#section-7.2">Section 7.2 of RFC 5050</a> [<a href="./rfc5050" title=""Bundle Protocol Specification"">RFC5050</a>]). In
situations where TCP will work effectively in communications between
pairs of DTN nodes, use of the TCP convergence layer [<a href="#ref-CLAYER" title=""Delay Tolerant Networking TCP Convergence Layer Protocol"">CLAYER</a>] will
provide the required reliability and congestion control for transport
of bundles and would be the default choice in the Internet.
Alternatives such as encapsulating bundles directly in datagrams and
using UDP or DCCP are not generally appropriate because they offer
limited reliability and, in the case of UDP, no congestion control.
LTP, on the other hand, offers its own form of reliability.
Particularly for testing purposes, it makes no sense to run LTP over
a protocol like TCP that offers reliability already. In addition,
running LTP over TCP would reduce the flexibility available to users,
since LTP offers more control over what data is delivered reliably
and what data is delivered best effort, a feature that TCP lacks. As
such, it would be better to run LTP over an unreliable protocol.
One solution would be to use UDP. UDP provides no reliability,
allowing LTP to manage that itself. However, UDP also does not
provide congestion control. Because LTP is designed to run over
fixed-rate radio links, it does provide rate control but not
congestion control. Lack of congestion control in network
connections is a major problem that can cause artificially high loss
rates and/or serious fairness issues. Previous standards documents
are unanimous in recommending congestion control for protocols to be
used on the Internet, see "Congestion Control Principles" [<a href="./rfc2914" title=""Congestion Control Principles"">RFC2914</a>],
"Unicast UDP Usage Guidelines" [<a href="./rfc5405" title=""Unicast UDP Usage Guidelines for Application Designers"">RFC5405</a>], and "Queue Management and
Congestion Avoidance" [<a href="./rfc2309" title=""Recommendations on Queue Management and Congestion Avoidance in the Internet"">RFC2309</a>], among others. <a href="./rfc5405">RFC 5405</a>, in
particular, calls congestion control "vital" for "applications that
can operate at higher, potentially unbounded data rates". Therefore,
any Bundle Protocol implementation permitting the use of UDP to
transport LTP segments or bundles outside an isolated network for the
transmission of any non-trivial amounts of data MUST implement
congestion control consistent with <a href="./rfc5405">RFC 5405</a>.
Alternatively, the Datagram Congestion Control Protocol (DCCP)
[<a href="./rfc4340" title=""Datagram Congestion Control Protocol (DCCP)"">RFC4340</a>] was designed specifically to provide congestion control
without reliability for those applications that traverse the Internet
but do not desire to retransmit lost data. As such, it is
RECOMMENDED that, if possible, DCCP be used to transport LTP segments
across the Internet.
<span class="grey">Kruse, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Recommendations for Implementers</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. How and Where to Deal with Fragmentation</span>
The Bundle Protocol allows bundles with sizes limited only by node
resource constraints. In IPv4, the maximum size of a UDP datagram is
nearly 64 KB. In IPv6, when using jumbograms [<a href="./rfc2675" title=""IPv6 Jumbograms"">RFC2675</a>], UDP
datagrams can technically be up to 4 GB in size [<a href="./rfc2147" title=""TCP and UDP over IPv6 Jumbograms"">RFC2147</a>], although
this option is rarely used. (Note: <a href="./rfc2147">RFC 2147</a> was obsoleted by <a href="./rfc2675">RFC</a>
<a href="./rfc2675">2675</a>.) It is well understood that sending large IP datagrams that
must be fragmented by the network has enormous efficiency penalties
[<a href="#ref-Kent87" title=""Fragmentation considered harmful"">Kent87</a>]. The Bundle Protocol specification provides a bundle
fragmentation concept [<a href="./rfc5050" title=""Bundle Protocol Specification"">RFC5050</a>] that allows a large bundle to be
divided into bundle fragments. If the Bundle Protocol is being
encapsulated in DCCP or UDP, it therefore SHOULD create each fragment
of sufficiently small size that it can then be encapsulated into a
datagram that will not need to be fragmented at the IP layer.
IP fragmentation can be avoided by using IP Path MTU Discovery
[<a href="./rfc1191" title=""Path MTU discovery"">RFC1191</a>] [<a href="./rfc1981" title=""Path MTU Discovery for IP version 6"">RFC1981</a>], which depends on the deterministic delivery of
ICMP Packet Too Big (PTB) messages from routers in the network. To
bypass a condition referred to as a black hole [<a href="./rfc2923" title=""TCP Problems with Path MTU Discovery"">RFC2923</a>], a newer
specification is available in [<a href="./rfc4821" title=""Packetization Layer Path MTU Discovery"">RFC4821</a>] to determine the IP Path MTU
without the use of PTB messages. This document does not attempt to
recommend one fragmentation avoidance mechanism over another; the
information in this section is included for the benefit of
implementers.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. DCCP</span>
Because DCCP implementations are not required to support IP
fragmentation and are not allowed to enable it by default, a DCCP
Convergence Layer (we will use "CL" from here on) MUST NOT accept
data segments that cannot be sent as a single MTU-sized datagram.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. UDP</span>
When an LTP CL is using UDP for datagram delivery, it SHOULD NOT
create segments that will result in UDP datagrams that will need to
be fragmented, as discussed above.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Bundle Protocol over a Datagram Convergence Layer</span>
In general, the use of the Bundle Protocol over a datagram CL is
discouraged in IP networks. Bundles can be of (almost) arbitrary
length, and the Bundle Protocol does not include an effective
retransmission mechanism. Whenever possible, the Bundle Protocol
SHOULD be operated over the TCP Convergence Layer or over LTP.
<span class="grey">Kruse, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
If a datagram CL is used for transmission of bundles, every datagram
MUST contain exactly one bundle or 4 octets of zero bits as a keep-
alive. Bundles that are too large for the path MTU SHOULD be
fragmented and reassembled at the Bundle Protocol layer to prevent IP
fragmentation.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. DCCP</span>
The DCCP CL for Bundle Protocol use SHOULD use the IANA-assigned port
4556/DCCP and service code 1685351985; the use of other port numbers
and service codes is implementation specific.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. UDP</span>
The UDP CL for Bundle Protocol use SHOULD use the IANA-assigned port
4556/UDP; the use of other port numbers is implementation specific.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. LTP over Datagrams</span>
LTP is designed as a point-to-point protocol within DTN, and it
provides intrinsic acknowledgement and retransmission facilities.
LTP segments are transported over a "local data-link layer" (<a href="./rfc5325">RFC 5325</a>
[<a href="./rfc5325" title=""Licklider Transmission Protocol - Motivation"">RFC5325</a>]); we will use the term "transport" from here on. Transport
of LTP using datagrams is an appropriate choice. When a datagram
transport is used to send LTP segments, every datagram MUST contain
exactly one LTP segment or 4 octets of zero bits as a keep-alive.
LTP MUST perform segmentation in such a way as to ensure that every
LTP segment fits into a single packet which will not require IP
fragmentation as discussed above.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. DCCP</span>
The DCCP transport for LTP SHOULD use the IANA-assigned port 1113/
DCCP and service code 7107696; the use of other port numbers and
service codes is implementation specific.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. UDP</span>
The UDP transport for LTP SHOULD use the IANA-assigned port 1113/UDP;
the use of other port numbers is implementation specific.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Keep-Alive Option</span>
It may be desirable for a UDP or DCCP CL or transport to send "keep-
alive" packets during extended idle periods. This may be needed to
refresh a contact table entry at the destination, or to maintain an
address mapping in a NAT or a dynamic access rule in a firewall.
Therefore, the CL or transport MAY send a datagram containing exactly
<span class="grey">Kruse, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
4 octets of zero bits. The CL or transport receiving such a packet
MUST discard this packet. The receiving CL or transport may then
perform local maintenance of its state tables; these maintenance
functions are not covered in this document. Note that packets
carrying bundles or segments will always contain more than 4 octets
of information (either the bundle or the LTP header); keep-alive
packets will therefore never be mistaken for actual data packets. If
UDP or DCCP is being used for communication in both directions
between a pair of bundle agents, transmission and processing of keep-
alives in the two directions occurs independently. Keep-alive
intervals SHOULD be configurable, SHOULD default to 15 seconds, and
MUST NOT be configured shorter than 15 seconds.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Checksums</span>
Both the core Bundle Protocol specification and core LTP
specification assume that they are transmitting over an erasure
channel, i.e., a channel that either delivers packets correctly or
not at all.
<span class="h4"><a class="selflink" id="section-3.5.1" href="#section-3.5.1">3.5.1</a>. DCCP</span>
A DCCP transmitter MUST, therefore, ensure that the entire packet is
checksummed by setting the Checksum Coverage to zero. Likewise, the
DCCP receiver MUST ignore all packets with partial checksum coverage.
<span class="h4"><a class="selflink" id="section-3.5.2" href="#section-3.5.2">3.5.2</a>. UDP</span>
A UDP transmitter, therefore, MUST NOT disable UDP checksums, and the
UDP receiver MUST NOT disable the checking of received UDP checksums.
Even when UDP checksums are enabled, a small probability of UDP
packet corruption remains. In some environments, it may be
acceptable for LTP or the Bundle Protocol to occasionally receive
corrupted input. In general, however, a UDP implementation SHOULD
use optional security extensions available in the Bundle Protocol or
LTP to protect against message corruption.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. DCCP Congestion Control Modules</span>
DCCP supports pluggable congestion control modules in order to
optimize its behavior to particular environments. The two most
common congestion control modules (CCIDs) are TCP-like Congestion
Control (CCID2) [<a href="./rfc4341" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control"">RFC4341</a>] and TCP-Friendly Rate Control (CCID3)
[<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>]. TCP-like Congestion Control is designed to emulate TCP's
congestion control as much as possible. It is recommended for
applications that want to send data as quickly as possible, while
TCP-Friendly Rate Control is aimed at applications that want to avoid
<span class="grey">Kruse, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
sudden changes in sending rate. DTN use cases seem to fit more into
the first case, so DCCP CL's and transports SHOULD use TCP-like
Congestion Control (CCID2) by default.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
Port number assignments 1113/UDP and 4556/UDP have been registered
with IANA. The assignment for 1113/UDP referenced [<a href="./rfc5326" title=""Licklider Transmission Protocol - Specification"">RFC5326</a>]; this
entry has been changed to add the present document in addition to
[<a href="./rfc5326" title=""Licklider Transmission Protocol - Specification"">RFC5326</a>]. The assignment of 4556/UDP had no reference; this entry
has been changed to point to the present document. The service name
for 4556/UDP has been changed from dtn-bundle-udp to dtn-bundle.
Port number 1113/DCCP (ltp-deepspace) with Service Code 7107696 has
been assigned for the transport of LTP. Port number 4556/DCCP (dtn-
bundle) with Service Code 1685351985 has been assigned for the
transport of bundles. The port number assignment for 4556/TCP is
addressed in the [<a href="#ref-CLAYER" title=""Delay Tolerant Networking TCP Convergence Layer Protocol"">CLAYER</a>] document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This memo describes the use of datagrams to transport DTN application
data. Hosts may be in the position of having to accept and process
packets from unknown sources; the DTN Endpoint ID can be discovered
only after the bundle has been retrieved from the DCCP or UDP packet.
Hosts SHOULD use authentication methods available in the DTN
specifications to prevent malicious hosts from inserting unknown data
into the application.
Hosts need to listen for and process DCCP or UDP data on the known
LTP or Bundle Protocol ports. A denial-of-service scenario exists
where a malicious host sends datagrams at a high rate, forcing the
receiving hosts to use their resources to process and attempt to
authenticate this data. Whenever possible, hosts SHOULD use IP
address filtering to limit the origin of packets to known hosts.
<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-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-RFC2147">RFC2147</a>] Borman, D., "TCP and UDP over IPv6 Jumbograms", <a href="./rfc2147">RFC 2147</a>,
May 1997.
[<a id="ref-RFC2675">RFC2675</a>] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
<a href="./rfc2675">RFC 2675</a>, August 1999.
<span class="grey">Kruse, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
[<a id="ref-RFC4340">RFC4340</a>] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", <a href="./rfc4340">RFC 4340</a>, March 2006.
[<a id="ref-RFC4341">RFC4341</a>] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", <a href="./rfc4341">RFC 4341</a>, March 2006.
[<a id="ref-RFC5050">RFC5050</a>] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", <a href="./rfc5050">RFC 5050</a>, November 2007.
[<a id="ref-RFC5325">RFC5325</a>] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
Transmission Protocol - Motivation", <a href="./rfc5325">RFC 5325</a>, September
2008.
[<a id="ref-RFC5326">RFC5326</a>] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", <a href="./rfc5326">RFC 5326</a>,
September 2008.
[<a id="ref-RFC5327">RFC5327</a>] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
Transmission Protocol - Security Extensions", <a href="./rfc5327">RFC 5327</a>,
September 2008.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-CLAYER">CLAYER</a>] Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant
Networking TCP Convergence Layer Protocol", Work in
Progress, January 2014.
[<a id="ref-Kent87">Kent87</a>] Kent, C. and J. Mogul, "Fragmentation considered harmful",
SIGCOMM '87, Proceedings of the ACM workshop on Frontiers
in computer communications technology, 1987,
<<a href="http://doi.acm.org/10.1145/55482.55524">http://doi.acm.org/10.1145/55482.55524</a>>.
[<a id="ref-RFC1191">RFC1191</a>] Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC 1191</a>,
November 1990.
[<a id="ref-RFC1981">RFC1981</a>] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", <a href="./rfc1981">RFC 1981</a>, August 1996.
[<a id="ref-RFC2309">RFC2309</a>] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", <a href="./rfc2309">RFC 2309</a>, April 1998.
[<a id="ref-RFC2914">RFC2914</a>] Floyd, S., "Congestion Control Principles", <a href="https://www.rfc-editor.org/bcp/bcp41">BCP 41</a>, <a href="./rfc2914">RFC</a>
<a href="./rfc2914">2914</a>, September 2000.
<span class="grey">Kruse, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7122">RFC 7122</a> Internet Datagram Transport for DTN March 2014</span>
[<a id="ref-RFC2923">RFC2923</a>] Lahey, K., "TCP Problems with Path MTU Discovery", <a href="./rfc2923">RFC</a>
<a href="./rfc2923">2923</a>, September 2000.
[<a id="ref-RFC4342">RFC4342</a>] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", <a href="./rfc4342">RFC 4342</a>,
March 2006.
[<a id="ref-RFC4821">RFC4821</a>] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", <a href="./rfc4821">RFC 4821</a>, March 2007.
[<a id="ref-RFC5405">RFC5405</a>] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", <a href="https://www.rfc-editor.org/bcp/bcp145">BCP 145</a>, <a href="./rfc5405">RFC 5405</a>, November
2008.
Authors' Addresses
Hans Kruse
Ohio University
31 S. Court Street, Rm 150
Athens, OH 45701
United States
Phone: +1 740 593 4891
EMail: kruse@ohio.edu
Samuel Jero
Purdue University
West Lafayette, IN 47907
United States
EMail: sjero@purdue.edu
Shawn Ostermann
Ohio University
Stocker Engineering Center
Athens, OH 45701
United States
Phone: +1 740 593 1566
EMail: ostermann@eecs.ohiou.edu
Kruse, et al. Experimental [Page 11]
</pre>
|
