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

"Metzler, Dan J" <dan-metzler@uiowa.edu> Fri, 24 April 2015 13:33 UTC

Return-Path: <dan-metzler@uiowa.edu>
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 8F6991A9145 for <v6ops@ietfa.amsl.com>; Fri, 24 Apr 2015 06:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 7Yh7B6KHe5jF for <v6ops@ietfa.amsl.com>; Fri, 24 Apr 2015 06:33:14 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D071D1B2FAC for <v6ops@ietf.org>; Fri, 24 Apr 2015 06:33:14 -0700 (PDT)
Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 24 Apr 2015 13:33:14 +0000
Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0136.026; Fri, 24 Apr 2015 13:33:14 +0000
From: "Metzler, Dan J" <dan-metzler@uiowa.edu>
To: Ted Lemon <Ted.Lemon@nominum.com>, "George, Wes" <wesley.george@twcable.com>
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYouA3ye9AcRTck+xU68IbGwQo50k3BQAgAB1XgCAADeeAIADZz+AgAFS54CAAVsLAIAAFWiAgAAAioCAAA8DgIAAC2wAgABuQoCAAa/cAIAAFKSAgAD9fgCAAAeaAIAAW2CAgAwMloCAAANjAIAC0b8AgAHh/oCAAPtCAIAAyzkAgAXumQCAA55OgIAMjYoagADohQCAAAWfgIAALsWAgAAgvgCAAAlvAIAAASwAgALroeA=
Date: Fri, 24 Apr 2015 13:33:13 +0000
Message-ID: <CO2PR04MB585018697B4DE32875EAFCEFEEC0@CO2PR04MB585.namprd04.prod.outlook.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> <D15D242E.4E4C7%wesley.george@twcable.com> <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>
In-Reply-To: <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nominum.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [2620:0:e50:1001:d4b7:97ba:25dc:ef4d]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585;
x-microsoft-antispam-prvs: <CO2PR04MB58598343B37EFFF9AAB6D97FEEC0@CO2PR04MB585.namprd04.prod.outlook.com>
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(377454003)(24454002)(40100003)(50986999)(74316001)(99286002)(75432002)(93886004)(76576001)(54356999)(77096005)(77156002)(88552001)(33656002)(87936001)(62966003)(2656002)(106116001)(19580395003)(122556002)(90282001)(19580405001)(46102003)(2950100001)(92566002)(15975445007)(102836002)(5001770100001)(86362001)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB585; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:CO2PR04MB585; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB585;
x-forefront-prvs: 05568D1FF7
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uiowa.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 13:33:13.7066 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB585
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/tfjytGE9RgaqEdZuWsQo2-ns2Dc>
Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, 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: Fri, 24 Apr 2015 13:33:17 -0000

See below

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
> Sent: Wednesday, April 22, 2015 9:38 AM
> To: George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions --
> NAT64/DNS64 remains insufficient
> 
> On Apr 22, 2015, at 10:33 AM, George, Wes <wesley.george@twcable.com>
> wrote:
> > WG] Should we be trying to raise visibility on this issue in other forums?
> > For instance, IETF has a formal liaison relationship with W3C. Perhaps
> > an effort there would be useful, even if it doesn't necessarily cover
> > non-web app developers?
> 
> I am skeptical that the people who are using IPv4 literals are active in any
> standards community.   I suppose it's possible, and reaching out and getting
> e.g. W3C to make a strong statement about this would certainly be good in the
> sense that it might shorten the long tail, but I don't think it's going to fix the
> problem soon enough.   I really can't see any way to address this that doesn't
> look something like 464xlat or IPv4-as-a-service (e.g. softwire MAP/lw4over6).

[DJM] 
I see one common theme in this discussion:  "IPv4 literals are harmful."  
If we really want to write a document, that states that IPv4 literals must not be used, shouldn't that be the first step?  Recognize the harm, and make a strong statement that IPv4 literals should/must not be used.
Why dance around these issues?  Seems to me that this is step 1.  The solution is to start by making that strong statement.  If we have tangible information about who has IPv4 literals, why not make that public?  Let people know where the problems are.
If the IETF can't bring itself to do this, then there is no need for this discussion, because it isn't really a problem, and we can all just turn off IPv4 today, or embrace it.

Only after addressing the above, (accepting that it is a problem), is it time to look at what to do in the meantime as a work around.  
Dual stack is a certainly solution if people aren't ready to move to IPv6-only.  It gets around the IPv4 literal problem by simply maintaining support for IPv4 while it's needed.

So then what if you don't have the IPv4 address space, or you can't do dual stack?  Well you have 4 options, depending on your situation:
1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly, but I think we knew that was going to happen.  If you need it, then you need it.  (If you are one of those who suggest that IPv4 will always be there, then do this and embrace your future now.)

2) Use 464xlat or IPv4 as a service, and just realize that not everything has support for that.  When customers call to complain, don't blame the vendor who won't support your technology of choice.  Place the blame on those using IPv4 literals, where it belongs, and point out that there is a document that states it is wrong to implement IPv4 literals; (because IETF took the first step as mentioned above.)

3) Maybe not everything on your network really needs to talk IPv4.  Shift some of your network to IPv6 only, and move the addresses around, to buy time.  If IPv6-only customers call to complain, place the blame on those using IPv4 literals, where it belongs, and point out that there is a document that states it is wrong to implement IPv4 literals; (because IETF took the first step as mentioned above.)

4) Ignore the issue, and treat it as insignificant.  When customers call to complain, place the blame on those using IPv4 literals, where it belongs, and point out that there is a document that states it is wrong to implement IPv4 literals; (because IETF took the first step as mentioned above.)


If however, a WG and the IETF cannot be bothered to make the statement that IPv4 literals are bad, then it follows that IETF really would be saying that IPv4 literals are not a problem.  It would suggest that IETF is not really committed to IPv6-only, and that the plan is to try to scale IPv4 to suit the needs of tomorrow.  My personal opinion is, I think that would be irresponsible, but I'm starting to wonder if that's really where things stand for some.

- Dan Metzler

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