Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Lorenzo Colitti <lorenzo@google.com> Mon, 27 April 2015 01:37 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672BE1B2D22 for <v6ops@ietfa.amsl.com>; Sun, 26 Apr 2015 18:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 86l1uKgRLqGl for <v6ops@ietfa.amsl.com>; Sun, 26 Apr 2015 18:37:54 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 3AC7D1B2D1C for <v6ops@ietf.org>; Sun, 26 Apr 2015 18:37:54 -0700 (PDT)
Received: by igbyr2 with SMTP id yr2so51605227igb.0 for <v6ops@ietf.org>; Sun, 26 Apr 2015 18:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+qD9RFZmfKWKGbhhuP/LzRwirVrmaHx/LjGXjCI3nK0=; b=bY+MR1JTDMUqPnvshcmfkgHn4exjvjhxe1xpCQSjLHRiI1IhipuYtvVQi+CGNzIxV7 ZrayCI/TC19DtgQwwTtIVNmZgGzLCfMOQeUE6ksipSlGELFbfFssO/8tgE3FE75Y4Ay2 DdidpNuiPi0s8r+378RtN2TrpwIi4aq+krAQDxxBcKjxvR8uK2lh+nZqBcbZNF+0qoGR MRehQYpGXms1ci5KmTVeTvGLuyXfELiFCEPnaa+2jEFk24QGIgPj3cInnY2Zo2VsTtpI ljbT4cz728z1grRrBRKlzrgUSoSdbPnIBo+Z5xFkE+0qqlgNlkaB77Ggq3YjfxwvfkzV DKCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+qD9RFZmfKWKGbhhuP/LzRwirVrmaHx/LjGXjCI3nK0=; b=X+SUe4t9S8CpXBcEeCOHmuTaLb33PE3Oa467jIGA3FvMr0NF69x9vbhCJIfeornuFz 2jQP9k5dj9nGayxoSZd2SQ/S1U3MjHiUsN0kKqf2pMLEO2ahPsjPXse/I+tiCD5Yjxz5 Xh7anj+27j/2kAjW73fDwqfIDdE0mmLHH5pLibrTaNL0ZivlAF+JtrKvLLvqRpBTqVmy b1m1s/QQPGNI/Yf6MDCpLT7lIIAD6x90dunOXL/gDWjxNWYYl6YTTGvPdec1vCCQmmp/ qGUwmo4hEKal1wzorq7bBDkMJvry7KkimPaUN4GbmI9pzAZhfI22Uv6uTFynqyPVZvDC zh1g==
X-Gm-Message-State: ALoCoQnBmVX7CbmaAqOXGdTIrxpM9QPX7DrxA3hMO+I8gfkJzgxeQChxAEA/XNakR3tJaRyAkOOR
X-Received: by 10.50.137.97 with SMTP id qh1mr10521344igb.39.1430098673597; Sun, 26 Apr 2015 18:37:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.73.2 with HTTP; Sun, 26 Apr 2015 18:37:33 -0700 (PDT)
In-Reply-To: <CADhXe5302YTxvTSqoOyXJSMiT_vpuhkZPiE3W1Kty8E-Pd89nw@mail.gmail.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com> <CAD6AjGTcKgK8W+VB1H5EQpHaYiKVYXqOz_2RS-w_CiTf9kL2CQ@mail.gmail.com> <CADhXe530+OVZrFZVaYh1-zoRDvJhUd0rf4sx6a2nO8SvKmm6zg@mail.gmail.com> <CAPi140PQ+TF0rED_bQPeS=Fj415qt0-zE2RdGnEL34PAzHyx6Q@mail.gmail.com> <CAD6AjGTjXAeMF6pw5MO2Jrf9B8LJ48D3m1YTVkdBe=_OHjtroQ@mail.gmail.com> <CADhXe51TCqU2eMP4LS3DooZxQDAPD95OVJDXbiU7qvuvKCMq+w@mail.gmail.com> <CAKD1Yr2=zc57+pOA9TFs+0azw0ZR1g67+08T=9eZPHjGXBvgFQ@mail.gmail.com> <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com> <D1441574.4C168%wesley.george@twcable.com> <CAD6AjGQrzoBJrqQfKO0N8Ji=oJ-ZP6Sn88sXf=opJ6bYVmTDZg@mail.gmail.com> <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> <CADhXe51BDuPhc8wdKGmRiBfSnrz7PMtqYXaoDO+5cwLx_xW2tw@mail.gmail.com> <55290E26.8080500@cernet.edu.cn> <CADhXe50zz9EtNtifMh+tN9XT-jKCTJB=vsQ6uG515iddOo7f2Q@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com> <CAD6AjGR65jtZN4NV62p1XnUgoQRC+h=ELmsLcQaFTdrToMtwRA@mail.gmail.com> <CADhXe53VJeUDLpq2fpdndXF1VyPzQLTO=3LEYqbpOFmEPNbCJw@mail.gmail.com> <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com> <CADhXe52acGYR-y7VNpfXt=OQK7uqm1vNyHL3mwGhX8cpaYyW3A@mail.gmail.com> <CAKD1Yr0UAYH+tCc7LCLWbqzqiez7kZNJ8mVH3FB-K1LvnjXVUQ@mail.gmail.com> <CADhXe5302YTxvTSqoOyXJSMiT_vpuhkZPiE3W1Kty8E-Pd89nw@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 27 Apr 2015 10:37:33 +0900
Message-ID: <CAKD1Yr0snsxmHMXazJfKFhYhOpj3a+wNKcGuhHLgLXAhd07ixg@mail.gmail.com>
To: James Woodyatt <jhw@nestlabs.com>
Content-Type: multipart/alternative; boundary="001a11c3f1f46f20860514aacbaa"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ylhSgXedc6r42XkBToXI_1S8m2A>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2015 01:37:55 -0000

On Sat, Apr 25, 2015 at 3:21 AM, James Woodyatt <jhw@nestlabs.com> wrote:

> Let me put it this way. Until someone [you?] writes this draft and gets it
> into the pipeline at 6MAN, this group won't have any real idea of precisely
> what is the CLAT that it might consider recommending be implemented in All
> The IPv6 Hosts. Maybe you don't want to go through POSIX.1 looking for all
> the corner cases when you're writing the draft, but I would recommend you
> do that anyway. Someone will, and you can either have the answers ready at
> the start, or you can have an endless discussion about the unanswered
> questions. I'm sure I can think of lots and lots and lots of questions that
> should be easy for someone who has implemented a CLAT to answer.
>

A statement that it is necessary to go through all of POSIX.1 looking for
corner cases when defining an IPv6 compatibility method is so surprising to
me that I'm trying hard not to see it as a tactic to stall this
conversation. :-)

So, assuming it isn't... what sort of questions do you see around 464xlat
that cannot be immediately answered by just saying that "464xlat is an
unnumbered IPv4-only point-to-point link"?