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

James Woodyatt <jhw@nestlabs.com> Wed, 22 April 2015 22:36 UTC

Return-Path: <jhw@nestlabs.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 04F241B3ACD for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 15:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 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] 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 TR1BltP9gTHp for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 15:36:40 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 A33301B3AC9 for <v6ops@ietf.org>; Wed, 22 Apr 2015 15:36:38 -0700 (PDT)
Received: by wgen6 with SMTP id n6so582560wge.3 for <v6ops@ietf.org>; Wed, 22 Apr 2015 15:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=n03YUufqemy2HGZ3Gd9r5udgU0jLGgiJ35Dcmxg0k1s=; b=aUj03qicTJbpggDoD0Tp0LBhVw4wORfik0ZCEfjKbnJ+Fy4D32WCLKuM7IA/bgIfB0 6b+v+JyNVTqxEz/XYXO9imhODiPZR8bW3BQmR2spXR6Sg0VEZzVW7eWPWSOYBH0mKJae 4+5SFnkTyUtwJCGkMrVsVlE3Vr+CLiA4aV330=
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:date :message-id:subject:from:to:content-type; bh=n03YUufqemy2HGZ3Gd9r5udgU0jLGgiJ35Dcmxg0k1s=; b=F/I/o8Ti0ikx0zhazwlVmg7eToPdXwHou14uxiMSMIej2yCjTuNU7ZL04wgibhC5aZ cXnxdXl8ZBtsaftzHcz6o4/vH4QSIgWZgRnNIxWBRKXFqcgHXTb09e66y/H5giHGtv1k It16rV2YezrNLNjCMYJ0xAf/vTGRGcDPyw17EhDvAYiywJ0aKnpxOo2Eb++5jqagGHWK d4vQxJIEqHRe6ug8yGYsvffEShrRfsVZvylzXXK6jdelbe8IokwqZlCAcsQCheC35i/z o1IVFIap2cLedds7WXcgNNSOcuuYhdDTfw1bpZFi4ZcZuaCEth0uDqrCDOX2eDnetdRV kCeA==
X-Gm-Message-State: ALoCoQkA9VYa+kbaBS8zkmeD2NlgFzo6/KaI/DVXByBlEi2efWcVGR0Gf6zJGB+jjtbZZxwWa+pH
MIME-Version: 1.0
X-Received: by 10.194.71.208 with SMTP id x16mr53462231wju.129.1429742197350; Wed, 22 Apr 2015 15:36:37 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Wed, 22 Apr 2015 15:36:37 -0700 (PDT)
In-Reply-To: <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.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>
Date: Wed, 22 Apr 2015 15:36:37 -0700
Message-ID: <CADhXe52acGYR-y7VNpfXt=OQK7uqm1vNyHL3mwGhX8cpaYyW3A@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bfcead0cb3d27051457cbd6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/NFSrVAch87XawWfsUUgLVClP3Q4>
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: Wed, 22 Apr 2015 22:36:41 -0000

I'm not optimistic that consensus would emerge for that recommendation.

Again: I think if 464XLAT promoters want to direct their energies on this
topic in the most useful direction possible, then the best course of action
would be to prepare drafts for updating RFC 3493 and RFC 3542 accordingly.
In particular, I think it's critical to have a clear understanding of
precisely what features of the PF_INET interfaces are expected to be
handled by the CLAT function. If the IP_PKTINFO socket option, for example,
is expected to be unsupported, then it's important to know that. What does
the CLAT do with IPv4 link-local scope addresses? What about the
SO_REUSEADDR option? A good place to start would probably be to go through
the entire POSIX.1 standard, and for all the IPv4 networking interfaces,
describe what is and isn't supported by the CLAT function recommended by
IETF.

If this stuff is going to be a standard feature of host operating system
for the foreseeable future, then I for one would like it to be standardized
as well as the current IPv6 programming interfaces are standardized. I
don't think that's an unreasonable position to start.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering