Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 06 November 2018 12:16 UTC

Return-Path: <prvs=184881054d=jordi.palet@consulintel.es>
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 C67CF130DF0 for <behave@ietfa.amsl.com>; Tue, 6 Nov 2018 04:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 PzbGqM9P-gwQ for <behave@ietfa.amsl.com>; Tue, 6 Nov 2018 04:16:46 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DB3130ECF for <behave@ietf.org>; Tue, 6 Nov 2018 04:16:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1541506602; x=1542111402; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=a0u1YS3Tfug/lYLXbXLBF/oU4TLGNeAVZqWM7n2GavY=; b=se8cx/OSVtk4R 2LZf6dOD+OdQVf+DcC0gsIS/3S8Ue+9HFTQTv09K3pkxbXR6ZviFcWaDjB7YP6pT Aled5DTXkFCGRRqfOJaLvP9WEsAO/nhxfzWZ3DxX8c2eP8fz8qsBqFMtgQtaHjxN iy66I/kp9+zU3RbZFH/b4RJZhTV3jE=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 06 Nov 2018 13:16:42 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 06 Nov 2018 13:16:41 +0100
Received: from [172.20.60.83] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005946446.msg for <behave@ietf.org>; Tue, 06 Nov 2018 13:16:39 +0100
X-MDRemoteIP: 10.8.10.6
X-MDHelo: [172.20.60.83]
X-MDArrival-Date: Tue, 06 Nov 2018 13:16:39 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=184881054d=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: behave@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.3.181015
Date: Tue, 06 Nov 2018 19:16:30 +0700
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Fred Baker <fredbaker.ietf@gmail.com>, Christian Huitema <huitema@huitema.net>
CC: Congxiao Bao <congxiao@cernet.edu.cn>, <mohamed.boucadair@orange-ftgroup.com>, Dave Thaler <dthaler@microsoft.com>, Xing Li <xing@cernet.edu.cn>, <spencerdawkins.ietf@gmail.com>, <dwing@cisco.com>, <huitema@microsoft.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, <behave@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Message-ID: <75370789-566F-4187-8374-719E40D59D31@consulintel.es>
Thread-Topic: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)
References: <20181106085323.07C1BB80008@rfc-editor.org> <27516408-05B3-4C08-B40E-B01E44525AB5@gmail.com> <5a5d6ac6-2d9a-96ee-118d-3601e47804cc@huitema.net> <0F8964C5-7C2F-4C90-854A-D1ADF02D7C08@gmail.com>
In-Reply-To: <0F8964C5-7C2F-4C90-854A-D1ADF02D7C08@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/9xM5gf9H0NEvHikzgzxz_h7e4-o>
Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)
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: Tue, 06 Nov 2018 12:16:50 -0000

The advantage I see with a WKP is that you can roam to another NAT64 (and/or DNS64) without changing configs, and also, that you may ignore the prefix discovery mechanism (I've seen this coded in some places), if you presume that the WKP is the "default" one ...

Regards,
Jordi
 
 

-----Mensaje original-----
De: Behave <behave-bounces@ietf.org>; en nombre de Fred Baker <fredbaker.ietf@gmail.com>;
Fecha: martes, 6 de noviembre de 2018, 18:28
Para: Christian Huitema <huitema@huitema.net>;
CC: Congxiao Bao <congxiao@cernet.edu.cn>;, <mohamed.boucadair@orange-ftgroup.com>;, Dave Thaler <dthaler@microsoft.com>;, Xing Li <xing@cernet.edu.cn>;, <spencerdawkins.ietf@gmail.com>;, <dwing@cisco.com>;, <huitema@microsoft.com>;, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>;, <behave@ietf.org>;, RFC Errata System <rfc-editor@rfc-editor.org>;
Asunto: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)

    
    
    > On Nov 6, 2018, at 5:17 PM, Christian Huitema <huitema@huitema.net>; wrote:
    > 
    > 
    > 
    > On 11/6/2018 4:23 PM, Fred Baker wrote:
    >> On second thought, the exact case is incorrect. I still think it's a silly restriction, but the private address in the case would not be placed into the Well-Known Prefix (and used as a destination address); it would be put into a /64 out of the subscriber's prefix (and used as a source address). So I can live without this change.
    > 
    > Good.
    > 
    > I think that the text should not be changed by an errata. The text is a
    > fair rendering of our technical assessment at the time. We did not want
    > to use the WKP to build ambiguous IPv6 addresses,
    
    If the objective was to not create ambiguous addresses, why did we build a well-known prefix? A well-known prefix is probably the best possible way to create ambiguous addresses.
    
    > and wanted to make
    > sure that private IPv4 addresses will be mapped using private prefixes.
    > It may or may not have been the right decision, but this is definitely
    > what we intended.
    > 
    > -- Christian Huitema
    > 
    
    --------------------------------------------------------------------------------
    The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
    
    _______________________________________________
    Behave mailing list
    Behave@ietf.org
    https://www.ietf.org/mailman/listinfo/behave
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.