Re: draft-bourbaki-6man-classless-ipv6-00

Warren Kumari <warren@kumari.net> Thu, 15 June 2017 17:05 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7235812EAA1 for <ipv6@ietfa.amsl.com>; Thu, 15 Jun 2017 10:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQGsY1OemImG for <ipv6@ietfa.amsl.com>; Thu, 15 Jun 2017 10:05:00 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538EA12E04B for <ipv6@ietf.org>; Thu, 15 Jun 2017 10:05:00 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id g40so11936687uaa.3 for <ipv6@ietf.org>; Thu, 15 Jun 2017 10:05:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nefmu8ujn+CUeUSrLevL1fEgI2yY3LM2lVvbp+QoJTE=; b=z+x4kPwKhTyCJDuOxtF+mCnK9nb7zb8+fu/IpYcAA+sy7tdkMkO8ILwoQlOQ116f87 QY9q3Xyp9RyZ2NuBnBwrEXHaqy9dn3NnlZ/l4kjBoB8aWev0ZB6hOVYF9W4bxbxcSF1I C5NEGqWAeH85Xag/T9ndL3wMbqEFcS8u/QzOVNjTJbPZRr3OftyJRgvMpIL4qnSj4CZG mLKdWr8EDi1EZ5FehuwJb+Kl0WakEfbgWvB5XglGF+olzZDbJYcBxRoXaVcRVJTD5NHQ JyMJzYC3WIAspgd9LOYTiIlXyHoh3wMFDls0ZeTyDWj0SusAj6AbJLvB9r+PATTTUO7I rbdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nefmu8ujn+CUeUSrLevL1fEgI2yY3LM2lVvbp+QoJTE=; b=UONnMsfxDV7iOy1IbRwriG+auUI1f8eCcstxfxurhVxhWq9RGQ+NArrXd+FmImz6nu dbtkI+/vVo38YvI2Hrjy/ike4QAL8nfhKtaE1CCFkHMsrfpoXKjSMSDsK8vrMW7wbCNb AB103CZreZrEbnXOE+FlktQyw2zP+YA4qceq1/NsGaOYXVyz1Msc3u6gn6XRMawazvKv MQxkME7vWMfJV3kcwhLFp8qTIBlptKEKmn4HKK3h4uxqzwAFyF3ijkP+XNrxCGSk8pg7 DiEwFCwdrtxHMJXzsrNgl8a+JvkJHm0oZm39uZG2Q/wJ+cqB7Lg9DOtNd6KX5Zo7FN41 apgw==
X-Gm-Message-State: AKS2vOwlzjKS6Xv9Fwu5hukw2o5H7Y2waf78JGAUslWjlFLjDyChY7Gn QcJvOeRPsoi4of+WJTQgnShErjQSluFFKs1mHg==
X-Received: by 10.159.59.143 with SMTP id r15mr2343712uah.110.1497546299280; Thu, 15 Jun 2017 10:04:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.82.198 with HTTP; Thu, 15 Jun 2017 10:04:18 -0700 (PDT)
In-Reply-To: <m1dLQwv-0000HYC@stereo.hq.phicoh.net>
References: <E02C4C99-155A-4358-A845-F00F8BB071C1@employees.org> <b3ca5271-21b1-ab33-2dff-82735ebe9128@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <E61AFFF1-0354-41EE-8E11-50433B26BAF7@employees.org> <20170614094034.GC30896@gir.theapt.org> <A7502902-245B-499B-916B-28630CD5A824@employees.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <CAKD1Yr0dU+1rHo7LB2k7MOhJ+UOB5t7v11T2WYa+VtLnNC-7ag@mail.gmail.com> <m1dLQwv-0000HYC@stereo.hq.phicoh.net>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 15 Jun 2017 13:04:18 -0400
Message-ID: <CAHw9_iLU=5mkVoe2DsTLKxonPXc8wkHAvka-c5djv0i7ZwjC1g@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Cc: ipv6@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/p-bMw_tWWcxns-UArCwz1f4ZWEk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jun 2017 17:05:02 -0000

On Thu, Jun 15, 2017 at 5:20 AM, Philip Homburg
<pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>>SLAAC doesn't work unless the network provides enough address space to make
>>collisions vanishingly unlikely.
>
> Indeed. So any RFC that makes smaller pseudo random IIDs possible has to
> have at least a section that analyses collision probabilities.

So, a couple of years ago I was doing some work with Juan Carlos and
Dan Harkins in the IEEE on MAC Randomization (basically randomizing
your (WiFi) MAC address to improve privacy / thwart pervasive
monitors).

There was some discussion on how many bits you would need to randomize
to make it unlikely that multiple machines will independently choose
the same address. I argued that if you randomize 24 bits, and have a
stadium of ~2000 people, you will basically never get a collision.
Dan disagreed, and so, in a fit of pique, I wrote an App Engine app to
prove him wrong -- and achieved exactly the opposite. This is a
birthday paradox problem, and you will get a collision once every ~9
times.

I've just updated my little app and put it here:
https://ipv6-collision-probability.appspot.com/

It's interesting to play with the numbers and see how likely a
collision is, given a certain subnet length and number of hosts.

>  And set
> a lower limit that is generally safe.
>
> Just leaving it to an operator to figure out that a /112 prefix will
> sometimes lead to an IoT device failing due to an address collision is
> extremely poor protocol design.

Example: With a /112, and 100 hosts, you will have a collision every
~14 times...

W

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf