Re: [6lo] fragment forwarding document

Michael Richardson <> Mon, 24 July 2017 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95A34131E93 for <>; Mon, 24 Jul 2017 09:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K1Ik4V72HpKd for <>; Mon, 24 Jul 2017 09:28:22 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47FBC131E86 for <>; Mon, 24 Jul 2017 09:28:22 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id E7EAA2009E; Mon, 24 Jul 2017 12:29:41 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 915178070B; Mon, 24 Jul 2017 12:28:20 -0400 (EDT)
From: Michael Richardson <>
To: "Pascal Thubert \(pthubert\)" <>
cc: Jonathan Hui <>, "6lo\" <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 24 Jul 2017 12:28:20 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [6lo] fragment forwarding document
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Jul 2017 16:28:25 -0000

Pascal Thubert (pthubert) <> wrote:
    > Fragment_offset:  11 bit unsigned integer; when set to 0, this field
    > indicates an abort condition; else, its value depends on the value
    > of the Sequence.  When the sequence is not 0, this field indicates
    > the offset of the fragment in the compressed form.  When the
    > sequence is 0, denoting the first fragment of a datagram, this

    > reword. I think it means:
    > if Sequence > 0; fragment_offset == 0 => abort.
    > ; else offset of fragment
    > if Sequence ==0; fragment_offset is total size of datagram.
    > --------------------

    > [Pascal] This is effectively a big stone you are unturning. The intent
    > of the initial logic is: 

    > If fragment_offset == 0; forward of you can and cleanup (aka abort)
    > ; else
    > if Sequence ==0; fragment_offset is total size of datagram
    > ; else fragment_offset is offset in the datagram in octets

    > [Pascal] With the current text (sequence, offset) tuple of (0, 0) is
    > significant whereas with your proposal, this tuple becomes a protocol
    > error. Either way, we probably need some more text what nodes should do
    > in that case. I'm not too much in favor of creating an error case;
    > error flows have a tendency to not perform well.

I wasn't suggesting to change the protocol, I was trying to explain it.
I clearly did not understand it!

    > [Pascal] Let's consider this: (0,0) could be useful, because it carries
    > the original IP header so there's a chance it goes all the a to the
    > reassembly end point even if the forwarding state is broken midway;
    > this could be important because the end point is where the buffers are
    > wasted. And because it may be routed differently than a previous (0,
    > X>0), a (0, 0) may fail to clean up state along the old path even when
    > the old path is not broken. We'll note that the old path may be cleanup
    > all the way back (to the breakage if there's one) by a reset message
    > from the end point. That reset message could be stimulated by receiving
    > a (0, 0). But with the 6LoWPAN signaling as it stands now, the end
    > point may not recognize that this is the same IP packet because the
    > datagram tags would possibly be different, being switched differently
    > along different routes. If we care to take that path, we need the end
    > points to exchange end-to-end IDs for the flows. Doable but
    > expensive. Worth it?

I think you've jumped ahead of me.
You are talking about a way to clean up state given multiple possible paths.

I'm just barely at the point where I can understand how the state is
created :-) 

    > section 5 says:
    > The process ensures that at every hop, the source
    > MAC address and the datagram_tag in the received fragment are enough
    > information to send the RFRAG Acknowledgment back towards the source
    > 6LoWPAN endpoint by reversing the MPLS operation.

    > It seems that we are assuming SLAAC built addresses using EUI-64s?
    > (which could well be 2-byte short addresses too!)  otherwise, mapping From MAC address back to an IPv6 address is not possible?

    > [Pascal] I do not see how/why. 

    > [Pascal] All it means is that the MPLS operation address is indexed by
    > the tuple (incoming link - as identifies by smac, label - the datagram
    > tag). No big news there, once created an MPLS LSP can carry non IP
    > traffic.

I think you are saying that since the final fragment assembler will have
reassembled the L3 header, that it will know where to send the ACK.

    > ------------
    > change the source MAC address to from MAC_prev to MAC_self

    > "to from" --- is this correct, or is there an extra word here?
    > [Pascal] 
    > [Pascal] fixed typo : )

okay, good. I thought that maybe there was some extra meaning I didn't get.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-