Re: [homenet] Let's make in-home ULA presence a MUST !?

James Woodyatt <jhw@nestlabs.com> Mon, 20 October 2014 20:24 UTC

Return-Path: <jhw@nestlabs.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58B1ACDF4 for <homenet@ietfa.amsl.com>; Mon, 20 Oct 2014 13:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level:
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 XUuHjdVOYnym for <homenet@ietfa.amsl.com>; Mon, 20 Oct 2014 13:24:11 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715671ACDE0 for <homenet@ietf.org>; Mon, 20 Oct 2014 13:24:11 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id c41so3939526yho.34 for <homenet@ietf.org>; Mon, 20 Oct 2014 13:24:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zLHWIH25/ijxnorfIi2OkNvkJo8ewQQFKzFMJWlWpJc=; b=HHI5IF7Q3dSUD/bwQtKovxpKWxrBjf7Fa+r0WRxmbElWTgNZKQZu/Hvk0X9FQq3LUt PtKxqjIFzxgR/E9q5s0D86A5cD25XUdVnnzuc4ZQF4pZG6mY8KEllBQ+LTE3IFPq7rNx 8Qvw6Xh65RV5OgNYDGLBs5snk3Y+zv2QWnTG2xGDtDUu9VSBw7+5F4J4t0cBUWhwnWhW RDjcK8XWg6s7fN2eSCd0fUly7VXqR+HblIMW10v2mDXC2UbbAFizgMlXwclqN0D3l12d 7T53KCefdmVAjXCgMdOx5VyP3skwss2wqDVEGfUpyEsFvA6uVcJvWvOu/j431PBVNElD pxSA==
X-Gm-Message-State: ALoCoQnzcd7OZsMdHl+04QPsd76rttnyD5xyJ5SKhSPjE/Qfbkd7L6L4OWR0M6vlBmYDlgQadup9
MIME-Version: 1.0
X-Received: by 10.53.5.132 with SMTP id cm4mr15862835vdd.50.1413836650626; Mon, 20 Oct 2014 13:24:10 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Mon, 20 Oct 2014 13:24:10 -0700 (PDT)
In-Reply-To: <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> <CAAedzxp1R-C5E9RJVMVLRJxPc0w4zooPtqnvWK9eggpZu4=xtg@mail.gmail.com> <alpine.DEB.2.02.1410141020360.30853@uplift.swm.pp.se> <C52D3324-3015-45E0-88CF-D2A778D246B8@iki.fi> <CADhXe52iH_Abh3iZvpgQQYJF_FzbKkhNwzwjkcDt-DJA3RL+VA@mail.gmail.com> <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com> <CADhXe533umX9Q3NSbEktjcj8mBatXkDmRQKz0hOkGriBSX0t4g@mail.gmail.com> <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com> <CADhXe50DoZjjoG5tfidcGgtXx1TFyYECZyzeWmQstsT3=HPyaA@mail.gmail.com> <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com> <CADhXe51ya1bHnP8NCvNkuN1+xdhNnA3qnapn7h1XEvmDX2D_jg@mail.gmail.com> <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com> <CADhXe51MC4ubB3de+sSm+KSRNQJH7RLVvRUWmQnE393RR+HBnA@mail.gmail.com> <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com> <CADhXe52FW+7e8t9Z8fHGvHZfZJWM48gwnDBLhHz8TwZQzMGa4Q@mail.gmail.com> <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>
Date: Mon, 20 Oct 2014 13:24:10 -0700
Message-ID: <CADhXe53EiyUKM9DBwqVrVQv=ofgw8no4fpz83Dy0rC9UY-4SJQ@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: HOMENET Working Group <homenet@ietf.org>
Content-Type: multipart/alternative; boundary=001a1133eda25508730505e07f26
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Dqy4xIcdytIENetWWjwgyQm_V6M
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 20:24:13 -0000

On Mon, Oct 20, 2014 at 12:34 PM, Ted Lemon <mellon@fugue.com> wrote:

> On Oct 20, 2014, at 2:00 PM, James Woodyatt <jhw@nestlabs.com> wrote:
> > Okay... except it seems you're admitting that my scenario where a simple
> reconfiguration of a network topology, e.g. one caused by an intermittent
> RF interference on an unlicensed band of the radio spectrum, would result
> in a fully regular and normalized generation of a ULA prefix that would
> subsequently be deprecated on network rejoin and subsequently deprecated
> again. This could happen several times per hour, right?
>
> No, if it's done right the network would have to be partitioned for on the
> order of a week or two before the new ULA would be generated.


Did you respond to my previous criticism of this idea? If so, then I missed
it. It's not a good idea to commission a new standalone network with the
same ULA as a previously commissioned network, because it destroys the main
property of ULA prefixes that makes them useful: the statistical
unlikelihood of merge collisions in the global address realm.


> The reason I think it's beneficial is that it reduces to the minimum the
> number of instances where a long-lived connection will have to be broken
> because of a renumbering event.   I don't think we can reduce that number
> to zero, but I think we can make it a lot less likely than it would be if
> we renumber every time the upstream link goes away.
>

Sounds to me like a benefit of very dubious value at best.  It's a fact
that applications cannot depend on the network never encountering a
renumbering event. That's the whole reason addresses have valid and
preferred lifetimes in the first place.  Applications that use long-lived
IPv6 connections cannot escape the problem that interface addresses may
expire at any time.  If they're not coded to recover from such events, then
it's their logic error, not ours.

I see no reason to work very hard to provide applications with a class of
global scope interface addresses that IETF documents encourage developers
to assume will never reach vltime=0 except when that assumption is
mysteriously invalid anyway because reasons. If there is a good reason for
it, which I'm missing, then I'm happy to consider it.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering