Re: IPv6 only host NAT64 requirements?

Jen Linkova <> Mon, 20 November 2017 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3169712E041 for <>; Mon, 20 Nov 2017 12:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 StRzc54lTaog for <>; Mon, 20 Nov 2017 12:34:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEFE6120713 for <>; Mon, 20 Nov 2017 12:34:13 -0800 (PST)
Received: by with SMTP id x68so11593615lff.0 for <>; Mon, 20 Nov 2017 12:34:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zu+bIKdfgeKFwwYm5C40Dp/H0ahEsssK0aghAh5Cp8I=; b=uTsjBcGqFzOqjPWgGqvTv1YPbQnquaEXJSRYxhgbCsjy6+u53HzPBGAsP4OKB+r/y2 FwXig7ltLC0pUguUcdtA4AOFdq/yjcmqAX5p4o0GbhGcCInGPg+F6KBxZch+WnkKwM0M mcfcvX3SZy1JcgJxNeThuiJcF2End7ZHR5x/1qhNc5rHgnvEwkas2gJ2XXQbYtYMLpSf U5fYqg7l1O4wswx25Loc1qlCAYaUCle3ucaH4KFUWc20NLa9FOx7jBbyOorWDH5zjAGG 4hKfbUI0OUb9hQyCTGbujNq/CZE8fNQ/zSnl+zx10k01e9CKw8iOYDyXVmyxFHImcMQZ Iepg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zu+bIKdfgeKFwwYm5C40Dp/H0ahEsssK0aghAh5Cp8I=; b=G9KZp9txmJIIAtZe2uUlJtotZ40Z+W58aNbvayVZVT9fEyBJoP0OpTsG8oprYVCY8G MwSgspk0BuJz2MxHpfSrbR/VzDsPU/qJkInTqOowwSIf0aXEKNIYt2bq00K6r9zAd7g/ +6zZZ4/RbcoF5Pz+5jS7wvMm7GAwDnO+DG6IKak9xj0rrLko1MgF60ihyT6p+ZmAneQI FzwZhFZ+71aLhIiQ2FQSQH4kbj1xETLHJxaLG4OJW4UPm1KvsVhWsMf6GcMyiEngXKXL Qp9FKLubfRaoWiVclhfTC0xKZwcEEqbOTYheKOiLgLHR4i4CTVlTzl9l4Fhc9Y2XeeBh oGpQ==
X-Gm-Message-State: AJaThX4ifdc/85tolHSpQT6nS3vy4MZmOj68nHFNqPNC0lgBR42SaQGk DbQ+Der/oqDLlZ6JxDv2oCBUTvwlcAC9QePRkIE=
X-Google-Smtp-Source: AGs4zMZeDOGOLQnGtKK+CrUFVPmHw8pk+GbyoQuQ8bYpw67nG3whZcaSg8FCEvtcS1duiPspEouMvggGQN6u2dzvMAA=
X-Received: by with SMTP id a4mr2124513lfa.105.1511210051999; Mon, 20 Nov 2017 12:34:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Nov 2017 12:33:50 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <>
From: Jen Linkova <>
Date: Tue, 21 Nov 2017 07:33:50 +1100
Message-ID: <>
Subject: Re: IPv6 only host NAT64 requirements?
To: "Manfredi, Albert E" <>
Cc: Brian E Carpenter <>, 6man WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Nov 2017 20:34:16 -0000

On Tue, Nov 21, 2017 at 7:12 AM, Manfredi, Albert E
<> wrote:
> Very instructive thread for me, I must say. I'm getting this sense of urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some ISPs.
>Ultimately, it's not up to 6man to decide.

I do not see this thread as 6man deciding that everyone is to get rid
of Ipv4 right now. I see it as 'there are networks deploying IPv6-only
hosts and 6man is discussing how to help hosts to operate in such

>It's up to device vendors,  and up to the deployed base of devices.
>The IETF can only suggest, and ISP networks have to meet the real world needs.

People from the real world is coming to IETF saying 'we are deploying
Ipv6-only hosts' [1] [2]


>> Dual stack in every hotel room in the world is viable, from the
>> hotel guests' point of view.
> This seems the most practical answer, whether it's a client server model, such as in a hotel room, or a peer to peer network. In a mostly peer to peer network, the normal case would be for IPv6 hosts to be introduced gradually. I'm not sure how anything other than dual stack can work, in this case. If the goal is to have continuous robust operation of the network, during an indefinitely long transitional phase, because no one up the chain could care less about the nitty gritty, they just want everything to keep working flawlessly, then what motivation would there be for anything other than dual stack? The only practical solution is to introduce IPv6 hosts only if they are dual stack. And then carefully, on a case by case basis, individual subsystems that do not need to interoperate with IPv4 subsystems can shut off IPv4.
> I realize that such transition drag on for years. But again, in the greater scheme of things, this matters very little to those who must make sure the systems work at all times.
> Bert
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

SY, Jen Linkova aka Furry