[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)
Gyan Mishra <hayabusagsm@gmail.com> Fri, 14 June 2024 05:53 UTC
Return-Path: <hayabusagsm@gmail.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 6AB5DC15108E; Thu, 13 Jun 2024 22:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 L7_7rCiIJjKd; Thu, 13 Jun 2024 22:53:34 -0700 (PDT)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 5557CC14F704; Thu, 13 Jun 2024 22:53:34 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-70435f4c330so1403742b3a.1; Thu, 13 Jun 2024 22:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718344413; x=1718949213; 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=G18R79ECC7GeFiAZsj8+vOzKRT+/C8CwbO31s1E07m4=; b=GJGeZ/XFU7oIrmqOMyvOxeWlaMFSt1u7aGDynO0KxWoWxlqTifwvylmm/I6Z6EyML1 yEIw7NMTj1nL29SL/LyEcpwXShv7jtMXmrPqlGucuXhmZWrpdanK9m97TH4AZV05Y9iW TyvbAZkJ7BBVR31EiyxHvUSQ79PV/ZOkyUvMhAEDzElpuRESjfd6kM6ERZv+DI8+XmK0 JL9mcOsD4DPsu+FYkPG3Ef9BqI+0fnMTBhjxcVQPiezoz6F4Wi11tfsG/t7kO7wyhLsw SwTL/UXP9lt+McgN9Pb+cS0oakjDuxdOke8naEPbzsjJNdlgBWcIP6rlpOuthqRsFxRz y6Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718344413; x=1718949213; 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=G18R79ECC7GeFiAZsj8+vOzKRT+/C8CwbO31s1E07m4=; b=ZUL528PKXQH4/5qo6NhLsEL6E33tmfuTWpAWbGuJ5cPbuaCRJxNHYR2jZZ0RqCx+n0 kpa94KJ3hjhvwVl5TcyxnhANqllydEU9t2iU8q2Qj94jtK6lAbOi2SS9NkaQmG8EaOgj x3KRBbt8SjBEr9WSNfJ+JoPq50EmHv9m+BCVvvoHFn8hUYR7QoaPhVPBdJ0I8h/pDkH2 yIvhUHPDgXIQUUAhlEdfRglEI4zYTHlfISRNuds+G9U1gFYNLfV9LxKT7CbNj0j9o6Wb cg1+1QMle7IPRaeZvORx6jcY2tDjiOuPdRaHZLUwxpJmh5ZgoqaiAVpgmc54sQBBA+pV rygQ==
X-Forwarded-Encrypted: i=1; AJvYcCUoEqL5gdFg61eMWl396wVsJVpyWIeygcsx3EUPr3ffPKrEqZ2EkuibUF8pLcKn7NmB+KS13YNj11VLZFfH8zBjmUJ2L8mLq6rC3aHxYjPxovHaM3GJ6VDeNuDR8XPPX6Ni7CKiXGIyFR4wNlWMa8pYy9B1Ik8TH1g0Mu2CTTRGemKnPZZl9YivQ4i6nWTNsGKB
X-Gm-Message-State: AOJu0YyiwS5GcMrQAZp89IKfdpfqIBWJLmy+R4FrbXfDGYEEv69KdTB2 nDjB1doskFeS4xska+f0llzb0yROB7O4fRAywpud1LDgJWTQvEerfrrudyqYZkFXmoSPj8gATey 8ikP7gNCRbmxwCZseUaAyi0XsQ8g=
X-Google-Smtp-Source: AGHT+IEtZpOiD286IpYnzfWvFR2oA5Cq/eaehIjEds8qSukDinuhMFT9KYfmPloE2nGH1Ku/bvkFRrqGRizsHolJTp0=
X-Received: by 2002:a05:6a21:1788:b0:1b8:6383:dee9 with SMTP id adf61e73a8af0-1bae82156ccmr2112207637.47.1718344413297; Thu, 13 Jun 2024 22:53:33 -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> <CALx6S35fQKHKGRbB_myYJCjv3Pc_yjYh4axQLtSRzvE6me+oBA@mail.gmail.com> <CABNhwV1WrYiJ4rBwVG_A3BO+zKbC3BgeuJYPNNJi5JgX0a0kYA@mail.gmail.com>
In-Reply-To: <CABNhwV1WrYiJ4rBwVG_A3BO+zKbC3BgeuJYPNNJi5JgX0a0kYA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 14 Jun 2024 01:53:22 -0400
Message-ID: <CABNhwV1jGs6BQhkrRM8u-bZMh4k5eMqyKXXY05KVCf9wKwjhCg@mail.gmail.com>
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005b4448061ad33ca6"
Message-ID-Hash: THME4VYAU6YKLXOELPTV3GAVDYGAANFI
X-Message-ID-Hash: THME4VYAU6YKLXOELPTV3GAVDYGAANFI
X-MailFrom: hayabusagsm@gmail.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: 6man <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, Robert Raszuk <robert@raszuk.net>, SPRING WG List <spring@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@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/Eoe9xW5Zy1GeSv4qPqMyVU0zA4E>
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>
Along the same though process of a middle box server that is a session endpoint performing L4 checksum. So the middle box would have to be final destination if it’s session endpoint and then in that case the L4 checksum would succeed. So then I don’t see any issue with the middle boxes. On Fri, Jun 14, 2024 at 1:29 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > Hi Tom / All > > AFAIK what Robert is trying to say is that compare to IPv4, the IPv6 > header does not have a checksum field. The designers of IPv6 believed > that the link layer checksumming provided by protocols like PPP and > Ethernet, combined with checksums in upper layer protocols like TCP and > UDP, would be enough. They also wanted to make the header more efficient > and easier to process by removing the CRC check > > So that being said the L4 upper layer protocols TCP, UDP would perform the > checksum which would be done by the session endpoints as Robert pointed > out. > > Another point is that all customer traffic TCP, UDP endpoint flows would > be IPv6 encapsulated in the payload which would be unfettered and untouched > and thus the session endpoint would be perform the L4 checksum would > succeed. > > SRv6 would be deployed in a single administrative domain which could be > many domains or sub domains within a single administrative control. In > that case the operator would take precaution's per the draft as to middle > boxes being deployed in an SRv6 domain to avoid any L4 checksum issues or > upgrade as necessary to avoid any issues. The rarity of this issue is that > not only would the operator have to deploy these middle boxes, but the > middle boxes as well would have to be session endpoints in the middle of > the SRv6 domain. Quite rare. I don’t see a use case where a network > appliance middle box would be a session endpoint. Even a sniffer middle box > would be just mirroring the flows but would not be terminating the > session. The only possible case I see is if a server was a middle box > siting as one of the transit nodes as a session endpoint. In most operator > networks the underlay transport network P nodes are kept ultra clean and > stable minimal changes as well kept clean of any devices that could > comprise the integrity of the underlay. That being said makes it even more > rare that an operator would put server or devices that could potentially be > harmful and impact stability of the SRv6 core transport. > > I don’t see why there would be a need to update RFC 8200 to account for > the highly remote possibility of middle boxes L4 checksum issue given that > it is within an operators domain whom has full control to easily avoid this > circumstance or situation ever occurring at all costs. > > Kind Regards > > Gyan > On Thu, Jun 13, 2024 at 1:29 PM Tom Herbert <tom= > 40herbertland.com@dmarc.ietf.org> wrote: > >> 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 >> >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: >> -------------------------------------------------------------------- >> >
- [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