Re: [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)
Ole Trøan <otroan@employees.org> Thu, 04 April 2024 19:37 UTC
Return-Path: <otroan@employees.org>
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 D7251C14F70D; Thu, 4 Apr 2024 12:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 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, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
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 oaXEQbN0clJO; Thu, 4 Apr 2024 12:37:42 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B8BF9C14F6FA; Thu, 4 Apr 2024 12:37:42 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 30689E6672; Thu, 4 Apr 2024 19:37:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=Xnt7TBZb0+B/E+rQ 9XlX1SriImvfWRoUmYAFwXa4PsU=; b=Zl+8gMddhVQPTN4bLolQWPwmykASXWoW cnQBOj4fExHwVLT5TO1KUbq0/yd/qy6VH1eWWTGFIFF+Zftc8cgoF3uxMIF/sso+ +IN6/h+qXTFRqIo7A5sALcgi3kjLvccyeJScbP5juNW2HqHh+ojU6+fMHTSpnjJy V7uUYJJT6zlFFGVEZOE8QueWd1BPfpvSaXa8JO5sKcSqZvoGZAKpBizr5RMeJHf/ op0ld3YPAiplmCxNvWh4AE3DK3y6eChSJGNh78SI49W1Mi2xWgzzP31Qu56x7X87 NPEGh8Ttmyu8RZtANfxh0cwRVJWWQ6Ln5UyyMkDJWPRedcAa1nwlTA==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id 0087CE666D; Thu, 4 Apr 2024 19:37:35 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2001:4650:c3ed:37a:a855:7e61:a191:a620]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 8DB9F4E11AF9; Thu, 4 Apr 2024 19:37:34 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-C51B8ACD-4BD2-4F28-80D6-D4C150AB4578"
Content-Transfer-Encoding: 7bit
From: Ole Trøan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 04 Apr 2024 21:37:21 +0200
Message-Id: <3D87E6A7-2487-4E18-9553-008AE4DB37C1@employees.org>
References: <CALx6S34WAJxqZzcOVFUw4-L36kBJOx7rowcKbvzJLGUykTmzTg@mail.gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, spring-chairs@ietf.org, SPRING WG List <spring@ietf.org>, 6man <ipv6@ietf.org>
In-Reply-To: <CALx6S34WAJxqZzcOVFUw4-L36kBJOx7rowcKbvzJLGUykTmzTg@mail.gmail.com>
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rH1b8EU_FikFDxNNuJIHuGCTB08>
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, 04 Apr 2024 19:37:46 -0000
On 4 Apr 2024, at 21:22, Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> wrote:
--------------------------------------------------------------------Tom,> SR aware routers to update L4 checksumThat is completely unrealistic.Show me the box which can forward all interfaces at 800 Gb/s and read entire each packet and compute upper layer checksum on it.Robert,It's not necessary to calculate the whole checksum, only the L4 checksum needs to be updated by adding in the delta checksum. With IPv6 we can also do a checksum neutral mapping. Basically, this uses the low order 16 bits in the DA address as the checksum adjustment value. For instance, if we can use the low order bits in a SID block then that would be simplest to implement.TomIf anything just do encap and move on.Thx,
R.Hi Tom,Yes I am with you here.However let's observe that this is pretty common best practice to disable any hardware offload on the box when running tcpdump or wireshark.In fact some implementations (F5) do it for you automagically :)And as it has been said based on the fact that hardware offload does not understand any Routing Headers it really does not matter if it is there or not :)Robert,tcpdump is independent of hardware offload. If the checksum is incorrect per the packet contents we'll see bad checksums reported if we snoop packets, but like I said, we can't differentiate the bad from the good.Offload becomes an issue for NICs that do protocol specific checksum offload. We lose the capability on RX which is an inconvenience, on TX we'd need to change the implementation to ensure the checksum is not computed by HW.If SR without SRH is needed, then I believe the best answer is for SR aware routers to update L4 checksum when they change DA per NAT requirements. This solves tcpdump as well as offloads.TomCheers,R.--------------------------------------------------------------------Hi Tom,Tcpdump can determine that this packet is steered onto an SRv6 path by checking if the DA matches the SRv6 SID block.Francois,That would require introducing external state to tcpdump for correct operation. This would be a major divergence in both implementation and ops compared to how things work today.TomThanks,Francois
Hi Mark,Tcpdump/wireshark decodes the IPv6 header just fine. I do not see any issue here.Francois,The problem is that tcpdump can't tell that a packet is an SR packet if there's no SRH. For instance, if the checksum is not maintained to be correct in the wire then tcpdump will show that the packet has a bad L4 checksum, but there's no way to tell if that is an SR packet or if the checksum is actually bad. This will make debugging checksum failures in the network much more difficult, and this affects our ability to debug all traffic not just SR packets.Tom--------------------------------------------------------------------Cheers,Francois
Hi Alvaro, all,RFC 8754 allows the SR source node to omit the SRH when it contains redundant information with what is already carried in the base IPv6 header. Mandating its presence for C-SID does not resolve any problem because it will not provide any extra information to the nodes along the packet path.How are troubleshooting tools like 'tcpdump' going to know how to automatically decode these packets as SRv6 packets if there is no SRH?--------------------------------------------------------------------Specifically for the case of middleboxes attempting to verify the upper-layer checksum,
- An SRv6-unaware middlebox will not be able to verify the upper-layer checksum of SRv6 packets in flight, regardless of whether an SRH is present or not.
- An SRv6 and C-SID aware middlebox will be able to find the ultimate DA and verify the upper-layer checksum in flight, regardless of whether an SRH is present or not.
Furthermore, transit nodes (e.g., middleboxes) should not attempt to identify SRv6 traffic based on the presence of the SRH, because they will miss a significant portion of it: all the best-effort or Flex-Algo traffic steered with a single segment may not include an SRH, even without C-SID. Instead, RFC 8402, 8754, and 8986 define identification rules based on the SRv6 SID block.Thanks,Francois
[Moving this conversation up on your mailbox. :-) ][Thanks, Robert and Tom for your input!]We want to hear from more of you, including the authors. Even if you already expressed your opinion in a different thread, please chime in here.We will collect feedback until the end of this week.Thanks!Alvaro.On March 28, 2024 at 8:06:18 AM, 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" rel="noreferrer noreferrer noreferrer noreferrer noreferrer nofollow" target="_blank">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" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nofollow" target="_blank">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" rel="noreferrer noreferrer noreferrer noreferrer noreferrer nofollow" target="_blank">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" rel="noreferrer noreferrer noreferrer nofollow" target="_blank">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