Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Philip Levis <pal@cs.stanford.edu> Sat, 16 August 2014 00:33 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F41A08FD; Fri, 15 Aug 2014 17:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.268
X-Spam-Level:
X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 SB6vNeuh8FL9; Fri, 15 Aug 2014 17:33:39 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E901A08F7; Fri, 15 Aug 2014 17:33:39 -0700 (PDT)
Received: from [76.14.66.110] (port=61003 helo=[192.168.0.106]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XIRw8-0002NS-Bh; Fri, 15 Aug 2014 17:33:37 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <53EE6441.1000908@globis.net>
Date: Fri, 15 Aug 2014 17:33:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/e3dXR5dgfjPSoiwLUtMGTaOI08Q
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, roll <roll@ietf.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sat, 16 Aug 2014 00:33:40 -0000

On Aug 15, 2014, at 12:49 PM, Ray Hunter <v6ops@globis.net> wrote:

> After reading the draft it seems to me that what is being attempted is
> 1) to add some stuff to the IPv6 header that is RPL domain specific
> 2) to reduce the overall packet length to reduce active radio time and thus save energy
> by
> 3) overloading an existing well-defined and used IPv6 header field
> 
> My simple logic tells me that
> 1) could be best solved at an architecture level via an extension header http://tools.ietf.org/html/rfc2460#page-11 + http://tools.ietf.org/html/rfc7045
> 2) could be best solved at an architecture level via IP header compression http://tools.ietf.org/html/rfc2507.html with or without additional tweaks
> and that overloading an opaque field in 3) by incorporating values with low entropy (as per the RPL flow label) gives additional security risks to http://tools.ietf.org/html/rfc7098
> 
> So what's wrong with my simple logic?

1) There is an extension header already; the problem is that it can introduce a significant (ballpark estimates are, in well engineered networks, up to 5-10%) cost. The proposal is to replace the extension header with using the flow label.

2) There'a already significant IP header compression in the cases we're talking about.

Phil