Re: IPv6 only host NAT64 requirements?

Ca By <cb.list6@gmail.com> Mon, 13 November 2017 16:16 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 3887A129B13 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:16:38 -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 XxA3UCWo0Rdo for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:16:36 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 E1DB41200F1 for <ipv6@ietf.org>; Mon, 13 Nov 2017 08:16:35 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id i198so13844818ywe.7 for <ipv6@ietf.org>; Mon, 13 Nov 2017 08:16: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=eg/YaS2s8HZtRymfXBSehoxeap87Ue3WadDisO5Kp5o=; b=Zz68GqESaQpp4Tg4ilKl7Lh/ydJ8AnK3DyEy5u2eWsul66ZnLh/XYHuj/UPZgZAGMi 4ne2NDiB4l18P2JsW6QFDFDJFeqDhmboZplzKBvNNUwTx5VlEUMT+pFa0bjMt0gcgBuT 99ycUT7LcoycEIV5pAJxrQGl/RGkllPme9xr7v0xTwP0RECE8Un2j2KbelbU3j17Kyme qKoeygRJADLKVPGaumn9+kbtff2tosZ67CMlVfsmlp8s+zwpZU2+deMlMykkClXGlxIC 9X/y6+HjLx6eAQcKRm24NHfItAcxgs285I2rgFe9bJAjaIGL2Q5CaCumqB9FBVgcCE2+ 9jPA==
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=eg/YaS2s8HZtRymfXBSehoxeap87Ue3WadDisO5Kp5o=; b=kWh4MVxssUiLdp0CeRYU0RPvi8vyqtwwgRbRqYedR93ptArNVEdMLvfF5ypixdRBVK PkBbAbKoisZoCsqpc2ysiYnWKe7W4vYKketq/OcALVwDYcJdILwAEjtaGbuBFTo4cwE8 9jHPZBm1nSgRE9Qogh3X4RqmA5Ip5QyWy2d8VMA5ydydLAQkHFU9M1oGnxCWcVa6NJP7 wm7DNxjrqrpMJVCDsaVohYQ2mUm6gpo1s3ddnlLWq8K1ZH3C77hBtA5FtMDSeF3hj16B TYiJ8ZuwqtHMxGty9KWAOXlv0J53aPkAEPP0zVob8IQ2wyw8JU4nlgy0MfUD0DSBt4po /vpA==
X-Gm-Message-State: AJaThX5mMuquxtrvuaM+gQVbBJEMtOaCrtK8mnH7j4TCfcQxG+JS4Npm tsxp7jJZZMEDb0uqAGPgFxnTb1+xtjOnsBCQ4JE=
X-Google-Smtp-Source: AGs4zMYZAeJO4x31xWyM7VryLMLg5oXPdYH8aO1AmbNM+JJ5ofMB2oKeSBtlBQY80cHKnntY8maDjzdOLhJ5R7KeVOc=
X-Received: by 10.37.130.11 with SMTP id q11mr5722395ybk.50.1510589795122; Mon, 13 Nov 2017 08:16:35 -0800 (PST)
MIME-Version: 1.0
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <CAD6AjGR3FrVST4nyDDSOzFW8txK974FiFTtzt-4_GJwUvoA--Q@mail.gmail.com> <B1B5B9A2-9108-48C8-AEFF-B2B105B13485@employees.org>
In-Reply-To: <B1B5B9A2-9108-48C8-AEFF-B2B105B13485@employees.org>
From: Ca By <cb.list6@gmail.com>
Date: Mon, 13 Nov 2017 16:16:24 +0000
Message-ID: <CAD6AjGRgsmsduL9_jyzWjKJhKsBiFuVOZat0_E_Yys59V5-jPg@mail.gmail.com>
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Content-Type: multipart/alternative; boundary="089e0828c20c23c88e055ddf9877"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gnpDJqzwitI0itWhr3tjiTprpxA>
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 16:16:38 -0000

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

> > > In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
> > >> 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
> > >
> > > Personally I don't like how NAT64 requires an IPv6 stack to deal with
> all
> > > kinds of IPv4 issues. So for IPv6 node requirements, it should not go
> > > beyond the level of MAY.
> >
> > Yes, that's certainly the bind we are in. Are we going to require all
> IPv6 only nodes to be able to communicate with IPv4? And what does that
> entail? Do you have examples of "all kinds of IPv4 issues"?
> >
> > Apart from the requirement of NAT64 prefix discovery and IPv4
> synthesising, is there anything you don't need to do anyway?
> > I can't quite see ICE/STUN going away, just because the end to end path
> is IPv6.
> >
> > 1. ICE and STUN are apps, and they should be fixed in the app layer not
> network.
>
> Right, AFAIK IOS solves it at the stack level (with some application
> requirements). So this can go both ways.
>
> >
> > 2.  ICE and STUN work great today with v4 and v6 peer candidates,
> especially when combined with their close cousin TURN, in TRAM WG and
> specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>
> But we did find ICE/STUN applications not working in an IPv6 only + NAt64
> network at the hackathon.
>

The ICE needs to be paired with a dual stack TURN server, i believe that is
the correct way to handle this scenario

That way, the peers always see v4 and v6 candidates

The issue you saw was that the v6 host was only presented with v4 peers
from ICE?



> > While I'm also concerned about the consequences of carrying IPv4 debt in
> all IPv6 implementations, the alternative seems to be that we are stuck
> with Dual stack forever (for some definition of forever). This would at
> least allow us to move to single stack IPv6. Which appears to me to be a
> step forward. And we're very close to that already, and there are millions
> of devices already implementing it.
>
> Cheers,
> Ole
>
>
>