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

James Woodyatt <jhw@nestlabs.com> Wed, 22 October 2014 18:46 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 6AB361ACFCD for <homenet@ietfa.amsl.com>; Wed, 22 Oct 2014 11:46:40 -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 7Z0GMRfPtB4l for <homenet@ietfa.amsl.com>; Wed, 22 Oct 2014 11:46:38 -0700 (PDT)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457DD1ACFCE for <homenet@ietf.org>; Wed, 22 Oct 2014 11:46:37 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id la4so2420869vcb.13 for <homenet@ietf.org>; Wed, 22 Oct 2014 11:46:36 -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:cc:content-type; bh=KZk+yGOb2J7ci5NOqCjHGeuPk1zNmCjUFwy5P4+Gyzc=; b=LWUx/SedylRhT9m9ZKVjGXdrBCDYxAz70baQd8JaDiGFU9KScXMWhBepLp6yqf6JBa fR3k38U5t9tojOZ+BL5FhL3iP1PiMk5CLMEalj7Jv9PrhkmD8JBFyKo9r8w2c1VjY9ol pZNt/HtuI/RE7iWkSQL9QvM73HboRWD/gnuWNEwumKg0J/Onv9KB01mefVakS4P+9uVW MJy8+9IRIBp93yJLImqylHZXtITNtvneSHwrFPeS+EzMmoJa8wRQ3HgYUKgfZnS9ueGs 60uMiO8EoLNGprPGxT8kqDBrNiKX4WDDs1ZjP9NnsZXJ//Wx1FFKHOJ58DLf+NBpODnc DFrQ==
X-Gm-Message-State: ALoCoQkH3dllBDErnPdE9Y7Y8Vau0wkxa7UXvf/3DNtOAEIuZZfui3RZYyQpfqzfLfdGlC2Sri56
MIME-Version: 1.0
X-Received: by 10.221.4.73 with SMTP id ob9mr37834368vcb.13.1414003596297; Wed, 22 Oct 2014 11:46:36 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Wed, 22 Oct 2014 11:46:36 -0700 (PDT)
In-Reply-To: <32190.1414001095@sandelman.ca>
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> <CBD056DD-D5CA-4B2E-878F-14BB0EF123FD@fugue.com> <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi> <CADhXe53drG2EzQmAvzGstcM-gC0UtjDOY3YQoKswRWYfqky-2g@mail.gmail.com> <32190.1414001095@sandelman.ca>
Date: Wed, 22 Oct 2014 11:46:36 -0700
Message-ID: <CADhXe51p8roxXT9+vm9eyXg0C9YB4+cUuozHhGg+jJxWV_dGQQ@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary=089e0116052411a0210506075e2b
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_33VvANuG4NbfeMmpA_U2q1Gj8A
Cc: HOMENET Working Group <homenet@ietf.org>, Markus Stenberg <markus.stenberg@iki.fi>
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: Wed, 22 Oct 2014 18:46:40 -0000

On Wed, Oct 22, 2014 at 11:04 AM, Michael Richardson <mcr+ietf@sandelman.ca>;
wrote:

>
> James Woodyatt <jhw@nestlabs.com>; wrote:
>     >> My assertion:
>     >>
>     >> Given HNCP generated one spans whole administrative domain, _and_
>     >> should not have routing anywhere outside it, it’s uniqueness does
> not
>     >> _matter_.
>     >>
>
>     > Wait. Where did this "and should not be routable anywhere outside"
>     > recommendation come from? And if it's only a recommendation and not a
>     > requirement, then it still matters, right? I don't see that we can
>     > meaningfully make it a requirement, and I would advise against
>     > attempting to make it a recommendation. I don't believe such a
>     > recommendation will be followed.
>
> I won't mince words, "recommendation"/"requirement"/"potato"/etc..  I think
> it's a very strong SHOULD, the only reason for someone to do otherwise
> would
> by explicit geek-administator action.  Manually configuring a VPN for
> example.
>
> It's not saying that ULA can never be routed by consenting adults, it's
> saying that the Homenet ULA SHOULD never be routed outside that homenet.
>
> Where it comes from; from the architecture document, I hope.
> I'm pretty sure we said that somewhere, but I'll have to go search for the
> specific statement. [...]


You won't find it.  It isn't actually there.  There is some text that maybe
you were thinking says it, but it doesn't, and the people who will be
implementing this stuff will never look in the architecture document
anyway, so it's moot.

p1. I won't mince words either: the HOMENET architecture document is full
of wrong on this topic. In particular, section 3.6.6
<https://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6>;.
ULAs as a hint of connection origin makes the unwarranted assumption that
subscriber home gateways are the only routers bordering the home network.
They may often be the only *default* routers, but there can be— and
absolutely definitely will be in the vast majority of cases— overlay
networks that route ULA prefixes to, from and most likely *between* home
networks over tunnels. We can't tell people not to do that. If there is a
routing protocol in a HOMENET, then it will be done, and it ought to work
right.

p2. These overlay networks will not be "for geeks only" and they will not
require advanced manual network configuration skills. If this issue isn't
handled right in HOMENET, then we can expect each of those overlay networks
(there will almost certainly be more than one in many homes) to use
delegated ULA prefixes instead of the HNCP locally-generated prefixes if
necessary, but that just goes to show that the locally-generated prefixes
are likely to be crippled compared to the ones from overlay networks, which
will actually be generated and delegated properly to keep them from
colliding on network joins and splits.

What's the point of having a HNCP locally-generated ULA prefix if it
doesn't actually have the statistical properties of collision avoidance
that ULA prefixes were designed in the first place to have?


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