Re: [Roll] useofrplinfo version 5

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 18 July 2016 14:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68A612DD3D for <roll@ietfa.amsl.com>; Mon, 18 Jul 2016 07:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO3i38s9XKlZ for <roll@ietfa.amsl.com>; Mon, 18 Jul 2016 07:57:00 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861F912DF98 for <roll@ietf.org>; Mon, 18 Jul 2016 07:28:37 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E686E200A7 for <roll@ietf.org>; Mon, 18 Jul 2016 10:38:00 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5E046638D1 for <roll@ietf.org>; Mon, 18 Jul 2016 10:28:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <e4d82623-86e1-efd7-b813-de4dedb2eaf8@gmail.com>
References: <b9e569f12a008245ef824e340f510dff@xs4all.nl> <e4d82623-86e1-efd7-b813-de4dedb2eaf8@gmail.com>
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-sha1; protocol="application/pgp-signature"
Date: Mon, 18 Jul 2016 10:28:36 -0400
Message-ID: <28854.1468852116@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mL28NA5AayvmsDvoyk4iE6PCFAA>
Subject: Re: [Roll] useofrplinfo version 5
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 14:57:02 -0000

Cenk Gündogan <cnkgndgn@gmail.com>; wrote:
    > Hey *,

    > ---
    > 5.3) The question in this scenario is how the root knows how to address
    > the IPv6-in-IPv6 header.  It can not know that the destination isn't
    > RPL aware, so it must insert an IPv6 header that can be removed on the
    > last RPL aware node.  Since the root can not know in a storing network
    > where the last RPL aware node is, the IPv6-in-IPv6 header must be added
    > hop-by-hop along the path from root to leaf.
    > ---

    > in section 5.3 it is said that the sender does not know whether the
    > destinationaddress is rpl-aware or not.  This might be true for P2P
    > traffic, but for root->leaf traffic, I would expect that the root knows
    > that.

I don't want to be confused by the term P2P: let's use the term leaf to leaf
traffic unless you are speaking about a path that is arrived at via P2PRPL.
(RFC 6997).

    > There is the Transit Option for DAOs with the 'E' flag to indicate that
    > the target address was not learned from rpl.  I would expect that this
    > 'E' flag is set for all Transit Options in DAOs until it reaches the
    > root node (recursively).  So the root node should actually be aware
    > which address was learned from RPL and which not.

Assuming that the 'E' bit was set, and that it propogated up to the root
(I can't find any text in RFC6550 that mandates that, maybe I missed it),
the root still would not know the address of the adjacent 6LR, if there is
more than two layers of mesh.

And, as you point out, it won't work for leaf to leaf traffic, so we still
have to support the situation of hop-by-hop IPv6-in-IPv6. (unless rfc2461bis)

It does permit us to distinguish between situation 5.2 (root to rpl-aware
leaf) and 5.3 (root to not-rpl-aware-leaf), which is certainly an
improvement! The root then learn about the "E" status for all leaf nodes, and
if there are no not-RPL-aware leafs, could announce that in it's DIO.  That
would permit leafs to know that case 5.10 (leaf to not-RPL-aware leaf) never
occurs, and therefore could avoid IPv6-in-IPv6 headers in that case.
        (can you contribute any text for the document from this?)

This a definite improvement as well: and the result is that we may need a
document to describe an option to put into the DIO to announce this
situation. (If there *are* not-RPL-aware leafs, then another option instead
of IPv6-in-IPv6 hop-by-hop for all traffic, would be for leafs to
IPv6-in-IPv6 traffic to the root rather than go across the DODAG.  Serious
performance and congestion issues if we do that, but maybe less code and less

Ines and Michael.

--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-