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

Fred Baker <> Tue, 06 November 2018 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE5B6130DC5 for <>; Tue, 6 Nov 2018 01:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QHLwZHYjBZgv for <>; Tue, 6 Nov 2018 01:24:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB526130DDF for <>; Tue, 6 Nov 2018 01:24:01 -0800 (PST)
Received: by with SMTP id k1-v6so5563842pgq.1 for <>; Tue, 06 Nov 2018 01:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gD6iX6OqwlmxS+oMBXecChIp87TdPV29Kroeu4VVJyg=; b=EIasjMqjOcTgoAAUiklPdRktOF5YFcHxVQfSZ6h75A0hIxqCZJ56hJXqYvjHauWRjO 1IP5QhRADOMiJZcagBAGJj7Y87UErmtcquD6/Srey670IjIlTplmVahZRVJCK+9aUxuq ISOo0jM2eEB5SvnX9Uz+6Z8y6aF3RxrAHyle2QayiFGP2IQYxFub5L7LZHh0fn+a5Vdk BVwX3LAtU0VSgbJB96EVxa+lCvnbEwtnk2NqYcg+FXdzDwHb1BQpUPXhGOrrSynEV5Nf kKBUah0DSbU8xvSxppb1ayx3faG/H7urqSHr9g2Ymvu/tcIcUtjQrdPSjEKNCnUUHF8k GxKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gD6iX6OqwlmxS+oMBXecChIp87TdPV29Kroeu4VVJyg=; b=h2baN+oO/0cvGiNwYMeDC4tR1/O1YOfox/6n7CS6uYrj5ywZnryqwqepZj7ZzTTtXx C3lLJvyOjlOLGg547ZNntpzTpYYGycGTDDHdhbOu+gEd4EGzRd5i9FIZ7jbivy95h1f9 wiic67i1mmUkqO3cTT93MWdxWqVRNEYGS7b1izJbbcEG2ve3RPSyHCWkMb9TTiye84bR dt5/GS+kF4PjMA+Nz0tfjmsQW2+Qu/HlixqztpqWcZYnKLL+8ZCwE7jlqExXYSKM6hIR SPbgks1FwSxCWu6mOwt1TRvaXen+1hVhwpENlE+kPRWnJp+bCz7lnOQWb/uwiKLwQOlf /CWw==
X-Gm-Message-State: AGRZ1gJDLrYNzdi7FRe8MBTzfMQhj+77QoTI6OkzIgXLtJpUvz8dTYCI gxFeyoWFuFuQ64pEbjIpBK4=
X-Google-Smtp-Source: AJdET5cCtjdncCWxVVGqV8E41RIf/q3GVXfP0IBwPn+njviOK6/vuPOylvRT11und4ZHzSsj17gruw==
X-Received: by 2002:a62:8a0d:: with SMTP id y13-v6mr25595551pfd.142.1541496241219; Tue, 06 Nov 2018 01:24:01 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:341e:679a:13c5:eab0? ([2001:67c:370:1998:341e:679a:13c5:eab0]) by with ESMTPSA id q1sm28515503pgs.14.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 01:24:00 -0800 (PST)
From: Fred Baker <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_322C1F98-6A64-4837-BDCA-5E08BB34614B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 6 Nov 2018 16:23:55 +0700
In-Reply-To: <>
Cc: Congxiao Bao <>,, MARCELO BAGNULO BRAUN <>,, Xing Li <>,,,, Dave Thaler <>,
To: RFC Errata System <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 09:24:09 -0000

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.

> On Nov 6, 2018, at 3:53 PM, RFC Errata System <>; wrote:
> The following errata report has been submitted for RFC6052,
> "IPv6 Addressing of IPv4/IPv6 Translators".
> --------------------------------------
> You may review the report below and at:
> --------------------------------------
> Type: Technical
> Reported by: Fred Baker <>;
> 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

The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...