Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

mohamed.boucadair@orange.com Tue, 02 April 2024 08:27 UTC

Return-Path: <mohamed.boucadair@orange.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 4395FC14F604 for <ipv6@ietfa.amsl.com>; Tue, 2 Apr 2024 01:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.794
X-Spam-Level:
X-Spam-Status: No, score=-2.794 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 hXh5mYELeffY for <ipv6@ietfa.amsl.com>; Tue, 2 Apr 2024 01:27:53 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.210.122]) (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 D7CD6C14F5E2 for <ipv6@ietf.org>; Tue, 2 Apr 2024 01:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1712046473; x=1743582473; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=L/vEWR/79jPs8T6Bj/OE0J1HhJeM0QIyeEjt/MdQW84=; b=fpWmcPJD2hHBu/om4YyXyUEVS6p2HTQEobvl2fc3lJgfiwJ50uhx+zyK AfX8O9LrKJcGfVrxvT+cBdEMs1L4sBRswsCWLUUySu48OaVkHUy3gVari jG9kk7VJ4ptlbYB1amAjIQ/Frzl5ivnUa/PJfS9rIP+aa134EJD5OqkLj H0FF3+FMq4wwJmN6s/aDHLYZ5Yos/bdRAYexCM7DgpkhnoWHPNzSvZX8b mmPf89sTBaUYTJnoegIo0ja/PIjrHW0KbtE3ss0rulVBMj0YsbD4aBI92 qfTV8X0/q7ZyObL/sgFhqQ7JKzMABGaACBuCvJdQLNdcn2FOW8b3tzmSn A==;
Received: from unknown (HELO opfedv1rlp0g.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2024 10:27:46 +0200
Received: from unknown (HELO opzinddimail3.si.francetelecom.fr) ([x.x.x.x]) by opfedv1rlp0g.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2024 10:27:45 +0200
Received: from opzinddimail3.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id 4A7F75202A55 for <ipv6@ietf.org>; Tue, 2 Apr 2024 10:27:45 +0200 (CEST)
Received: from opzinddimail3.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 440625201724 for <ipv6@ietf.org>; Tue, 2 Apr 2024 10:25:30 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail3.si.francetelecom.fr (Postfix) with ESMTPS for <ipv6@ietf.org>; Tue, 2 Apr 2024 10:25:30 +0200 (CEST)
Received: from mail-db3eur04lp2051.outbound.protection.outlook.com (HELO EUR04-DB3-obe.outbound.protection.outlook.com) ([104.47.12.51]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2024 10:25:29 +0200
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by PAWPR02MB9030.eurprd02.prod.outlook.com (2603:10a6:102:336::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Tue, 2 Apr 2024 08:25:27 +0000
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::18a0:3679:a134:1d02]) by DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::18a0:3679:a134:1d02%6]) with mapi id 15.20.7409.042; Tue, 2 Apr 2024 08:25:27 +0000
From: mohamed.boucadair@orange.com
X-TM-AS-ERS: 10.106.160.158-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-DDEI-TLS-USAGE: Used
Authentication-Results: smtp-out365.orange.com; dkim=none (message not signed) header.i=none; spf=Fail smtp.mailfrom=mohamed.boucadair@orange.com; spf=Pass smtp.helo=postmaster@EUR04-DB3-obe.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 104.47.12.51 as permitted sender) identity=mailfrom; client-ip=104.47.12.51; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="mohamed.boucadair@orange.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:spfa.orange.com include:spfb.orange.com include:spfc.orange.com include:spfd.orange.com include:spfe.orange.com include:spff.orange.com include:spf6a.orange.com include:spffed-ip.orange.com include:spffed-mm.orange.com -all"
Received-SPF: Pass (smtp-in365b.orange.com: domain of postmaster@EUR04-DB3-obe.outbound.protection.outlook.com designates 104.47.12.51 as permitted sender) identity=helo; client-ip=104.47.12.51; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@EUR04-DB3-obe.outbound.protection.outlook.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"
IronPort-Data: A9a23:d5ymTa3gtHu8f4/AkfbD5ad2kn2cJEfYwER7XKvMYLTBsI5bpzwAz zYYDDyPbvreZ2akKN4nPIq29hxUu5SHyodkHVc6qSg9HnlHl5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOKn9BGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYDR7zil5 5Wq/KUzBHf/g2Qoaj5MsfrawP9SlK+aVA0w7wVWic9j7Ae2e0k9VPo3Oay3Jn3kdYhYdsbSq zHrlezREsvxpn/BO/v9+lrJWhRiro36ZGBivkFrt52K2XCukMCQPpETb5LwYW8P49mAcksYJ N9l7fRcQi9xVkHAdXh0vxRwS0lD0aN6FLDvJ2OGruaSiFX8fzjm6tU2ERxmOrwk07MiaY1O3 aRwxDElQy25377z7JjgD+5mi4IkMdXhO54Ztjd41zbFAP06QJfFBaLX+dtf2zR2jcdLdRrcT 5NBNXwzM1KZOVsSYz/7C7pm9Ausrnz4czRdpV7Tr60q6GHfxQ1r+L/3Odzad5qBQsA9ckOw/ TudoD2nU0ly2Nq31TGB7VGq3LTzsib/X5gRNb6g8eFznwjGroAUIEZNDwfkyRWjsWa7VtZbL Eo89DchsKV0/0uuJvH3RRyxpjiJ+BUVQcJdFfE38imCz6PV50CSAW1sZj9ZdoIOtcIqS3otz FDhoj/yLTlmsbnQRXjG+6qO9W+2IXJNcDZEYjIYRwwY5dWluJs0kh/EUtdkFuiyk8HxHjbzh TuNqUDSmon/k+YNzJyk11GAmwig5ZLgblYou1XQb16Mu1YRiJGeW6Sk7l3S7PBlJYmfT0Wcs HVspyR4xLBfZX1qvHzcKNjhDI2UC+C53Cr0oHMHInXM3zGk+nrmcYoL7SxkfBttKpxcJGavZ 1LPswRM4pMVJGGtcaJ8f4O2DYIt0LTkEtPmEPvTa7Kig6SdlifWoUmChmbJhAgBdXTAd4lhZ f93lu7yUR4n5VxPlmbeegvk+eZDKtoC7W3SX4vn6B+szKCTYnWYIZ9cbwLXP7Fntv3Z+VmMm zq6Cyds40QHOAEZSniPmbP/0XhWdSZhbXwLg5AJKbLYclI2cI3fI6aIkOp9JuSJYJi5Zs+Tp SvhBSe0OXL6hHbdLh6NZGwrY7T1Rf5CQYETbEQR0aKT8yF7O+6Htf9BH7NuJOVP3LI5kZZcE aJeE+3eWasnd9gy029BBXULhNc/LEjDaMPnF3bNXQXTiLY7G1aQpYS7I1OynMTMZwLu3fYDT 3Sb/luzafI+q85KVa46tNrHI5KNUXkhdCZacnbyeoUWVG+3tY9gJmr2k+M9JNwKJVPb3DyG2 g2KABAe4+7Qv4sy99qPjqeBx2tsO/UrBVJURgE38p7vXRQ2PEL7qWODbApMVTfHXWX79eOpY uA9IzTULqgchFgT22ZjO+oD8J/SP+fSmoI=
IronPort-HdrOrdr: A9a23:ztFIVaOn+4lIzsBcT17155DYdb4zR+YMi2TDiHoddfUFSKalfp 6V98jzjSWE8Ar4WBkb+exoS5PwOk80lKQFl7X5Uo3SODUO1FHHEGgm1/qa/9SCIVy2ygc+79 YGT0EWMrSZYTdHZITBkW+F+r0bsbq6GdWT9ILjJgBWPGNXgs9bjjtRO0K+KAlbVQNGDZ02GN 63/cxcvQetfnwRc4CSGmQFd/KrnayBqLvWJTo9QzI34giHij2lrJTgFQKD4xsYWzRThZ8/7G n+lRDj7KnLiYDw9vac7R6f031loqqv9jJxPr3DtiHTEESstu+cXvUsZ1RFhkF0nAjg0idorD CGmWZbAy060QKtQojym2qk5+HtvQxel0PK2BuWh2Durtf+Qy9/A81dhZhBeh+c8EY4uspguZ g7ql5xmqAnfi8oph6NleTgRlVvjA65sHAimekcgzhWVpYfcqZYqcga8FlOGJkNESrm4MR/ed Mee/309bJTaxeXfnrZtm5gzJilWWkyBA6PRgwHttaO2zZbkXhlxw8TxdAZnH0H6JUhIqM0k9 jsI+BtjvVDX8UWZaVyCKMIRta2EHXERVbWPGebMT3cZdE60rL22u/KCe8OlZ6XkbQzveUPpK g=
X-Talos-CUID: 9a23:oSGp821I4OggBXKPqS15ObxfHNscbVfci2/qLwyyIEYxVeDFTm6s0fYx
X-Talos-MUID: 9a23:ZcvunwwG4ZKEu8BSGA/DiSfGSnWaqLilDF8ul89dh+aBMStqOBaelDOoW5Byfw==
X-IronPort-AV: E=Sophos;i="6.07,174,1708383600"; d="scan'208,217";a="31371690"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I++EVWoZoJPzItX3Y+aMk4fr1ltw/Va5lsRLX/Ou/sBM8W6Pkq/QNCz15dNWpFMmVPyPpTG+nJzjJ8Gh6vU7jvC4QoFVS0U8xBF3PzRXnJRKgMIT+OzFlZ3We9SpiJdNktIPsNQ8lg0gDpMen0hzB8fdXKlMzjwJFcK3skmyny+L1MOxm3zbG90vCmdwYb+47EA3UNMhZ9CGEVvk3XF5ykfDD8BsTBKOvdyT9BJEcvGrm9QN3/dY7XjQelCMr6nd3I6Kab3B3RMjL8+yHV5nCK1B/6UeXVtY2uo0Ur3SqsHD/V1zW5Mrv18EHizxCPq8qblHPL3VqDcqJuEu0xcrEg==
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=oBZA06VH5gj5WeOvzMwVavnwISOoTHaDPC7Ensrgkh4=; b=EXcnXLw5jg0FZrlDy/7Xv+mc6AUA3cFATiPOD5AkQeLdZhtTMazPqC+v82gsS7kLAZSoLIjwD4JAfIXAvIoYm3fBC1H0PZ3LqA4ddxHb9xi0iKdQbLsyu93A83GWaj5kq40Lq7bYBEk5LnL5cAyBBrVv2gcxxO5XM764n8+aSv9hAzA2kPtgkhKugXLSuWicf9A3sL+KBqwVn+hxHjfkqvVCeM57cOkhRMB/xbfo0GeOQG7xhK0SBCQy+DQETbgi/oiyfwoEvmyzakElm7hT6f1mKSpkGUCyJoqlJzwGE5Wqui3mH5hp7dpuf+/6/i4fDNSYG1ZrCQuDsI7Xt1Kk0A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none
To: Ted Lemon <mellon@fugue.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Thread-Topic: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
Thread-Index: AQHagT7MfogsIFL8QkyR/UVWRqXBMbFNjcSAgAcWVQA=
Date: Tue, 02 Apr 2024 08:25:27 +0000
Message-ID: <DU2PR02MB101602B1AAFD37A67062929A9883E2@DU2PR02MB10160.eurprd02.prod.outlook.com>
References: <CADmxuPF1AReQCSY13HjqXE+8Jofy_uoo1wmnzs8+whG7Tdc+UQ@mail.gmail.com> <836E3A12-FAAF-4C19-91A1-322203645AAA@employees.org> <CADmxuPEBXYeTPrJqfPEGaxmUM75iKQx6kfCcpHHjxyekZy0xuQ@mail.gmail.com> <2DB6E450-9EE4-438A-9D3B-78DDFF0CA78F@employees.org> <CAKD1Yr0+ArFfn7uZddMAGpxYroSxw-u=cpti4mwp_7-yRBSRSA@mail.gmail.com> <CACMsEX_Can2Uc4dEvC+9B_zG3OuP0YwQnGr=4uQyrFcjjgLHjA@mail.gmail.com> <CAO42Z2yghAZdk_ZO8nzufkJXsgsJMhUNi_Fm+SpUUQ1b7GLCuQ@mail.gmail.com> <CACMsEX8S26NMaseCfepBzoHHyN68k5aApSwG4nSKwJWk4mMKOA@mail.gmail.com> <CACMsEX-hmi+PqvdykmTGA_+Jq7cK+TwZiWWFhEkeOHgFgSr=Rg@mail.gmail.com> <6283d492-41c1-4ebe-9974-a891f797b02f@gmail.com> <CAPt1N1=Dv6e98gLAKToEpWHdFPwB2O4BxpeF1uqKTJP0TUdTfw@mail.gmail.com>
In-Reply-To: <CAPt1N1=Dv6e98gLAKToEpWHdFPwB2O4BxpeF1uqKTJP0TUdTfw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=a15abeb3-ba56-4de0-9f42-32b2a8366651; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2024-04-02T08:11:56Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=0; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU2PR02MB10160:EE_|PAWPR02MB9030:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XDcveLdl0s2EOi0FbW+Zs06BZCiRVkks1eDbiG1+rAoO1b45d8nvXY3IC8fM6nvmbqp/WOYtM2RrMe18pE1S8x9E2rdnK2GRKGU6Iud3eUVO7Gm2uY18FyfaipLBabEXk+ouZlZ7CYNPLstrc+Kd2lAvSjIk+OFEDufr6YGrU50x0e+ItU6RjC/6eJsO6o6AGS3j+rB9D8pO7x6HJLQ5yLbwlcVv7QFIwhWTPFZdyZcelzJxeLN7xmBpOnClUwLL6TPjXeN6LMqY0d72W01Jw0OOXreactCczHrXy5ExxEufaKAD/oQfTVm90eFkFxr0GpbC6N86VMv7hQASEBllMLdFVp+bAKSNF9/8qCzXKYxWglB+wIbZe8pgMK+Vi+vwikHMqobtUGc0vUGBbiQvo+/veSHF9lmrdwIZFUeuXFo545k3Ogv2keStk5n2/aTFsnxnz5Lyd9E9vOs/+wJXcu0S8icbrETfBZGRFcXPEWl2srhLwv9WLxlPv04eZVYo1SRF2hiXrrYJnv/PXgzof+fAOxEiH9MiMrayG/soTJKodb93e38OcoDg9hsLy7XnNogya78VIS6ZN3dRHNJXH+5aVEEwzg6O7yumoAlGQ6A=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2PR02MB10160.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(1800799015)(376005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Us2U0H0SFQrG68Tikfx7HlkHwxFmPKeHsnhpBeWx6Y1qtY1fCl+Izxvd/JbKNLr/MNvOcyxYs9mqnYmteT/OhXsYSDS5f7yklNuwiYKqJYDNuq5NV+owVYer+X6RHhCExtkEuw/OE9Y7zigM9E18Ca/tGXuIuuCK5aO/1lhlCxDjJYcgn63FM0U2wq7vbWFzbSDRXBEkCoXEwHLLLPT+8m3abYmWBwnuo3CqTHEFT9v5VGWO7bIcq7d716eVzF8MZZuQ4nZNcTV6CYLrQq3OnVaCdxlAbLLxOhDVBMR7O5hYO2JeRIQOt5b52l0dIQiCYh9kNmNfL5i2hynP6OlsZHCGtkaPaHarq8Zubx0wNKOCWLdTu8eIR5pVnviIufZJszzklHMgE8i1FfdZusYH52i+NHbhEjw93c4fRLil6TdZJLT8wEpnH/CRo2oGsG+NeVy49lNneCq7qcXf6m7kqFWZCEMQshhNjewOIfadX3lXRkeUEGI4os4jP+ZZe2h0gz9pX5DUcjoSQk1JpBbyWCoTTRjxorpXue+q/gFjgYBDwd1ZspMPsbrjyhAS3BaQC2hEYLHi38gG7QzwpaHN0tvnWgxq0ddubSadavvTpblvJGL/IF/d1+/gMlDLqeDIFlPWl+MIhAZkLnrJfCUWhedHYkagkWS9l6SY1ixPPmF1RgYIyuiaH7eTpHXRior/Q68vQW794/fWmG8JGiE+IDwhUXuL8bVS+a1oHWRu3l+pOSzfkJMmyZ0JZ9jD4VNHPLXSkHKbq66HImsNAYG3tAnoPVYeew3ZsVLgMHMO51p9Qekma4eNphNlvjbaHRO60AOsybfZA+IotxORQ9slOXaG+ZP0EOfX1hnYzBazXYkGNkeicENooYiunR4Q2zmhGklQ7PJa9OaYMpF/SxHuOc8amKkfYV9XTKdVTY3waGrVqpk9l5DVwflG5a+O8OKvOPk8jmgWaGZyxRl8166z2BcBucLSt/gY0hExP43JAuzoZs6cC1eLgFS72PRwQdD0WXon/aTJKD4t5SLwGCFQLvCaI3oIXqwQLLMXG/uhQGEhGSHg4LlhkGWoEw4RaZUC6Slts9b59RqHvMz+YSRveRrQiK9StSsLDIypsKmqAgpQ7ONppBV11VC5DSKg+Z5s+Whz8iMtIamNC6sk6EiFxkdA2Nrwly20cwUMjo5bPGjSHjkWHAd1CCoJ9JSEpF+3lcw6sDSJ1hAsZIm+pMP/jw3n5nfFQpv+esgTmUH1RQxQfm9G/y7Cl8XnB0uNRwiFnzpKvFeheeFp4ApAZ44QapFRt/qTnMqk3cyeNB6THKbPUa3Xu5jW1zN/vLbVbiyFWh6hDwBKPIuB7Hprg1gvrgZlN9uI90/gyaXXwdiREusLH1kX1Mor/xAq/PWnj/9wnVPsA7HU+pnjKXWM5A3NaOAMGgEfi28L5r349t/KYikHnieal6QMtkcw13x2KYpBkEPcCOKHk3AYjihNfploMgY4Lh60PSf1NumI67ylgO8yq2BIrUu4wkaxTSz/5MJ7zW0q+iAcZ3K5g2J1LzcqE6Ma7CjkZ1NIrlT/pgZEzjbjnBmszl6PpublLiUcerVa4v3ab8/K1i0axQiS1GbTew==
Content-Type: multipart/alternative; boundary="_000_DU2PR02MB101602B1AAFD37A67062929A9883E2DU2PR02MB10160eu_"
MIME-Version: 1.0
X-OriginatorOrg: orange.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10160.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: df13c86a-d28e-48e0-4055-08dc52ee73ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2024 08:25:27.6946 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Wi0nUQEDn8epphUx+rLp+0S77U7jByzK3S2pmq7egrOYlY1P7A7usaXHSO2Y6ExzPajlBAX3+F68BS0Ap/lSAvKgcnvb98+gNnNrZ5RrgGk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR02MB9030
X-TM-AS-ERS: 10.106.160.158-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.0.1002-28292.006
X-TMASE-Result: 10--34.303400-10.000000
X-TMASE-MatchedRID: iKTMlETJ4psPA7Hl+MrTa08HitdqBBn7Dlgxb8s+r0CwZ31xQ8WS6Gqu w69QUQrL1IeckOrbKEwSuut4i3qCeBQiu+Nqmsg9aEsmopAJRAlkGI+vgRTxMPioIsi7Sa0gS6Q izeDUeN439UJ8ExuM5i774nlxVOXqJe36Z4bPXwikpm87KqZ5R/knCf5Y5jPYNi8L88UV9IBShX 3jPAundRjbR/XCsHXWvf66wqL2jFXi3A9Zt5S/qjN1VvnSogA6olVO7uyOCDUSrxWnE1VUiUty8 cifGH0UIPU0QLczhnquhdwbFLNuARZqyPXTXXqXZc38TsM6WGBp5gkCyfx58E+crEA4+nhZNvFA 2dDQnJ9+DkNwm07y49lvIVMpuCojpxmXmu3IpnUCkI6Mamr9f0zs4u81P77pohrMq0nEhQeqlff cnRFwa4+ct2HZTZEc+LjG5DRSM+ivr1Xc6yEe80+XEMkkfX2ebMGKOuLn5FVFhibp9uFm9Uyi1T 9AUgUbilJmlF8p4QeiKS41nrqIoySc4ah4hDOWcVeYCqx1wVyu1VI105F9biUnLzk1+IxzN2zK9 lb+laaGdV1o2FvDHPgCRiAb/Aa3jNbG/17KYGUtPhLAKQq0UZmW/bMdGpkodmWMDQajOiK4IXQ3 z8dnau+JZYyj9fvYp7V+pIANDRoFuLMARNvIbiDyvgVYdlWLfUkgDiuGxn/rxZDnkdZZgfQQSB+ AA86ah74LAtIO9rahrlikINGeNYnVGTOpEYaBvMVE7Zdb7nssZAW16UOXi1EwSDwOevUhx8BJ7u ScK220EXorlkfMJlz18s1AmPZAWtxX1bZT1YKPaFHMfVTC4MBX4Iey09T4Vb3rZjw/bpwUyRS/O CD9xZUdXE/WGn0FFUew0Fl/1pGypq0eC3FVtlZ0V5tYhzdWIG4YlbCDECtruV6hT84yE/IxdJB3 PGL0
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-TMASE-INERTIA: 0-0;;;;
X-TMASE-XGENCLOUD: 6eb983b7-061c-4088-8b98-7d528d862c88-0-0-200-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nLtFw09RNISxcKuXvc5KyqtV3nA>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
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: Tue, 02 Apr 2024 08:27:57 -0000

Hi Ted, all,

On the PCP point, I confirm that the spec supports NPTv6 (protocol=0, internal port=0).

                 internal  external  PCP remote peer  actual remote peer
                 --------  -------   ---------------  ------------------
   IPv4 firewall   IPv4      IPv4         IPv4              IPv4
   IPv6 firewall   IPv6      IPv6         IPv6              IPv6
           NAT44   IPv4      IPv4         IPv4              IPv4
           NAT46   IPv4      IPv6         IPv4              IPv6
           NAT64   IPv6      IPv4         IPv6              IPv4
           NPTv6   IPv6      IPv6         IPv6              IPv6

               Figure 5: Address Families with MAP and PEER

Note that some optimization were made in the past to help building PCP requests as a function of the PCP-controlled device: draft-boucadair-pcp-capability (CAPABILITY Option) and  draft-cheshire-pcp-unsupp-family (UNSUPP_FAMILY Error), but were not adopted by the WG at the time. See also slide#5 of https://www.ietf.org/proceedings/83/slides/slides-83-pcp-3.pdf.

Cheers,
Med

De : ipv6 <ipv6-bounces@ietf.org> De la part de Ted Lemon
Envoyé : jeudi 28 mars 2024 20:43
À : Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc : 6man WG <ipv6@ietf.org>
Objet : Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis


Part of the problem here is that the camel's nose is sticking under the tend and we have to ask ourselves if we really want the camel in the tent. Clearly if NPTv6 is operational on a network, and we want devices on the network to be able to set up listeners, then we may need extensions to PCP to make that work. Or possibly PCP already does what we need—I'm not sure. But if we need to extend PCP, now NPTv6 is being further legitimized by yet another bit of standards work done to support it.

This isn't a problem if this is a niche solution that doesn't impact most general use cases, but if we standardize it and it starts seeing wider deployment, now we're stuck having to do more protocol work to support it. IMO this is a bad outcome.

One of the things that worries me about this is that there is always an economic tension between peer-to-peer and client-server. Toll collection is a lot easier for the client-server case than for the peer-to-peer case. And so there is a clear economic incentive to create solutions that make peer-to-peer impossible. You may have heard the term "over the top" used by ISPs. I always found this scandalous—this is the ISP saying "I want to collect a toll from the provider of a service on top of the money I'm charging for the service I'm actually providing, simply because I'm on-path and so I can." To me this is security issue, which the IETF should be working to prevent, not to facilitate.

Of course this is completely orthogonal to the stated use case, and I am not suggesting that the proponents of the stated use case here at the IETF are secretly plotting to block over-the-top services. Really I am not. But that's one of the things that this standard will do, and if you are getting pressure to do this from people who can't state a clear use case, you might want to ask yourself what /their/ motivation is.

On Thu, Mar 28, 2024 at 2:36 PM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
On 29-Mar-24 06:02, Nick Buraglio wrote:
>
>
> On Thu, Mar 28, 2024 at 9:45 AM Nick Buraglio <buraglio@forwardingplane.net<mailto:buraglio@forwardingplane.net> <mailto:buraglio@forwardingplane.net<mailto:buraglio@forwardingplane.net>>> wrote:

<snip>

>      >>>>
>      >>>> The benefit of NAT class mechanisms, is that cost and benefit are aligned. Only one side needs to deploy it.
>      >>>
>      >>>
>      >>> Actually, the benefit of NAT class mechanisms is that one party deploys them and another party incurs the costs. NAT is great for the network operator, because it moves a number of problems out of the network operator's domain. But it doesn't do that by solving the problem, it does so by making the application's job more difficult.
>      >>
>      >>
>      >> I don't think that is typically true.
>      >
>      >
>      > For client/server applications, where the client is on the inside of the NAT with a private address, and the server is on the outside with a public address, that wouldn't be typically true.
>      >
>      > However, for applications where the communications model is peer-to-peer, or a mix of client/server and peer-to-peer, the application developer has to implement RFC 8445 ICE using STUN and TURN for NAT traversal, incurring additional development, debugging and testing costs.
>
>     Is that still accurate for a device behind NPTv6? RFC3235 section 3.1.5 points out that statically configured NAT bindings are largely exempt from the problems of port mapping, and NPTv6 is only a non-stateful translation that does not require the transport header to be re-written, simply translating the first 64 bits, so unless the communication embeds an address, which is problematic for all of the obvious reasons we see with things like legacy FTP, the peer-to-peer applications should work - assuming no security policy is in place to prevent it.  In fact, vendor documentation specifically calls out one of the advantages of NPTv6 as keeping peer-to-peer networking accessible:
>
>     /The NPTv6 support allows you to redirect or forward packets from one network to another in an IPV6 environment. The NPTv6 support on is an algorithmic translation function which provides a 1:1 relationship between the addresses within the inside and outside network. When NTPv6 is used, you can interconnect different networks and support multihoming, load balancing, peer-to-peer networking. The NPTv6 does not create any state in the data plane and hence can operate using minimal memory and also supports high availability by default./
>
>     Of course, it's vendor documentation so take it with a grain of salt, but I would not expect that to remain in published documentation unless it actually had some validity.
>
>      >
>      > Alternatively the application developer adopts a client/server communications model for the application, even though a peer-to-peer model would be more scalable and more robust against a centralised server failure and server performance problems.
>      >
>      > This is why I say that NAT (of any type) imposes a default client (inside NAT) /server (outside NAT) communications model at the IPv4 or IPv6 network layers, rather than the default peer-to-peer model that can then accommodate both client/server and peer-to-peer applications communications models.
>      >
>      > NPTv6 may be stateless, however since hosts behind the NPTv6 will have to discover their public addresses via ICE if they want to be peers, NPTv6 still imposes those ICE costs on application developers and the applications' end-users.
>
>     Do they need to discover that? If the mapping is 1:1 it is functionally the same address unless there is an embedded address in the protocol communications, right? Or am I missing something obvious?
>
>
> I talked to some developer friends that helped me understand this a bit better, thanks for giving me the terms to build from to dig deeper. Specifically, the need for determining the actual address for a peer to peer application is required because there may be peers both inside and outside of the translation boundary and a given application needs to know what those are in order to avoid things like tromboning traffic or blackholing connectivity. This makes much more sense now that I have had someone walk me through it.
> My question back which I think is still a valid question and is couched in a dichotomy of ideal vs pragmatic debate is "does this extra work implementing the overhead of the ICE/STUN/TURN impose significant overhead compared to existing application development requirements to support how networks work on average today?"
> I am not knowledgeable enough to answer that question. At face value it *seems* that there will be a need to support these tools (ICE/STUN/TURN) already in order to support port address translation that is likely required for the foreseeable future for environments that are devoid of public addressing and are behind some kind of a port address translation device for v4. And, how does that map into a NPTv6 deployment using one of the specific use cases? Does the lack of state make that easier or harder or make no difference?
> Myself and others have pointed out very clear and very specific use cases where NPTv6 solves a real operational problem, and has been in operation for quite some time.
>
> As an aside, I don't think we should "what if" about ISPs deploying NPTv6 at their edges or all home users insisting on using it as they are functionally forced to do with NAPT, those use cases for NAPT are a forced function caused be a problem we don't currently have (address exhaustion) and any guessing about exploding use is all speculation. Operators are going to do what they are going to do, but what we could do is be very clear about the problems that this solves, and the places where it does not add value and is discouraged.

Which is exactly why changing NPTv6 from experimental to informational status, with information added about which scenarios this assists and which scenarios it damages, based on experience, is the right thing to do.

     Brian

>
>
>      >
>      > Network engineers who deploy NATs aren't directly exposed to or pay any of these additional application development costs (other than when they're the application users), which is why it appears that NAT is a simple and low impact technology to deploy.
>
>     Given that nearly every application must be written to support dual-stack, and therefore must implement these techniques for port address translation, is that cost not already incurred by default? I understand that it may take some work to add IPv6 support to applications that require ICE/STUN/TURN, however, assuming (and that's a big assumption on my part), that the 1:1 stateless nature of NPTv6 and a lack of an embedded address, what is the surface area of applications that need to incur that cost specifically for IPv6 where it does not currently exist?
>     Is it 90% of applications? Is is 10%? I don't actually know but would like to. Likelihood of occurrence is a key in making design decisions, at least in my world.
>
>     I fully admit that I am not an application developer, and there are undoubtedly aspects here that I do not understand, so pardon my potentially basic questions - I simply don't have the background but would like to fully understand. Knowing the likelihood and actual need at an application level where it does not already exist as part of a normal development workflow to support existing environments, and specifically where it is required where NPTv6 is a valid design model  would be very, very useful, especially with the use cases for NPTv6 being fairly specific.
>
>      >
>      > Regards,
>      > Mark.
>      >
>      >>
>      >> I will definitely say from experience that there is a significant operational cost to deploying any translation tool, and more so when there is active state tracking and overload involved. There are often (but not always) logging requirements to do these things at scale, and there are definitely operational costs in dealing with state table tracking and scaling. These don't exist at the same level for mechanisms that do not track state and that do not masquerade using port address translation. They may still incur application cost, or they may not, that is always going to be based on the application stack and is more likely in real time applications that don't use a third party intermediary, as you have stated.
>      >>
>      >> There are similarities in the translation toolkits, yes, they all perform translation at some level. However, what is generally referred to as "NAT" in the general term is typically PAT or NAPT or Masquerading, depending on the nomenclature. That said, *because* it is significantly easier to deploy NAPT, I do not believe that it is an apples to apples comparison. They're all tools in the "translation" category, but they're definitely not all created equally. NPTv6 does a 1:1 translation, the NAT that folks seem to be referencing in the IPv4 world does not, and I do not believe it is a reasonable comparison.  It's a far better comparison to say that NPTv6 is like a traditional one-to-one NAT (which does still have notable, albeit significantly fewer considerations, which I believe are noted in the draft).
>      >>
>      >>
>      >> nb
>      >>
>      >> --------------------------------------------------------------------
>      >>>
>      >>> IETF IPv6 working group mailing list
>      >>> ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org<mailto:ipv6@ietf.org>>
>      >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>      >>> --------------------------------------------------------------------
>      >>
>      >> --------------------------------------------------------------------
>      >> IETF IPv6 working group mailing list
>      >> ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org<mailto:ipv6@ietf.org>>
>      >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>      >> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org<mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.