IETF Logo Mail Archive

Re: [Softwires] MAP-T issue - UDP packets with zero checksum

"Gottlieb, Jordan J" <Jordan.Gottlieb@charter.com> Fri, 04 November 2022 16:12 UTC

Return-Path: <Jordan.Gottlieb@charter.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D70C152561 for <softwires@ietfa.amsl.com>; Fri, 4 Nov 2022 09:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=charter.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 MTTxN0xyB-30 for <softwires@ietfa.amsl.com>; Fri, 4 Nov 2022 09:11:59 -0700 (PDT)
Received: from mail.chartercom.com (nce.mail.chartercom.com [142.136.234.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136A9C15271F for <softwires@ietf.org>; Fri, 4 Nov 2022 09:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=charter.com; i=@charter.com; q=dns/txt; s=1; t=1667578319; x=1699114319; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=S1H5t5GHUC2ZdTU7iWvZ/wPqG/ouYSDRv78J1Eu+DQY=; b=V1fZVsTZ9pecKCa+KlGOdM57gGFODxk8H0wm+SfSHWrVR3oMtk/T4Gw7 of7W/Cs+ysPMLc3wonAyDZ5QayAcnD46Y0DqBxOfPtQw/OQPgeQdqZggL vagcJ1qaKtAIfFLwg0SmWgjACCwsahkbGs29tW8kTq6pxFBPpluKPlqfq tlcAdMbPETA6nYApLdvrvp9tCsa5uRETA0n97pD4Alx2td+JpBrZ7rfdb 65PcnAlPO14GNzvq3Kz0+SAtThYNrC5GAljwU6y31DTQTUwIxOdKzAurS 0HIjECXfiH8HHFBKadCYeLkulih761om+L9wWGPuXys0+jYQ2fSPCOS6a g==;
X-Ironport-Dmarc-Check-Result: validskip
IronPort-SDR: 83OZlHV6cSLkmk50FjLdDqCQuhJt0u6shtMj9mTrYfYJYONkg+xsMAVaZ/E6RgpvyILJFfr6T1 GcqpF48n+pyw==
X-IronPort-AV: E=Sophos;i="5.96,137,1665464400"; d="png'150?scan'150,208,217,150";a="260608000"
Received: from ncemexgp041.corp.chartercom.com ([142.136.234.56]) by mail.chartercom.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 04 Nov 2022 11:11:57 -0500
Received: from ncemexgp037.CORP.CHARTERCOM.COM (2002:8e88:ea34::8e88:ea34) by ncemexgp041.CORP.CHARTERCOM.com (2002:8e88:ea38::8e88:ea38) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Fri, 4 Nov 2022 16:11:56 +0000
Received: from ncemexgp037.CORP.CHARTERCOM.COM ([fe80::39af:a3ee:abce:8b46]) by ncemexgp037.CORP.CHARTERCOM.com ([fe80::39af:a3ee:abce:8b46%20]) with mapi id 15.00.1497.036; Fri, 4 Nov 2022 16:11:56 +0000
From: "Gottlieb, Jordan J" <Jordan.Gottlieb@charter.com>
To: "Overcash, Michael (CCI-Atlanta)" <michael.overcash@cox.com>, "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: MAP-T issue - UDP packets with zero checksum
Thread-Index: AdjwUUmY0/et/yqoSIW1ZoK7abCNIwAFSeXg
Date: Fri, 04 Nov 2022 16:11:56 +0000
Message-ID: <e574a7b999c246ea9391dc6399213c56@ncemexgp037.CORP.CHARTERCOM.com>
References: <BN0PR01MB6845514B7AA311E72CF066DD9F3B9@BN0PR01MB6845.prod.exchangelabs.com>
In-Reply-To: <BN0PR01MB6845514B7AA311E72CF066DD9F3B9@BN0PR01MB6845.prod.exchangelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [142.136.235.122]
Content-Type: multipart/related; boundary="_004_e574a7b999c246ea9391dc6399213c56ncemexgp037CORPCHARTERC_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/IxCOsCH9iX8rGOqyOpnF_LVb7Hc>
Subject: Re: [Softwires] MAP-T issue - UDP packets with zero checksum
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2022 16:12:03 -0000

Hi all,

I just to highlight that RFC6145 (a normative reference to RFC7599) which is obsoleted by RFC7915 covers this in detail.  They very appropriately have assigned a SHOULD on the calculation function of zero checksum IPv4 traffic.   I also want to point out that rfc6936 addresses tunneling protocol rather than a header translation based softwire and therefore should not be included as any kind of reference to RFC7599.

I am very much opposed to making it a MUST as it has significant performance implications on the BR.  It makes more sense on the CE for outgoing traffic as it has significant implications for IPv4-mapped IPv6 address traffic.

Sincerely,

Jordan

From: Softwires <softwires-bounces@ietf.org> On Behalf Of Overcash, Michael (CCI-Atlanta)
Sent: Friday, November 4, 2022 7:44 AM
To: softwires@ietf.org
Subject: [EXTERNAL] [Softwires] MAP-T issue - UDP packets with zero checksum

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
Hi,

IPv4 packets are allowed to have a zero checksum, but IPv6 packets are not. The problem of tunnelling zero checksum IPv4 packets through IPv6 tunnels is described in RFC 6935.

Currently RFC 7599 doesn't address this issue, and as a result we've found that some existing BR and CE implementations don't handle zero checksum UDP IPv4 packets correctly.

I think it would be helpful to add RFC 6935 as a normative reference and add a new section 8.5 to discuss the issue. Something like the following would help:
8.5. UDP Checksum Considerations
IPv4 UDP packets arriving at the BR or CE are can have a checksum value of zero, indicating no checksum was calculated. Historically, a zero checksum value is not
permitted in IPv6 UDP datagrams, and some implementations will discard these packets. The MAP-T CE and BR MUST translate and forward zero checksum UDP
datagrams in both the IPv4 and IPv6 domains as described in [RFC6935].

The text above could use some wordsmithing, but hopefully you get the idea.

Michael Overcash
Principal Architect, Premises Technology
C 678.637.5649

[cid:image002.png@01D8F035.07EEC0D0]

v2.23.0 | Report a Bug | By Email