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

Brian E Carpenter <> Thu, 13 July 2017 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DE3B131566 for <>; Thu, 13 Jul 2017 13:36:39 -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 jLqhHvV9LAYI for <>; Thu, 13 Jul 2017 13:36:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 091D612EC44 for <>; Thu, 13 Jul 2017 13:36:38 -0700 (PDT)
Received: by with SMTP id c73so34782819pfk.2 for <>; Thu, 13 Jul 2017 13:36:38 -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=662mzEaWnczg6YOF8MP6/8WxS4uSpjDRfkiNxr3BzmI=; b=FPmv9t/5zoqldKVpTFYLHqBt98sueku1JbH7NKbfAWKRt0/laOeIYcsCU35vvWq3Jg bhn5Wi58g1mY6DSB+f8EnA2JrkC9c+mkM4DTNuouKdIP0gJ7WFfR7WykT2C6O4OhAiLG fZZDZyOQ5NX5yCvyuCB3rzppoilpOTeqcgC582X6p3XDmxdG2LHmwosDm8KK7IbLh50j 2vHEMzMszsgoko5qLYx4sWnwhGgw8/lKcHQyUEivNKoB+YYd/EPejwqEU8EhcgfY2uXm mytHKhfyGznM7sgtE0SmOfXhT4P+U6rJZYbTFKyzQZNrKgpqL/dPHLsrt0Yo1jk5NuOy efLQ==
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=662mzEaWnczg6YOF8MP6/8WxS4uSpjDRfkiNxr3BzmI=; b=F6O9/CIuTjd6hxG2BvI+ORfq1+fP90ENkqvAZG72IUhTMD+63MLUM4nM2g1IF3fh85 Kw6hP0z7lI14ac2CqCSRov9TUZZ9ZZSr3PEJNryNbxCiOTWVXOcmApi8mcDWot0A8dAe feLEjQPVzD5APUnMzfT+/Gs+y2gGUmfLLeSZfAD1UibsfL0FpRQT3WUVI3Kx+ovn4CXV vbnuUCyfxBdDYPPTDzTHg17Fpg4SFCQgq+D93CBEDSfQ33nkBDuCWwlR0UzVBDxPvsle AZ1i4+mlUcjXtjiY5KRA1vnlkomHbHBzfCDj8NyplQ27tz02RlRzA45DIyQzloPvE/qS yeqQ==
X-Gm-Message-State: AIVw112/622hbSxWEHCquxYt15YkpsP4EY8QA5DNzmyeE/IJTmTPkbC+ MNbmzvqKJwwON6Pq
X-Received: by with SMTP id t18mr12071850plj.273.1499978197397; Thu, 13 Jul 2017 13:36:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id x65sm15220509pfa.107.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 13:36:36 -0700 (PDT)
To: Michael Richardson <>
Cc: Anima WG <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 14 Jul 2017 08:36:41 +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: Thu, 13 Jul 2017 20:36:39 -0000

On 13/07/2017 21:40, Michael Richardson wrote:
> Brian E Carpenter <> wrote:
>     > OK, I'm getting there. More in line:
>     >> 1) Registrar accepts any Lx1 as local.  There is no precedent in v6
>     >> APIs to open such a socket, but this actually supported on many
>     >> platforms.  It's used for nasty stuff like transparent application
>     >> layer proxies, forced HTTP proxying, and the like.
>     > I think there's a more subtle way to look at it. When the registrar
>     > receives a protocol 41 packet from a new ACP address, it conceptually
>     > synthesises a new virtual interface and assigns Lx1 as its link local
>     > address. On that interface, things would look normal. Thus RFC2473:
> I can buy this.
> It argues that the Proxy should send a gratuitous packet to the Registrar to
> prime that virtual interface.  An ICMP echo request perhaps.

Or a GRASP M_NOOP, designed for such purposes!
> How can we document this well?

I think it has to be spelled out almost at the pseudocode level. We had to
spell out the encap/decap behaviour for 6to4 in some detail, and that was
just about the only bit of 6to4 that never created trouble ;-). There
are various encap/decap specs of that kind, and the NAT64 stuff
also goes into horrible detail...


>     >> 3) We have the Registrar tell the proxy an Lx value to use.  I chose
>     >> to put this option into the protocol, because we can always set Lx=
>     >> Lanycast in the future, and perhaps we can set it to :: if we want
>     >> case (1).
>     > I like this least of all. What happens if there are multiple
>     > registrars?  And when a proxy node comes up as a pledge, it must give
>     > itself a LL address on each interface before it even tries to perform
>     > its own BRSKI, and before it looks for its own proxy and joins the
> Yeah, you are right, this doesn't work if there are multiple registrars.