RE: Comments on raft-fz-6man-ipv6-alt-mark-01

Tianran Zhou <> Tue, 05 November 2019 10:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D24D91208BE for <>; Tue, 5 Nov 2019 02:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZigLGTIVXkZZ for <>; Tue, 5 Nov 2019 02:06:00 -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 E50BC120881 for <>; Tue, 5 Nov 2019 02:05:59 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 4D5BFFDFBE3A602C76B2; Tue, 5 Nov 2019 10:05:58 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 10:05:57 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 5 Nov 2019 10:05:57 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 5 Nov 2019 10:05:57 +0000
Received: from ([fe80::a54a:89d2:c471:ff]) by ([]) with mapi id 14.03.0439.000; Tue, 5 Nov 2019 18:05:50 +0800
From: Tianran Zhou <>
To: Mark Smith <>, Ole Troan <>
CC: 6man WG <>
Subject: RE: Comments on raft-fz-6man-ipv6-alt-mark-01
Thread-Topic: Comments on raft-fz-6man-ipv6-alt-mark-01
Thread-Index: AQHVkNp1vSw+2l7wQkiVjZA5BgCgSqd2EMsAgAAC24CAAAVMgIAGGU5Q//+BjICAAI5ZsP//hgqAgAAIVICAAIud0A==
Date: Tue, 5 Nov 2019 10:05:49 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF07AE81NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2019 10:06:07 -0000

Hi Mark and Ole,

Thanks both of your suggestions.
You are right. Using DO for hop by hop action would cause the performance degradation.
But my question is, do we have anyway for the compatibility?
That’s why we want to discuss the way as in RFC7837, maybe as a deployment consideration.


From: Mark Smith []
Sent: Tuesday, November 05, 2019 5:34 PM
To: Ole Troan <>
Cc: Tianran Zhou <>om>; 6man WG <>
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01

On Tue, 5 Nov 2019, 20:05 Ole Troan, <<>> wrote:

> Yes, I know 8200 considered and changed the way to process the HBH.
> Do you mean the following words?
> NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header, it is now expected that nodes
> along a packet's delivery path only examine and process the
> Hop-by-Hop Options header if explicitly configured to do so.
> From this I am always confused. We can decide/configure whether to process the HBH. But we cannot decide whether it's processed in fast path or slow path. I think this is one issue raised by the reference
> Do I miss some other words in 8200?

Right, HBH processing by a router now has to be explicitly configured.
E.g. if a router didn't support alt mark, it would be no purpose in even parsing the HBH header (unless other options also was configured and supported).

You can of course not control how efficient that implementation implements your option...

> In addition, we did test many asics and devices. They will direct packet to the slow path.
> In addition, in real deployment, there are legacy devices that follow RFC2460.
> So our idea is to show alternative options for potential environment.

Sure, and this was discussed a lot in the context of the other RFC.

Hiding the per-hop options inside of destination options, would have pretty bad performance characteristics I would expect.

For HBH a router needs to:
if ipv6->nh == 0
   walk HBH TLVs and process them

For DestOpt a router would need to:
walk EH chain looking for DestOpt:
  walk DestOpt TLVs and make a guess which one is for in-flight versus destination

Yes, the *Destination* Options are for the device holding the packet's *Destination* Address.

Using HBH you use a mechanism engineered for it, using DestOpt you are in middlebox territory. And you will be much more likely to end up conflicting with host functions.

Best regards,

PS: If you would do a EH performance testing project at the Singapore hackathon I would be all supportive.
IETF IPv6 working group mailing list<>
Administrative Requests: