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

Ole Troan <otroan@employees.org> Fri, 04 October 2019 12:10 UTC

Return-Path: <otroan@employees.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7631208F1; Fri, 4 Oct 2019 05:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UVOQXin-ACtc; Fri, 4 Oct 2019 05:10:23 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06170120963; Fri, 4 Oct 2019 05:10:23 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a02:20c8:5921:100:d9f1:37ec:73bd:aecf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id DD7074E11B14; Fri, 4 Oct 2019 12:10:21 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B089E1E6DEDB; Fri, 4 Oct 2019 14:10:17 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <alpine.DEB.2.20.1910040752050.968@uplift.swm.pp.se>
Date: Fri, 4 Oct 2019 14:10:17 +0200
Cc: Markus Stenberg <homenet@ietf.org>, 6MAN <6man@ietf.org>, Ted Lemon <mellon@fugue.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A52F076F-817D-4807-8CD6-280C2040AEBF@employees.org>
References: <56255ECF-9002-4440-BA0D-665EFC4BA9C6@fugue.com> <F638F635-9A1C-409E-BDB8-C00DF00A64C8@employees.org> <alpine.DEB.2.20.1910040752050.968@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/58ezP6Ty6o1uJZwcGM30AkWdBuM>
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Oct 2019 12:10:30 -0000

Mikael,

>> RFC7084 does not have any support for internal routers.
> 
> While this is true, OpenWrt does support DHCPv6-PD within the home, out of the box. I also have a report of AVN Fritzbox supporting sub-PD without additional configuration.
> 
> In all devices I've looked at the WAN is WAN, it comes up with firewalls on, requests PD etc, and if it doesn't get it then there is no GUA IPv6 on LAN.
> 
> In my opinion the work in homenet could be leveraged into an operational document where recommendations on what parts of homenet could be easily implemented to make it work within a home (without implementing everything), thinking primarily of "firewall off" and "service discovery proxy on". If no PD was available, turn ethertype 0x86dd bridging on between LAN and WAN. I guess we would still need to do NAT44 because without HNCP there wouldn't be a route to the IPv4 network on LAN of the "sub-router".
> 
> It would however mean that a printer on the sub-router LAN could be reached over IPv6. In order for this to happen without HNCP then this sub-router would need to send RAs on its WAN announcing reachability to its LAN IPv6 prefix (either GUA+ULA if PD is available, otherwise just ULA). I have never seen RA guard or similar functions in residential equipment, so I would expect this to work.

There has been multiple proposals in that direction.
None of them succeeded, because they left too many corner cases "undefined".

Homenet has solved the problem of self-configuring networks in arbitrary topologies.

Unless someone goes to lengths describing exactly how this is supposed to work, the idea of "simplifying" the homenet solution sounds like a recipe for failure. How are you going to tell the customers that you can only plug in devices in particular topologies and in particular ways.

- single router and bridging (7084)
- arbitrary topology plug and play (homenet)
- manually configured (meaning ansible, scripts or whatever automation solution external to the routers themselves).

Cheers,
Ole