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

"Heatley, Nick" <nick.heatley@ee.co.uk> Mon, 27 April 2015 09:18 UTC

Return-Path: <nick.heatley@ee.co.uk>
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 0FBBA1B2F6E for <v6ops@ietfa.amsl.com>; Mon, 27 Apr 2015 02:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UEMBFj1rvxoH for <v6ops@ietfa.amsl.com>; Mon, 27 Apr 2015 02:18:18 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D921B2F5C for <v6ops@ietf.org>; Mon, 27 Apr 2015 02:18:17 -0700 (PDT)
Received: from [85.158.136.35] by server-16.bemta-5.messagelabs.com id 78/66-25453-8DEFD355; Mon, 27 Apr 2015 09:18:16 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-14.tower-125.messagelabs.com!1430126295!37630343!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received:
X-StarScan-Version: 6.13.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2325 invoked from network); 27 Apr 2015 09:18:15 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-14.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Apr 2015 09:18:15 -0000
Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id <B553dfed50000>; Mon, 27 Apr 2015 10:18:13 +0100
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id <B553dfed6000a>; Mon, 27 Apr 2015 10:18:14 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Mon, 27 Apr 2015 10:18:14 +0100
From: "Heatley, Nick" <nick.heatley@ee.co.uk>
To: "Metzler, Dan J" <dan-metzler@uiowa.edu>, 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: AQHQYtCVneMUqIFM3UWKOHw0TbKROp0lUOcAgAA3nwCAA2c/gIABUuaAgAFbCwCAABVpgIAAAIqAgAAPA4CAAAtsAIAAbkKAgAGv2wCAABSlgIAA/X4AgAAHmQCAAFthgIAL+9OAgAADYgCAAtG/AIAB4f6AgAD7QgCAAMs5AIAF7pkAgAOeT4CADJ5Bd4AA3PKggAAAeoCAADxNoIAAEzYAgAAJbwCAAAEtAIADEpSAgAAVCCCAAeS6gIABsX1Q
Date: Mon, 27 Apr 2015 09:18:14 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303E90298@UK30S005EXS06.EEAD.EEINT.CO.UK>
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> <CO2PR04MB585018697B4DE32875EAFCEFEEC0@CO2PR04MB585.namprd04.prod.outlook.com> <6536E263028723489CCD5B6821D4B21303E8F236@UK30S005EXS06.EEAD.EEINT.CO.UK> <CO2PR04MB5857C39B938B7F41AD20EBAFEEB0@CO2PR04MB585.namprd04.prod.outlook.com>
In-Reply-To: <CO2PR04MB5857C39B938B7F41AD20EBAFEEB0@CO2PR04MB585.namprd04.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/BCQYs0daZTXkd1dXj-TwJqhIWzE>
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: Mon, 27 Apr 2015 09:18:22 -0000

In short I am reacting to the premise in option 3 & 4 that things are allowed to break for customers. I believe network operators will simply not move to the future mode of operation.
I believe the way forward lies somewhere in your option 2, but I question the assumptions, as your options maintain status quo without considering changing the game in our favour.
I certainly don't expect support in every OS (let's call it the the Win95 situation - old OS wither and die, no attempt of retrospective support) but I think this community needs a view on the critical success factors (breadth of support for the future mode of operation in new and emerging environments), which I think this email thread was about. I think Cameron called it a "unified front".

To give a longer answer:
I think Ted is right when he says he is sceptical that the purveyors of IP literals are active in any standards community.
Any message given out on "literals as harmful" to these intended recipients, how is this message any more relevant than the IPv6 message in general?
I see no more reason to heed the message of "ready content for v6" as for "purge your app/content of literals".
(For all intents and purposes, readying content for v6 (i.e. dualstacking content) appears to me to fix the main issue so perhaps there is no need to change the message at all
So it is just detail - "ready content for v6, by the way making content protocol agnostic is the way to go").
Now given the state of content and v6 readiness in general, I don't see we will see any more joy and any faster progress on driving out literals. Eradicating literals will be on the same timelines as readying content/apps for v6. I we already know the chicken/egg situation there.

>From what I have seen of IP literals they are not insignificant. Even if well-known apps were healed, and well known hosting sites policed, there still appears a long tail of unquantified content.
As an operator I cannot make a value judgement on the quality of this long tail, and it appears significant.
So I question the premise of option 4. I cannot see an operator moving to this future mode of operation and allowing the literal problems to occur. Any customer impacted will see the network as deficient, not the OS, not the content. This is not in the interests of the network operator and if put into practice will drive customers away. It cannot see it happen for paying customer networks.
Back to chicken/egg problem.

While option 1 exists as tactical, I don't think we need to discuss this further here.
Within options 2 I think a way forward may exist.
We need a gamechanger to kickstart this move to the future mode of operation (the final mode of operation) - my personal opinion is that the gamechanger is translation residing in the OS as per 464xlat/MAP-T, and I am encouraged by the other discussions on this thread. I'd like to think there is a BCP in the making here.

To those who think not eradicating literals means we never move to the future mode of operation, I think we are already in that hole - we are already in held in stable equilibrium of "perpetual dualstack". If I was building the next wave of Wifi networks in the next few years I would wish to go IPv6 only because it is simple and cheap. But I'd be unable to do this with the current mode of operation. This is wrong and we need to aim to solve this! 
(However if I was google, and was rolling out the next wave of wifi networks, I would definitely go IPv6-only though (probably omit DNS64 as well), safe in the knowledge that my biggest rivals devices would be stuffed on IPv6-only networks! Imagine a free wifi network that ithingies don't fully work on for until....)

I think the IETF has proved that these gamechangers can be enabled. I remember in the last decade for a previous telco I ran through a matrix of IP address exhaustion options (including all those called "anti-social by CB). I remember DS-lite and something called P-NAT being in that matrix, and these were *almost* discounted at the time because of the lack of support in equipment. Now we have major install bases of DS-lite and whole mobile network architectures around 464xlat. So the only real barrier to any gamechanger is time :-)
Regards,
Nick



-----Original Message-----
From: Metzler, Dan J [mailto:dan-metzler@uiowa.edu] 
Sent: 25 April 2015 20:43
To: Heatley, Nick; Ted Lemon; George, Wes
Cc: Bjoern A. Zeeb; IPv6 Ops WG
Subject: RE: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Nick, see responses inline.

> -----Original Message-----
> From: Heatley, Nick [mailto:nick.heatley@ee.co.uk]
> Sent: Friday, April 24, 2015 9:28 AM
> To: Metzler, Dan J; Ted Lemon; George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: RE: [v6ops] The need for local-ipv4 socket transition 
> solutions --
> NAT64/DNS64 remains insufficient
> 
> Dan, those options are costly, unsustainable in the long term, and 
> drive customers away from the network.
[DJM]
Can you be more specific?  Which options are costly, and unsustainable? 
Given that I think I stated every possible option, I recognize that options can be costly, some more than others.  Never-the-less, those are the options available to us, so we are all going to pick one or more of them regardless, right?


> It doesn't matter what helpdesk staff blame it on, what matters is that call has
> cost time and money.
[DJM] 
I'm more focused on "cause" than on "blame", but not only does it matter, it is critical.  It determines where, and whether, efforts will be focused on actually solving the problem or not.  What matters most is the willingness to accept and identify the "cause" of the problem.  If there is a refusal to address the cause, then the problem will not get fixed, and will simply become more costly on a broader and broader scale, as everyone else is forced to absorb the cost of workarounds or inaction.  

That call is going to come into the helpdesk regardless.  Whether that is the last call, or the start of many more, depends entirely on what the response is, and whether it includes actions that address the cause of the issue or not.

> 
> 
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Metzler, Dan J
> Sent: 24 April 2015 14:33
> To: Ted Lemon; George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions --
> NAT64/DNS64 remains insufficient
> 
> 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
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> NOTICE AND DISCLAIMER
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use for
> any purpose.
> 
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments are
> free from any virus, but it remains your responsibility to ensure that viruses do
> not adversely affect you.
> 
> EE Limited
> Registered in England and Wales
> Company Registered Number: 02382161
> Registered Office Address: Trident Place, Mosquito Way, Hatfield,
> Hertfordshire, AL10 9BW.
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.