[IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

"zhuyq-ietf2024@foxmail.com" <zhuyq-ietf2024@foxmail.com> Fri, 07 June 2024 01:23 UTC

Return-Path: <zhuyq-ietf2024@foxmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BCE8FC14F68D; Thu, 6 Jun 2024 18:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.091
X-Spam-Level: *
X-Spam-Status: No, score=1.091 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1k4mhMGRwxJl; Thu, 6 Jun 2024 18:23:20 -0700 (PDT)
Received: from out203-205-221-153.mail.qq.com (out203-205-221-153.mail.qq.com []) (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 6152BC14F60A; Thu, 6 Jun 2024 18:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1717723393; bh=EtI0N6T3ky8EBOEKq6GPKzoQMLTKZ/WSJoPZXOmTcRA=; h=Date:From:To:Cc:Subject:References; b=Blv0cW3PK/8JScn4KWiyd2mG4oqgfgy+b06JFFh45qrow2OAAjrOBkq6gis4uGhCI CyefN1qZkIvjPqKA4aNx6CNQXuSjvsISp/gqPTi44P13cIglX1V2b9cLoyfhsELCo4 U3ljXCsRqaNR2rtUe9lHgNJBcuDiczV1Cm7uSW5U=
Received: from LAPTOP-62COFCP0 ([]) by newxmesmtplogicsvrszc5-2.qq.com (NewEsmtp) with SMTP id 446B66A2; Fri, 07 Jun 2024 09:17:06 +0800
X-QQ-mid: xmsmtpt1717723026t2ijvgjof
Message-ID: <tencent_404B8C0D020D0ACFCC0B870EBE3998611C07@qq.com>
X-QQ-XMAILINFO: Mw5V7KuSxHjfM1ROOmNqjy+dj7CaKTPCskgYcfX0aPTD3ssTxlO2N4QOzoUIC+ Kb4zPwBwmaydHVzdU+RCVD5Ipu0qvEzh43R04OT/U2nY5TKKvDKh6ANgXqxuxtFzlFpPGfA+MvOg IXYwFwZLw1ch7QdFSGKu64ni0sNSfNadwOh1Crwiby28swq1sFKuEuzTPRYIRv1XRKfhogCjQ8Nx Ypp8Cd4AVHWOAqDjASalmn4Src4MYmicaYwOxIEih2zGiAtS1an+DMdeMldFqjf7fVW1ESXvFjgf 5Uztooy7nY9cSwfq8h5tyBDpOFqLs/5My9nP2hCp6rnjtaSF/SYkQwIhX5yip40Vi6sF/AbrChlU rH/R0Uy+RcKqg7LgMUxUtDMVyq3MWbB+ZXSXvkqdsK2Cva6P0D1dF/5oXRzKzMn/Qqx1lPi+3LmH 8vyDqFyswiyXKlK2eaLL0ug5iY6Hc02wF5U7pdtLLX9Sx8E5W9qN0kk8zde9fKMgZzkidaaAH+NG LiK5yKFyIoZ7Ib5IJOghNBANOZ6Egt+oL5s2ZekTGHTyEqc7XVko48PlVGs76HdSuHrPY9aug7OU JYs+pvKsCnzrVLa9we7GdullOVBtdViSojjDgvKfMc6QbHqc4ZD33kY1gmldSwzQrtogDF+hNEQ7 csiMC2LbWJlBC2+33yEShF2F2WVUHuPTXrkCPe7G8z8M/yAorn49W+hgilaR6oe+MCxQQfEYEE5u 20Fv0hZS7sNbhRQvjUHL0lxxRHz656A1+ZYqhdnePptXPVQU2YbndMTNzAXmI1U1gy50dzfJscaw fmvSSfFJ977IEDaWw1kCjc2+LlSHutBoh3Bh3ND2WCQsCn1Vo3QR7pMqiPV/FiRKGQQAJnRuezOU dUc8fXEyghzsh8VVmFI3VYc7hM0XTfhBQDh5dr2I57EYinuDVWPNsowbH+eVy628IHTRWWoDcKj4 TMVLCI5Sq3ZCbCGppQ7Xuy7QA8lmVZP8oGzRQhPPs=
X-QQ-XMRINFO: Mp0Kj//9VHAxr69bL5MkOOs=
From: "zhuyq-ietf2024@foxmail.com" <zhuyq-ietf2024@foxmail.com>
To: "aretana.ietf" <aretana.ietf@gmail.com>, IPv6 List <ipv6@ietf.org>
References: <CAMMESsyrbnWJTCKxwbQusWWe0SRoRHqP7j069KYNRvsVPL6Zzg@mail.gmail.com>
X-Priority: 3
X-GUID: 5CAEC168-39EA-4398-AFC5-7255FF35F53E
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
X-OQ-MSGID: <2024060709170681816020@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart826225258433_=----"
X-MailFrom: zhuyq-ietf2024@foxmail.com
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0
X-Mailman-Approved-At: Tue, 11 Jun 2024 08:11:45 -0700
CC: "int-ads@ietf.org" <int-ads@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, spring-chairs <spring-chairs@ietf.org>, spring <spring@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3zRJh3-pH-L09M17c-zjUGk36fQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>
Date: Fri, 07 Jun 2024 01:23:24 -0000
X-Original-Date: Fri, 7 Jun 2024 09:17:07 +0800

I think this text is good to me.
It is aligned w/ RFC8200, nothing is needed.
Using C-SID as the text specified doesn't modify the IPv6 dataplane.

Zhu Yongqing 
China Telecom

From: Alvaro Retana
Date: 2024-06-03 20:00
To: 6man
CC: int-ads@ietf.org; rtg-ads@ietf.org; 6man Chairs; spring-chairs@ietf.org; SPRING WG List
Subject: [IPv6]C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)
Dear 6man WG:  

As you may be aware, the spring WG is in the process of advancing  
draft-ietf-spring-srv6-srh-compression [1]. The WGLC discussions have  
resulted in the need to ask you the following questions (see below)  
related to the use/operation of compressed SIDs (C-SIDs).  

Please provide any opinions by June 14, 2024. 



§6.5 (Upper-Layer Checksums) explains how to calculate the Upper-Layer  
Checksum in the presence of C-SIDs. §9.3 (Upper Layer Checksum  
Considerations) discusses the related operational considerations.   
For convenience, both sections are reproduced here: 

===== ===== draft-ietf-spring-srv6-srh-compression-17 ===== ===== 

6.5. Upper-Layer Checksums 

   The Destination Address used in the IPv6 pseudo-header (Section 8.1  
   of [RFC8200]) is that of the ultimate destination. 

   At the SR source node, that address will be the Destination Address  
   as it is expected to be received by the ultimate destination. When  
   the last element in the compressed SID list is a C-SID container,  
   this address can be obtained from the last element in the  
   uncompressed SID list or by repeatedly applying the segment behavior  
   as described in Section 9.2. This applies regardless of whether an  
   SRH is present in the IPv6 packet or omitted. 

   At the ultimate destination(s), that address will be in the  
   Destination Address field of the IPv6 header. 


9.3. Upper Layer Checksum Considerations 

   Upper layer checksums are computed by the originator of an IPv6  
   packet and verified by the ultimate destination(s) as it processes  
   the upper layer protocol. 

   As specified in Section 6.5, SR source nodes originating TCP/UDP  
   packets ensure that the upper layer checksum is correctly calculated  
   based on the ultimate destination of the session, which may be  
   different from the address placed in the IPv6 destination address.  
   Such SR source nodes leveraging TCP/UDP offload engines may require  
   enhancements to convey the ultimate destination address. These  
   implementation enhancements are outside the scope of this document. 

   It was reported that some network node implementations, including  
   middleboxes such as packet sniffers and one software router  
   implementation, may attempt to verify the upper layer checksum of  
   transit IPv6 packets. These nodes, if deployed inside the SR domain,  
   may fail to verify the upper layer checksum of transit SRv6 traffic,  
   possibly resulting in dropped packets or in the inability to carry  
   out their function. Making these implementations SRv6 aware in  
   general or C-SID aware in particular is out of the scope of this  

===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== 

Is this text aligned with §8.1/rfc8200 (Upper-Layer Checksums) [2]?  
Does anything need to be added, deleted, changed, or clarified?   

Is using C-SIDs in the above scenarios (§9.3) compatible with IPv6  
transit node deployments compliant with rfc8200? 

Does using C-SIDs as specified above represent a modification to the  
IPv6 dataplane? If so, is the modification considered acceptable to  
the WG? 

[1] https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression  

[2] https://datatracker.ietf.org/doc/html/rfc8200#autoid-17