Re: [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)
Tom Herbert <tom@herbertland.com> Thu, 28 March 2024 14:29 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD93C151548 for <ipv6@ietfa.amsl.com>; Thu, 28 Mar 2024 07:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 DQxjPfLsLJku for <ipv6@ietfa.amsl.com>; Thu, 28 Mar 2024 07:29:41 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 1E893C151542 for <ipv6@ietf.org>; Thu, 28 Mar 2024 07:29:41 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a46ea03c2a5so198760666b.1 for <ipv6@ietf.org>; Thu, 28 Mar 2024 07:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1711636178; x=1712240978; 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=WRpiJUl1YaIi+Uet/Pb/eN8KRUhcWT/8/ZHz5LQ7nR0=; b=BMFaCvTe7O3Cww18Wt7R0qthr2teaZkuaYxgkX+FjKh9Atk+Xu97Tv8rIItULv9XAV R5dFwzbV/desYoH5DjkwRnS4SasnHocIUX/Ktk2RRLGWKWSz+mVO+MVjjaRZktxzNdm5 qTCGILpR6G5j1/Jdwqcks1OdHWR0B56RF15qXYUMZHFYvOuaupxmFzVfxTlfY8NrKkvy NP4ejqxtyJd0UhjD9b00ISWl33+xDM1Z03GC+qLFawSKNV3s9XwbDbt/8i4oWDHg8zaq hAmNOmm/cJMccadZ15+Z2NtyMHrKvP2BNChoBnhCI/P1p5skCfUDGMKb89ytiSSANieT vODw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711636178; x=1712240978; 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=WRpiJUl1YaIi+Uet/Pb/eN8KRUhcWT/8/ZHz5LQ7nR0=; b=KfeDc56tYCFfL72NlrWxOoM9KlnVAtbMFHqxs4ahAmVU5xr+fiIBPDNQhAT1gvjQdD KC7Vdi7OpNEDCL8AfsYs0lTGqwzkRjrTuCuTQIoqxfvopSHNJi19C1s+BXAl4h/ffu4/ ZITUUzUawVwXC7K9Fd+eg2Hkw+bVAVgyjRDsoYfqEPuW0JJQ1sVqUT3O3RQSzhmpe1E9 qu0A6GcdvkZQTksE2u6ELZsoKezDNQ7eXyDI1XD4R/Agh6Dh0h9s1Q97lmF03ZPfHLTH dsriyRy7Nhg3zr9fSf3xIzFoDbHfTF2O7YyFuR+QIjlVss0VJ+KhPBy4EpTLgr8uukMm B7zA==
X-Forwarded-Encrypted: i=1; AJvYcCXY51qzmtfzV0TQkcOtJvRx02f9ydmAgEhP2zFk/puf6MAdQbGQnhbdTYTvdTlE0OZ/eLTTz/MDmRTqs1Uw
X-Gm-Message-State: AOJu0Yw9DW073P9CzHevJGNxq9nm8L/FHWZL7RTTbSLGiiocyoz16+3L czH+T4WnkGc5wym41L8ZJaG+YhHcxTZ3ynLnFLs46IHeJsVjWsDfLFt5DlDJ7p+DBGWNU4KNMLm d3jB8+ISFYSUU3kLx9vhYGGq86fqAMgr3E5Q5
X-Google-Smtp-Source: AGHT+IHE6IVNcmYiXG/zZql360W42+uaaDX5crpa85RkVGFXNtewJRbsr7lqCAX5A0eNMTdlTTQxwGolhUmBktqLYTo=
X-Received: by 2002:a17:907:944c:b0:a4d:fe2f:a70e with SMTP id dl12-20020a170907944c00b00a4dfe2fa70emr2682029ejc.1.1711636178488; Thu, 28 Mar 2024 07:29:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESszUUdDw-xnDtZKqz75g6SXZ+7mXtZujBKwN+hxypC-Kuw@mail.gmail.com> <CAOj+MMFTpKdNtE2SGubsBKkwbgdX2G5qBxBCViCu-EFmUXjfHw@mail.gmail.com>
In-Reply-To: <CAOj+MMFTpKdNtE2SGubsBKkwbgdX2G5qBxBCViCu-EFmUXjfHw@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 28 Mar 2024 07:29:27 -0700
Message-ID: <CALx6S37CK69EU+59r_M8caO4MNRQFC8fgo4+VyTSgSE0aNTVTQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, SPRING WG List <spring@ietf.org>, 6man <ipv6@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RE6C_tsuB_ThLN_0remwK53LD6E>
Subject: Re: [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2024 14:29:45 -0000
On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk <robert@raszuk.net> wrote: > > Hi Alvaro, > > On this specific topic I think you have flatted it a bit too much. > > These are apparently the options on the table: > > A) Original packet get's encapsulated with IPv6 header > > A.1 SHR is added to it > > A.1.1. Regular SIDs are used > A.1.2 Compresses SIDs are used > > A.2 SRH is not added to it > > A.2.1. Regular SID is used as destination > A.2.2 Compresses SIDs are used in a container > A.2.3 Compresses SID is used > > B) Original packet get's send from SRv6 host (without encapsulation) > > B.1 SHR is added to it > > B.1.1. Regular SIDs are used > B.1.2 Compresses SIDs are used > > B.2 SRH is not added to it > > B.2.1. Regular SID is used as destination > B.2.2 Compresses SIDs are used in a container > B.2.3 Compresses SID is used > > So within all checksum related discussions so far it seems that the only concern is about B.2.2 and perhaps B.1 however folks did state that if there is SRH added there is no issue so I am not sure how the presence of SRH fixes it. > > Maybe there was some assumption that presence of SRH mandates encapsulation, but I do not believe this is the case for native SRv6 hosts. > > All in all I think it should be no business for transit nodes to verify packet's upper layer checksum. I do not know if there is any RFC which would describe what is an expected behavior for transit nodes or even say that they MAY do it. Robert, I can go further than that. I believe that intermediate nodes have no business parsing into the transport layer, and yet firewalls do that all the time even though there is no standard RFC on it (I've asked for someone to formalize the requirements of firewalls, but to no avail). Validating the checksum in flight is an instance of this, and there are devices that commonly do this in deployment. Protocol specific checksum offload in NICs is one example. Also, if someone is seeing checksum failures in their network, an obvious action is to sample packets from routers in the path and look at the traces. If the checksum is incorrect on the wire because of SRH then the operator sees a whole bunch of checksum errors at the router, but has no way to distinguish those packets that are actually good from those that are bad. It's a long established convention in IP that the transport checksum is maintained to be correct on the wire-- this is done in NAT by adjusting the checksum directly, there's also checksum neutral NAT that adjusts another part of the IPv6 header to keep the transport layer checksum correct. IMO, deviating from this convention is risky, not just to SRH packets but that can have collateral damage like breaking the user's ability to debug bad links as I described above. Tom > > Kind regards, > Robert > > > > On Thu, Mar 28, 2024 at 1:06 PM Alvaro Retana <aretana.ietf@gmail.com> wrote: >> >> Focusing on the C-SID draft, some have suggested requiring the >> presence of the SRH whenever C-SIDs are used. Please discuss whether >> that is the desired behavior (or not) -- please be specific when >> debating the benefits or consequences of either behavior. >> >> Please keep the related (but independent) discussion of requiring the >> SRH whenever SRv6 is used separate. This larger topic may impact >> several documents and is better handled in a different thread (with >> 6man and spring included). >> >> Thanks! >> >> Alvaro >> -- for spring-chairs >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- [IPv6] Subject: Mandating SRH when using C-SIDs (… Alvaro Retana
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- [IPv6] Requiring Tunneling - subject change Joel Halpern
- Re: [IPv6] Requiring Tunneling - subject change Martin Vigoureux (Nokia)
- Re: [IPv6] Requiring Tunneling - subject change Bob Hinden
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Requiring Tunneling - subject change Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Alvaro Retana
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Francois Clad
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Mark Smith
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Francois Clad
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Francois Clad
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Ole Troan
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Michael Richardson
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Cheng Li
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Ole Trøan
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Adrian Farrel
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Michael Richardson
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Suresh Krishnan
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Francois Clad
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Suresh Krishnan
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Michael Richardson
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tom Herbert
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Bob Hinden
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Tal Mizrahi
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Antoine FRESSANCOURT
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Tom Herbert
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Robert Raszuk
- Re: [IPv6] Subject: Mandating SRH when using C-SI… Ketan Talaulikar
- Re: [IPv6] [spring] Subject: Mandating SRH when u… Mark Smith