impacts of rfc2460bis on draft-ietf-roll-useofrplinfo
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 18 July 2016 19:03 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445A412B077; Mon, 18 Jul 2016 12:03:16 -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 Yr3IcjwRsKkU; Mon, 18 Jul 2016 12:03:14 -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 3356512B01E; Mon, 18 Jul 2016 12:03:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 69223200A7; Mon, 18 Jul 2016 15:12:38 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 391C5638D1; Mon, 18 Jul 2016 15:03:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
Subject: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo
X-Attribution: mcr
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 15:03:13 -0400
Message-ID: <24554.1468868593@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-wF5P27S59DDCvxH2onT4wUVHRc>
Cc: 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 19:03:16 -0000
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...) (It is unclear what end-hosts can/should do. I will assume they can also ignore hop-by-hop options if they haven't been told to pay attention to them). https://goo.gl/cxWkP5 this is a reference to an RFC diff between: draft-ietf-roll-useofrplinfo-06.txt and draft-richardson-roll-useofrplinfo-2460bis-00.txt (Note we have only re-analyzed storing mode , so please ignore changes in section 6) The summary is that in storing mode we never need to use per-hop IPv6-in-IPv6 encapsulation with the 2460bis text. Packets originating from not-RPL aware nodes (i.e. 6LN leafs or Internet nodes), need to be encapsulated so that the RPI option can be added, but no complex considerations need apply for where to remove the RPI, as it can be left in place until the end-host. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- Re: impacts of rfc2460bis on draft-ietf-roll-useo… Brian E Carpenter
- Re: impacts of rfc2460bis on draft-ietf-roll-useo… Michael Richardson
- Re: impacts of rfc2460bis on draft-ietf-roll-useo… Michael Richardson
- Re: [Roll] impacts of rfc2460bis on draft-ietf-ro… Pascal Thubert (pthubert)
- Re: [Roll] impacts of rfc2460bis on draft-ietf-ro… Pascal Thubert (pthubert)
- Re: impacts of rfc2460bis on draft-ietf-roll-useo… Brian E Carpenter
- Re: impacts of rfc2460bis on draft-ietf-roll-useo… Michael Richardson
- Re: impacts of rfc2460bis on draft-ietf-roll-useo… Brian E Carpenter
- impacts of rfc2460bis on draft-ietf-roll-useofrpl… Michael Richardson
- Re: [Roll] impacts of rfc2460bis on draft-ietf-ro… Tim Chown