Re: IPv6 only host NAT64 requirements?

Ca By <cb.list6@gmail.com> Mon, 13 November 2017 15:37 UTC

Return-Path: <cb.list6@gmail.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 5DD17128B8D for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 dnsw5-hsQOpa for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:37:08 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 43E201286B2 for <ipv6@ietf.org>; Mon, 13 Nov 2017 07:37:08 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id g204so2075752ywa.6 for <ipv6@ietf.org>; Mon, 13 Nov 2017 07:37:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w3CFepmWv3YPVefVoDlRFN6If5Fn1noqwiltgzVIo+w=; b=aM2AJQ2mWtg433YerGxxOmdmWOerKfpIgtcCRmLP4DwNO/IauQBpzsQa5VgasRR0FT I/BnA/soPIor2gUX6bk6MxkWiQI3pmtXoJgd9m3l/V8uiRgs20ZtweKA+S/osD6Df8wF QTNOOKlPuqcHAJ7YLkYtIYChItWqIMOhPhcM30Iuqhfo+gY8NzOsmt3684jgYHdqN6DU wX7V1EkxkAc/PChaWVTiv3zDI0GKZ8cU6O3XmgPJC0MCQRjE7nGYc+WXvJmV0ouOfTh5 6GXYg6Zyvehhor7OZ5EUpoS7JU400oBLaavv1cdk2d9ZFzSzvxR9gojEtdMwOratlAzd oDTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w3CFepmWv3YPVefVoDlRFN6If5Fn1noqwiltgzVIo+w=; b=ktA7AzA3T3ySoLwysczJQ2zJ8uKdSSzO5R7eIJvF4l6v3/qIWyR804lzkBiU06iOD2 fwgLw9i9k61gZ2VZjDElOdLJc6cXgNLd6G7MsVKuynFyLjZIcdRPmfaECREylYUCXO1d 6Pg4LFsyU7z7w3LUNG14ugONPjJfr/J+0o2frTnE36WWOwHfXA3+fqda/KTlw61nxkVJ RqjBz7rWWM7V9oX4OKHzo15tXDy0SlldsfF7BBl2TbzHlKHwF2lh2/PkDUFkFNS3NGXr Wp90U9CGcXjgbAybt+rCTToKaPpTxJSxb3/7CJuDw4AvLiKdSjVlw7mtAnbJ5W89rTvW 0t7g==
X-Gm-Message-State: AJaThX7JNto1kKHNcn3ezQ2WPVXHtvBT+hkw5eiAXCIPBQThrBiE3ZN/ C6j/1yggbKZb+qNab2nivBsY60PgJ726TAuHCP8=
X-Google-Smtp-Source: AGs4zMYM0EbTyQ5z6WZ8whRGlqar6+B/n/EQ1b2WKsTmF5kKfg1vTxTmODE6TuUhrf3fUgUJW0wj15kU4MLOSUWtcXg=
X-Received: by 10.13.214.130 with SMTP id y124mr2355562ywd.234.1510587427536; Mon, 13 Nov 2017 07:37:07 -0800 (PST)
MIME-Version: 1.0
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> <D4AB0373-B105-4E13-B4CA-94FCDACCEBA6@employees.org>
In-Reply-To: <D4AB0373-B105-4E13-B4CA-94FCDACCEBA6@employees.org>
From: Ca By <cb.list6@gmail.com>
Date: Mon, 13 Nov 2017 15:36:56 +0000
Message-ID: <CAD6AjGSzXPEN1Snu9=Acnc6xggJ3=9T4Zks1H=+pfNOyt-qaoQ@mail.gmail.com>
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Tim Chown <Tim.Chown@jisc.ac.uk>
Content-Type: multipart/alternative; boundary="94eb2c0761ce0541f4055ddf0b84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VsrZrVi6qJ6OHx9dOHGxdiATaPY>
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 15:37:10 -0000

On Mon, Nov 13, 2017 at 6:56 AM Ole Troan <otroan@employees.org>; wrote:

> 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


Ole,

Yes, the first 2 are not objectionable and are already well know,
documented and deployed as part of various transition solutions.

My feeling is the plane is already in flight and operators do not need any
additional guidance / confusion from the ietf.

In short, this is a solved problem and the industry needs more stability
and less tweaking .... especially in something fundamental like the node
definition

http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png




>