Skip to main content

Last Call Review of draft-ietf-6lo-fragment-recovery-07
review-ietf-6lo-fragment-recovery-07-iotdir-lc-nordmark-2019-11-27-00

Request Review of draft-ietf-6lo-fragment-recovery
Requested revision No specific revision (document currently at 21)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2019-11-29
Requested 2019-11-04
Requested by Suresh Krishnan
Authors Pascal Thubert
Draft last updated 2019-11-27
Completed reviews Iotdir Last Call review of -07 by Erik Nordmark (diff)
Genart Last Call review of -08 by Peter E. Yee (diff)
Secdir Last Call review of -08 by Tirumaleswar Reddy.K (diff)
Tsvart Last Call review of -11 by Colin Perkins (diff)
Genart Telechat review of -12 by Peter E. Yee (diff)
Assignment Reviewer Erik Nordmark
State Completed
Review review-ietf-6lo-fragment-recovery-07-iotdir-lc-nordmark-2019-11-27
Posted at https://mailarchive.ietf.org/arch/msg/Iot-dir/GO1642x4azuE8K0xXwdAMYah9L4
Reviewed revision 07 (document currently at 21)
Result Almost Ready
Completed 2019-11-27
review-ietf-6lo-fragment-recovery-07-iotdir-lc-nordmark-2019-11-27-00
Review of draft-ietf-6lo-fragment-recovery-07

Section 4.3 seems to silently assume that all fragments of a datagram go
through the same intermediate hops. This should at a minimum be made explicit.
But does the intended deployments satisfy such an assumption?

Drawing in section 5.1 shows an 8 byte datagram_tag but the text says it is 16
bits. That's inconsitent.

I'd like to understand the issues and protection against reuse of the
datagram_tag. Since this is rewritten on each hop and the hops can be routers
forwarding at high rate, even 16 bits can cycle very quickly.

The document should presumably specify how the receiver knows it has received
all the fragments in 6.0; as I understand the sequence number can not be used
for this but instead the receiver needs to check that it has received every
byte offset from zero to datagram_size at least once. (The refragmenting due to
MTU changes makes this complex.) Question: If the receiver has already received
from byte range once and receives a subset of that range again (due to a
retransmission after MTU change) is the receiver supposed to do something to
compare the content being the same for the repeated byte range?

Note that for IP fragmentation we have determined that overlapping fragments
can be used to fool firewalls. I don't know to what extent that is an issue for
this fragmentation. Perhaps that should be mentioned in the security
considerations section?

Section 6.1.1 seems to make the assumption that a packet with sequence zero is
only transmitted once, hence I don't understand how this will work when it is
lost and then retransmitted by the sender.

Nits:
Section 2.3 defines 5 terms but all of "LLN" are unused. I suggest the unused
terms be removed to avoid any confusion. Yet other terms like "LSP" are not
defined.