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

RayH <> Mon, 07 October 2019 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C24FA120020; Mon, 7 Oct 2019 07:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.477
X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tiRhL0LIJH_u; Mon, 7 Oct 2019 07:15:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3EFA6120013; Mon, 7 Oct 2019 07:15:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14FD840109; Mon, 7 Oct 2019 16:15:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PdgTYYRtZEv0; Mon, 7 Oct 2019 16:15:12 +0200 (CEST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 26400400AF; Mon, 7 Oct 2019 16:15:12 +0200 (CEST)
Date: Mon, 07 Oct 2019 16:15:09 +0200
Message-ID: <>
X-Android-Message-ID: <>
In-Reply-To: <>
From: RayH <>
To: Michael Richardson <>
Cc: Markus Stenberg <>, 6MAN <>
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
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: Mon, 07 Oct 2019 14:15:18 -0000

On 7 Oct 2019 15:47, Michael Richardson <> wrote:

Mikael Abrahamsson <> wrote:
    >> The deployment challenge of that is that every router must support HNCP and
    >> must support SADR.

    > Yes, there is indeed a problem here with incremental deployment.

    > That's why I think there might be upside in "homenet lite" which drops the
    > arbitrary topology requirement and keeps the "routed home" requirement, but
    > also brings with it the service discovery part. Perhaps it's an easier chunk
    > of code to deploy if vendors do not need to implement full homenet but
    > instead implement RFC7084 plus a few other things?

So, 7084++ or HomeNet-Lite. 


I wasn't enamoured with the idea of 7084 being part of Homenet at all, but concensus was reached in the WG to spin out that document as the last-ever do-it-as-a-quick-win "single router" solution, after pressure from operators.

IMHO there's no future in updating 7084, because the goal of that document was purely a single router solution.

Anything else requires either full Homenet (yes, sorry, throw away or reflash your old router and embrace the required complexity),

Or it inevitably fails by either prolonging the lifetime of NAT, or being so broken in the limited topologies that it supports as to be nearly useless.

This goes to the decisions and discussions we had when writing the Homenet Architecture rfc7368.

My preferred path would be to look at why Homenet hasn't been rolled out.

If it's because manufacturers aren't updating boxes at all, or even ipv6 at all as per my local internet non-service provider, another standard ain't going to solve that.

So is there concensus on what's broken? And what needs fixing?


    > High level would be to use DHCPv6-PD, turning sub-router WAN firewall off and
    > enabling service discovery proxies, as I outlined in previous email.

I agree. 7084bis should suggest downstream DHCPv6-PD be supported, and we
need to explicitely signal there when HNCP is available so that we don't wind
up double allocating things, etc.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

homenet mailing list