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

Alvaro Retana <aretana.ietf@gmail.com> Mon, 03 June 2024 12:00 UTC

Return-Path: <aretana.ietf@gmail.com>
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 39F0CC16940C; Mon, 3 Jun 2024 05:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeeiWjyZlyFB; Mon, 3 Jun 2024 05:00:06 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9604BC169434; Mon, 3 Jun 2024 05:00:06 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1f47f07aceaso26145265ad.0; Mon, 03 Jun 2024 05:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717416006; x=1718020806; darn=ietf.org; h=cc:to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=kymloPjDJ0KPUmMHdhJ9azsjoEemOp6dlQC6+Mp1yEM=; b=bRuzn1V7/Nnxy/aQa/NI3SID7L2ofpYIBTiznHNAdXl8+/D+JK3yurkXTv9XXrbrs8 PdeLieYBDoCzVQLNnt0Gg0b3nnFD0uD+S1TxK6aBhgFrICgUK/huWyMyA1xbZLMWrzzX Cs844fAz0uh2OMo9/A2uKmhSWL+CjVyA5gd2JWmm28AtD6nUhDD5jtK3SJqMvyR0BS0Z pMjSM4yUptJnmgMW2ebvZdUKvVVNYdtMwQ+xwKWmXozPDtezK2apvtSOP5vhW3coJD73 ulz9dmCS/7WjYZdbo3vS3/9U5Na3WFNVbV6D8Hxi+4voiKB1faaQ0mAF+OaFd3nPC9B3 tnGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717416006; x=1718020806; h=cc:to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kymloPjDJ0KPUmMHdhJ9azsjoEemOp6dlQC6+Mp1yEM=; b=HM/B3AoDSQZgypLhdoXhBU7ozLPI8Fy7e0EubG1c8ZyAye6c6fvsguOPy4fFPYdV1j 0f5bvlJmbD9AbAOZ92EXqo7BChBYdaoal+BkDfmt5EXjX3nEqhuPHjgJGWGKBwm4usSg 9abXOHOlaDF0uO2YS4DRs+LQmPwm4SaJ+o868VuplyosXz8y6osQYW6B3+Iubq2c5WdP Knz2EXjPnTYGoS0bzCPWnLGUb3ck9RJ3Df3D1OE1igfOcvab9L3roMMN4GYf7wKEVrFQ 12Z2KpnOzpFyJyTrZA2Is6ap7xnOOyZ90nbbaJPCMrVHSLrysBe8+CUPcqeK6TDa5Etu Ii6Q==
X-Forwarded-Encrypted: i=1; AJvYcCWQ6t4BvA96IS/oaD+ro2vPuMHI9shiy51m7ExL3+LF3MZ0Unr26wL6/OhXvjmX8QpN3inuSO0On8c0tRv7xlHVOkwb9P7SrX69Twzvw/ktYnIre7uOIKEC+cT0f/i6hmc+86LzIdW/IkltwSTB59K5r0fr4Ubi7LOJekMwR7Cp
X-Gm-Message-State: AOJu0Yw4URjZJnJ5rIQqPcxcdlURXk9RYWbYehTGOpMd+0syJCvbl1mj PwmKrUbHAFevchYll5YgN/bGE+9+/lECoa4Vwwf/yvyUc5uTwprwaHaeOviSpNSrGdEXcF3l3Dl hqkaYW8Ptnxx9pq7HehjpcN4rGZmnvQ==
X-Google-Smtp-Source: AGHT+IGQcZ6W+MMBMJTxEHp5H/9enkuCRNk1gWoYodsQ6becbQczgnpezGTyZpGAumVrcBCDpMYvnaSo9Z7lte0Jk1I=
X-Received: by 2002:a17:90a:bf06:b0:2b3:9ce8:1239 with SMTP id 98e67ed59e1d1-2c1dc568f4bmr7406312a91.6.1717416005167; Mon, 03 Jun 2024 05:00:05 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 3 Jun 2024 08:00:03 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Mon, 03 Jun 2024 08:00:03 -0400
Message-ID: <CAMMESsyrbnWJTCKxwbQusWWe0SRoRHqP7j069KYNRvsVPL6Zzg@mail.gmail.com>
To: 6man <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eb72180619fb122c"
Message-ID-Hash: 7M47NCS7WB7NFS3T3HJZYL2EHG5IJBIG
X-Message-ID-Hash: 7M47NCS7WB7NFS3T3HJZYL2EHG5IJBIG
X-MailFrom: aretana.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: int-ads@ietf.org, rtg-ads@ietf.org, 6man Chairs <6man-chairs@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, SPRING WG List <spring@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [IPv6]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/hOM8JezKqlxnksz0PdntGH2xO8o>
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>

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.

Thanks!

spring-chairs



§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
   document.

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


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