[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 17:15 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 A4363C1840CB for <spring@ietfa.amsl.com>; Thu, 13 Jun 2024 10:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_ZEN_BLOCKED_OPENDNS=0.001, 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 N-ZIZCTphYMb for <spring@ietfa.amsl.com>; Thu, 13 Jun 2024 10:15:00 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A7ECCC1CAE8A for <spring@ietf.org>; Thu, 13 Jun 2024 10:15:00 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2e724bc466fso14516671fa.3 for <spring@ietf.org>; Thu, 13 Jun 2024 10:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1718298899; x=1718903699; 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=lMeSJs8IZcE0uzzC4QvH2aLTyeoUDtZ3jSn/oMx4mqg=; b=AHmp4xeLQ0OXzdcIip5ODWXMlILzJTNHq73AXzViO1SJiomO7pWWdhxpyWdLoxDH4e 8t5N8tQ1Gq6kHfXyMZhcgpPOJWkqaj4RdP06qIk8JQicUc2hUpf3TtonCPvqIbyugG9P ySaIClaOvBi5cbgMN9WywEqKCOOsaVRj29+festsSoM/+nncdJb2DMrs9uX9D5LHUfwX mB6tM3slytWIGE6cHurCiqL60h3zSxIF25ahkQ4Yad+JybzlegVb8PgvCw8sNfjwvi/J KjjryBPTZC1lP2ZFHqpF9LoV6SgnefWWosO1FwOvlxaCzODyYfsKXGhHtG8MPPERcPmO Yv1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718298899; x=1718903699; 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=lMeSJs8IZcE0uzzC4QvH2aLTyeoUDtZ3jSn/oMx4mqg=; b=GzeD9hq8wmOK/lq9HI9/M0v2h+7tvdmh7JjwQuZYleolTp2N+veU3caK3jT+9VMSAo c8NPGS2iSMrgiwbJ9NUSs3tOxIdKjBqkxo6oP4p7FT7zgZ6GuMuq6Tw0+4nEDDTn8xrz EJFH5enJVCxOdNPajNcrnnCl4RSj82kscvJcHPgWNQnzwy1djclcaon3ttV4vRk4dTDl RKczIYLnQG39j3V6mPl0LxU6tty5GG+oQPJkRstNi9X/Rsd/vegbGYd9Y3OBlIqiSnHU Jks6bS+BxJptq06xshzpYMNTXOat/ICmu0bOl7CQEFlduJCIY4+vWEiFG9w2T6MUEEb5 hD/g==
X-Forwarded-Encrypted: i=1; AJvYcCU0R9JRkOjX5IU7jW+5/GtpxZfVyspeEq18gr48vPBuHI30DHxRfv5s9ZuYbRiErcR9DF/jr6aQawo5ZS14TGg=
X-Gm-Message-State: AOJu0Yy7E2FuyTtzLHx8Eqxh0vnKOJqykSa25yiZddacWiFaswttDY1w pS1fuCivcZTw1fnEvAz8k/pxBcqe5KH+SOHHAQz9AhG6JxuXIDZCC1EtdZx5AjLfqbrkQkooEE/ 2oJf5CIlWUMdOHdqDXgrcoi+O3acPvy/084dktQ==
X-Google-Smtp-Source: AGHT+IE49Rufiz5JbNMC4SoYTuHUqeI57+jE53xQgjoCv1atYKIR7Cj2+DjZWnPdLKer6oMH/JoXbD95iaPm12gcMX0=
X-Received: by 2002:a2e:854a:0:b0:2eb:eed1:965d with SMTP id 38308e7fff4ca-2ec0e5c6c19mr3201901fa.21.1718298898819; Thu, 13 Jun 2024 10:14:58 -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> <CAOj+MMFbgUeEvqEjYKu=kJcXcc+-O09JXHCA2ozz7R+BOd7Rqw@mail.gmail.com> <CALx6S342t1XKvCTX0Zgj5Quew7MVtOH0wNoew_mYb0QUTZ3JOQ@mail.gmail.com>
In-Reply-To: <CALx6S342t1XKvCTX0Zgj5Quew7MVtOH0wNoew_mYb0QUTZ3JOQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 13 Jun 2024 19:14:47 +0200
Message-ID: <CAOj+MMGkRXZe9uVXabOtrz2tuXreWonbSdPne1Jwq81JUKXNEg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Content-Type: multipart/alternative; boundary="0000000000007b90f3061ac8a3bc"
Message-ID-Hash: EFPDX4CSKFAVAPU5HBVM7TWKANNSYMLK
X-Message-ID-Hash: EFPDX4CSKFAVAPU5HBVM7TWKANNSYMLK
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: Andrew Alston - IETF <andrew-ietf@liquid.tech>, SPRING WG List <spring@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/L7VQFLx3u83skAtqi-GDua8ucfM>
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>
Tom, For starter let's take a look at RFC1958 .. Entire document is pretty good including statements like this: *The basic argument is that, as a first principle, certain required end-to-end functions can only be performed correctly by the end-systems themselves.* Thx, R. On Thu, Jun 13, 2024 at 6:54 PM Tom Herbert <tom@herbertland.com> wrote: > On Thu, Jun 13, 2024 at 9:28 AM Robert Raszuk <robert@raszuk.net> wrote: > > > > 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. > > Robert, > > Please cite the RFC that expressly forbids an intermediate node from > validating the transport layer checksum for operational or debugging > purposes > > Tom > > > > > 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 > > >
- [spring] C-SIDs and Upper-Layer Checksums (draft-… Alvaro Retana
- [spring] Re: [IPv6]C-SIDs and Upper-Layer Checksu… Cheng Li
- [spring] Re: [IPv6]C-SIDs and Upper-Layer Checksu… Tom Herbert
- [spring] Re: [IPv6]C-SIDs and Upper-Layer Checksu… zhuyq-ietf2024@foxmail.com
- [spring] Re: [IPv6]C-SIDs and Upper-Layer Checksu… zhuyq-ietf2024@foxmail.com
- [spring] Re: [IPv6]C-SIDs and Upper-Layer Checksu… Andrew Alston - IETF
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Ted Hardie
- [spring] Re: [IPv6]C-SIDs and Upper-Layer Checksu… Sander Steffann
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Tom Herbert
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Robert Raszuk
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Tom Herbert
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Robert Raszuk
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Tom Herbert
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Gyan Mishra
- [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Che… Gyan Mishra