[BEHAVE] [Technical Errata Reported] RFC6052 (5547)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 06 November 2018 08:53 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 7E496130F5F for <behave@ietfa.amsl.com>; Tue, 6 Nov 2018 00:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 S722CgTCyXmb for <behave@ietfa.amsl.com>; Tue, 6 Nov 2018 00:53:40 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44685130E72 for <behave@ietf.org>; Tue, 6 Nov 2018 00:53:37 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 07C1BB80008; Tue, 6 Nov 2018 00:53:23 -0800 (PST)
To: congxiao@cernet.edu.cn, huitema@microsoft.com, marcelo@it.uc3m.es, mohamed.boucadair@orange-ftgroup.com, xing@cernet.edu.cn, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, dwing@cisco.com, dthaler@microsoft.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: FredBaker.IETF@gmail.com, behave@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20181106085323.07C1BB80008@rfc-editor.org>
Date: Tue, 06 Nov 2018 00:53:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/neViYve8FjxIhbqkKutSa4Q_nQs>
Subject: [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 08:53:47 -0000
The following errata report has been submitted for RFC6052, "IPv6 Addressing of IPv4/IPv6 Translators". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5547 -------------------------------------- Type: Technical Reported by: Fred Baker <FredBaker.IETF@gmail.com> Section: 3.1 Original Text ------------- The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST drop these packets. Corrected Text -------------- The paragraph should be removed. Notes ----- IPv4 packets with private addresses are routinely translated to IPv4 packets with global addresses in NAT44. If a 464XLAT CLAT (stateless NAT64) cannot translate a private address to an IPv6 /96 prefix with that address as an IID (or whatever it's called), then the packet may not be translated to an IPv4 packet with a global address by the 464XLAT PLAT (stateful NAT64). This changes the intent of the sender, and in so doing violates the end to end principle. Practically speaking, it means that a network that uses 464XLAT or MAP-T with IPv4 in the subscriber and translating to IPv4 via NAT64 into the IPv4 Internet, it forces the network or the subscriber to purchase global address space. That's just silly. Let the user use private address space in the home or whatever. 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. -------------------------------------- RFC6052 (draft-ietf-behave-address-format-10) -------------------------------------- Title : IPv6 Addressing of IPv4/IPv6 Translators Publication Date : October 2010 Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG
- [BEHAVE] [Technical Errata Reported] RFC6052 (554… RFC Errata System
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … Fred Baker
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … Christian Huitema
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … Fred Baker
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … JORDI PALET MARTINEZ
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … Fred Baker
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … JORDI PALET MARTINEZ
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … mohamed.boucadair
- Re: [BEHAVE] [Technical Errata Reported] RFC6052 … Christian Huitema