IETF Logo Mail Archive

Re: Removal of destination options that precede a routing header

Sander Steffann <sander@steffann.nl> Tue, 26 May 2020 14:23 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390DA3A0F93 for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 07:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 KFT4ElRYC2SW for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 07:23:36 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 D822E3A0F90 for <6man@ietf.org>; Tue, 26 May 2020 07:23:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B119F4D; Tue, 26 May 2020 16:23:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1590503007; bh=chMVCZOsXlU8Y+txuaQ 30b0vrouNnF0naQdKbnC+Meg=; b=RHwG7Gkun1SYDTVQK6f/Lldv6wThau84oLb JQqXQRP3LnO3IQk06MBu5jD7ziR4xDTSrtunaI6LWsy8go1ufsQJQXQfsXGhJDOw 5IQHi+HrN/n3O1ccZHlqqyQOIgVimIc/Hp4c3ZYm7g95kZz8wxERVPbq9hSwIdTX GJdJheqU=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bYdNDmT-VcaQ; Tue, 26 May 2020 16:23:27 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:19f6:dcc2:c2ab:45c4] (unknown [IPv6:2a02:a213:a300:ce80:19f6:dcc2:c2ab:45c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 7BC9049; Tue, 26 May 2020 16:23:27 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <27AD0B48-3DDD-4EE6-9325-B897727BB30C@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_9ACF9AF4-76FE-467D-91D7-B43E92AED97F"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Removal of destination options that precede a routing header
Date: Tue, 26 May 2020 16:23:25 +0200
In-Reply-To: <DM6PR13MB306686E9F1A444C05BB5EF56D2B00@DM6PR13MB3066.namprd13.prod.outlook.com>
Cc: 6man <6man@ietf.org>
To: James Guichard <james.n.guichard@futurewei.com>
References: <DM6PR13MB306686E9F1A444C05BB5EF56D2B00@DM6PR13MB3066.namprd13.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zXOXvFOqaCXGB6kRqRQJTPE4RT4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2020 14:23:42 -0000

Hi,

> Note 3 is for destination options after a routing header. As such the destination option is processed after the routing header and therefore the router is able to determine from the SRH that it is the final destination as segments left = 0. Presumably an implementation would at this point remove the routing header and the destination options and send the packet on its merry way.

The header aren't removed. When there are no segments left the destination address is that of the final destination, which will get the full packet as sent by the sender with all the headers intact.

Cheers,
Sander

v2.23.0 | Report a Bug | By Email