[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)
Tom Herbert <tom@herbertland.com> Thu, 13 June 2024 17:28 UTC
Return-Path: <tom@herbertland.com>
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 22011C14F695 for <spring@ietfa.amsl.com>; Thu, 13 Jun 2024 10:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=herbertland.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 prlUwfXQpLoL for <spring@ietfa.amsl.com>; Thu, 13 Jun 2024 10:28:01 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 DB553C14F6E2 for <spring@ietf.org>; Thu, 13 Jun 2024 10:28:01 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-57c68c3f8adso1494860a12.1 for <spring@ietf.org>; Thu, 13 Jun 2024 10:28:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1718299680; x=1718904480; 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=gBNvJdDvxe0J0Mq3mtlTLZ6XO5HU9/TXEmzbs8GFbok=; b=OLK+ZQEIYYLrMo1079rKjEm/cvS+O3hhiIB0i5HZBJcRF2LVdGKpqHWlsVKWQwuGYG ojnmbalyPmKtx/GqUKiJqrNtXffm/+6r1411u6uNB+x23Av/mMQtnwVUp6KfTnCfP8gS g0rUZADPy1CHK+6hq/CO1BT5iM/vJRBivS/sP9IvafwRw3SFEapuGSfbS0nfK5SAYA/y iEIKfRES5R7XmkWTH8AIpOws0WF1rAhHhFFjR6ieF2hZqdOmcrEj8RHhLK3nHdYCaLUr VLds01Fm5dX7PCWL8c9vG64WSIwtBudZqiENMmVkZOEjagHx8D3eBNoXC93rwq/lOy27 q8qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718299680; x=1718904480; 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=gBNvJdDvxe0J0Mq3mtlTLZ6XO5HU9/TXEmzbs8GFbok=; b=gDIuwORaqqaSs3pQ+N8cAVNZcIJmtg30+OTEhkVYyQIqZuCCgtI/zjHEESfCQz52tf MgSjpfPx6rHGy8YmJDymjdQ1i/AM214gdFnJtFGMhgiGv1eN1FArLT+LATTYpVQj9ElF h084eXTBmfnRublSgMx1mfwKXX44UI6XbLubv+x/phpGrQamYyaMl+UfMYIiFu5C3tCZ X4YOPHWSwT0Qnn78GJLlwW35JQuKtE9DaXVGNmMUwQA1FAs5q/FQK+5HPw5AP+hykO06 D0Mnz5v7PoyV9vu+d6Tn2b67htRgkH4I6MWRpwk7V1T8gQ5gsYKuo61DU15CrZxfNlX3 87Yg==
X-Forwarded-Encrypted: i=1; AJvYcCWNrJOhA1QEGdHY9Kdzxh8aPVHUXME0z4VMPt/fGCNeHuGqIw5Py2H2lcEapv2tNWrKmSPRDFQp1bpIuKEtuuw=
X-Gm-Message-State: AOJu0YzdE31AIQxZlj0tIw5QO7DddHqyQq8CzwLW6KxyQ/mjP1XVS3nT vZMv7S42cmrjQjr24Uy/oOBBAxPymVrYuRB02PYD7FFIBcvyeh4yLeQ8m8nK03XdA8c4DsNN3DI 9aKUoe4Ivcyntcrw5EJpu2/qUdq+5ipioz3qn
X-Google-Smtp-Source: AGHT+IFp9oVbD57Xoe0feynheIHV58UAZx6DjgQJgOxAD8zoU2tLp5FG29/eQzdKJltJ+CcwyALdqOvG6QeOxnyqcko=
X-Received: by 2002:a50:d792:0:b0:578:6410:1d50 with SMTP id 4fb4d7f45d1cf-57cbd69e78amr355412a12.34.1718299679855; Thu, 13 Jun 2024 10:27:59 -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> <CAOj+MMGkRXZe9uVXabOtrz2tuXreWonbSdPne1Jwq81JUKXNEg@mail.gmail.com>
In-Reply-To: <CAOj+MMGkRXZe9uVXabOtrz2tuXreWonbSdPne1Jwq81JUKXNEg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 13 Jun 2024 10:27:49 -0700
Message-ID: <CALx6S35fQKHKGRbB_myYJCjv3Pc_yjYh4axQLtSRzvE6me+oBA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: KTX7JPZDF7QVJXZTFZBYMQ226CWTXOJD
X-Message-ID-Hash: KTX7JPZDF7QVJXZTFZBYMQ226CWTXOJD
X-MailFrom: tom@herbertland.com
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/_c0eIQczJlN24AJB5t_5AqNcvYg>
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>
On Thu, Jun 13, 2024 at 10:14 AM Robert Raszuk <robert@raszuk.net> wrote: > > 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. Robert, RFC1958 does not mention the checksum nor any normative protocol requirements. And if we're going to base the argument on principles, then I'll quote the robustness principle: "Be conservative in what you send". For the past thirty years the checksum has always been sent to be correct on the wire unless there's a routing header, so changing that behavior would be a violation of the robustness principle. Tom Tom > > 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