IETF Logo Mail Archive

Re: [homenet] DNCP/HNCP Revisited

Juliusz Chroboczek <jch@irif.fr> Wed, 18 September 2019 23:02 UTC

Return-Path: <jch@irif.fr>
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 6F7A212010C for <homenet@ietfa.amsl.com>; Wed, 18 Sep 2019 16:02:43 -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 D4lGAVnjjBVT for <homenet@ietfa.amsl.com>; Wed, 18 Sep 2019 16:02:41 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F70F1200C3 for <homenet@ietf.org>; Wed, 18 Sep 2019 16:02:41 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x8IN2aMr013669; Thu, 19 Sep 2019 01:02:36 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9D06554506; Thu, 19 Sep 2019 01:02:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KeUDqeWEPWIG; Thu, 19 Sep 2019 01:02:33 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 35BA154504; Thu, 19 Sep 2019 01:02:33 +0200 (CEST)
Date: Thu, 19 Sep 2019 01:02:33 +0200
Message-ID: <878sqlb43a.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Ted Lemon <mellon@fugue.com>
Cc: "Ray Hunter (v6ops)" <v6ops@globis.net>, HOMENET <homenet@ietf.org>
In-Reply-To: <DE13B405-C1B6-4603-84DC-F7A8E22EF075@fugue.com>
References: <2737406f-c615-3963-2226-d2eadf79e846@globis.net> <87a7b1bdhe.wl-jch@irif.fr> <DE13B405-C1B6-4603-84DC-F7A8E22EF075@fugue.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 19 Sep 2019 01:02:36 +0200 (CEST)
X-Miltered: at korolev with ID 5D82B78C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D82B78C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5D82B78C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/5KloCDjhiXx9iFtdh0hUltUDAcI>
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: Wed, 18 Sep 2019 23:02:44 -0000

> 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.

(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.)

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

v2.23.0 | Report a Bug | By Email