Re: [v6ops] GRASP

james woodyatt <jhw@google.com> Tue, 16 January 2018 20:03 UTC

Return-Path: <jhw@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7612EB0A for <v6ops@ietfa.amsl.com>; Tue, 16 Jan 2018 12:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0RuxZUUyQwut for <v6ops@ietfa.amsl.com>; Tue, 16 Jan 2018 12:03:21 -0800 (PST)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 9EFF512EACB for <v6ops@ietf.org>; Tue, 16 Jan 2018 12:02:50 -0800 (PST)
Received: by mail-pl0-x22d.google.com with SMTP id b96so6989395pli.2 for <v6ops@ietf.org>; Tue, 16 Jan 2018 12:02:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5L6bqzeswZiVyJt0jV4+N2Lws8YJfZN/YH+EtiMnuk8=; b=SBZeSGyzExh6WK7ezFU5Ew3a2ms1Q66AsyoeHCTeFleZMJTzYIY5wyIreQ7gSO3OJj HwQIAgMYN6c6CZaHNQWFnkKMRIJl2eSpUN5PhosoCQvYIzxMxru3w+mDOVp1iFAwy+qL ygUL0xTuD4OFeYQ4dR3uol91XRfWZcAvYB4RaI8ihrQ4o9ZSfjhxRQ+N2GvyqXLcULJo j8PDMgm5j8HiXZYBrBtc4EuA1Lj24vhXZjhfdhXFueGTPQHtHK9wUZfAk0opCXAFIqoo nU22VWxHRpNyjVBxFL/yrnpVls5udT8HFsobGfaebLv0HlnQ1egZqdizvPpZC/lA2/Fe OOQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5L6bqzeswZiVyJt0jV4+N2Lws8YJfZN/YH+EtiMnuk8=; b=d/hkbozGpZNgDHP5019rTEepAw4ineRpUxsuEjNjXRJfVRbMr9mpX841Oz6fUiMMUx Wc6arLggzRxax5UidUKDpTzwG2fzug/YcSDm4daWyplPuM1IfeG0XP2zkUeec0J63XX9 R0j/Fmy3GwhMG3jgX7ph9CoEKi3gFWtreotQXLIeOy+xCY0+5osdKCSQvlBaVMWZL4P/ o2g1fmP9TRNVDiZRgNr8JJX4RY5J2ExIlVxFeyOPAVFbAas4JI4wBijyESjlpdYtoISU 6w9cBq6SDpBZ4NHldIKkySa+nP6E9AWSCAoAAIfdmOBIa4N/8nX1MhUVI3g9y1lV0dQv AFJw==
X-Gm-Message-State: AKwxytcq37eSxFTGm+WEiROSKuJBYu/xGA8fyUpDLsfxamLoXrNtTQzd SeW9IkC+eio8r1I4vMmnK1B2Vw==
X-Google-Smtp-Source: ACJfBourG2NH2GGAUmay52pva83gZgIN+RprqMea/GMSBNxT/2hBuBFHY2DCjP2c4HqbJMq5PkzCKA==
X-Received: by 10.84.236.14 with SMTP id q14mr7652583plk.445.1516132969795; Tue, 16 Jan 2018 12:02:49 -0800 (PST)
Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id q27sm5288507pfd.14.2018.01.16.12.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 12:02:48 -0800 (PST)
From: james woodyatt <jhw@google.com>
Message-Id: <D184EA11-CEFC-4760-B4D5-A02B39B22768@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_10D7BC95-EF58-408C-857D-B38AB4123AAB"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 16 Jan 2018 12:02:47 -0800
In-Reply-To: <AD06035C-63CF-47F4-BA6B-C5173F261BC7@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops@ietf.org
To: Ole Troan <otroan@employees.org>
References: <fc31bd170b134c8292d33f52400b175b@XCH15-06-08.nw.nos.boeing.com> <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <B07B4644-B5DC-408E-8130-0832AFAE47E2@google.com> <CAO42Z2y6rO8S-F93J6BDcMzgkHb4-czuQd-1QArzM3MfO77EKw@mail.gmail.com> <EC75835C-7ACA-4FF9-8A98-467EA7222021@steffann.nl> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> <AD06035C-63CF-47F4-BA6B-C5173F261BC7@employees.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IxvEtiCdY7I_HJFhAqIQsYyshKA>
Subject: Re: [v6ops] GRASP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 20:03:34 -0000

On Jan 15, 2018, at 00:38, Ole Troan <otroan@employees.org> wrote:
> 
> Perhaps if we James can describe his use case, that might give us a bit more leverage.


Again? Okay.

Consider the Nest Secure system of products, which includes Nest Guard, Nest Detect, Nest Tag, et cetera. One product in particular is called Nest Connect. It’s a simple wall wart that provides Thread/WiFi border routing functionality. This functionality is also included in Nest Guard and other products with better marketing, but if you have a big house and you need to connect a Nest Guard to a Nest Detect too far away to reach over Thread, then you would use a Nest Connect for that.

All these devices have a Wi-Fi interface and a Thread interface.

  <https://store.nest.com/product/nest-connect/ <https://store.nest.com/product/nest-connect/>>

Here’s more about Thread border routers from the nice people at OpenThread:

  <https://openthread.io/guides/border_router/ <https://openthread.io/guides/border_router/>>

The basic use case is that each Thread mesh that depends from the home Wi-Fi network requires its own /64 prefix. But the Nest Connect cannot reliably get one on practically any currently deployed home networks, even those like Comcast which provide IPv6 service to hosts. Neither can the Nest Guard or any of the other products in system that operate as Thread border routers. Thread™ is a network layer, and not an application layer, but without a reliable method of acquiring a prefix, a border router can only be made to function passably with a NAT66 function.

There is no reason to be optimistic this will change. And IETF is making it worse by signaling that it won’t include HNCP and Babel or anything else that can solve this problem in its revision of the RFC 7084 recommendations for CPE routers. I’ve raised this topic before and the response has never been more than shoulder shrugs.

Sure, the Nest Guard and the Nest Connect currently work by providing a sort of application proxy: they establish a private virtual IPv6 network over an IPv4 tunnel between the home and the Nest Service. Because the Nest Service does not (currently) assign globally routed addresses to Thread border routers in the home, e.g. Nest Connect and Nest Guard, it’s not possible for any 3rd party product that joins the Thread network to reach anything other than the Nest Service, i.e., not even other devices on the home Wi-Fi network. Resolving that problem in the absence of a reliable system of assigning globally routed prefixes to interior routers on home networks is not easy. For a variety of reasons related to the weedy technical aspects of how Thread works, which are too tedious to explain here, using NAT66 instead of ND6 Proxy is really the only sensible way to work around the prefix delegation cluster-fail.


--james woodyatt <jhw@google.com <mailto:jhw@google.com>>

p.s. Clever readers will naturally want to try to fix the problems in Thread that made ND6 proxy unsuitable for solving this problem. Good luck storming that castle. I tried and gave up.