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

Mark Andrews <marka@isc.org> Thu, 26 March 2015 03:46 UTC

Return-Path: <marka@isc.org>
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 740121A7004 for <v6ops@ietfa.amsl.com>; Wed, 25 Mar 2015 20:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 JU8-NSkBSMCF for <v6ops@ietfa.amsl.com>; Wed, 25 Mar 2015 20:46:07 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8438D1A7001 for <v6ops@ietf.org>; Wed, 25 Mar 2015 20:46:06 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 5EEED1FCC87; Thu, 26 Mar 2015 03:46:03 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5852816005C; Thu, 26 Mar 2015 03:53:14 +0000 (UTC)
Received: from rock.dv.isc.org (unknown [38.96.210.190]) by zmx1.isc.org (Postfix) with ESMTPSA id 30C48160042; Thu, 26 Mar 2015 03:53:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by rock.dv.isc.org (Postfix) with ESMTP id 29A772C026D2; Thu, 26 Mar 2015 14:46:01 +1100 (EST)
To: Andrew šŸ‘½ Yourtchenko <ayourtch@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com> <alpine.DEB.2.02.1503200639340.20507@uplift.swm.pp.se> <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <A0BB7AD89EA705449C486BDB5FDCBC7B28518DD8@OPE10MB06.tp.gk.corp.tepenet> <550F1F1F.3060703@cernet.edu.cn> <CAD6AjGSxk-Hrf_NBOjpV-jvraG+xSA4p1j-AO+FQFcVGzuf1Lg@mail.gmail.com> <CAKD1Yr3ywVy_00GYuw4Eq6cW_ZeL16bxpquaWWDMgSz44LagAg@mail.gmail.com> <CAD6AjGS-QMi+3oVGWDxnSMhEJH=VymwcF=PwKLdwFRxwHpp_-Q@mail.gmail.com> <CAKD1Yr3Fhnx3XaXouK57gupGOzodKGb0quhQxaf76NjWxSp3WA@mail.gmail.com> <CADhXe51MUB-czeCtpc63E0cHPpb_39Vv0o2Y57EVU2w_makP5Q@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>
In-reply-to: Your message of "Thu, 26 Mar 2015 01:08:00 +0100." <CAPi140PQ+TF0rED_bQPeS=Fj415qt0-zE2RdGnEL34PAzHyx6Q@mail.gmail.com>
Date: Thu, 26 Mar 2015 14:46:01 +1100
Message-Id: <20150326034601.29A772C026D2@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/sJt1fTzA8vbXTqEks-jMBD88KZc>
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: Thu, 26 Mar 2015 03:46:08 -0000

In message <CAPi140PQ+TF0rED_bQPeS=Fj415qt0-zE2RdGnEL34PAzHyx6Q@mail.gmail.com>, =?UTF-8?B?
QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= writes:
> On 3/24/15, James Woodyatt <jhw@nestlabs.com> wrote:
> > Cameron, Lorenzo
> 
> 
> > Cameron writes, "IPv4 dependence is hurting the internet and allows for
> > middle-box proliferation."
> >
> > My reply: "I agree that IPv4 dependency is hurting the Internet, but I 
> also
> > view 464XLAT as a scheme to prolong the viability of IPv4-only software.
> 
> One of more reliable ways to drive the IPv4-only software sunset would
> be to emit a compiler warning whenever the static analyzer discovers
> an AF_INET socket being made.
> 
> This warning would come with a corresponding developer page explaining
> why AF_INET is the new strcpy(), and give the correct examples of how
> to implement the dualstack networking correctly.
> 
> But even absent the compiler magic, I would like you to consider the
> following logic:
> 
> 1) One can say "dualstack" access network promotes IPv4-only apps
> stronger than "IPv6+CLAT" access network.
> 
> 2) Universal availability of CLAT would allow the percentage of
> "IPv6+CLAT" networks
> to increase, because now a network can just flip from IPv4-only to
> IPv6-only+CLAT at little or no cost.
> 
> 3) This would increase the overall share of IPv6 while decreasing the
> share of IPv4 *at the same time*
> 
> 4) This will increase the attractiveness of using AF_INET6.
> 
> What do you think ?

#ifdef KERNEL
#define AF_INET X
#endif

#define AI_DEFAULT      (AI_V4MAPPED | AI_ADDRCONFIG)

> --a
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org