Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Wed, 15 November 2017 23:24 UTC

Return-Path: <otroan@employees.org>
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 81A12126D0C for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 15:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oeOe6m72WktY for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 15:24:53 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1F9120727 for <ipv6@ietf.org>; Wed, 15 Nov 2017 15:24:53 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 269242D512B; Wed, 15 Nov 2017 23:24:52 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AF0B4200C29B9B; Thu, 16 Nov 2017 07:24:52 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <AEA51AB8-63B0-4CAA-A085-5290F5987E92@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_DBAAB5F7-48F1-4D24-BA7F-A33BE1C17E3C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Thu, 16 Nov 2017 07:24:51 +0800
In-Reply-To: <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
Cc: Jen Linkova <furry13@gmail.com>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
To: james woodyatt <jhw@google.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>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tV94VV3oeqZ-LJCTbFtmrZa8a08>
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: Wed, 15 Nov 2017 23:24:55 -0000

James,

>> 
>>>> 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.

It's not for the lack of trying that IPv6 isn't adopted everywhere.
As IPv4 address sharing ratio's increase, say good bye to endpoint independent NATs, IP fragmentation...

But now I have to first implement a PCP client, discover the PCP server address, and then finally get the NAT64 prefix. ;-)

>> Is PCP successful in IPv4?
> 
> Well, there was this: <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> 
>> Or does it even work well with A+P based solutions?
> 
> Designed expressly for it.

Ah, yes so it does.
Doesn't work well with address and port dependent filtering though.

Cheers,
Ole