Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

"Dongjie (Jimmy)" <> Sun, 27 September 2020 06:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94DD43A0766; Sat, 26 Sep 2020 23:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eQYWBh5YS6Nm; Sat, 26 Sep 2020 23:43:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C56483A080C; Sat, 26 Sep 2020 23:43:32 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 878565A9A7A97E380D00; Sun, 27 Sep 2020 07:43:28 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Sun, 27 Sep 2020 07:43:27 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sun, 27 Sep 2020 14:43:25 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Sun, 27 Sep 2020 14:43:25 +0800
From: "Dongjie (Jimmy)" <>
To: John Scudder <>, "idr@ietf. org" <>
CC: "" <>, Hares Susan <>
Thread-Topic: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
Thread-Index: AQHWke6R/vziZzLJCEG5MAjI/j3hKql5NjsAgAKZECA=
Date: Sun, 27 Sep 2020 06:43:25 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_f58c0f99d8474e41bb7ed91fe880643bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Sep 2020 06:43:35 -0000

Hi John,

Thanks for bringing this to list discussion.

I agree it would be no harm to clarify it as “Is a fragment other than the first”. (Sorry for the typo with “segment”, I mean fragment actually).

And since the description of the rule  “fragment offset is not 0” is added in 5575bis, perhaps it would be helpful to note whether the semantics aligns with RFC 5575, or is a small update?

Best regards,

From: Idr [] On Behalf Of John Scudder
Sent: Saturday, September 26, 2020 3:15 AM
To: idr@ietf. org <>
Cc:; Hares Susan <>
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi All,

Jie brought up another point in a unicast email. He points out that

The description about component type 12 (Fragment) has been updated, the meaning of the Bitmask values is added. For Bit-6 (IsF), the new description is:

   IsF -  Is a fragment - match if [RFC0791] IP Header Fragment Offset is not 0.

This description is IMO a little bit confusing, as it simply says “is a fragment”, but the matching rule does not include the case of the first fragment (MF=1, offset=0),. Perhaps it could either update the matching rules to also include the first fragment case, or it may update the description as “fragmented and not the first segment”.

Let’s also discuss this before we take the document off of hold and continue its processing. Speaking for myself, I don’t find the quoted text confusing since the rule specifically says “fragment offset is not 0”, but on the other hand it would do no harm to change the description to the even-more-correct “Is a fragment other than the first” (I didn’t use “segment” as Jie does, since that’s potentially a new source of confusion; “segment” is a TCP term, not an IPv4 term, and it’s a *different* IPv6 term).