[Roll] RFC6553 headers if HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 28 March 2016 15:41 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A8D7812DB01; Mon, 28 Mar 2016 08:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1jkPvayOp_71; Mon, 28 Mar 2016 08:41:48 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD0612DAE7; Mon, 28 Mar 2016 08:41:08 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id 589D52009E; Mon, 28 Mar 2016 11:44:08 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5814D63755; Mon, 28 Mar 2016 11:41:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ipv6\@ietf.org" <ipv6@ietf.org>, Ronald Bonica <rbonica@juniper.net>
In-Reply-To: <BLUPR05MB198551769CEF18D840903C03AE860@BLUPR05MB1985.namprd05.prod.outlook.com>
References: <BLUPR05MB198552E9C04B2DCDFB564387AE820@BLUPR05MB1985.namprd05.prod.outlook.com> <CAHw9_iKkHhCOZ+=xQJRFp351P9d=YJhw2HktwS1bxC6rN-Kgzw@mail.gmail.com> <CAD6AjGS94ueF7vA5s_cQvmG1cp2T-9w2UYE3DR6hepm0eV=Cmw@mail.gmail.com> <56F45BEB.2010906@gmail.com> <BLUPR05MB1985F8C5850FB7A60372C920AE830@BLUPR05MB1985.namprd05.prod.outlook.com> <29956.1458941723@obiwan.sandelman.ca> <BLUPR05MB198551769CEF18D840903C03AE860@BLUPR05MB1985.namprd05.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
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, 28 Mar 2016 11:41:07 -0400
Message-ID: <17512.1459179667@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/8Hr_woZERFKzokzHb0b7ZeZyXB0>
Cc: Ca By <cb.list6@gmail.com>, roll@ietf.org, Warren Kumari <warren@kumari.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Brian Haberman <brian@innovationslab.net>
Subject: [Roll] RFC6553 headers if HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)
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, 28 Mar 2016 15:41:50 -0000

Ronald Bonica <rbonica@juniper.net> wrote:
    > I thought about that possibility. But doesn't that mean that hosts
    > would have to recognize HBH forever, if for no reason other than to
    > know enough to move on to the next header?

That's a good point.
Yes, they'd have to know how to skip it if they want to look at the next

So, this would not affect routers that do not care to look at the next
header, but would affect end-hosts ... mostly. And security devices.

Anyone with deployed code *NOW* has this already.
So this only matters to people writing new code (or new chips).

If you think that there is ENOUGH savings... I'm listening.

What would happen to packets with RFC6553 HbH when they hit a core routers
after the change?  Ignore end hosts: I assume that if they need to understand
6553 packets addressed to them that they can afford the code.

Then we need to consider what it means for an LLN gateway that receives
a packet with a 6553 HbH option in it: since they act a bit like MPLS or
VLAN tags, we might have to drop them anyway, since they aren't trusted.

So, at the least, we would like to put IPsec AH on them, but since they are
mutable, that doesn't help that much (at least it authenticates the source,
maybe...), so we actually have to put IPsec tunnel mode on it... at which
point we are essentially back to IPIP headers on a hop-by-hop basis.
(This is precisely the ANIMA ACP model, btw. IPv6(LL)-IPsec-RPI-IPv6..)

So maybe core routers and security devices would never see RFC6553 HbH
headers..!  I'd still like to change them from 63 to 43 for the case where
the end-host doesn't speak RPI, such as in the ANIMA
NOC-does-not-speak-ACP-yet use case.

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