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

Tom Herbert <tom@herbertland.com> Mon, 03 June 2024 15:03 UTC

Return-Path: <tom@herbertland.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 8062CC1D4A66 for <ipv6@ietfa.amsl.com>; Mon, 3 Jun 2024 08:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LG-9l3crU4ED for <ipv6@ietfa.amsl.com>; Mon, 3 Jun 2024 08:03:07 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 F1567C1D4A68 for <ipv6@ietf.org>; Mon, 3 Jun 2024 08:03:07 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-57a1fe6392eso5036456a12.0 for <ipv6@ietf.org>; Mon, 03 Jun 2024 08:03:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1717426986; x=1718031786; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cEAsj1ncR3z5cWGc53VPKcLCZkl6eF4r4E1r52WFZ/4=; b=fhjt1zrXgfMqrHen13VIVGEiUDfkmavcPUWHNPmi6efiPvGOaUgiBVKXqdp5ISBsS4 kfsGr/NR1kzYXTRMUs90tehhafpEIciEd0lF/Yu7NMK/hVmNq3YihFoY1mWxi90AG2eI OQ0ODgYX9HCR/vegSiZAO7TrslelEkrvRWTqZkbEY67IrwFmQ5gsTKNy64vowMLs8CXO Qane2z8HUkruF1wsqeg/3Z8HpQHd47l4iYh8UNe1NdhIV1Z3xLAh6CAFequ1y2gtEyTC 5I2DJ0ulqo8HuqH+GIjVTBnhbl+kqC+fThNu2oOJJzoIk6YHTn5JckunYVV7rOHFn4/D y1hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717426986; x=1718031786; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cEAsj1ncR3z5cWGc53VPKcLCZkl6eF4r4E1r52WFZ/4=; b=clu1BvaLfecYyCZ2inDrqDpZDdWPROZSjLG5CgnqvRFEKk2ddmmoyvz3X839AO3Owk vC1XnqMvYit11mZ5ANjBGxtwj0lVz1gEG3lo7ZomhUbfH8extyYjKNIEQBYnQMWKOiQ9 1TwbyMdf2v3zOQ5N/j29eWcVL2C2ZWABEnq4MwYd5eqrhNZbsfIwNbW0mCjN1z6KKa46 cYh64zWp5LiSrTn5kqNgbPseFvIYa1707cKdikBzj6GIagHqabrorXG4yTtt3rkGO/Ok /2peiOUJZ9tjQdQ0XQ/tq/Fb2pZvPqGIEQel9cA1cxxtSwezF+WJSoiuWcI/PYDhdZwz AkzA==
X-Gm-Message-State: AOJu0YzCj9w6jzKCYDcApsIITA6VZCSDRS5RlkuGH6YnR17vUIRB3S/Q 8AIw2lMdMDpvZUO/vxZMyxzqdE/M3XsLBTNM4M1o8qDZOv3iIowdtc//zwYi3LWEBJJWhXK02Y3 4z5scII8lKeAG2UyIUMAEfYopaxK4oqtsSPC1
X-Google-Smtp-Source: AGHT+IGZ9SjOBaTQD0cpy9Xx1hDtxcEClKEjpSagtaG2mZo1x+49EPQ+GNH20Ow7UNZaEg+EgA3t3k85IOe/EIV5gnU=
X-Received: by 2002:a50:9b1b:0:b0:57a:2eff:8ae with SMTP id 4fb4d7f45d1cf-57a36348fd6mr6119984a12.1.1717426985533; Mon, 03 Jun 2024 08:03:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsyrbnWJTCKxwbQusWWe0SRoRHqP7j069KYNRvsVPL6Zzg@mail.gmail.com>
In-Reply-To: <CAMMESsyrbnWJTCKxwbQusWWe0SRoRHqP7j069KYNRvsVPL6Zzg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 03 Jun 2024 08:02:57 -0700
Message-ID: <CALx6S371cxEQn9-j4ADiadnb+FYFFh2t8tJDHmx6w5zMKXq-sA@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-MailFrom: tom@herbertland.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: 6man <ipv6@ietf.org>, 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]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/pWjJGjeiE6BOlS1FmEnG_6KG0cI>
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>

On Mon, Jun 3, 2024 at 5:00 AM Alvaro Retana <aretana.ietf@gmail.com> wrote:
> 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?


Yes, this has major impacts on host dataplanes particularly when the
SRH is not present. As the new text states, this potentially breaks
useful and deployed functionality in middleboxes and at end hosts (for
instance, this would break certain types of NIC offloads). The new
text suggests that we need to make middlebox implementations of SRv6
aware, but I think that's backwards-- it's the new protocol that's
breaking existing implementations so the problems should be addressed
in the protocol definition. Note the checksum problem can be fixed by
applying a variant of checksum-neutral mapping NAT (Section 2.6,

IMO, the bigger issue here is that the idea of sending a compressed
SID list without a routing header is not well specified. In the draft,
the only statement I can found about is:

"If the SR Policy results in a Segment List containing a single
segment, and there is no need to add information to the SRH flag or
add TLV; the DA is set to the single Segment List entry, and the SRH
MAY be omitted."

This needs a lot more elaboration and requirements and motivation.
AFAICT, in this mode segment routing degenerates to Network Address
Translation except that there's no requirement to maintain the correct
checksum. Why not explicitly say that? Also, do the benefits outweigh
the costs? We could put a minimum sized 8 byte SRH in packets to
ensure that the network won't try to interpret the packet as a plain
IPv6 packet. Is sending eight bytes to avoid ambiguity going to really
break any applications? Maybe the idea makes sense and can be
justified or maybe it really isn't worth doing, but either way clarity
in the draft on the requirements and motivations seems prudent.


> [1] https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression
> [2] https://datatracker.ietf.org/doc/html/rfc8200#autoid-17
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> --------------------------------------------------------------------