Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 13 November 2017 14:56 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 A667D129AD4 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 06:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 z7zF0-SXvYyX for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 06:56:17 -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 81FA3128CD5 for <ipv6@ietf.org>; Mon, 13 Nov 2017 06:56:17 -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 E06F82D4F99; Mon, 13 Nov 2017 14:56:16 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C8E88200BFC237; Mon, 13 Nov 2017 22:55:51 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <D4AB0373-B105-4E13-B4CA-94FCDACCEBA6@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_BA113047-D14C-46A8-9404-4204542A0231"; 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: Mon, 13 Nov 2017 22:55:50 +0800
In-Reply-To: <CAD6AjGQdenKMxQ6KBeBGzTu6fAtR9d_x7HuSPYVATcKEOdmNUQ@mail.gmail.com>
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, 6man WG <ipv6@ietf.org>
To: Ca By <cb.list6@gmail.com>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk> <CAD6AjGQdenKMxQ6KBeBGzTu6fAtR9d_x7HuSPYVATcKEOdmNUQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UcujmGjpj75KPuFMkq5rfIjnqWo>
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: Mon, 13 Nov 2017 14:56:20 -0000

Cameron,

> > @Ole, I agree. Just swap the RFC#.
> >
> >>> - Must be able to do NAT64 prefix discovery (RFC6052)
> >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> >
> >
> > @Tim,
> >
> >> If someone wishes to propose text in a new section 10.2 on “IPv6-only” operation, we could include that if the WG agrees.  This
> >
> > It might be useful to have some text in section 14 (v6 router) to accommodate v4 hosts/apps in case of v6-only uplink/ WAN.
> 
> I think the trick for 6434bis is deciding what the scope of the doc is. Such suggestions, while they certainly have merit, are a slippery slope to adding many things, as we’ve seen when Jordi started proposing transition mechanisms for RFC7084-bis.
> 
> Yes , slippery slope indeed. And you would have to deal with me opposing the case being included.
> 
> I have a network with 10s of millions of ipv6-only nodes, none of which can so dnssec (neither android nor ios support it) and the implication that these nodes are no longer ipv6 since they don't do dnssec is ludicrous.
> 
> i think this is just folks tryjng to raise the bar against nat64, again, with nonesense usecass that users and operators don’t want or care about.

I wanted to put the DNSSEC requirement out there. After having talked with a few people here, it seems doing validation on a off-box resolver isn't any worse than what's typically done today. I wouldn't mind dropping that requirement.

You appear to have missed the two other requirements I suggested in the original email?
This wouldn't be the exact opposite of raising the bar against NAT64. It would be to try to ensure NAT64 worked for all IPv6 only nodes.

Cheers,
Ole