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

"Overcash, Michael (CCI-Atlanta)" <michael.overcash@cox.com> Fri, 04 November 2022 18:09 UTC

Return-Path: <michael.overcash@cox.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 0B467C14CE43 for <softwires@ietfa.amsl.com>; Fri, 4 Nov 2022 11:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=cox.com header.b=hQhEn2DB; dkim=pass (1024-bit key) header.d=cox.com header.b=eRWz+rdX
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 U3zG4_B49gi3 for <softwires@ietfa.amsl.com>; Fri, 4 Nov 2022 11:09:53 -0700 (PDT)
Received: from mx0a-002b3901.pphosted.com (mx0a-002b3901.pphosted.com [148.163.151.18]) (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 828B4C159A1D for <softwires@ietf.org>; Fri, 4 Nov 2022 11:09:46 -0700 (PDT)
Received: from pps.filterd (m0121838.ppops.net [127.0.0.1]) by mx0a-002b3901.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2A4GPSLX024606; Fri, 4 Nov 2022 14:09:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cox.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=DKIM1; bh=3Ytf/R61zMVacwg7ugzF3OQPQgdjeNX8Xoy7M9i+1yo=; b=hQhEn2DB9sGtVH1JkLPYOwgaorY0wSZSuOyv0BM3v/N/ckR1tj/P0w7Nt67LtZKUy1/N Oko5DUQjn8cS/SdMCu0kv04BiFzlVtB40C0BQYxdWlg7o9jTUN3mx2GqHBiSvLXq3g1p nfdXiet5gTvz4KazoOV4ZwLW0Mt1XpcqH8Srnq9W+QBxYFqosetzj580e8bAULAF5Xp3 WHKZpfBjWB0C5ibapJP1EYXqz6qqLhyVe/mfULQ6ICYzrT6ND4agL7OztemFyyJbYMZR pBQN6gl3Nw1AabJtsyTKDoaOd6KE0YR4QoEItMUXDiHuD4iiI2ilx88uHR/mEYgjPxCu Og==
Received: from nam11-dm6-obe.outbound.protection.outlook.com ([24.248.74.108]) by mx0a-002b3901.pphosted.com (PPS) with ESMTPS id 3kmpghug44-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 04 Nov 2022 14:09:20 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JlOZCOsz7kgsyZarI3TYqsSw1ZxmE9Aw+xS+SCSH5IeBJQ7+nRn9bKcjYiVltEEugsycNK/tPZOlKnjP/Vl0zPJsT+zkAbw7mzfZr2tmbSQPeoWIUaFSzaMWfwP1aeLWLYns+/jAcAk369c3csjbH2/ck7Ray1hYcPrCT8kFFxEjJYYep7poft1G+Y6zRr+0O+1t1lotu5w78JkVqz9K5HAB9MUa6OH1KIMfn2+wFjb+pWxEZzBS4UW+xrsCWirScZBMC+fKgtPI2vmdZirBjwque0QMVHQjuAX/lCVwgzAvPWV/ezPzFq+Z+yDTHr3A+oHMqBnHWNYRvIEFqf/JIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3Ytf/R61zMVacwg7ugzF3OQPQgdjeNX8Xoy7M9i+1yo=; b=iiDFsx6xETiaBilI4C1xU73Azd/ckMW/FirumA8MClpgMPEPyTHR6LSJneVfG/q7yRg2e/6TEGT1DDh+KUUYHb8KhI7zFimFnZKl7ioUBRmhchcQsGotJAoYpOvLyAlp4FE3voHf50XcGjeFAXL5nmiEtKxB+zM2vU12cF/vlQXIv/1Ilg1/F4Tg6GqbNsAZMVDXCdOu2uLzKhltEnWEuM6+PEoo7YZwUPL5f5k1B5HXji19e99NAiE3xLYkx0Ezcmgx49BWD+vZ1WZBao+ZHL2BcFe2ZAXD4yfAy6pIe7nNSQTpSg86luBwDjGohhrGKtBQabP6N+6vexxFc1G4Lw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cox.com; dmarc=pass action=none header.from=cox.com; dkim=pass header.d=cox.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3Ytf/R61zMVacwg7ugzF3OQPQgdjeNX8Xoy7M9i+1yo=; b=eRWz+rdXhHWDeq59/jsAAAkDmhLYUl2VZ1UU/KnKcPzsq2yp5uzKps/5MjgNVIAsNbcxSZEmSslj4DDFlZmkRARxJg2f6A1Orp7qT5KOexWEGL7HsS4NDPiV72sViXXSE98HYnAJ8/m6CIxGzx1RARttcPafxREeFQ9/gd4PUSY=
Received: from BN0PR01MB6845.prod.exchangelabs.com (2603:10b6:408:14a::18) by SA1PR01MB6575.prod.exchangelabs.com (2603:10b6:806:18a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.22; Fri, 4 Nov 2022 18:09:17 +0000
Received: from BN0PR01MB6845.prod.exchangelabs.com ([fe80::eafc:ae32:cc89:dca7]) by BN0PR01MB6845.prod.exchangelabs.com ([fe80::eafc:ae32:cc89:dca7%3]) with mapi id 15.20.5791.022; Fri, 4 Nov 2022 18:09:17 +0000
From: "Overcash, Michael (CCI-Atlanta)" <michael.overcash@cox.com>
To: "Gottlieb, Jordan J" <Jordan.Gottlieb@charter.com>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "Poscic, Kristian (Nokia - US)" <kristian.poscic@nokia.com>
CC: "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: [Softwires] MAP-T issue - UDP packets with zero checksum
Thread-Index: AdjwUUmY0/et/yqoSIW1ZoK7abCNIwAFSeXgAACacrAAASIHjwABARqAAAGxtOA=
Date: Fri, 04 Nov 2022 18:09:17 +0000
Message-ID: <BN0PR01MB6845B86947CE0F194C36FD7E9F3B9@BN0PR01MB6845.prod.exchangelabs.com>
References: <BN0PR01MB6845514B7AA311E72CF066DD9F3B9@BN0PR01MB6845.prod.exchangelabs.com> <e574a7b999c246ea9391dc6399213c56@ncemexgp037.CORP.CHARTERCOM.com> <SA2PR08MB6521E712618525A7A703E846ED3B9@SA2PR08MB6521.namprd08.prod.outlook.com> <A682B9A1-2C05-4091-8D48-DF57C7EE5F79@cisco.com> <d71bdf57379b4d8f9715c91e24a8930b@ncemexgp037.CORP.CHARTERCOM.com>
In-Reply-To: <d71bdf57379b4d8f9715c91e24a8930b@ncemexgp037.CORP.CHARTERCOM.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0PR01MB6845:EE_|SA1PR01MB6575:EE_
x-ms-office365-filtering-correlation-id: 2f6e12f9-2e08-4d72-1b0f-08dabe8fb052
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5/KmT4x6+Fw2YJeZblK53SNyATKeJua3g9pptVH491Xf/l9qn5baBY3LUAl8c8MGZdKtOLOYxSMmA2BVQzW+rQPAMEdRulNwDfEV0VZ/8bv5L76aaf+2fkkwHeZC5aqSevaJvy6f3Pa+i7rum+XQGFfdqJU50qMK8YZlREw8RicO8mESkWhr5kTl67aitnj6orMOaGgHl3e75F0ZHGVJyyn47uSsyTVdV78yu5zbhWoyfY381P/l7LjEvhMil8P3dZybqhsAQq3qR20eswVXYwiD/SDFzCxOmx+9g26d8u1xnWCDX0nHghRitbAMN8POCFIchrC5Yx7d0v4jtFgY6Rvja7IPwHBX3E+ucsAio9xGwcpl52m+U/M/jSffy/MzJsq0KRg2EBHeHXtv8UWdlFu61jNyZC14K0PDP+D4BPX+ookN58e8n8OHRyMsR11w+reCTiaSwgD+yIAGmbXa+pyiMhfChbBGXizbzbLwyGBblUtchDc28m/rors1EMmxSFQE7YXPCDhgmY5wrEZ6ytDOwnLcQTKPRkeR5GDG4J2T3T8bULM95v/6uc1FfzM68W3tnWFlyJGZZ7g25c4MIIze7sV4ZoJu5sh7MMMI4Fv/YyUwJ5sb4Nmtax/fDuTSeb/Wm9DINNlw536lmRImYn+0lHobC2i9vMkC3WyCTr9/doIRMoIX1B30u1d6waGGEPOFpLHtiimnU56WDWj85NUWuqiNeEZTLVOeQj5GP/TX2Z2RkzdLVZzo0yw6p/C5phDns7tp92Wy+Wqc42mmG+fPlhXhzA3PtAFDsF/v9I8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0PR01MB6845.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(39860400002)(136003)(366004)(346002)(396003)(451199015)(71200400001)(478600001)(55016003)(52536014)(5660300002)(2906002)(110136005)(316002)(41300700001)(8936002)(76116006)(64756008)(66446008)(4326008)(66556008)(40140700001)(66946007)(66476007)(166002)(38070700005)(99936003)(82960400001)(122000001)(38100700002)(7696005)(966005)(86362001)(186003)(6506007)(53546011)(9686003)(8676002)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: I03P3UhMXIIa55gIfgZ5jJNrQZr0pUyS61Q3g0mzgQWd/LDCmjcSHFlcIERzcAsYEmrnQfQ7ukS2VmAAOPdUiEdHBdMZ/hp55Pk/r1RPMMle2ySeE03FAkddi6LJXF3IsCr8RnOut3EpWCYIo2NNmxXAourpH0GspO3luf0POBu+P7yVyMc3nlv45OpA5xehWs1z0dcNdmC/bx/tBCDJVWyPvtLhtyoPR1ibIhgCZ2Sogxp8TZbbNe0DnfoMOojtzNMOUAq4eLaYXBeg6WUqxuHkxAx8O4bqmpR6wgFZTO/7lDwbMpjKcF/bb2Pfd7rSUoa5sKoPDndovIdqcaQ/du/G7nE/spm6BxPfbvuDjrpOwxOZKByFXgdWA0MWEQkJRRqniYFrOzC5sMWlzA4JxERhS4604l2J1VB/ams5K5eiHf+Si+iWKBoxq/X8R724NPlQFM7bB78d6IYuWNchwmXUBaur8JBKHi81TswU0mzoWDYonkhVrxyL5umrNkPBlJRHWaNMzbl26iGdUaoadEaW3ZvBfrHNcMbPuM6IzPCR/b82KcWXzGQ4h/BSsb7jRsGgz40TImbc8l/MHGBuQuNPQD9MsRqyh2btsCTstyrnTFT3Zh42ra/2wf5HbtgXtYcW50r/F3aP2s9JYq221vmY3ulzsFLvrXVowJxjsEY6lzUopy5NJvAh64+Bitq0y1FJT2Kt31Nz1Y5wYLf+wRKjF8EzqybsPu71QneMPn9Pde+UqiqC5IKK2Y7YomJ+YgBoyeidyzdGHwR1SMjaYkg7golWljOTTZwR9AOfLDnbkTutqqUOzdKlr/cvjC+ATY84s+CT5D6Sm7SCJPdCh9jhLYDTY8yVs3yIWEvbNdLo6GEyK6e3Cf990zmrv0raacGROgh4SNItcpurntRT3W1o7LXM1k7Ir5MUIhJD/C+pplzKCnEdHJy7w04J1hHL4X8GD/30YUtCTxjJP6h0dUj43Wy5RRmZOfk4BA4KlMXFzys6qsgbmFkNOomHc4mmH9Q/cCa+QCFA+sGqzM6haQ6szCcSkoMq+ARzZCVWuDfB34wzZR6t2tzI7qfws4f09+L8sh/e9D9PPgfsOK3IHFmbSBndragtDMLVwZEKi7Zm3yZvSwf+AuPJhaYIIK2G1NDSEVsee+pMudQZ7ehpB9ToG6D7HE4cpPox8rsdXdOX5tO3eaBEXWdo13NxDdvZjptZzmE9pkkxGVyK0SN/3rmpWGQy/l7hecnYI8OZGVmV51NVqiT8xVoO02eVHDkgMmLvb+ikPhxajebwnQbR2cMzbDWb54vbszNZTPZwGlyQF8ysVjH/WHdPuVqoAkLy41E2kW9TLbAuhbLCnHx2J0Z53f66JGQm5U/piTx0yeFPbc3Qh/qXlR4DyqFyYiuurcAEROrU9LQyrcgsCNO/u00onNySyYbQeje7AfndCS/nrdXJXO/VgpAqCeCLQ3UPVHQBtu9QToyMrOMJL5wliWP/3/SDrDQczQWrTAQLslB+gINPwVTslll0aRhgbph3+4bVqCb/K/olPO6JSMyOihTQ6b/FxqplJ6E94H+bll0PstdzXNqBbhdgDGsYxrWmsntA9X/7UCCzSrdsmr77cMaeEVxAMww0IzekkH2wEfQqDdkCb2jAwZ6f5jaZPJ9vKBae37pWoR9PxhKWOgzDSA==
Content-Type: multipart/related; boundary="_004_BN0PR01MB6845B86947CE0F194C36FD7E9F3B9BN0PR01MB6845prod_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: cox.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR01MB6845.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f6e12f9-2e08-4d72-1b0f-08dabe8fb052
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2022 18:09:17.3961 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9feebc97-ff04-42c9-a152-767073872118
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QwLbTJKilzpM/TQNDWerT2PwaMUCCbKVMGWjuH5t4mBuPnEVTq13HdUwKpT1Ku2U/88aGN2UQYrkRKhPIAuC+7O3Ri2lpHy8aN9DGK/ZX4I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR01MB6575
X-Proofpoint-GUID: XGu6kciG_Ep6avjmgq7QGzidNoXW2C-C
X-Proofpoint-ORIG-GUID: XGu6kciG_Ep6avjmgq7QGzidNoXW2C-C
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-04_11,2022-11-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 spamscore=0 malwarescore=0 suspectscore=0 phishscore=0 mlxlogscore=999 clxscore=1011 adultscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211040114
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/1LiJQvF-_ZulQ_oEmzmcz0MYcRo>
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 18:09:58 -0000

@Ravij: correct, I am suggesting that the CE and BR MUST forward datagrams with zero checksum. The end-to-end goal is that if IPv4 zero-checksum datagrams go in one end, they pop out as zero-checksum datagrams on the other end.

@Jordan: I’m not sure I quite follow your concern… did I just address it?

Michael Overcash
Principal Architect, Premises Technology
C 678.637.5649

[cid:image001.png@01D8F057.05B48FD0]

From: Gottlieb, Jordan J <Jordan.Gottlieb@charter.com>
Sent: Friday, November 4, 2022 1:30 PM
To: Rajiv Asati (rajiva) <rajiva@cisco.com>; Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com>
Cc: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com>; softwires@ietf.org
Subject: [EXTERNAL] RE: [Softwires] MAP-T issue - UDP packets with zero checksum

I think this is going to be very implementation specific and I am in the option that changing to a MUST is too constraining.  This is especially true when considering the CE case as stated at the start of the thread.  Think QUIC to IPv4-Mapped IPv6 addressed CDN.  Even in the BR case (though I do not apply it) I think it is not wise to employ this constraint as there are some possible use cases where this would be impactful.

-Jordan

From: Rajiv Asati (rajiva) <rajiva@cisco.com<mailto:rajiva@cisco.com>>
Sent: Friday, November 4, 2022 10:49 AM
To: Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com<mailto:kristian.poscic@nokia.com>>
Cc: Gottlieb, Jordan J <Jordan.Gottlieb@charter.com<mailto:Jordan.Gottlieb@charter.com>>; Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>; softwires@ietf.org<mailto:softwires@ietf.org>
Subject: [EXTERNAL] Re: [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.

Jordan’s distinction about tunneling vs translation is key here given the considerations for the normative language.

Mike’s suggestion is not that BR should calculate checksum, rather that BR should forward packets with UDP checksum being 0. Is that right, Mike? If so, then it is reasonable.

Cheers,
Rajiv Asati
VP.CTO, Cisco

“Focus on what we can do with what we have, not the other way around.”


On Nov 4, 2022, at 9:19 AM, Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com<mailto:kristian.poscic@nokia.com>> wrote:

I agree with Jordan, that it should NOT be made a MUST.
In the extreme, someone can use this as attack so that BR does nothing but recalculates checksums.
Kris

From: Softwires <softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>> On Behalf Of Gottlieb, Jordan J
Sent: Friday, November 4, 2022 11:12 AM
To: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>; softwires@ietf.org<mailto:softwires@ietf.org>
Subject: Re: [Softwires] MAP-T issue - UDP packets with zero checksum

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<mailto:softwires-bounces@ietf.org>> On Behalf Of Overcash, Michael (CCI-Atlanta)
Sent: Friday, November 4, 2022 7:44 AM
To: softwires@ietf.org<mailto: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

<image001.png>

_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/softwires__;!!Hit2Ag!wjS6zL7RadF7fHzUCc7H03UenqQsbxtrrJW3EHisODDmXva_L7ZNT4ZqehJVlqqKP_YJY06jSCVqEd_c7WdlXUw1jtsvO8E$>