Re: IPv6 only host NAT64 requirements?

james woodyatt <jhw@google.com> Thu, 16 November 2017 00:13 UTC

Return-Path: <jhw@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508851293D8 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 16:13:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ZtfDNiQuycUf for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 16:13:11 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354F8128E19 for <ipv6@ietf.org>; Wed, 15 Nov 2017 16:13:11 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id t69so9246599pfg.4 for <ipv6@ietf.org>; Wed, 15 Nov 2017 16:13:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8kX3BuEXm5OZvINTPKBCUDmHuz0vAPJlMe0ysFcTe/k=; b=P1DD4HecgsIzCwmd6c4qzy8F/xWeKVnkXlnhpY/WxydpgXqR/Zs72PfaXMbNYjTu6n nQaMz0/4grUV6zHBTziRA1dmWBKtT/yuNQoWV5shMl5oxYALPnaLMhyooH4krHBzOGVv 38cbxh1dvSyGoa8wblgsUOcISTo8VySfYjmfXf2bl1NHOE77H6vvaB+z+TyNRWk0RyMd bBGV7FbbjxfKWVNy4JuiXaJ9Dp6PkHx5FMJg+tGXFvFsYzzXdpmEzmmfmzPR+oG4DOsj pBfCdwqnIG4ZSctwPPKC2cEYP94/iDxx0ooaFoFMJIsJ0T1fly6yVZmDsEtjsvVRLImu Qgbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8kX3BuEXm5OZvINTPKBCUDmHuz0vAPJlMe0ysFcTe/k=; b=mukOfxuLigsec+zJn1hUfGu1pnD8jYiOQbCUQ2rvKUaz25KdoDqRqF08L1juCeqTdu nG2Ch1dNy43vwxVlxG+A+top7ZEqFXPIJotITQj/LV9YVgFI0IHUiVMnYIHUoQQ3K+hT vwL+aPpGyvg/8jneYPhYCgdnsBLAI0xmIigKN1msRxYCOJcryZyc3V6APdyM3X5gPQ7n 6gKgO3yUVI92/fkdOXMrC+he3eisQL3bvYnh9i+h+P5ErQXSDQ25X9kZ8MaKiAZPa4JT qeWs5+RGeHfvUSrHXPdsWnEu/Rs4t4VDWaqHrq5VsPG13AkDOC6quLEQlr0kipcbWSWh viMw==
X-Gm-Message-State: AJaThX4TOOvBZYu8iTrCO0Ar7EZGhaZLzFSlu85cA35CFWPNFCyT0EAh kyMJh4f1xsLkEA7oZ80FvZIZvqE0JVs=
X-Google-Smtp-Source: AGs4zMYSak7b2oDCgFRZq7HZOZNQQcO7LHEZDWPSnxWBEU983c0sv396HLbGuu6cGdPxUkWP4curzw==
X-Received: by 10.101.92.202 with SMTP id b10mr17678517pgt.164.1510791190401; Wed, 15 Nov 2017 16:13:10 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by smtp.gmail.com with ESMTPSA id i125sm1067057pfe.151.2017.11.15.16.13.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:13:09 -0800 (PST)
From: james woodyatt <jhw@google.com>
Message-Id: <022434F4-43DD-4455-90C2-C7774EF19B23@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35D2485E-25A5-4BF2-97DC-FAE8D5BAD83A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 16:13:08 -0800
In-Reply-To: <6cb115a1-dec8-f31c-2865-7aca032bc771@gmail.com>
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <6cb115a1-dec8-f31c-2865-7aca032bc771@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UGpG5QVKQS8qXUbdyXr71930b0g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 00:13:13 -0000

On Nov 15, 2017, at 15:36, Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
> On 16/11/2017 12:04, james woodyatt wrote:
>> On Nov 15, 2017, at 13:47, Ole Troan <otroan@employees.org>; wrote:
>>> 
>>>>> IMHO the optimal solution is:
>>>>> - the network SHOULD provide a host with NAT64 prefix information in RA;
>>>> 
>>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye gods, this is the very last thing that should be jammed into RA messages.
>>> 
>>> Do we really want PCP in IPv6?
>> 
>> If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.
> 
> I have a more practical view. We can't assume that IPv6 hosts
> grok DHCPv6, and we can't assume they grok PCP. We know that they
> grok RAs, although of course they need an update to grok a new
> option.

Simplifying... hosts need an update, and the question we have had on the table for four years now is what update to push. What if answers were something people wanted to read?

> So it seems to me that there isn't much doubt about the
> need for an RA based solution.

It seems to me that, of the various solutions analyzed by RFC 7051, that particular one comes with a raft of problems, which were the reasons we have RFC 7225 now.

	<https://tools.ietf.org/html/rfc7051#section-5.7 <https://tools.ietf.org/html/rfc7051#section-5.7>>


--james woodyatt <jhw@google.com <mailto:jhw@google.com>>