Re: IPv6 only host NAT64 requirements?

Ca By <cb.list6@gmail.com> Mon, 13 November 2017 13:54 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 46678129584 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 05:54:42 -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 kXw-DoOKSnVR for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 05:54:38 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 4362412957A for <ipv6@ietf.org>; Mon, 13 Nov 2017 05:54:35 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id q1so13453921ywh.5 for <ipv6@ietf.org>; Mon, 13 Nov 2017 05:54:35 -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=Qha5GPfKv4AYIqjnWDKoPiv7ZFjnCImJTHZKLMPylBM=; b=LWj/2nnPPIZnaLpbd/VQ8GGsTF96Iy99pILj+pC0A8MJdWFYXV1+2co2tA7xprB2iv 2CNZ33qxM5Fn20+aIiKLncXaVOOU3hXp9+vZvCWHUueISVTIMJ/tqnHBl+WrSuiGmODR +T7w9BaeliYkYAF1qfg+BRE6/Rj5h7FUUljY35v8dBNYe1yK3uhB+JSwTXVRsgY6ZcG4 LK5GfxwuftMrbS5xqvnBL93fG0YaTpEyQoUesnd1HF8m1HK609hNOmnWSdd3w12bSMit 9fbEpZUbgJwcQpRatKurOSrcGMlZKaynRlxSVMa7nSvxVTIDDZOwOkP3BSwGZVAt2ELM nKLA==
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=Qha5GPfKv4AYIqjnWDKoPiv7ZFjnCImJTHZKLMPylBM=; b=Qm6I+uFcs020CX9o5ZHKK4F0fTg6k3YibGIXua05SaR7y3TlABRk+SrB9eg3xPMvGv lxCPcTFGDamF8JIVqZt5E0S46s7fagAFY5wZSlyK5v8MZYcssVveboQgjUhuLW9/mNHw 1Ox8Jk9p0w5ckIArQQRHODYSDsM4YXZ/qfO8IgZgim62jjSmfqkVxrbXLUimqUfxJyZJ Ov0TNPaqws/aLsTtI6TtS+HvlWVh+5F7pXn4rSW800SQf2eeeyfLIq7/AP5EXqlopogL yMdu0/xChl2SNZ8ba7nIJ8BdgJJRogCbykOfJF6peZ6Ee5RJamZDZbbmwJkeEtH9+bVi wyyA==
X-Gm-Message-State: AJaThX57z1jAM6fziylbohNesN0N8KA0lVX3O2AZW6eEQUoWVgBNib4a MZhnxkU4Bh5BiL9Z6+n2OpnaCONaFEP2sVtNRnA=
X-Google-Smtp-Source: AGs4zMZE7bA4YBqDiarGTvSQPZUhcbrOf2191jS+CMZOMMqLcXqePtOWYiNDn5ZVeNhpomXNpfs+r98rlDWzFteQq0E=
X-Received: by 10.37.130.11 with SMTP id q11mr5438079ybk.50.1510581274315; Mon, 13 Nov 2017 05:54:34 -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>
In-Reply-To: <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>
From: Ca By <cb.list6@gmail.com>
Date: Mon, 13 Nov 2017 13:54:23 +0000
Message-ID: <CAD6AjGQdenKMxQ6KBeBGzTu6fAtR9d_x7HuSPYVATcKEOdmNUQ@mail.gmail.com>
Subject: Re: IPv6 only host NAT64 requirements?
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: 6man WG <ipv6@ietf.org>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Content-Type: multipart/alternative; boundary="089e0828c20c429dee055ddd9cbf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ehsYY36cpV3zhQKbOdfstgzu-l0>
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 13:54:42 -0000

On Mon, Nov 13, 2017 at 5:43 AM Tim Chown <Tim.Chown@jisc.ac.uk>; wrote:

> > On 13 Nov 2017, at 13:27, Rajiv Asati (rajiva) <rajiva@cisco.com>; wrote:
> >
> > @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.

Sad


> Steer from the WG is, as ever, very welcome.
>
> Tim
>
> > Cheers,
> > Rajiv
> >
> >
> > On Nov 13, 2017, at 8:08 AM, Tim Chown <Tim.Chown@jisc.ac.uk>; wrote:
> >
> >> Hi,
> >>
> >>> On 13 Nov 2017, at 02:50, Ole Troan <otroan@employees.org>; wrote:
> >>>
> >>> At the hackathon there was quite a bit of testing of IPv6 only hosts
> with access to the IPv4 network via a NAT64.
> >>>
> >>> While many applications work well on a classic IPv6 only host, there
> are a few things required to make all applications work.
> >>>
> >>> - Must be able to do NAT64 prefix discovery (RFC6052)
> >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> >>>
> >>> This is to be able to deal with IPv4 address literals. Which are
> common in protocols like SIP/ICE/STUN.
> >>> These can be implemented directly in applications, or it can be
> implemented in the host stack (although application might still have to
> change).
> >>>
> >>> - Should do local DNS64 to support DNSSEC (RFC6147)
> >>> (if you do validation).
> >>>
> >>> A DNS64 service in the network looks like a man in the middle attack,
> so to support DNSSEC, validation should happen before synthesizing, and
> must be done on the host itself.
> >>>
> >>> If this is the direction we want to go. Encourage IPv6 only host
> deployments (as opposed to dual stack hosts), are these requirements we'd
> like to add to the IPv6 node requirements document? Somewhere else?
> >>
> >> draft-ietf-6man-rfc6434-bis-02 includes a (very short) Section 10 on
> transition, see
> https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-10
> >>
> >> 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 could be something
> for TimW to add as a question when the draft is presented in 6man.
> >>
> >> Tim
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>