IETF Logo Mail Archive

Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 19 July 2016 10:31 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 8F55812B05A; Tue, 19 Jul 2016 03:31:10 -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 G8GLhULbwMwc; Tue, 19 Jul 2016 03:31:07 -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 D112A12B049; Tue, 19 Jul 2016 03:31:07 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7197C20183; Tue, 19 Jul 2016 06:40:34 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0FE5D638D1; Tue, 19 Jul 2016 06:31:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org, 6man@ietf.org
In-Reply-To: <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com>
References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@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: Tue, 19 Jul 2016 06:31:07 -0400
Message-ID: <30725.1468924267@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/-WkQvrHdpj3hlN-C28XopC5gdpc>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo
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: Tue, 19 Jul 2016 10:31:10 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >>
    >> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a
    >> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3).
    >> There is work on 6lo to allocate additional 6lowpan IPHC codes such that
    >> the work in ROLL:
    >> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can
    >> know what kinds of things we need to compress.
    >>
    >> A number of things are constrained by the need to always remove the
    >> RFC6553 Hop-by-Hop option RPI option which had been marked critical:
    >> i.e. drop packet if you don't understand it.
    >>
    >> As a result of the change in RFC2460bis, which says that intermediate hosts
    >> will in general not examine hop-by-hop options, but should just ignore
    >> them, we can make certain simplications to the useofrplinfo document.
    >> (rfc2460bis, section 4, page 8, "NOTE: While...)

    > You can already do that, because RFC7045 section 2.2 updates RFC2460:
    > " The IPv6 Hop-by-Hop Options header SHOULD be processed by
    > intermediate forwarding nodes as described in [RFC2460]."
    > which of course means that forwarding nodes MAY ignore HbH.

It's not what *I* want to do, it's what *I* can expect *others* to do.
So 7045 doesn't help me.

    > 00 - skip over this option and continue processing the header.

A type=10 option was allocated by RFC6553

I think it was a mistake.  We have discussed changing it as we add
compression for 6553, 6554 and IPIP (which would be a flag day anyway).
This was considered undesireable, because there was a desire not to leak
our headers; that the internet would drop our packets if we screwed up.

But, it turns out that the internet won't drop out packets, so we might
as well optimize the situation so that if we don't need to remove our
Hob-by-Hop header, then we don't need extra IPIP headers.

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

v2.23.0 | Report a Bug | By Email