Re: [homenet] Support for RFC 7084 on shipping devices...

Michael Thomas <> Sun, 06 October 2019 22:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DC2C1200CE for <>; Sun, 6 Oct 2019 15:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=jmhtpN3d; dkim=pass (2048-bit key) header.b=EC1Rkfx5
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ndb4S43bn8Q1 for <>; Sun, 6 Oct 2019 15:46:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0332F12003E for <>; Sun, 6 Oct 2019 15:46:01 -0700 (PDT)
Received: by with SMTP id p1so5248988pgi.4 for <>; Sun, 06 Oct 2019 15:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ha6fg7takm4NmyQtNO+CBol7tfIyTnVU05JQl65PDqw=; b=jmhtpN3dPkQYF0xzjZWcFswQtPWW/GoeUnp41jExd/EhMTyw5XJnyl4LURzKwn/E0J /QW0Q/X1AmjGiilOhLEw2ngrSRV7rw7vCep0UKhGULNxzVcTV4Tvu2mXYO6wZq1aAu3w bENmNwOfu1DGhBkf0q0DW1bBPrTTO15QhG+2M=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ha6fg7takm4NmyQtNO+CBol7tfIyTnVU05JQl65PDqw=; b=EC1Rkfx5ITUqaDLSJUVHKWZ9r+yakksM35yZr7I3B0MtEPcVOck7ri7/Yl3QuFohM4 XmkSTixFxpcMZCspTL/JJsaUND/Vnd5nssJfgKrm/UmWatSjfk3MsFFPBz9A/i23bmXC YvsWfdVh/YxeTpGV8Ed0SI/O1yIH7BBJYPC2EcOXT8bY7lXW3ScRadgi4yjTVSiOVyT2 EIkOz0FpUmkD6KaODkHNSSfgOSU8oa6UsQ7gNq4w+cF9ZHMYUGd/7zSvcwvCqN+PG9+h gM9Em2O7ZqiIj+iwkubq/H8kscoZbkzqCnodsSdYi13LBqxFvPBf4fSDvz55+xC/BlZt mAVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=ha6fg7takm4NmyQtNO+CBol7tfIyTnVU05JQl65PDqw=; b=rX8gHyjl2Xny1Hc+bgjY3jGM9lvv1p1oF3LXeWgwLoK8ASdr/FS7b/BS+G0gStUZci wzCfQVP2x7J/l4QC8ZwG3A2ZLCsJCcn0COc5ja9g26y/ugmtA7J7RVJBqqHngMRzAXlz QOFmEJlgL9KPTODLmt70fc3deB1QF8Fg/itfGp0fnumOdbMxUKvZ84r593Z+tnbJSvpq zV7R5SJQN9cqRqTcnP9mxZ1YvdLhJykubBLu15ZgiSIZozhDpjHEUgjyEl7XY4PTWbLV wkUkggFMW9LZxrHFT50v2QMu32iOzjoG+qcSr/xmo1iQFIR7j1LwF8xladCI2TlTS3gu 5EAw==
X-Gm-Message-State: APjAAAVPXCx9bhSLebCBeRVjcXLATXUIdjFpReqjt14adWHIjQon/WVF Ke/YIpqI9QmCwhW9k9r4uf86dfJRfQo=
X-Google-Smtp-Source: APXvYqwVVbChAc0cS16SY2gWPEYYblFH7D5s6EiRLgmdpG+H9q+VQdcrezs0b+I8aMo6lnoJvhXiGg==
X-Received: by 2002:a17:90a:266c:: with SMTP id l99mr30034536pje.93.1570401960924; Sun, 06 Oct 2019 15:46:00 -0700 (PDT)
Received: from Michaels-MacBook.local ([]) by with ESMTPSA id cx22sm10521692pjb.19.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Oct 2019 15:45:59 -0700 (PDT)
Sender: Michael Thomas <>
References: <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Sun, 6 Oct 2019 15:45:57 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1A22231E0DC8861195366ECD"
Content-Language: en-US
Archived-At: <>
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Oct 2019 22:46:04 -0000

On 10/6/19 2:41 PM, Ted Lemon wrote:
> On Oct 6, 2019, at 10:58 AM, Ole Troan < 
> <>> wrote:
>> Are you saying there might be gaps in HNCP? Or things we could do to 
>> make it more deployable?
>> If it's just a matter of running code missing, I'm not sure defining 
>> anything else new in the IETF would help that problem.
> There are definitely missing features from the protocol that I’d like 
> to add.   But I think the fact that the protocol isn’t deployed on a 
> _single_ commercially available router, and is not really usable on 
> OpenWRT by a non-expert, is an indication that there is substantial 
> remaining work to do.   Operations work is not out of scope for IETF; 
> maybe I should have asked this on v6ops.   We have historically said 
> “not our problem,” but I don’t agree that that’s the right answer.   
> If HNCP had really convincingly solved the problem, we would not be 
> seeing what we are seeing.

If the protocol is not truly plug and play in reality... wasn't that the 
entire premise? That doesn't sound like an ops problem. I understand 
that openwrt is a wonk box, but still if there isn't default 
configuration that would make it truly plug and play for most 
situations, that sounds really problematic.

Can you confirm or not that openwrt could be set up by default in a way 
that met the charter's requirements for operations (ie, like what you 
might expect in a commercial home router)?


>> I know why I haven't implemented HNCP on software I work on... and I 
>> also know that there aren't any very realistic alternatives either.
> Can you say why that is?
>> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about 
>> routing and routers. I.e. what happens at the network layer.
> You mean at the “internet layer,” I assume?
>> If you are talking about what happens at the often integrated bridge 
>> CE devices have, then sure, they could implement RA Guard.
>> But having your additional router sending RAs across the homenet 
>> might not be a particularly good idea anyway.
> Why not?   What would be a better idea?   I don’t mean to say that 
> using RAs in this way is ideal, but what’s the alternative that 
> doesn’t involve the vast complexity of per-host routing?
>> Sounds like you need to set it up as a NAT.
> I really hope you are just making a funny joke here.   But it’s not 
> very funny.   What I want is something that’s operationally simple, 
> not something with lots of moving parts that have to be kept track of. 
>   NATs in particular suck for any UDP-based protocol.
>> I wasn't thinking of doing it exactly like the 6lowpan does it.
>> Regardless I don't see why scaling should be problematic, are you 
>> planning to have millions of rapidly moving hosts on your shared /64 
>> network?
> If you have N devices on a single link on the other side of the 
> router, then when using either RA or a routing protocol, the amount of 
> information you need to propagate to get things working is very small: 
> just a prefix and a router.   If you can’t do that, then the amount of 
> information you need to propagate is at a minimum N units, and 
> possibly K*N, for some not insignificant factor K.
> To be clear, the reason I’m concerned about this is that I’ve looked 
> at implementing it on OpenWRT, and it’s at least roughly doubling the 
> complexity of the work required, even if you can depend on using IPv6. 
>   If you have to use IPv4 on one side, then it’s even more complexity. 
>   And it’s utterly stupid complexity—it adds no value over subnetting. 
>   Why add that to the network?
> This is why I’m asking people if they have knowledge of what is 
> actually deployed.   I think this is the right place to ask, but if 
> you disagree, I’m open to suggestions.
> _______________________________________________
> homenet mailing list