IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Thu, 13 June 2024 16:28 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79015C14F708 for <spring@ietfa.amsl.com>; Thu, 13 Jun 2024 09:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=raszuk.net
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 3t5fepcAF82D for <spring@ietfa.amsl.com>; Thu, 13 Jun 2024 09:28:50 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 8F2A0C14F747 for <spring@ietf.org>; Thu, 13 Jun 2024 09:28:50 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2ebdfe26242so14051691fa.0 for <spring@ietf.org>; Thu, 13 Jun 2024 09:28:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1718296128; x=1718900928; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LiLbHJgD4vK8Uj2IXAzjdLBoowX8dELfxH88ix+yP/g=; b=PQv8Db7ta4S0h6N2lyTSuaPDJb+o+GvhgP0+mO6duIPVaRCkLA0955Utl2DbZ55O0R 4vUHoWzMwi4sl1CO+2VPeOVMZXpklHiNP7cU2jzay3Ib14PLrd1CVsXUu6ocUVkbwC4T dTd5SM3M8UrLWpMU1q/BUdzPc8wTFBkoiglV9B33TkV6vJNRe7xCOh9ZG29RhN8AJi3v e5BpkJpEKk+EbPf4UAO0gVEjd4H2Lva7TLtejm7JaM1xuVFpcbkR+9pB2I57h6YMh1xr /Oj4tlWASugdN3YgECTAYqIolz6tRfsMiLd4fP9RW/jXdBT78F+0fzQ1EBwXkcabmQLD b0kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718296128; x=1718900928; h=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=LiLbHJgD4vK8Uj2IXAzjdLBoowX8dELfxH88ix+yP/g=; b=iFH45A7lxEX5H+FffhmHvy/JsnAwTzxZbDpxQTBBU+xWa1VQpBqlKqeg9Qq6S3lXxS g+Bllvq0ZudNJ3e3B0KWFQrw/JR6YOX8L6MIJuUDTambfVdKjp2wGaYkIsqkrDCqwCpJ jUTlDFjXBx1IW/QhPMZWVgXJj4quVdmzpv60w4qSp1JYUGIkEt6cbPNmG1mHrxcrkBMR BuhwAU9SQSABEIP/lHO4tilcL6o53R2j9bX2vcDCcxgvM6TVxZnGN+9K6LO77tuVOqj7 a+Yb8cfNRoEyG0aUAchiPV2vie55PhrmZO70p48lTaawI0dMaUL0yMUGxfDAksK7nTfA WT7Q==
X-Forwarded-Encrypted: i=1; AJvYcCW71gM8vYDvyHH7pLZ5IYIHaNfLn/0rJL/R9WaxK87RVZYam4YTncqTMhyHUoy0blYob3Wb4bVrCYfYt4Pqsb4=
X-Gm-Message-State: AOJu0YyDX/7KmeLIBbuS+D32Y4BnzAcmEIEup/X49iwFUNkYODYMsezV +g56Fo0buVwwgpQJ8lnyKPr06/Q9OivtHW92m0g3gr4lQ+Y89Q7HkcdHNIA2IH37e5fDqiBuPCF /VFMMW7ylC6I49/+l7brjb2ALbaL7DDMomozLyg==
X-Google-Smtp-Source: AGHT+IEd4+WDpHeaT4h0Xfluzvs9v7yZg6XjQQNozS2Naltx0VoGhqRx7kucPj1qxfRo+g1j+ovvGuRc14WXhPhbbgA=
X-Received: by 2002:a2e:b16a:0:b0:2ec:580:bb93 with SMTP id 38308e7fff4ca-2ec0e4632c4mr2449771fa.5.1718296128333; Thu, 13 Jun 2024 09:28:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsyrbnWJTCKxwbQusWWe0SRoRHqP7j069KYNRvsVPL6Zzg@mail.gmail.com> <DU2PR03MB8021FFDA47C7B5A659E39ABEFAC12@DU2PR03MB8021.eurprd03.prod.outlook.com> <CALx6S35s08-L-CnPxY8LSLaRib+=g8X8=vJaKDEDXC+TMFJwzA@mail.gmail.com>
In-Reply-To: <CALx6S35s08-L-CnPxY8LSLaRib+=g8X8=vJaKDEDXC+TMFJwzA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 13 Jun 2024 18:28:37 +0200
Message-ID: <CAOj+MMFbgUeEvqEjYKu=kJcXcc+-O09JXHCA2ozz7R+BOd7Rqw@mail.gmail.com>
To: Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000594b89061ac7fe41"
Message-ID-Hash: EXOLMLI5AKP5OS6DRNRKMM7KV3KJ5IPK
X-Message-ID-Hash: EXOLMLI5AKP5OS6DRNRKMM7KV3KJ5IPK
X-MailFrom: robert@raszuk.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>, 6man <ipv6@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/4mut4sfitey5bu59JNk0VFr_qmw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

All,

As far as I recall during IPv6 discussions a notion of end-to-end principle
of Internet design was treated as paramount. Number of decisions made in
shaping IPv6 encoding were derived from this.

One of those is checksum which has been removed from the IP header and
shifted to higher layers (TCP or UDP or UDP-light etc ...).

That means that no transit node (ie the node which is not the ultimate
destination of the transport and above layers) have the right to validate
any IPv6 checksum. If it is being done that is a spec violation and they
should do it at their own risk.

So with that *"the time has come to say"* that this discussion which aims
to simply block the subject draft which many customers do use today for
various real network applications should just end.

Regards,
Robert

v2.27.6 | Report a Bug | By Email | System Status