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

Markus Stenberg <markus.stenberg@iki.fi> Wed, 22 October 2014 07:20 UTC

Return-Path: <markus.stenberg@iki.fi>
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 3E1AA1A8A99 for <homenet@ietfa.amsl.com>; Wed, 22 Oct 2014 00:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.573
X-Spam-Level: **
X-Spam-Status: No, score=2.573 tagged_above=-999 required=5 tests=[BAYES_50=0.8, PLING_QUERY=0.994, SPF_NEUTRAL=0.779] 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 enStvy7p6ksW for <homenet@ietfa.amsl.com>; Wed, 22 Oct 2014 00:20:02 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1F1A897B for <homenet@ietf.org>; Wed, 22 Oct 2014 00:20:01 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 543C16C900B0F2B4; Wed, 22 Oct 2014 10:19:55 +0300
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
Date: Wed, 22 Oct 2014 10:19:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>
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> <CADhXe53EiyUKM9DBwqVrVQv=ofgw8no4fpz83Dy0rC9UY-4SJQ @mail.g mail.com> <CBD056DD-D5CA-4B2E-878F-14BB0EF123FD@fugue.com> <CADhXe50Cg5nsjTBOpjJXxwububOgDo381QRPd3dyW=XfnqO1sw@mail.gmail.com> <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
To: Pierre Pfister <pierre.pfister@darou.fr>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LYoin3plJWgc_hY18egrOT0ZTjk
Cc: James Woodyatt <jhw@nestlabs.com>, HOMENET Working Group <homenet@ietf.org>, Markus Stenberg <markus.stenberg@iki.fi>, Ted Lemon <mellon@fugue.com>
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 07:20:04 -0000

TL;DR: I do not understand the reason for new text, and would vote against it.

I am probably being thick, but I can see three cases of ULAs in home network:

[1] something not from HNCP (e.g. from ISP, from some IoT gateway device, configuration, ..) that are essentially static from HNCP point of view, and just routable to,

[2] something not from HNCP (e.g. from ISP, from some IoT gateway device, configuration, ..) that also (partially) delegated to HNCP (also obviously routable to),

and

[3] HNCP generated (spontaneous) ULA (relatively dynamic), exactly 1 of them (or 0 if you buy the SHOULD argument which I do not).

My assertion:

Given HNCP generated one spans whole administrative domain, _and_ should not have routing anywhere outside it, it’s uniqueness does not _matter_. 

Therefore, what is the case for having to deal with ULA changing in case of network split/merge?

Case 1: Let us imagine split; I give one of my homenet routers to my neighbor. My neighbor winds up using same ULA. It has different owner, it does not talk with my network devices, and nobody knows they have same ULA nor cares if they do.

Case 2: Eventually, my neighbor gives the router back to me. I give it either physical access (wire) or appropriate wireless credentials. Again, it does not matter it has the same ULA, as long as the /64s it has assigned on it’s interfaces do not conflict what is in the rest of the network, and given it is [3] prefix, HNCP should take care of it.
(Hell, even [2] type prefix would be fine too in this case).

Only case where having same ULA in multiple places would matter, if you plan to route traffic between those places. Due to that, [3] case MUST NOT conflict with whatever comes from [1]/[2], but within [3] type, it does not matter at all. Internal is internal.

However, the case 2 looks much different if the ULA prefixes in the merge are different. Then you have to renumber either devices connected to the added router, or to the rest of the homenet. Due to that, I would advocate clearing ULA state before doing the merge to prevent wrong side of the fence winning the ULA allocation arms race. And having 2 ULAs in a home network as result of that is just wrong, from my point of view. Still, renumbering devices connected to router being added to your homenet sounds perfectly acceptable in case the ULA is of type [3]. If it is [1]/[2], just more than one ULA is also fine so it would not be applicable here anyway.

I have not looked at the draft text, but expressing these ideas should not be hard. The new text I strongly disagree with.

Cheers,

-Markus