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

Brian E Carpenter <> Wed, 12 July 2017 02:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 304E7126D46 for <>; Tue, 11 Jul 2017 19:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9IJchmcaovaU for <>; Tue, 11 Jul 2017 19:02:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E1231241FC for <>; Tue, 11 Jul 2017 19:02:46 -0700 (PDT)
Received: by with SMTP id u62so4918643pgb.3 for <>; Tue, 11 Jul 2017 19:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vwq+ocrUeLttGObJmKyDx5/rgheqMWnJJ6Wj31DGHBc=; b=iQu76tGtthGNIm6pQ5JKlO6b74Y6+ORV7YuXaFXyslxQjm9R7OquCJNiGBxjiNH/he MGnSS5UptjWfHzm0QjFog7JZJZtIOxud3TgogzgteeuC3asAm6RYe6WBFYakkR2ddgWP rYgWZPjH4eaLJ8Yh9h1UatGv7NYTRdH7m9aF5kUuVMReDyH0A4omk+abPTLvow8FZFjh E3etgSy6tV3/Pca9ggnW5WbAabG5kkHpNti9v9JPCTFkfMdipDSl3rlGGBoZEfbYljkB ZCHmVGxkeeCYK3uPWGjUpXNmwGPH1wVixY8uocLgTDCgvtaR/3tR0nvxcZJXO/hBUn3/ bw9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vwq+ocrUeLttGObJmKyDx5/rgheqMWnJJ6Wj31DGHBc=; b=dRx3/pC6i17lWLHry1xTz0nPL5Sl6/gb/3bBWgfnSaFx4xCGdhe1oAaqW8IW5GBgev OlCXI39JC86fOc2fXO4u9zMo2tkAmvgQ4UAWFQTx/3Vx9F2ESIlH6w8T4KptGmHEV3mU F7aEC+kcKCNSFFz5qyyV/8mwBdURaql1OuQcGolEMGek+dDEM6LGcuwgnQrdp4pA5Chj PeoXGKiS+4XQDStPjrP73u1PRiP++eehJhzPNr1mYZlPFs04AS+4Y+5PhfF11Jvfi28s hjLg73/NB+uLwVAPvW66p+Iq8iNZV/goZTMT7BwOOcy+auXjNQ7CH71/AHBIUsfEmD3V VeLw==
X-Gm-Message-State: AIVw110/7+cCOAOJ2W8HJEobO4zUPasETh4sWED/mdtM3TgGtUHNdwFG wkzbM6p57cmdlc7n
X-Received: by with SMTP id i4mr1436432pgn.250.1499824965098; Tue, 11 Jul 2017 19:02:45 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id q67sm1136359pfi.81.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 19:02:44 -0700 (PDT)
To: Michael Richardson <>
Cc: Anima WG <>
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 12 Jul 2017 14:02:44 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 02:02:48 -0000

On 12/07/2017 12:44, Michael Richardson wrote:
> 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.

Yes, that would disambiguate it. But in general it isn't necessary for
a node to have multiple ACP addresses just because it has multiple
interfaces, is it?

> That's why I
> wanted a /96 or so provided by the ACP to each device.

That would be one way, but it will create noise in 6man.
In any case if the requirement is one address per proxy+interface
I'm sure it can be done somehow; IPv6 addresses are cheap.

> 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"

I don't understand where Lr would be used. The LL messages are
all between the pledge and the proxy, which have perfectly fine
LL addresses of their own.

>   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,

Why? The IPIP encapsulation and decapsulation can happen inside the proxy
(and the registrar). Why does the pledge care?

> 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
> v6-police).
> As for Toerless' notion that we should invent a new UDP-based encapsulation

IPv6-over-UDP isn't exactly a new invention. It's been used in Teredo,
TSP (RFC5572) and SixXs (
More to the point, draft-ietf-intarea-gue is in progress.

All the same, if straight IPIP works, so much the better.


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