[6lo] Iotdir last call review of draft-ietf-6lo-fragment-recovery-07
Erik Nordmark via Datatracker <noreply@ietf.org> Thu, 28 November 2019 00:45 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C34D3120B15; Wed, 27 Nov 2019 16:45:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Nordmark via Datatracker <noreply@ietf.org>
To: Iot-dir@ietf.org
Cc: last-call@ietf.org, draft-ietf-6lo-fragment-recovery.all@ietf.org, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Nordmark <nordmark@sonic.net>
Message-ID: <157490190471.21976.4374446442156394748@ietfa.amsl.com>
Date: Wed, 27 Nov 2019 16:45:04 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/DfRdrHVtgWZ9Tf3Dp2_ORDda6ak>
Subject: [6lo] Iotdir last call review of draft-ietf-6lo-fragment-recovery-07
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2019 00:45:05 -0000
Reviewer: Erik Nordmark Review result: Almost Ready 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.
- [6lo] Iotdir last call review of draft-ietf-6lo-f… Erik Nordmark via Datatracker
- Re: [6lo] Iotdir last call review of draft-ietf-6… Pascal Thubert (pthubert)