[Hipsec] Using Next Header with IPv6

Robert Moskowitz <rgm@htt-consult.com> Thu, 08 September 2016 20:16 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F2EDF12B124 for <hipsec@ietfa.amsl.com>; Thu, 8 Sep 2016 13:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MZKp8a5fIo_s for <hipsec@ietfa.amsl.com>; Thu, 8 Sep 2016 13:16:49 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com []) (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 42CDB12B117 for <hipsec@ietf.org>; Thu, 8 Sep 2016 13:16:49 -0700 (PDT)
Received: from localhost (localhost []) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3196A62131 for <hipsec@ietf.org>; Thu, 8 Sep 2016 16:16:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([]) by localhost (z9m9z.htt-consult.com []) (amavisd-new, port 10024) with LMTP id kDiHBfg03lOw for <hipsec@ietf.org>; Thu, 8 Sep 2016 16:16:30 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 86DB262130 for <hipsec@ietf.org>; Thu, 8 Sep 2016 16:16:30 -0400 (EDT)
To: HIP <hipsec@ietf.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <fb77d194-418e-849f-b418-bb087fc01289@htt-consult.com>
Date: Thu, 08 Sep 2016 16:16:20 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/l74MGZ-Z3qwmtEqG5Jrrt-RZ9Mc>
Subject: [Hipsec] Using Next Header with IPv6
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 20:16:51 -0000

This is more to implementors or people that understand network stacks...

We provided in 7401 a Next Header field as all good IPv6 payloads are 
suppose to do.  But we really have not used it in front of 'real' IPv6 
payloads like ESP, TCP, UDP, or IPnIP.  Or have we and I have just 
missed it?

Anyway this is for faster mobility; looking at 5206-bis and IF the 
payload is small enough to fit in a HIP UPDATE, to send the Mobility 
UPDATE along with the actual first data from the moving host.

This question is primarily 'will the stack handle this'?  That is, HIP 
gets to payload first.  If validates the UPDATE, changes the necessary 
bindings the either:

     pushes a revised frame without the HIP UPDATE back into the IP 
     or sends the Next Header off to where it belongs.

I am not a person that has dealt with the insides of the OS(s) to know 
how this would be done or if it is really practical.

Oh, and what is the length of the basic HIP UPDATE in 5206-bis?  I can 
do my best calculation in a bit, but if someone has it...