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

Michael Richardson <> Wed, 12 July 2017 00:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28C3613181E for <>; Tue, 11 Jul 2017 17:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5npL4VkId613 for <>; Tue, 11 Jul 2017 17:44:36 -0700 (PDT)
Received: from ( [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71033131705 for <>; Tue, 11 Jul 2017 17:44:36 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:b:a11:96ff:fe01:81e0]) by (Postfix) with ESMTPS id 9FE161F906; Wed, 12 Jul 2017 00:44:33 +0000 (UTC)
Received: by (Postfix, from userid 179) id E1F1AE43; Tue, 11 Jul 2017 20:44:31 -0400 (EDT)
From: Michael Richardson <>
To: Brian E Carpenter <>
cc: Anima WG <>
In-reply-to: <>
References: <>
Comments: In-reply-to Brian E Carpenter <> message dated "Thu, 06 Jul 2017 14:19:23 +1200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 11 Jul 2017 20:44:31 -0400
Message-ID: <>
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: Wed, 12 Jul 2017 00:44:39 -0000

Brian E Carpenter <> wrote:
    > Is the following correct?

    > Topology (ASCII art):

Topology is essentially correct.
As you point out, RFC7217 is the recommendation going forward, so having
a a big IEEE OUI allocation isn't necessary anymore.

But, the problem is you have a single Ax for the device.
The ACP needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc. That's why I
wanted a /96 or so provided by the ACP to each device.

So it becomes:

> Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1]
> Proxy sends to Registrar [Ax1, Ar, 41,   [Lp, Lx1, 17, UDP-PAYLOAD1]]
> Registrar replies to proxy [Ar, Ax1, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]]
> Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2]

Toerless says that a non-priveledged process (the proxy) can't easily
configure additional LL addresses.  That's true. It also can't configure the
addresses for the ACP.  The ACP needs to do that.

The Lx1 and Lx2 could be identical, although I'd not want to design my device
that way.  I looked at the CDP/LLDP spec, and both are unclear what the
source L2 address is.

    > So, what the registrar needs to tell the proxy is: I accept IP in IP on
    > address Ar.  Nothing else - no port number, no link-local address.

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.

Instead, I have two suggestions, not entirely mutually exclusive:
  1) the Registrar says, "I accept IPIP on Address Ar, use Lr for connections"
  2) we make Lr = well known Link-Local anycast address

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.

    > What the proxy needs to tell the pledge is: I accept BRSKI/TCP or
    > BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact the
    > registrar, it simply forwards the packets as-is in both directions,
    > encapsulating and decapsulating accordingly. The pledge knows nothing
    > about IPIP.

It needs to know it's IPIP, but I think you mean, it knows nothing about
what's inside the inner IP header.   There is some work (which I've yet to
complete) to arrange to forward LL-IP packets coming out of the IPIP
interface to the physical interface, since LL packets are normally never
forwarded.  Really, this is a kind of bridge (that's what I'll tell the

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.
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 =-