Re: [dtn] BPbis rules for future extension blocks

"Burleigh, Scott C (US 312B)" <> Fri, 20 November 2020 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1EED3A0D9B; Fri, 20 Nov 2020 08:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oUcAjrkFGEHS; Fri, 20 Nov 2020 08:00:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56D233A0D97; Fri, 20 Nov 2020 08:00:55 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 0AKFw1oj146078; Fri, 20 Nov 2020 08:00:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=InSight1906; bh=9TnlRgXBTB7YEsuphinx2wXy1FH7ldtjyJTF95TEzIk=; b=ol79xsv6PQmETajCr2SCRP4QZXrNNQv1SWd5r7pMdHUTZW7COV+ovjUgSRSNNv349OQN YPGXhNEYCpdn/PUjnK+lVIzisS1+lHOrltO2GEYzbGlXqhY7YJ93LZMsewRfOucLus+4 /GhOe8aJ+2WUJOfYfIIoal45bmF8ZgcNfWkqAqV8LDii/HPJBG+MWM8YTCl5f8JrGfCO znvmCaxaugJNoC48CT870VHcIh0HoT7y6v7sHhcw3giGEkKGIzQFNCIKCnULIClujkgv Q+YpOFVU5VXCMFXsigqvG0VLFj9B4SXqhzhjDbxAjc8TXRAistIPFiCrJ0YhYwHfC93f xQ==
Received: from ( []) by with ESMTP id 34xfuh80uj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Nov 2020 08:00:54 -0800
Received: from ap-embx16-sp40.RES.AD.JPL ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 0AKG0rJJ020929 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Fri, 20 Nov 2020 08:00:54 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 20 Nov 2020 08:00:53 -0800
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1979.006; Fri, 20 Nov 2020 08:00:53 -0800
From: "Burleigh, Scott C (US 312B)" <>
To: Magnus Westerlund <>, "" <>
Thread-Topic: BPbis rules for future extension blocks
Thread-Index: AQHWv003l8SJtEoS7kGU84euBT+wganRJHdg
Date: Fri, 20 Nov 2020 16:00:52 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: []
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_09:2020-11-20, 2020-11-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2011200108
Archived-At: <>
Subject: Re: [dtn] BPbis rules for future extension blocks
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2020 16:00:57 -0000

Thanks, Magnus.  As a starting point for this discussion, here is the text that I would propose to use in place of the current first paragraph of section 4.3:

"Extension blocks" are all blocks other than the primary and payload blocks. Three types of extension blocks are defined below.  All implementations of the Bundle Protocol specification (the present document) MUST include procedures for recognizing, parsing, and acting on, but not necessarily producing, these types of extension blocks.

The specifications for additional types of extension blocks must indicate whether or not BP implementations conforming to those specifications must recognize, parse, act on, and/or produce block of those types.  As not all nodes will necessarily instantiate BP implementations that conform to those additional specifications, it is possible for a node to receive a bundle that includes extension blocks that the node cannot process. The values of the block processing control flags indicate the action to be taken by the bundle protocol agent when this is the case.

No mandated procedure in this specification is unconditionally dependent on the absence or presence of any extension block.  Therefore any bundle protocol agent MAY insert or remove any extension block in any bundle, subject to all mandates in the Bundle Protocol specification and all extension block specifications to which the node's BP implementation conforms.  Note that removal of an extension block will probably disable one or more elements of bundle processing that were intended by the BPA that inserted that block.  In particular, note that removal of an extension block that is one of the targets of a BPsec security block may render the bundle unverifiable.  


-----Original Message-----
From: dtn <> On Behalf Of Magnus Westerlund
Sent: Friday, November 20, 2020 6:56 AM
Subject: [EXTERNAL] [dtn] BPbis rules for future extension blocks

Hi WG,

So in the discussion of BPv7 Extension in todays meeting some people did draw some parallels to IPv6 Extension headers. Ben Kaduk reminded me that there is one important aspect of that discussion that can hint at an issue. If you are following 6man and/or Spring WG you would know about the big discussion related to addition and removal of some IPv6 extension headers by anything other than the endpoints that IPv6 Segment routing proposal has caused.

So the existing Extension headers are all being changed interally and at least "received from" will be added by a forwarder which isn't the originating endpoint.  So the question to the WG and especially the authors. Is it really clear that Extension bundle blocks MAY be added by any node? Which nodes MAY remove a Extension bundle block? What controls if a Extension Bundle Block can be removed by an intermediate node. I do note taht the Block Processing Control Flags do not have a flag for "MUST NOT be removed, even if not understood". 

I would encourage the WG to think if there need to be any clarification of this now. If we are missing a control flag I think it is easier to add it now. Also to clarify what the general rules are for Extension Blocks so that this discussion don't show up a bit down the line here.