Re: [Anima] Is this how BRSKI/IPIP works?

Toerless Eckert <> Sun, 16 July 2017 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D197128961 for <>; Sun, 16 Jul 2017 11:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P0zo8KirlAgY for <>; Sun, 16 Jul 2017 11:27:54 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0660912702E for <>; Sun, 16 Jul 2017 11:27:53 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:77]) by (Postfix) with ESMTP id 1B9BD58C4B0; Sun, 16 Jul 2017 20:27:50 +0200 (CEST)
Received: by (Postfix, from userid 10463) id E24B4B0C5DA; Sun, 16 Jul 2017 20:27:49 +0200 (CEST)
Date: Sun, 16 Jul 2017 20:27:49 +0200
From: Toerless Eckert <>
To: Michael Richardson <>
Cc: Brian E Carpenter <>, Anima WG <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Anima] Is this how BRSKI/IPIP works?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Jul 2017 18:27:56 -0000

I thought i had asked that question already but not sure, and not seen an answer:
- I have never seen that a device has more than one link-local addr on an interface.
  Is this permitted by IPv6 arck ? Can you configure this in eg: Linux. I thought i
  tried on linux/cisco-ios in the past and i do not quite remember, but i think it
  failed (only one address).

- Do we have another address assignment scheme other than a) MAC address based,
  or b) RFC7217   or c) non-randomn manual config. Could we get some scope
  relative address range for this purpose ?

More inline:

On Tue, Jul 11, 2017 at 08:44:31PM -0400, Michael Richardson wrote:
> There is a small problems with this.  With a UDP transport, we simply
> have to arrange for the registrar to accept traffic to any LxX IP address.
> That's not stock POSIX, but it's not that hard.  LxX state can be handled
> by the application.  With TCP the kernel has be rather flexible, being
> able to keep duplicate Lp<->Lx1 connections seperate in the kernel, and
> at the same time, permitting any LxX on the Registrar's side.

How would this work, can you elaborate a bit ? 

Btw: Off the top of my head i think its a lot easier to forget kernel stuff and
use a registrar that maps received eg: UDP (or IPinIP) packets with encapsulated 
UDP/CoAP payloads than trying to persuade to build a virtual interface for each
association. When the payload becomes TCP/TLS/BRSKI, i do see more value in
trying to have the registrar app NOT have to deal with TCP.

> In my implementation, I dynamically set up an IPIP interface for each Lx
> on each proxy that appears.  The kernel assigns a new ifindex to each of
> these interfaces, and the normal LL-requires-ifindex rules apply to
> distinguish things.  This requires a retransmission since the first time
> there is a packet from a new Ax1/LAN1, the packet does not match any current
> IPIP tunnel, and is dropped by the kernel.  A process watches for these
> and configures them LRU.
> As for Toerless' notion that we should invent a new UDP-based encapsulation
> rather than use the well defined IPIP encapsulation, I have really no comment.

That easy to make you speech-less ? How bout writing a registrar on anything
else than Linux. Do you feel confident you can get what you need into any OS
kernel ?


> I'm pretty sure that many will want to leverage existing v6-extension header
> chasing hardware for the purpose of auditing, which is why I prefer not
> to invent new on-the-wire formats just to so that some software engineer can
> avoid having to learn a new API call.
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]        |   ruby on rails    [
> --
> Michael Richardson <>, Sandelman Software Works
>  -= IPv6 IoT consulting =-

> _______________________________________________
> Anima mailing list