< draft-ietf-6lo-fragment-recovery-10.txt   draft-ietf-6lo-fragment-recovery-11.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4944 (if approved) 6 February 2020 Updates: 4944 (if approved) 10 February 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 9 August 2020 Expires: 13 August 2020
6LoWPAN Selective Fragment Recovery 6LoWPAN Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-10 draft-ietf-6lo-fragment-recovery-11
Abstract Abstract
This draft updates RFC 4944 with a simple protocol to recover This draft updates RFC 4944 with a simple protocol to recover
individual fragments across a route-over mesh network, with a minimal individual fragments across a route-over mesh network, with a minimal
flow control to protect the network against bloat. flow control to protect the network against bloat.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 August 2020. This Internet-Draft will expire on 13 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 34 skipping to change at page 2, line 34
6.2. Receiving RFRAG Acknowledgments . . . . . . . . . . . . . 16 6.2. Receiving RFRAG Acknowledgments . . . . . . . . . . . . . 16
6.3. Aborting the Transmission of a Fragmented Packet . . . . 16 6.3. Aborting the Transmission of a Fragmented Packet . . . . 16
6.4. Applying Recoverable Fragmentation along a Diverse 6.4. Applying Recoverable Fragmentation along a Diverse
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Path . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Management Considerations . . . . . . . . . . . . . . . . . . 17 7. Management Considerations . . . . . . . . . . . . . . . . . . 17
7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 17 7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 17
7.2. Observing the network . . . . . . . . . . . . . . . . . . 19 7.2. Observing the network . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. Normative References . . . . . . . . . . . . . . . . . . . . 20 11. Normative References . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 21 12. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Considerations on Flow Control . . . . . . . . . . . 26 Appendix C. Considerations on Flow Control . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
In most Low Power and Lossy Network (LLN) applications, the bulk of In most Low Power and Lossy Network (LLN) applications, the bulk of
the traffic consists of small chunks of data (on the order of a few the traffic consists of small chunks of data (on the order of a few
skipping to change at page 13, line 8 skipping to change at page 13, line 8
(the receiver) receives a fragment with the Ack-Request flag set, it (the receiver) receives a fragment with the Ack-Request flag set, it
MUST send an RFRAG Acknowledgment back to the originator to confirm MUST send an RFRAG Acknowledgment back to the originator to confirm
reception of all the fragments it has received so far. reception of all the fragments it has received so far.
The Ack-Request ('X') set in an RFRAG marks the end of a window. The Ack-Request ('X') set in an RFRAG marks the end of a window.
This flag MUST be set on the last fragment if the sender wishes to This flag MUST be set on the last fragment if the sender wishes to
protect the datagram, and it MAY be set in any intermediate fragment protect the datagram, and it MAY be set in any intermediate fragment
for the purpose of flow control. for the purpose of flow control.
This automatic repeat request (ARQ) process MUST be protected by a This automatic repeat request (ARQ) process MUST be protected by a
timer, and the fragment that carries the 'X' flag MAY be retried upon Retransmission TimeOut (RTO) timer, and the fragment that carries the
a time out for a configurable number of times (see Section 7.1). 'X' flag MAY be retried upon a time out for a configurable number of
Upon exhaustion of the retries the sender may either abort the times (see Section 7.1). Upon exhaustion of the retries the sender
transmission of the datagram or retry the datagram from the first may either abort the transmission of the datagram or retry the
fragment with an 'X' flag set in order to reestablish a path and datagram from the first fragment with an 'X' flag set in order to
discover which fragments were received over the old path in the reestablish a path and discover which fragments were received over
acknowledgment bitmap. When the sender of the fragment knows that an the old path in the acknowledgment bitmap. When the sender of the
underlying link-layer mechanism protects the fragments, it may fragment knows that an underlying link-layer mechanism protects the
refrain from using the RFRAG Acknowledgment mechanism, and never set fragments, it may refrain from using the RFRAG Acknowledgment
the Ack-Request bit. mechanism, and never set the Ack-Request bit.
The receiver MAY issue unsolicited acknowledgments. An unsolicited The receiver MAY issue unsolicited acknowledgments. An unsolicited
acknowledgment signals to the sender endpoint that it can resume acknowledgment signals to the sender endpoint that it can resume
sending if it had reached its maximum number of outstanding sending if it had reached its maximum number of outstanding
fragments. Another use is to inform the sender that the reassembling fragments. Another use is to inform the sender that the reassembling
endpoint aborted the processing of an individual datagram. endpoint aborted the processing of an individual datagram.
The RFRAG Acknowledgment can optionally carry an ECN indication for The RFRAG Acknowledgment can optionally carry an ECN indication for
flow control (see Appendix C). The receiver of a fragment with the flow control (see Appendix C). The receiver of a fragment with the
'E' (ECN) flag set MUST echo that information by setting the 'E' 'E' (ECN) flag set MUST echo that information by setting the 'E'
skipping to change at page 19, line 24 skipping to change at page 19, line 24
at the sender. The values should be bounded by the expected number at the sender. The values should be bounded by the expected number
of hops and reduced beyond that when the number of datagrams that can of hops and reduced beyond that when the number of datagrams that can
traverse an intermediate point may exceed its capacity and cause a traverse an intermediate point may exceed its capacity and cause a
congestion loss. The inter-frame gap is another tool that can be congestion loss. The inter-frame gap is another tool that can be
used to increase the spacing between fragments of the same datagram used to increase the spacing between fragments of the same datagram
and reduce the ratio of time when a particular intermediate node and reduce the ratio of time when a particular intermediate node
holds a fragment of that datagram. holds a fragment of that datagram.
8. Security Considerations 8. Security Considerations
The considerations in the Security sections of [I-D.ietf-core-cocoa] This document specifies an instantiation of a 6LoWPAN Fragment
and [I-D.ietf-6lo-minimal-fragment] apply equally to this Forwarding technique. "On Forwarding 6LoWPAN Fragments over a
specification. Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the
generic description of Fragment Forwarding and this specification
inherits from it. The generic considerations in the Security
sections of [I-D.ietf-6lo-minimal-fragment] apply equally to this
document.
The process of recovering fragments does not appear to create any This specification does not recommend a particular algorithm for the
opening for new threat compared to "Transmission of IPv6 Packets over estimation of the duration of the RTO that covers the detection of
IEEE 802.15.4 Networks" [RFC4944] beyond the change of size of the the loss of a fragment with the 'X' flag set; regardless, an attacker
datagram_tag. By being reduced to 8 bits, the tag will wrap faster on the path may slow down or discard packets, which in turn can
than with [RFC4944]. But for a constrained network where a node is affect the throughput of fragmented packets.
expected to be able to hold only one or a few large packets in
memory, 256 is still a large number. Also, the acknowledgement Compared to "Transmission of IPv6 Packets over IEEE 802.15.4
mechanism allows cleaning up the state rapidly once the packet is Networks" [RFC4944], this specification reduces the datagram_tag to 8
fully transmitted or aborted. bits and the tag wraps faster than with [RFC4944]. But for a
constrained network where a node is expected to be able to hold only
one or a few large packets in memory, 256 is still a large number.
Also, the acknowledgement mechanism allows cleaning up the state
rapidly once the packet is fully transmitted or aborted.
The abstract Virtual Recovery Buffer inherited from The abstract Virtual Recovery Buffer inherited from
[I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of- [I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-
Service (DoS) attack against the intermediate Routers since the Service (DoS) attack against the intermediate Routers since the
routers need to maintain a state per flow. The particular VRB routers need to maintain a state per flow. The particular VRB
implementation technique described in implementation technique described in
[I-D.ietf-lwig-6lowpan-virtual-reassembly] allows realigning which [I-D.ietf-lwig-6lowpan-virtual-reassembly] allows realigning which
data goes in which fragment, which causes the intermediate node to data goes in which fragment, which causes the intermediate node to
store a portion of the data, which adds an attack vector that is not store a portion of the data, which adds an attack vector that is not
present with this specification. With this specification, the data present with this specification. With this specification, the data
skipping to change at page 20, line 40 skipping to change at page 20, line 46
| 11 10101x | 15 | Reserved for Experimental Use | RFC 8025 | | 11 10101x | 15 | Reserved for Experimental Use | RFC 8025 |
+-------------+------+----------------------------------+-----------+ +-------------+------+----------------------------------+-----------+
Table 1: Additional Dispatch Value Bit Patterns Table 1: Additional Dispatch Value Bit Patterns
10. Acknowledgments 10. Acknowledgments
The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent
Toutain, Carles Gomez Montenegro, Thomas Watteyne, and Michael Toutain, Carles Gomez Montenegro, Thomas Watteyne, and Michael
Richardson for in-depth reviews and comments. Also many thanks to Richardson for in-depth reviews and comments. Also many thanks to
Peter Yee and Erik Nordmark for their careful reviews and for helping Peter Yee, Tirumaleswar Reddy Konda and Erik Nordmark for their
through the IESG review process, and to Jonathan Hui, Jay Werb, careful reviews and for helping through the IETF Last Call and IESG
Christos Polyzois, Soumitri Kolavennu, Pat Kinney, Margaret review process, and to Jonathan Hui, Jay Werb, Christos Polyzois,
Wasserman, Richard Kelsey, Carsten Bormann, and Harry Courtice for Soumitri Kolavennu, Pat Kinney, Margaret Wasserman, Richard Kelsey,
their various contributions. Carsten Bormann and Harry Courtice for their various contributions in
the long process that lead ot this document.
11. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
skipping to change at page 23, line 40 skipping to change at page 23, line 46
virtual-reassembly-01>. virtual-reassembly-01>.
[I-D.ietf-intarea-frag-fragile] [I-D.ietf-intarea-frag-fragile]
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", Work and F. Gont, "IP Fragmentation Considered Fragile", Work
in Progress, Internet-Draft, draft-ietf-intarea-frag- in Progress, Internet-Draft, draft-ietf-intarea-frag-
fragile-17, 30 September 2019, fragile-17, 30 September 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-frag- <https://tools.ietf.org/html/draft-ietf-intarea-frag-
fragile-17>. fragile-17>.
[I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", Work in
Progress, Internet-Draft, draft-ietf-core-cocoa-03, 21
February 2018,
<https://tools.ietf.org/html/draft-ietf-core-cocoa-03>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019, draft-ietf-6tisch-architecture-28, 29 October 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. architecture-28>.
[IEEE.802.15.4] [IEEE.802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE Standard 802.15.4, DOI 10.1109/IEEE IEEE Standard 802.15.4, DOI 10.1109/IEEE
 End of changes. 10 change blocks. 
39 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/