Re: [BEHAVE] [Technical Errata Reported] RFC7050 (6270)

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 13 January 2021 15:08 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638A93A10FE for <behave@ietfa.amsl.com>; Wed, 13 Jan 2021 07:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBovNoUlhLOO for <behave@ietfa.amsl.com>; Wed, 13 Jan 2021 07:08:51 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.71]) (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 4F46F3A10FA for <behave@ietf.org>; Wed, 13 Jan 2021 07:08:51 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F1pWg0BpSSOqNrZsclsLPQ26DXnyN/hAp4sKgygoT+VFeJMVqoPebTv2TMhwE3UzfnQU3TBwGxQpNN1P+6IY2rYVKkweKaihrmjLlm0raVR4Hiikt3l89nR2ccmxfcfm5c449KCfq+K6koChWt7PcBOAwHCbpdUii92Ncl8giDUgqOruTwIWZ89zdE9+ZwUaEo3JCnlDw6sue5K3F+0JLr9YFTrSchcWawYlcHwQfAuZlwoz86DJ1tjL/Q4fpdL2EQlGI8tdnNz5vKBlmxlesRyXq6ZZz9M18N7CPKT5N38BT378btbsxbt3f1UXrvoj7DkbFMAQBJC/cnuo7Aj3zw==
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-SenderADCheck; bh=8fgH+xOQf7mRHajy6JEmJ7+N7ivjurJBKmGXW2PSx/M=; b=GDzfXvZqq+OxIVThc1f5FQuw8zZ7/21xgCXJIQpJiwVuBahgsb+dPCticSPojdbP8nlX54Qn0raaa8L8dBMd9w5JMXotHAXMRmbJ5xZCq9+LQdxhFeWdI93YwMgXjNvwPpLht/00awSo3o0dKb6F36iUEFo/B6HFgrlm6M0HazCckKwHX538uDuDbe+Lh3wrjUTELY8FlFuTwQwraPKFYXu6QxP9AD7NyLcyLpYhVTUn2iyT3FffiO0j4EMFTgwRS12IbXTmmGIsv9f4MiBDrv/cPyZWUvVGUnpJLg10PWgNomoO7GsZJaOV5z2GQNfPQSKl+R/AEU6CVEBc74gUFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8fgH+xOQf7mRHajy6JEmJ7+N7ivjurJBKmGXW2PSx/M=; b=vRnS2OlY+d6wvPbNF7cIl5Uk2o/tNt7HIfIZafIBSSvV0vYUHpMuCmBcwkS2Rh1fsXySp1rctnFYwdcdKyyGNkH91OLaGdwyuFZC71kM0yE9cyTCKXyZlRZv8cXxNuVxJVpXq68OPHqfxPKe7iO5/EcgOcvlUUSgDIqKuDQaJgY=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3706.eurprd07.prod.outlook.com (2603:10a6:7:8d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.7; Wed, 13 Jan 2021 15:08:41 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%6]) with mapi id 15.20.3763.009; Wed, 13 Jan 2021 15:08:41 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "dan@danwing.org" <dan@danwing.org>, "marka@isc.org" <marka@isc.org>
CC: "behave@ietf.org" <behave@ietf.org>, "dthaler@microsoft.com" <dthaler@microsoft.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "dwing-ietf@fuggles.com" <dwing-ietf@fuggles.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "tsavo@kotiposti.net" <tsavo@kotiposti.net>
Thread-Topic: [Technical Errata Reported] RFC7050 (6270)
Thread-Index: AQHWgAspmCoa9197y0uf5AcQGmQzx6ltV38AgABbcACAAAe+gIAABjKAgLi69AA=
Date: Wed, 13 Jan 2021 15:08:41 +0000
Message-ID: <836042821240b5d2387c33252bb4b16c78d2a1f3.camel@ericsson.com>
References: <20200901025348.AD36AF40771@rfc-editor.org> <E7035A63-CF71-4DBE-AC9C-C551B373863F@gmail.com> <C9BFCE03-4568-48CF-99E6-17A148554F03@isc.org> <5CE83ABE-FA71-415A-8620-A06EA9539DEE@danwing.org> <FA5A1584-0FAB-4BE7-9558-035BF85C37F6@isc.org>
In-Reply-To: <FA5A1584-0FAB-4BE7-9558-035BF85C37F6@isc.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: danwing.org; dkim=none (message not signed) header.d=none;danwing.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 18d5896b-6ada-41ed-f191-08d8b7d51d05
x-ms-traffictypediagnostic: HE1PR0702MB3706:
x-microsoft-antispam-prvs: <HE1PR0702MB37060E20B0F227FBAAAFC09E95A90@HE1PR0702MB3706.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: W+94mqpy5VBx7Z09KLmST0LlwvnXk1rxqTKFwHvF9WDbVBzqDkSjnTxl+fYnlFCFYDVWSeFK8igOmIpUO3weH5SAHr9XopE8yBBQbnw9a0bDy6b/UgErOXD8nkVrMHIlQBZmgz1wAPVxPVrkcaf9vM4bxZZYvhR6rnz+5lxG9AZipF5+0aO4bakXf6WwkAJrZQTn4Eyf1Po7SKgeCJc1ZYAb/SveUB0NhBLfwQDL0IOVCMZRILJge89OIkFJr3ER6mCD0KgYmEWk/ofoFBwbK227NA7X3nqsFrhRjo5k4ESFHv84KLM5CuPO2mXyN/T/RGdnZtlAs5qA03iF6wz5Jac/xJW8Xtyry6ZugLlxNeKGB4OC/sUzPeDVeCDwiAROrmYA9RknmBnOpgkFWH5QRfbmm9RvKJUDz0atm/NIluvjbxP1kbmNp0jKeE3WtpBRuoiSteiCNI881iHCaHJxfTLa0wKJFhfrosMnoJpV3UJZD0DGMyNUnwZBtpho25JqOke73kuMJdwNJ2iHXSnYLXXc/OZvZCQ8piLC3R6syvM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(39860400002)(136003)(366004)(66616009)(8676002)(36756003)(186003)(26005)(66446008)(6486002)(66476007)(2616005)(66574015)(66556008)(71200400001)(4326008)(66946007)(64756008)(8936002)(110136005)(44832011)(86362001)(5660300002)(316002)(6506007)(2906002)(966005)(53546011)(6512007)(54906003)(83380400001)(478600001)(76116006)(99936003)(99106002)(554374003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?WmlIRnFaZFpwQ3lZRjRqNXcyT2NIdzB4Y0hqT3I0ZFVQcmlWaFBSeEFTbjNz?= =?utf-8?B?ZERIVHNFZEZNZkdlcWo2VFhjbnp2K2ZTb2RYa0ZxOUFCb3NsNUhBYnJueDVu?= =?utf-8?B?RTFLNmRmdWp0cHJVQW1YNTFnckJGMVBDS3p0SFpsZ25xZVZHMzkwbUh4akQy?= =?utf-8?B?TWNXL2VRTkJyRy8yTFkwTFk1YnNOZmxpaUtDY1dSVzArM2VHSjdiNFFzQU1P?= =?utf-8?B?TncwL0YzWGNRWUlrUnRjbFNRb2hRcGRtb3JTZ0l0Rmc0emFmR1E5di9pc2xu?= =?utf-8?B?SjNaUG8vU0lCNG00VFMzSlYrUjhZdFFlcVp5WWVhRzcwajJPTU5ubjN6R3pQ?= =?utf-8?B?Y3NicDBVMkN5L0tCSVVBNUpZcHJSTkZMaFM5cGgyNnVEa0R1eDREejZWTXUy?= =?utf-8?B?ZXZsQWswb01zS3JpdS9zMEhmclJuekxPMFZreTQrTnJmeVl4MGMveWsxMnJx?= =?utf-8?B?UnY2OVBMSCtTc2V3Y1FjVU1BMllhVmZGUDcxSi9jVzlBSktVVzhFMEk5Um01?= =?utf-8?B?L1BCRUxVdkY2WEJUc29aNjBLN1o2N1Exbkhua3NYTmRxNVRnSGZKWnlPdnRq?= =?utf-8?B?ak1uOWorQllmekJPWktzSEg1TzJWb3dlSkUzeEZGQjJnVTUrNVNja0EvYmo2?= =?utf-8?B?akZNbTZHMzhZdXpRK2FPbkxHbUxrZXJ6VGhsQWdsZ012dEQ0dkN1cjQ0TTI1?= =?utf-8?B?ZG1POWpnalU4cEt0eXhwRDdsTCs2UnhzMnpyejZvVlN5d2V2dFFhcWdGbElI?= =?utf-8?B?akVYdjh6Y1Rpc3c0aURnZGFNTGJxbFV1ejhPMTBEaW43RFZEUUxxcEZjUjZ0?= =?utf-8?B?ZGw0bUhoMTFMTkhpRDVYL0NGb0wyQ0NpT0t5d0Z5b24vQ3JoODlsM1U4dldR?= =?utf-8?B?U3F5OUZiUDk5blVEWDRnZUlkaU1JM0xhOG44d2U5Y2l6aDAzang3ZkFSV3pj?= =?utf-8?B?R3pmZkFWSEkveGxLNGxLNjYrNFNUclg3R3hKaGt1dzdlVTlrekRxWTBpb1Np?= =?utf-8?B?cUo2UTh0U1pVQS9NenBFSitJTHNIM09CNGpFc0IvbzYvT2J0empmRmpwTG15?= =?utf-8?B?ZU9wZTR6OGRFc3hDR1EvYk9UQ0tpdUxDWVFnZTl2OVIzK29yR0FKcWJVand2?= =?utf-8?B?NHJXYlpsTUllbytCUVBjZHVFQTdjNW1mUFFDVDc4aGY3TXFCaGRENTRJaTRl?= =?utf-8?B?akYwREFCVzlyaSs0Z2pnRjZhT1BBZ1BvUGVZKzZvWktjeGtKMW5MSVJQY2Nu?= =?utf-8?B?K2NDR09ycENlYnZSd3lVU3VNM1ZIdEQ4VW5QRG5jRmUwS3FjY0U0RGZvTGFn?= =?utf-8?Q?i2p5cOI7HeXV0/3qJ9uEEkwSsHlw3/kyEl?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-Hpim3cV/WX28VPr9OUCk"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 18d5896b-6ada-41ed-f191-08d8b7d51d05
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2021 15:08:41.4891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 69wTwFGQIhGJvvNBoLQtd/6uFSKwN7d1Mrsye2+9QZ/Zs5LzynJrQwSQWWuSP0RrWHO5io56v1CCkjSzGuI0LLmZFWTZCd/NUFN2TU7a8/Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3706
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/aaQjcPjO1IatcibLoBZL0fu1BvE>
Subject: Re: [BEHAVE] [Technical Errata Reported] RFC7050 (6270)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2021 15:08:54 -0000

Hi,

I have reviewed the discussion on this errata. Although some possible
improvements to the specification on certain aspects that could be done if a
replacement specification would be developed.

However, looking at the errata I do agree with Dan and Jouni that the example is
not in conflict with what the RFC specifies when it comes to procedure. Thus, I
am rejecting it. 

Cheers

Magnus Westerlund


On Fri, 2020-09-18 at 12:07 +1000, Mark Andrews wrote:
> I would also be tempted to state that a DNS64 server MUST set the suffix bits
> to zero for these addresses.
> We have old servers that don’t do this, but ensuring that new servers don’t
> make discover harder than it
> needs to be is good.
> 
> > On 18 Sep 2020, at 11:45, Dan Wing <dan@danwing.org> wrote:
> > 
> > Cisco's client implementation didn't care about two A's unless the first was
> > at an unexpected place, then it looked for the other (to ensure the location
> > was right).  The heuristics for the client aren't well described in the RFC;
> > perhaps that can be improved.
> > 
> > -d
> > 
> > 
> > > On Sep 17, 2020, at 6:17 PM, Mark Andrews <marka@isc.org> wrote:
> > > 
> > > As a DNS64 server developer I’m quite willing to override the user and
> > > always return 2 AAAA records for this name by
> > > hard coding the addresses into the conversion algorithm.   Additionally
> > > this is the default.  Every A gets mapped to a AAAA unless it is in the
> > > exclude list and the default exclude list doesn’t include these two
> > > addresses.  Also any DNS64 server would be insane to only return one AAAA
> > > record as that defeats the redundancy of multiple addresses in the first
> > > place.  I’m sure if you polled the other DNS64 server developers they
> > > would have the same opinion.  We want the discover mechanism to work.
> > > 
> > > Then there is also RFC 8880 which also says return 2 AAAA records.
> > > 
> > > > On 18 Sep 2020, at 05:50, Jouni <jouni.nospam@gmail.com> wrote:
> > > > 
> > > > I don't agree with the errata. We cannot imho dictate what policy a
> > > > DNS64 server is using an _example_ flow. 
> > > > The text in Section 3.4 it actually states "The DNS64 server could also
> > > > return synthetic addresses containing the IPv4 address 192.0.0.171." so
> > > > it is not a copy-paste error.
> > > > 
> > > > - Jouni
> > > > 
> > > > > On 1 Sep 2020, at 5.53, RFC Errata System <rfc-editor@rfc-editor.org>
> > > > > wrote:
> > > > > 
> > > > > The following errata report has been submitted for RFC7050,
> > > > > "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis".
> > > > > 
> > > > > --------------------------------------
> > > > > You may review the report below and at:
> > > > > 
https://protect2.fireeye.com/v1/url?k=2e6171b8-70c1b3fd-2e613123-8692dc8284cb-d73a39e62ff1e92d&q=1&e=4af65926-372f-48ef-b5ac-d63abee92eab&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6270
> > > > > 
> > > > > --------------------------------------
> > > > > Type: Technical
> > > > > Reported by: Mark Andrews <marka@isc.org>
> > > > > 
> > > > > Section: 3.4
> > > > > 
> > > > > Original Text
> > > > > -------------
> > > > > "PTR" query #2 for "2001:db8:43::192.0.0.170
> > > > > 
> > > > > Corrected Text
> > > > > --------------
> > > > > "PTR" query #2 for "2001:db8:43::192.0.0.171
> > > > > 
> > > > > Notes
> > > > > -----
> > > > > The second PTR query should be for the reverse of the DNS64 mapped
> > > > > well known address 192.0.0.171.  This looks like a cut-and-paste error
> > > > > where 170 was not changed to 171.
> > > > > 
> > > > > Instructions:
> > > > > -------------
> > > > > This erratum is currently posted as "Reported". If necessary, please
> > > > > use "Reply All" to discuss whether it should be verified or
> > > > > rejected. When a decision is reached, the verifying party  
> > > > > can log in to change the status and edit the report, if necessary. 
> > > > > 
> > > > > --------------------------------------
> > > > > RFC7050 (draft-ietf-behave-nat64-discovery-heuristic-17)
> > > > > --------------------------------------
> > > > > Title               : Discovery of the IPv6 Prefix Used for IPv6
> > > > > Address Synthesis
> > > > > Publication Date    : November 2013
> > > > > Author(s)           : T. Savolainen, J. Korhonen, D. Wing
> > > > > Category            : PROPOSED STANDARD
> > > > > Source              : Behavior Engineering for Hindrance Avoidance
> > > > > Area                : Transport
> > > > > Stream              : IETF
> > > > > Verifying Party     : IESG
> > > 
> > > -- 
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> > > 
> > > 
> 
>