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

Brian E Carpenter <> Thu, 13 July 2017 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24179127869 for <>; Thu, 13 Jul 2017 15:41:34 -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 vta6EIPGJcBv for <>; Thu, 13 Jul 2017 15:41:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA22E12717E for <>; Thu, 13 Jul 2017 15:41:32 -0700 (PDT)
Received: by with SMTP id d193so8371552pgc.2 for <>; Thu, 13 Jul 2017 15:41:32 -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=3tfYYMfTUejmtsA6EjSSEYqsl/FkJh1v9MknI6mcQfs=; b=fJYs40GLkYDSioIWMUv+I+eFK4vrmmSBYgBjOCzqYwC7AvJOCmj+67sCW8064FyM3Y +bIcwQqEcU97SpZxOF4MK5N51lR0WTGQuD1jBiSgFJSGD2DIklM9sL3Pg3ud0sjsWkCu Zr+cMtBXQ9yjlFMhFwzS4GiYXD4pAjjp3vJSGWpVFkrJTa0B1XF5pCq4BrD+vI7rzHcD 6o6Y8Qqdmk/WyAEM6IbAo0dpjzcexi454n7ot9DEOSrzkv16q1ADpWGjs7+eW1OQY0kc jRI2KtNZSyLkf7ONACy1Sr6D5v4K63TBOuvDoa01DeqU3D7N1mDuXGYgmHuMR6WnTmlv iy3w==
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=3tfYYMfTUejmtsA6EjSSEYqsl/FkJh1v9MknI6mcQfs=; b=umeIBF00bGJt8WwWf+mcYEO8DLVy8/6hi71zyEIBVUo8mxCs80rmLUXcypBwtEn/9d 62bqtCp/YqEUIzvRa6JUEVNGtan5XY1q78mZSCZmhwZs3eSCCMtdUXr33RrLvZx1ffGZ pa1CRt23IVTIU27Xw9CYuRr/kETif9oQqzyfmqGliBfyZkBjN6xJqmzx0+g5k5zYC/ST 8QAjm1OA5GOHPrDLspN5wfT0p/xx4pz2qGjvqq6sE0nU61epcdrgN80+Q+4oL1qa8x5k BlTW/ZggWX4tuvaS0uCTRyUOTt3YeVifn4sM83YlQv/n+s84KjHuHd8zLLAM1Sk1x9g2 Q+jw==
X-Gm-Message-State: AIVw110xawhZ3o8U/Z+ztx1DtyKPMrdUycutacDHb4vE9frwXZis2Uo4 vaazUXaVekhHJqSd
X-Received: by with SMTP id 92mr12406382pli.56.1499985692034; Thu, 13 Jul 2017 15:41:32 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id x14sm14282993pfe.83.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 15:41:31 -0700 (PDT)
To: Eliot Lear <>, Toerless Eckert <>
Cc: Anima WG <>
References: <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 14 Jul 2017 10:41:35 +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 22:41:34 -0000

On 14/07/2017 08:58, Eliot Lear wrote:
> Hi Toerless,
> On 7/6/17 9:09 AM, Toerless Eckert wrote:
>> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote:
>>> It used to be, but the recommendation today is a pseudo-random
>>> value (RFC7217). In any case it's a software choice.
>> brand new recommendations do not equate to be expected
>> standard practice in products. Would be very good to have
>> folks with practical insight into various products to 
>> provide more information.
> On this point, I think it's quite likely that we will see a good number
> of devices fielded that will do a lousy job of PRNG, and so it would be
> inadvisable for them to implement RFC7217, lest they test their DAD code
> in ways not really intended.  I'm not thinking about iPhones here, but
> energy harvesting devices like some light switches, and a bunch of,
> well,... crap.
> The question is whether you should design for these devices.  IMHO "no"
> is a perfectly valid answer, but I'm still a bit skeptical about the
> value of 7217 for these class of devices in any event.

That may be true, but for BRSKI as such, the only hard requirement is
an address that is unique on a given link, which is a requirement anyway.
IPIP is more of an issue for the node providing the proxy, which is
hopefully a bit upscale from a light switch.