Re: [homenet] DNCP/HNCP Revisited

"Ray Hunter (v6ops)" <v6ops@globis.net> Thu, 19 September 2019 13:30 UTC

Return-Path: <v6ops@globis.net>
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 5681712022A for <homenet@ietfa.amsl.com>; Thu, 19 Sep 2019 06:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bn_jAZJeJUBf for <homenet@ietfa.amsl.com>; Thu, 19 Sep 2019 06:30:12 -0700 (PDT)
Received: from globis01.globis.net (92-111-140-212.static.v4.ziggozakelijk.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 06219120074 for <homenet@ietf.org>; Thu, 19 Sep 2019 06:30:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BF5FE401C3; Thu, 19 Sep 2019 15:30:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7EjAtUriiv8; Thu, 19 Sep 2019 15:30:08 +0200 (CEST)
Received: from MacBook-Pro-3.local (h9041.upc-h.chello.nl [62.194.9.41]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0511B401B5; Thu, 19 Sep 2019 15:30:07 +0200 (CEST)
To: Juliusz Chroboczek <jch@irif.fr>
Cc: Ted Lemon <mellon@fugue.com>, HOMENET <homenet@ietf.org>
References: <2737406f-c615-3963-2226-d2eadf79e846@globis.net> <87a7b1bdhe.wl-jch@irif.fr> <DE13B405-C1B6-4603-84DC-F7A8E22EF075@fugue.com> <878sqlb43a.wl-jch@irif.fr>
From: "Ray Hunter (v6ops)" <v6ops@globis.net>
Message-ID: <c1614efa-2436-9641-968a-bf18b76ef29a@globis.net>
Date: Thu, 19 Sep 2019 15:30:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <878sqlb43a.wl-jch@irif.fr>
Content-Type: multipart/alternative; boundary="------------8C5EACF2B029A428A4871735"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/4Pm2nPIHgjAYwFm582ZACIRNfpI>
Subject: Re: [homenet] DNCP/HNCP Revisited
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: Thu, 19 Sep 2019 13:30:15 -0000

Juliusz Chroboczek wrote on 19/09/2019 01:02:
>> The problem is, how’d the packet get so big that it was fragmented?
> HNCP relies on network-layer fragmentation: it uses UDP and has no
> application-layer mechanism for fragmenting large TLVs.  See Section 4.2
> and Appendix B.2 of RFC 7787.
Agreed. I'm aware it was a design decision.
>
> (I seem to recall that an earlier version of DNCP included provisions for
> application-layer fragmentation of TLVs, but that was removed at some
> point.  I don't remember why.)
Yes. I've read earlier versions of the draft and it was an open point 
whether to do L7 fragmentation as part of HNCP or not.

I can't recall the exact discussion on list but it changed between 
version 4 and 5
https://tools.ietf.org/html/draft-ietf-homenet-hncp-04 (Appendix A)
https://tools.ietf.org/html/draft-ietf-homenet-hncp-05 (rely on UDP 
fragmentation)

> Let's please come back to my question.  RFC 4443 paragraph 3.2 says
>
>     A Packet Too Big MUST be sent by a router in response to a packet
>     that it cannot forward because the packet is larger than the MTU of
>     the outgoing link.
>
> If your tunnelling software violates this, how is it not buggy?
>
> -- Juliusz
Yes, this is a very poor network set up that could be avoided.

Question is: is it worth addressing?

I'm still working on the basis of a simple workaround to address the L2 MTU mismatch (limit IPv6 UDP fragment size to 1280 octets).


The separate problem is that if the amount of HNCP state increases (e.g. due to electing a central name server or mud server or whatever), the apparent limit of having to transmit the entire superset of all node TLV states in a single UDP packet may become problematic.

I notice in the current Openwrt code that the max UDP packet size is set at 9000 octets with the comment:

/* Very arbitrary. On some implementations, I have seen some issues
  * with 10+kb frames so we use this for now. It MUST be significantly
  * more than 4k, due to how code is written at the moment. */
#define HNCP_MAXIMUM_UNICAST_SIZE 9000

With current code (without expanding the TLV data set), and my sample test routers, that sets a current maximum network size of approx. 12 nodes.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>