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

From: "George, Wes" <[email-masked]>
Date: Fri, 3 Apr 2015 10:08:38 -0400

Again +Sunset4.

Cameron, perhaps you want to suggest text (or modify what you've written below) to bolster section 7 of https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-06 including the addition of a recommendation around IPv6-only + IPv4 host socket support? I think that'd be a useful addition to the document, but am also open to a discussion in sunset4 about a standalone BCP document covering this specific issue that is simply referenced from the gap analysis.

Thanks,

Wes George, wearing his Sunset4 WG chair cowboy hat

From: Ca By <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 19, 2015 at 5:27 PM
To: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Hi Folks,

The point of this message is to discuss the use of IPv4 literals and how this use requires transition solutions such as MAP, DS-Lite, and 464XLAT -- all of which provide local IPv4 socket support to the host.  If the primary operating environment of the host is the "internet", and the "web" is a highly valuable part of the that operating environment, then local IPv4 socket support is still required.

Specifically, this note builds the case that NAT64/DNS64 alone is still (at this time) not a sufficient solution for consumer Internet access by creating an IPv6-only network as described in https://tools.ietf.org/html/rfc6144#section-2.1

Empirically, it is commonly know that IPv4 addresses are used on the Internet, despite the guidance in RFC1958 (https://tools.ietf.org/html/rfc1958#section-4).  One common example is enterprise VPN services.

Quantitatively, it is easy to generate information about how frequently IPv4 address literals are used on the web.

Several years ago, draft-wing-behave-http-ip-address-literals-02 shared a simple method to gathering the data and reported that 2.38% of the top 1 million web pages have IPv4 literals in their homepage.  I re-ran a similar test this week that yielded 1.39% of the top 1 million web pages having IPv4 literals.   My test, like Dan's, only looks at the HTML on the home page and thus under-counts literals in deeper links or loaded via CSS, XML, or Javascript.

Through other manual testing  i have seen catastrophic failure in Amazon's video streaming service with them passing literals in XML.  Facebook passes IPv4 literals in Javascript, but is not impacting the page load.

I posted IPv4 literals found in the HTML homepage of these 2,220 of the top 100,000 Alexa domains here https://sites.google.com/site/tmoipv6/ipv4literals

My conclusion is that it is not feasible for a network operator to deploy a purely IPv6-only socket solution.  As has been previously explored, about 20% of the apps in the Google and Apple "app store" cannot function on IPv6-only + NAT64/DNS64.  Even if these "app stores" were policed to force all applications to be Address Family agnostic, it is not possible to police the world wide web or enterprise VPN or SIP Phones.  Any network operator that attempt to do this would have to accept at least 1.39% failure to the total web and perhaps accept failure to some major services (like Amazon streaming).

I believe we are beyond the point of blaming the world for using IPv4 literals / referrals.  We just need to be realistic that internet service requires IPv4 sockets, and thus RFC6144 #2.1 is not today a consumer grade service.  A wild guess is that it this situation will not meaningfully improve (risk reduced to ~0) for 10+ years.

Thoughts?

CB

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 3 Apr 2015 10:23:35 -0400

From: James Woodyatt <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 6:23 PM
To: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

There is only one thing applying any pressure of any kind to developers currently using IPv4 literals in their application protocols: that their applications FAIL on Apple operating systems when those devices connect to IPv6-only+NAT64 networks.

If Apple caves on this, as every other major vendor of mobile device operating systems has already caved, then developers will continue to rely on the viability of IPv4 literals as a protocol element for the foreseeable future. Those applications that do so will continue shipping with a reliance on 464XLAT for years to come, and they will continue to be used in critical processes for years after that when they are no longer under maintenance. There are people today scrubbing web pages and application protocols of their IPv4 literals, and they are mainly motivated to continue doing this by the need to deal with the fact that 464XLAT isn't universally deployed on all the major mobile platforms yet. Apple is the last noteworthy holdout.

Publishing a BCP that entails telling developers that IPv4 literals are legitimate for use as application protocol elements is unnecessary and counter-productive to the interests of the IETF in promoting adoption of IPv6. Instead it would communicate to developers that IETF is capitulating on IPv6, that it doesn't really believe in it anymore, and application developers should feel safe ignoring it for the foreseeable future.

WG] interestingly, most of the above statement still works if you do %s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that particular bandwagon too.

You're simply advocating for pushing this problem and therefore all efforts to motivate people to stop using IPv4 literals back onto the carriers, because you know full well that unlike Apple/Android did with flash, the carriers aren't going to intentionally break their user's experience to prove a point until the risk is vanishingly small, so they simply won't deploy IPv6-only+NAT64, because doing so will make the phone ring.

Perhaps if Apple believes that the developers need more motivation, there should be explicit guidance in the App store guidelines that apps using IPv4 literals, even on the server side, are unacceptable? (yes, I realize you no longer work there James). Lorenzo, does Android have such guidance? Even with 464xlat support, if that's there, then we're continuing the pressure on fixing it while acknowledging the operational reality of making a decent user experience until it's fixed properly.

Wes George

---

From: Ca By <[email-masked]>
Date: Fri, 3 Apr 2015 07:35:42 -0700

On Fri, Apr 3, 2015 at 7:23 AM, George, Wes <[email-masked]>
wrote:

>
>    From: James Woodyatt <[email-masked]>
> To: IPv6 Ops WG <[email-masked]>
>  There is only one thing applying any pressure of any kind to developers
> currently using IPv4 literals in their application protocols: that their
> applications FAIL on Apple operating systems when those devices connect to
> IPv6-only+NAT64 networks.
>
>  If Apple caves on this, as every other major vendor of mobile device
> operating systems has already caved, then developers will continue to rely
> on the viability of IPv4 literals as a protocol element for the foreseeable
> future. Those applications that do so will continue shipping with a
> reliance on 464XLAT for years to come, and they will continue to be used in
> critical processes for years after that when they are no longer under
> maintenance. There are people today scrubbing web pages and application
> protocols of their IPv4 literals, and they are mainly motivated to continue
> doing this by the need to deal with the fact that 464XLAT isn't universally
> deployed on all the major mobile platforms yet. Apple is the last
> noteworthy holdout.
>
>  Publishing a BCP that entails telling developers that IPv4 literals are
> legitimate for use as application protocol elements is unnecessary and
> counter-productive to the interests of the IETF in promoting adoption of
> IPv6. Instead it would communicate to developers that IETF is capitulating
> on IPv6, that it doesn't really believe in it anymore, and application
> developers should feel safe ignoring it for the foreseeable future.
>
> WG] interestingly, most of the above statement still works if you do
> %s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that
> particular bandwagon too.
>
>  You're simply advocating for pushing this problem and therefore all
> efforts to motivate people to stop using IPv4 literals back onto the
> carriers, because you know full well that unlike Apple/Android did with
> flash, the carriers aren't going to intentionally break their user's
> experience to prove a point until the risk is vanishingly small, so they
> simply won't deploy IPv6-only+NAT64, because doing so will make the phone
> ring.
>
>  Perhaps if Apple believes that the developers need more motivation,
> there should be explicit guidance in the App store guidelines that apps
> using IPv4 literals, even on the server side, are unacceptable? (yes, I
> realize you no longer work there James). Lorenzo, does Android have such
> guidance? Even with 464xlat support, if that's there, then we're continuing
> the pressure on fixing it while acknowledging the operational reality of
> making a decent user experience until it's fixed properly.
>
>  Wes George
>
>
Talk is cheap, so are guidelines.  If it works, it ships.  We have been
waving the guidelines that people should turn on ipv6 for years, they don't
work.  Anyone who has turned on ipv6 has done it because they saw a
straight-line to risk and cost mitigation.

And again, there are ipv4 literals on major top 100, top 1000, top 1M
websites.... App store guidelines and even hard  requirements won't fix the
free and open web.

Releasing guidelines was soooo 2005. And, soooo ineffective at making real
ipv6-only ipv4-socket-free deployment possible.  In fact, we are pretty
sure no major (or minor) network or operating environment of any sort is
ipv4-free.

Meaning, nobody has even started.

Conclusion:  IPv4 sockets need to be supported on hosts that operate in
IPv6-only networks.

CB

> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: James Woodyatt <[email-masked]>
Date: Fri, 3 Apr 2015 13:07:56 -0500

> Conclusion:  IPv4 sockets need to be supported on hosts that operate in

That's an overly general statement, which is why I'm pushing back. A more
specific statement you could make is that the IPv4 programming interfaces
need to be supported on general-purpose multi-program hosts that operate on
IPv6-only networks which bear a strong resemblance to yours. Phrase it that
way, however, and the case for a BCP from IETF seems less pressing.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: James Woodyatt <[email-masked]>
Date: Fri, 3 Apr 2015 15:56:38 -0500

On Fri, Apr 3, 2015 at 9:23 AM, George, Wes <[email-masked]>
wrote:

>   Interestingly, most of the above statement still works if you do

That analogy *IS* interesting, isn't it? Can you imagine what the reaction
would be if carriers had responded to the introduction of handsets without
support for Flash by insisting that the HTML5 solution for replacing Flash
be available only to handsets that also support Flash programming
interfaces as a translation layer in the platform?

You're simply advocating for pushing this problem and therefore all efforts
> to motivate people to stop using IPv4 literals back onto the carriers [...]
>

I see myself advocating against permitting the carriers to escape
responsibility. As I view it, they snoozed while operating systems people
worked diligently to make dual-stack hosts ready for the transition. Now
they'd like an easy escape— asking for host operating systems and
applications to maintain the transitional state indefinitely, while they
make a clean break to green fields now.

If there is a good and fair reason to shift these burdens from the carriers
onto others, then I'm failing to recognize it. I'm not saying there isn't
one. Just that I don't know what it could be.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Apr 2015 05:57:43 +0900

specific statement you could make is that the IPv4 programming interfaces
need to be supported on general-purpose multi-program hosts that operate on
IPv6-only networks which bear a strong resemblance to yours.

James,

what do you purpose as a better alternative?

Suppose that, as you say, not all popular OSes implement 464xlat. Aren't we
just changing the outcome from "we'll never get away from IPv4-only socket
calls" to "we'll never get away from running IPv4"? If so, how is that
better?

You could well argue that for as long as IPv4 is around, we'll never get
rid of IPv4 socket calls either, because it's impossible for anyone to
impose a "thou shalt not write an IPv4-only app" policy without placing
themselves at a competitive disadvantage.

Cheers,
Lorenzo

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 3 Apr 2015 21:10:10 +0000

> On 03 Apr 2015, at 20:57 , Lorenzo Colitti <[email-masked]> wrote:
> 
> > That's an overly general statement, which is why I'm pushing back. A more specific statement you could make is that the IPv4 programming interfaces need to be supported on general-purpose multi-program hosts that operate on IPv6-only networks which bear a strong resemblance to yours.
> 
> James,
> 
> Suppose that, as you say, not all popular OSes implement 464xlat. Aren't we just changing the outcome from "we'll never get away from IPv4-only socket calls" to "we'll never get away from running IPv4"? If so, how is that better?
> 
> You could well argue that for as long as IPv4 is around, we'll never get rid of IPv4 socket calls either, because it's impossible for anyone to impose a "thou shalt not write an IPv4-only app" policy without placing themselves at a competitive disadvantage.

Ok, so we need a monthly global “we’ll get rid of all these 512k IPv4 prefixes in BGP for you”-day and the problem will be solved by christmas.  It’s probably good enough if 5 major transport networks will do it once for a start, very much like 5 major content players started making loud noises 10 years to late for IPv6.  June 6 2016?  Who’s in for a long weekend?

If you can say crazy things, so can I.

— 
Bjoern A. Zeeb                                  Charles Haddon Spurgeon:
"Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend."

---

From: Ca By <[email-masked]>
Date: Fri, 3 Apr 2015 14:15:13 -0700

On Fri, Apr 3, 2015 at 2:10 PM, Bjoern A. Zeeb <
[email-masked]> wrote:

> > > That's an overly general statement, which is why I'm pushing back. A
> more specific statement you could make is that the IPv4 programming
> interfaces need to be supported on general-purpose multi-program hosts that
> operate on IPv6-only networks which bear a strong resemblance to yours.
> >
> > James,
> >
> > Suppose that, as you say, not all popular OSes implement 464xlat. Aren't
> we just changing the outcome from "we'll never get away from IPv4-only
> socket calls" to "we'll never get away from running IPv4"? If so, how is
> that better?
> >
> Ok, so we need a monthly global “we’ll get rid of all these 512k IPv4
> prefixes in BGP for you”-day and the problem will be solved by christmas.
> It’s probably good enough if 5 major transport networks will do it once for
> a start, very much like 5 major content players started making loud noises
> 10 years to late for IPv6.  June 6 2016?  Who’s in for a long weekend?
>

On my mobile network, this is really not that crazy of a statement at all.

I just need one more mobile OS vendor to implement 464XLAT and IPv6-only
will be every device of any consequence by default in the store.

CB

---

From: James Woodyatt <[email-masked]>
Date: Fri, 3 Apr 2015 16:15:18 -0500

> what do you purpose as a better alternative?
I propose that IETF decline the invitation to publish a BCP to the effect
that host OS implementations should include a CLAT function.

Aren't we just changing the outcome from "we'll never get away from
> IPv4-only socket calls" to "we'll never get away from running IPv4"?

I think the former entails the latter. I think we get away from running
IPv4 by deliberately and carefully removing support for IPv4 from
application developers and users in a way that continuously makes forward
progress at a manageable and predictable expense. If we deploy CLAT
everywhere, then we will be making IPv4 more difficult to displace by
removing support for it in the network.

> themselves at a competitive disadvantage.

Is it really impossible? Because that's exactly what Facebook did— impose a
"thou shalt not use IPv4" policy on its internal developers, and it doesn't
look to me like it put them at a competitive disadvantage. Have you looked
at Google+ lately?

In fact, I suspect they might have found it more difficult if the majority
of their developers were using workstations that had CLAT implementations
in their operating systems. Taking away IPv4 was a critical step for them,
according to what their delegation to the World IPv6 Congress reported
earlier this month. If their developers could have still written IPv4
applications and relied on the system to translate it into IPv6 on their
interior networks, then I think it would have greatly complicated
transition.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 3 Apr 2015 21:19:02 +0000

> On 03 Apr 2015, at 21:15 , Ca By <[email-masked]> wrote:
> 
> 
> 
> On Fri, Apr 3, 2015 at 2:10 PM, Bjoern A. Zeeb <[email-masked]> wrote:
> 
> I just need one more mobile OS vendor to implement 464XLAT and IPv6-only will be every device of any consequence by default in the store.

No.  And no.   What you need is that things just work IPv6 end-to-end.

—

---

From: Ca By <[email-masked]>
Date: Fri, 3 Apr 2015 14:23:33 -0700

On Fri, Apr 3, 2015 at 2:15 PM, James Woodyatt <[email-masked]> wrote:

> Is it really impossible? Because that's exactly what Facebook did— impose
> a "thou shalt not use IPv4" policy on its internal developers, and it
> doesn't look to me like it put them at a competitive disadvantage. Have you
> looked at Google+ lately?
>

The fundamental issue is that you have no control over these on the
internet, https://sites.google.com/site/tmoipv6/ipv4literals

You, and i, also have no control over what is implemented in signalling
channels. Your sockets my be AF agnostic, but that does not stop the data
structures for peer to peer apps being ipv4 addesses like Bittorent or
Skype use.

In fact, Skype works on iOS today on IPv6-only.... why?  Because they built
a CLAT into the App.  It is a horrible idea of ask all the app vendors to
invent their of unique CLAT.  Because they have already reacted to the
threat of IPv6-only... and this is what they do.

Regarding the Flash analogy, that was one ecosystem acting unilaterally.
The ecosystem is well invited to uniformly and unilaterally move forward
with IPv6-only universally.  They are not invited to say choose IPv6 or
IPv4, and those that choose IPv6 only get 99% of the internet while the
IPv4 guy gets 100%

CB

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Apr 2015 18:02:18 -0400

On Apr 3, 2015, at 4:56 PM, James Woodyatt <[email-masked]> wrote:
> I see myself advocating against permitting the carriers to escape responsibility. As I view it, they snoozed while operating systems people worked diligently to make dual-stack hosts ready for the transition. Now they'd like an easy escape— asking for host operating systems and applications to maintain the transitional state indefinitely, while they make a clean break to green fields now.

I'm sympathetic, but I don't think this helps us.   What we want is for the transition to happen.   Focusing on fairness isn't going to get us anywhere because fairness really doesn't seem to motivate large corporations to spend money unless there's substantial public visibility, and I don't see that happening here.

What I think is a more viable path to v6only is simply that at some point it might become possible to charge a premium for NAT64, or else silently degrade service on NAT64 without entirely breaking it, e.g. by restricting the number of ports any host can get.   This will put v4-only apps and apps with IPv4 literals at a disadvantage, which might motivate them to upgrade.

Another thing that could motivate them to upgrade is if hosting providers start to charge extra for IPv4 transit, because the amount of market share they expect to lose as a result will not be significant enough to worry them.   But I think this will follow the NAT64 translator cost effect, not lead it.

The point being that I think 464XLAT is going to speed the transition, not slow it, and if that sucks for O.S. vendors, well, that's why they call it work...

---

From: James Woodyatt <[email-masked]>
Date: Fri, 3 Apr 2015 17:05:59 -0500

> internet, https://sites.google.com/site/tmoipv6/ipv4literals

That list is badly out of date.

(For grins, I looked at some entries on the list. The first one I looked at
was at nodejs.org which has an IPv4 literal in its pre-formatted example
code on the first page. Which I would note is example code that WOULD NOT
BREAK in the absence of a CLAT. You'd have to remove the IPv4 stack
completely from the host to break it. The second one I looked at was the
one at the top of the list. There is one IPv4 literal in the page. It's
assigned to an unused Javascript variable. The third one I looked at was
the second one on the list, which appears to have moved entirely since this
list was created. Please update the list.)

But put that aside for now. There aren't many people in this discussion who
DO have control over the entries in that list, but Internet service
operators certainly have more influence over them than anyone outside of
the actual site owners. Tremble at the risk entailed in using your
influence if you must, but don't complain that you have no influence at
all. You can choose to get them to stop using IPv4 literals by taking away
the free lunch. Or you can choose to let them run wild without consequence.
Just start moving select populations of CLAT-less users to IPv6-only+NAT64
networks. They'll figure it out pretty quickly.

> Skype use. [...] In fact, Skype works on iOS today on IPv6-only.... why?
> Because they built a CLAT into the App.
>

Ah yes, those pesky IPv4-only P2P applications. Especially the ones with
DHT keys containing IPv4 addresses. Which can't be easily adapted to handle
IPv6 address too. A scourge on the Internet those apps are. Exactly how
many are we talking about? Besides Skype and BitTorrent, I mean. Oh wait.
They're already IPv6-capable. So, who *are* we talking about today?

> It is a horrible idea of ask all the app vendors to invent their of unique
> CLAT.  Because they have already reacted to the threat of IPv6-only... and
> this is what they do.
>

Well, we aren't asking *all* the app vendors to do that, are we? Just the
ones that are so amazingly clever they can't do the simple straightforward
obvious thing, which is to change their protocols to not use IPv4 literal
addresses.

I simply don't see the downside of telling whatever remaining IPv4-only P2P
app vendors are out there that they have to implement their own UNSAF
mechanism over IPv6 rather than rely on the system to do it for them. Who
knows, for many of them, it might not be that hard to just upgrade their
protocols to support the dual-stack IPv4/IPv6 public Internet. That it was
hard for Skype, but not very hard at all for FaceTime, seems like a
relevant point to keep in mind.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Apr 2015 11:29:16 +0900

> that host OS implementations should include a CLAT function.

Ok, so let me see if we can determine the extent of the disagreement.

Suppose that instead of a BCP that says host OS implementations should
include a CLAT function, we instead had a BCP that says general-purpose
host implementations should *either* include a CLAT function, *or* ensure
that all applications are capable of running on an IPv6-only network. Would
you oppose that?

If so - then how do you see us getting to IPv6-only? Do you see application
developers moving to support IPv6 by themselves, including on legacy apps
that haven't been updated for years, or that can't be updated because they
were sold on CDs? Or do you see network operators removing IPv4 regardless
of whether that breaks their users' applications?

---

From: Ca By <[email-masked]>
Date: Sat, 4 Apr 2015 06:02:18 -0700

On Friday, April 3, 2015, James Woodyatt <[email-masked]> wrote:

> On Fri, Apr 3, 2015 at 4:23 PM, Ca By <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>> internet, ipv4literals | tmoipv6
>> <https://sites.google.com/site/tmoipv6/ipv4literals>
>>
>
It is only a few weeks old.

> (For grins, I looked at some entries on the list. The first one I looked
> at was at nodejs.org which has an IPv4 literal in its pre-formatted
> example code on the first page. Which I would note is example code that
> WOULD NOT BREAK in the absence of a CLAT. You'd have to remove the IPv4
> stack completely from the host to break it. The second one I looked at was
> the one at the top of the list. There is one IPv4 literal in the page. It's
> But put that aside for now. There aren't many people in this discussion
> who DO have control over the entries in that list, but Internet service

This is 0% executive leaders from the customer service, network operations,
marketing, or regulatory affairs would approve such a move. Seriously, the
only viable path for that is if the government required it.

> I simply don't see the downside of telling whatever remaining IPv4-only
> P2P app vendors are out there that they have to implement their own UNSAF
Hard  or not, FaceTime requires IPv4 the last time I checked.

-- 
> james woodyatt <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>

---

From: "Howard, Lee" <[email-masked]>
Date: Sat, 4 Apr 2015 09:46:05 -0400

From: Cameron Byrne <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 3, 2015 at 10:35 AM
To: Wesley George <[email-masked]<mailto:[email-masked]>>
Cc: 'IPv6 Operations' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Talk is cheap, so are guidelines.  If it works, it ships.  We have been waving the guidelines that people should turn on ipv6 for years, they don't work.  Anyone who has turned on ipv6 has done it because they saw a straight-line to risk and cost mitigation.
. . .
Meaning, nobody has even started.

Conclusion:  IPv4 sockets need to be supported on hosts that operate in IPv6-only networks.

Would an IETF BCP help convince your remaining vendor to do what you want?

Lee

CB

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Metzler, Dan J" <[email-masked]>
Date: Sat, 4 Apr 2015 13:59:16 +0000

From: v6ops [mailto:[email-masked]] On Behalf Of Ca By
Sent: Friday, April 3, 2015 9:36 AM
To: George, Wes
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Fri, Apr 3, 2015 at 7:23 AM, George, Wes <[email-masked]<mailto:[email-masked]>> wrote:

Wes George

And again, there are ipv4 literals on major top 100, top 1000, top 1M websites.... App store guidelines and even hard  requirements won't fix the free and open web.

Releasing guidelines was soooo 2005. And, soooo ineffective at making real ipv6-only ipv4-socket-free deployment possible.  In fact, we are pretty sure no major (or minor) network or operating environment of any sort is ipv4-free.

CB

---

From: Xing Li <[email-masked]>
Date: Sun, 05 Apr 2015 17:38:56 +0800

> Conclusion:  IPv4 sockets need to be supported on hosts that operate 
Fully agree, based CERNET2's 10 years IPv6-only backbone experience. We 
have the following observations.

(1) If it is the IPv6-only network and IPv6-only applications (IPv6-only 
socket), then nobody will use it, except for the demonstration.
(2) If it is the IPv6-only network with single IPv4/IPv6 translation and 
IPv6-only applications (IPv6-only socket), then somebody will use it, 
but they are not the majority (less than 5%).
(3) If it is the IPv6-only network with double IPv4/IPv6 translation and 
IPv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it 
happily.

So I think the transition path should be moving from double translation 
to single translation and eventually to IPv6-only.
Regards,

xing

>
> CB 
>
>     ------------------------------------------------------------------------
>     This E-mail and any of its attachments may contain Time Warner
>     Cable proprietary information, which is privileged, confidential,
>     or subject to copyright belonging to Time Warner Cable. This
>     E-mail is intended solely for the use of the individual or entity
>     to which it is addressed. If you are not the intended recipient of
>     this E-mail, you are hereby notified that any dissemination,
>     distribution, copying, or action taken in relation to the contents
>     of and attachments to this E-mail is strictly prohibited and may
>     be unlawful. If you have received this E-mail in error, please
>     notify the sender immediately and permanently delete the original
>     and any copy of this E-mail and any printout.
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Xing Li <[email-masked]>
Date: Sun, 05 Apr 2015 17:39:37 +0800

> The point being that I think 464XLAT is going to speed the transition, not slow it, and if that sucks for O.S. vendors, well, that's why they call it work...

+1. xing

---

From: Ross Chandler <[email-masked]>
Date: Mon, 6 Apr 2015 15:24:03 +0100

> On 5 Apr 2015, at 10:38, Xing Li <[email-masked]> wrote:
> 
> Ca By 写道:
>> 
> Fully agree, based CERNET2's 10 years IPv6-only backbone experience. We have the following observations.
> 
> (1) If it is the IPv6-only network and IPv6-only applications (IPv6-only socket), then nobody will use it, except for the demonstration.
> (2) If it is the IPv6-only network with single IPv4/IPv6 translation and IPv6-only applications (IPv6-only socket), then somebody will use it, but they are not the majority (less than 5%).
> (3) If it is the IPv6-only network with double IPv4/IPv6 translation and IPv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it happily.
> 
> So I think the transition path should be moving from double translation to single translation and eventually to IPv6-only.
> Regards,
> 
> xing

Once IPv6-only with double IPv4/IPv6 translation is available the next stage to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is.
Similar to ISPs dropping services they don’t have a natural advantage in providing (Usenet, web hosting, email, in fact anything not tied to the access network) they eventually won’t bother to operate NAT64.

Ross

---

From: James Woodyatt <[email-masked]>
Date: Mon, 6 Apr 2015 10:10:36 -0700

On Fri, Apr 3, 2015 at 7:29 PM, Lorenzo Colitti <[email-masked]> wrote:

> If so - then how do you see us getting to IPv6-only? Do you see
> application developers moving to support IPv6 by themselves, including on
> legacy apps that haven't been updated for years, or that can't be updated
> because they were sold on CDs? Or do you see network operators removing
> IPv4 regardless of whether that breaks their users' applications?
>

I don't see us getting to IPv6-only unless and until network operators are
compelled by some external force to start breaking IPv4-only applications
for their users. Yes, I understand that no such external force exists
(thanks in no small part to regulatory capture, but we can leave that aside
for now) at present. They will only do so when the costs of supporting
IPv4-only exceeds the cost of breaking IPv4-only. And that's probably just
as it should be, unless you're the sort who thinks that Internet service
operators ought to be treated like public utilities instead of private
enterprises.

I would support V6OPS publishing a BCP that recommends, to those network
operators which cannot abide breaking IPv4-only applications for their
users, that subscribers be provided with native dual-stack IPv4/IPv6
service, instead of them trying to make a hard transition to IPv6-only,
which relies on them somehow forcing customers to bring their own hosts
that can support 464XLAT to the network.

I would probably support 6MAN publishing a matching pair of Informational
specifications that update RFC 3493 and RFC 3542 with considerations for
hosts with a CLAT function integrated.

---

From: Xing Li <[email-masked]>
Date: Tue, 07 Apr 2015 13:23:20 +0800

> Once IPv6-only with double IPv4/IPv6 translation is available the next stage to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is.

If all the users on the Internet can access both the IPv4 (via double 
and single translation) and IPv6 (native) contents, who cares if the 
IPv4 literals will coexist with IPv4 and IPv6 for a long time?

> Similar to ISPs dropping services they don’t have a natural advantage in providing (Usenet, web hosting, email, in fact anything not tied to the access network) they eventually won’t bother to oper…

If the ISP lacks the public IPv4 addresses, the justification is to compare

(1) (stateful or stateless NAT64 + [host based] double translation)
(2) (NAT44 + dual-stack)
(3) NAT44-only

Based on 10 years IPv6 operation experience of CERNET2, I think (1) 
costs less than (2) and (1) has more features (IPv6) than (3). Therefore 
(1) is the way to go.

Regards,

xing

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Apr 2015 15:50:46 +1000

In message <[email-masked]>, Xing Li writes:
> >> (1) If it is the IPv6-only network and IPv6-only applications (IPv6-only s
> ocket), then nobody will use it, except for the demonstration.
> >> (2) If it is the IPv6-only network with single IPv4/IPv6 translation and I
> Pv6-only applications (IPv6-only socket), then somebody will use it, but they
>  are not the majority (less than 5%).
> >> (3) If it is the IPv6-only network with double IPv4/IPv6 translation and I
> Pv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it happily
> .
> >>
> >> So I think the transition path should be moving from double translation to
>  single translation and eventually to IPv6-only.
> >> Regards,
> >>
> >> xing
> >>     
> >
> > Once IPv6-only with double IPv4/IPv6 translation is available the next stag
> e to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is
> .
> >   
> 
> > Similar to ISPs dropping services they don’t have a natural advantage in pro
> viding (Usenet, web hosting, email, in fact anything not tied to the access n
> etwork) they eventually won’t bother to operate NAT64.
> >   
> 

(4) DS-Lite

Additionally ISP's don't need to operate the translation/encapsulation
services themselves.  464XLAT and DS-Lite both can be done elsewhere
on the net.  Eventually IPv4 will be a "service" you get from a
niche service provider not your regular ISP.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Xing Li <[email-masked]>
Date: Tue, 07 Apr 2015 14:14:37 +0800

> niche service provider not your regular ISP.

Good point. I includes this scenario in (1). Regards, xing

---

From: Ross Chandler <[email-masked]>
Date: Tue, 7 Apr 2015 10:25:45 +0100

> On 7 Apr 2015, at 06:23, Xing Li <[email-masked]> wrote:
> If all the users on the Internet can access both the IPv4 (via double and single translation) and IPv6 (native) contents, who cares if the IPv4 literals will coexist with IPv4 and IPv6 for a long time?

I think for 3GPP especially people care more about the IPv4 literals & IPv4 only apps issue as that necessitates IPv4+IPv6 on the PDP/PDN connection for Internet access. Having 464xlat stops this issue hindering adoption of IPv6. With the local-ipv4 socket transition solution efforts to fix IPv4 literals and IPv4 only apps can proceed in parallel with IPv6 deployment instead of impeding it.

In fixed Internet, not having a local-ipv4 socket translation solution isn’t as bad a hinderance as the end hosts sit behind a CPE providing dual-stack on the LAN side. 

Ross

---

From: James Woodyatt <[email-masked]>
Date: Tue, 7 Apr 2015 10:30:42 -0700

On Mon, Apr 6, 2015 at 10:23 PM, Xing Li <[email-masked]> wrote:

>
> If all the users on the Internet can access both the IPv4 (via double and
> single translation) and IPv6 (native) contents, who cares if the IPv4
> literals will coexist with IPv4 and IPv6 for a long time?
>

You have obviously never tried to sell recurring software maintenance work
to support IPv6 transition to the management of a commercial host operating
systems vendor.

---

From: Xing Li <[email-masked]>
Date: Sat, 11 Apr 2015 18:31:59 +0800

> In fixed Internet, not having a local-ipv4 socket translation solution isn’t as bad a hinderance as the end hosts sit behind a CPE providing dual-stack on the LAN side. 

In order not to downgrade the users experience, the choices are:
(1) Dual-stack: dual-stack network interface and dual-stack local sockets
(2) 464xlat:  IPv6-only network interface and dual-stack local sockets

I believe (2) provides a better chance to move to IPv6-only then (1), no 
matter with or without a CPE. Can we convince all the users turn off the 
IPv4 socket in their OS before the *whole* Internet fixes the IPv4 
literals & IPv4 only apps problem, even their ISP has IPv6 and NAT64 
services? Frankly speaking, it is very difficult, if not impossible.

Regards,

xing

---

From: Xing Li <[email-masked]>
Date: Sat, 11 Apr 2015 20:05:58 +0800

James Woodyatt 写道:
> On Mon, Apr 6, 2015 at 10:23 PM, Xing Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     If all the users on the Internet can access both the IPv4 (via
>     double and single translation) and IPv6 (native) contents, who
>     cares if the IPv4 literals will coexist with IPv4 and IPv6 for a
>     long time?
>
>
> You have obviously never tried to sell recurring software maintenance 
> work to support IPv6 transition to the management of a commercial host 
> operating systems vendor.
>
No. I am an academic network service provider and my goal is to provide 
global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and 
very limited public IPv4 addresses. If the end system has the RFC6145 
function, the subnet can be IPv6-only. If the end system does not have 
the RFC6145 function, the subnet must be dual stack and the RFC6145 
function is provided via access gateway (CPE).

Regards,

xing

>
> -- 
> james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Mark Andrews <[email-masked]>
Date: Sun, 12 Apr 2015 08:05:34 +1000

> function is provided via access gateway (CPE).
 
RFC6333 + RFC6334 also allows the subnet to be IPv6 only.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 13 Apr 2015 12:21:21 -0700

On Sat, Apr 11, 2015 at 5:05 AM, Xing Li <[email-masked]> wrote:

> global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and very
> limited public IPv4 addresses.
>

I can understand the goal of providing service on your networks to global
IPv4 and IPv6 destinations, and I can understand how you may be limited by
the scarcity of public IPv4 address space, but I fail to see either A) how
that goal is best achieved by removing IPv4 service from your local
network, or B) how the negative effects of scarcity in public IPv4 space is
mitigated by the deployment of a CLAT in host operating systems.

>From my perspective, deploying a CLAT ubiquitously in host operating
systems will have two deleterious effects: 1) it will prolong the viability
of IPv4 literals in publicly reachable application services, requiring the
maintenance of the PLAT service, and the public IPv4 routing that entails,
over a longer period of transition, possibly indefinitely; and, 2) it will
slow the transition of applications in your local network to using IPv6
instead of IPv4, because the IPv4-only legacy interfaces will still be a
viable, if somewhat impaired, despite your having removed IPv4 routing from
local subnets.

I would think the negatives of this plan would obviously outweigh the
positives. On the plus side: you get to deploy a nice clean IPv6-only
network that nobody knows is IPv6-only. On the minus side: you may never
get to stop supporting IPv4 in the applications and the hosts, because if
you ever do, the users will howl about it, and this you cannot abide. I
would think it better to just decide you can't ever live without IPv4 and
commit yourself to running dual-stack forever.

---

From: Erik Kline <[email-masked]>
Date: Tue, 14 Apr 2015 14:31:16 +0900

> From my perspective, deploying a CLAT ubiquitously in host operating systems
> will have two deleterious effects: 1) it will prolong the viability of IPv4
> literals in publicly reachable application services, requiring the

Regarding "1": sure, fine, IPv4 literals and protocols with embedded
IPv4 addresses will be a thing for a while.  But let's be clear: it
*will* dwindle down to "rotary tone dialing" levels eventually.  So as
long as there's a mechanism that can support them I don't think our
future should be held hostage by them, as it were.

Regarding "2": I think this is not a function of any single network,
but rather the percentage of networks that have native IPv6 with
Carrier Pigeon IPv4.

One reason this whole thing, transition and discussion, is hard, I
would posit, is because we have to move through two or more integrals
to get to the desired end effect.  Allow me to be mathematically
dubious, just to make my point:

    [0a] Assumption: We're talking about IPv6-only networks being
preferred by operators over dualstack networks due to
[perceived|accrued] operational simplicity/cost/$METRIC.

    [0b] Assumption: A "general use" IPv6-only network requires some
form of IPv4 access, e.g. Carrier Pigeon IPv4, until a business
decision can be supported removing it.

These assumptions should be challenged of course, tempered by input
from operators with deployment experience.  My understanding is
something like this is the document actually under discussion (but not
yet drafted)?

    [1] How deployable an IPv6-only network may be is a kind of
integral, with respect to time, of the availability of Carrier Pigeon
IPv4 technologies, with respect to all the OSes on the devices that
might want to be attached to that network.

    [2] The number of deployed IPv6-only networks is a kind of
integral, with respect to time, of the deployable IPv6-only networks
in [1].

    [3] Awareness of native IPv6 versus Carrier Pigeon IPv4
performance problems and other issues is some function of the number
of deployed IPv6-only networks in [2], possibly as simple as a direct
proportionality but maybe also an integral with respect to time.

    [4] The prevalence of fixed/working IPv6-only applications,
websites, et cetera is a kind of integral, with respect to time, of
the awareness in [3].

So in this discussion, I think we're way back around #1 trying to
affect the kind of change in #4, but we have to move through 2 or 3
integrals to get there.

All this is not to say that it's hopeless.  Rather, I think there is
indeed a path here.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 14 Apr 2015 10:58:27 -0700

On Mon, Apr 13, 2015 at 10:31 PM, Erik Kline <[email-masked]> wrote:

> [I wrote:]

>                 [...] 1) it will prolong the viability of IPv4

Eew. That analogy smells bad to me because "rotary tone dialing" is a
localized network protocol between subscriber equipment and the signaling
system, whereas IPv4 literals are a global application signaling protocol
over the top of the network. The network effect is different in each case.
I think that's very relevant to the discussion.

> dubious, just to make my point: [...]
>

This argument is the most persuasive one I currently see. It's neither
simple nor obvious, and I don't see any consensus behind it— so, I doubt
it's well understood by the community. Shorter james: that's persuasive,
but not enough to make me think a BCP is in order.

Again, I repeat: I would probably support 6MAN publishing a matching pair
of Informational specifications that update RFC 3493 and RFC 3542 with
considerations for hosts with a CLAT function integrated. Let's see what
happens when we try to write those documents and get them published. Then
let's revisit the idea of publishing a BCP recommending the ubiquitous
deployment CLAT functions in host operating systems.

---

From: Tore Anderson <[email-masked]>
Date: Fri, 17 Apr 2015 07:45:19 +0200

* Lorenzo Colitti <[email-masked]>

> On Fri, Mar 20, 2015 at 7:42 AM, Tore Anderson <[email-masked]> wrote:
> 
> > Justine Vick from Microsoft held a very interesting presentation at
> > the V6 World Congress on Wednesday about their plans to make one of
> > their buildings IPv6-only. One of the things she had identified a
> > need for was to have a CLAT in the desktop version of Windows. She
> > had already established contact with the relevant teams to try to
> > make that happen (I asked her to add the Windows Server folks to
> > her CC list). Fingers crossed!
> 
> Are the slides of that presentation available, and if not, do you
> know how we might be able to read them? (e.g., by getting in touch
> with Justine).

The slides were only available for delegates with a username/password,
so unfortunately I couldn't share them with the list. However I see now
that a recording of Justine's presentation has been made publicly
available at YouTube: https://www.youtube.com/watch?v=ev-hUpLaFbw

Tore

---

From: James Woodyatt <[email-masked]>
Date: Tue, 21 Apr 2015 12:02:08 -0700

On Tue, Apr 21, 2015 at 9:14 AM, Xing Li <[email-masked]> wrote:
>
>
> (1) If the host system can not do RFC6145, the additional CPE is
> required to do so, and that also keeps the IPv4 literals on the Internet
> forever.
>

I wouldn't characterize it like that. I think what you mean to say is this:
because support for IPv4 literals can never be removed from the Internet,
hosts must either be provided with IPv4 service forever or all the hosts on
the Internet must be upgraded to support the CLAT function in 464XLAT. My
point is that you can't require all the hosts to be upgraded with CLAT
functions any more than your require all the applications to stop using
IPv4 literals everywhere. You are left with exactly one alternative: you
must support IPv4 forever, and this is not because hosts don't have CLAT
functions, but entirely because you cannot abide breaking any of the
applications today that use IPv4 literals.

Shorter james: your problem is the IPv4 literals. If you can't ignore them,
and you can't do anything else about them, then you can't deploy IPv6-only.
It's really that simple.

(2) No ISP will deploy the IPv6-only network, if the end users cannot
> access the websites with IPv4 literals.
>

I don't have a problem with that. I've been saying all along that ISPs
should not be in any hurry to turn off IPv4 service to CPE devices
completely.

---

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 22 Apr 2015 08:55:16 +0000

In the event that there is only one OS ecosystem at the party that doesn’t support the IPv4-socket transition, what story will they tell?
In that scenario, I don’t see there is a great customer story there (stuck running a legacy protocol as transport/being disconnected from literals).
Simply pointing at the other party guests and saying they should have done more to remove the problem in the first place isn’t going to cut it IMO, when there is a fix in their OS that they could work on.
From a smartphone/tablet perspective that is looking a likely scenario.

What I believe to be true for mobile: the disease is IPv4 literals, it cannot be eradicated, go immunise the OS.

(In the mobile consumer case, I don’t have an issue with IPv4-literals failing per se, I have an issue with IPv4-literals failing and customers thinking it is my network and ringing my helplines.
If browsers redirected these fails to a page that said “IPv4 literal problem encountered - ring vendor A” then that would be fine by me. A foolish idea? Well, it boils down to take some ownership, and don’t penalise operators taking the lead! IPv6-only transport has to be the target, we all know this.)

From: v6ops [mailto:[email-masked]] On Behalf Of James Woodyatt
Sent: 21 April 2015 20:02
To: Xing Li
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Tue, Apr 21, 2015 at 9:14 AM, Xing Li <[email-masked]<mailto:[email-masked]>> wrote:

I wouldn't characterize it like that. I think what you mean to say is this: because support for IPv4 literals can never be removed from the Internet, hosts must either be provided with IPv4 service forever or all the hosts on the Internet must be upgraded to support the CLAT function in 464XLAT. My point is that you can't require all the hosts to be upgraded with CLAT functions any more than your require all the applications to stop using IPv4 literals everywhere. You are left with exactly one alternative: you must support IPv4 forever, and this is not because hosts don't have CLAT functions, but entirely because you cannot abide breaking any of the applications today that use IPv4 literals.

Shorter james: your problem is the IPv4 literals. If you can't ignore them, and you can't do anything else about them, then you can't deploy IPv6-only. It's really that simple.

I don't have a problem with that. I've been saying all along that ISPs should not be in any hurry to turn off IPv4 service to CPE devices completely.

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
Nest Labs, Communications Engineering

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.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 22 Apr 2015 09:15:23 +0000

> On 22 Apr 2015, at 08:55 , Heatley, Nick <[email-masked]> wrote:
> 

Given the entire “WinXP is still alive and IPv6 story” the timeframe to put to this is at least half a decade to a decade from now.

I think when people here mean “OS” they often think in “mobile OS” but don’t say?

> If browsers redirected these fails to a page that said “IPv4 literal problem encountered - ring vendor A” then that would be fine by me. A foolish idea? Well, it boils down to take some ownership,…

See, the thing I like about this thread is, that everybody is trying to point their fingers to someone else in order to fix something elsewhere but not with themselves or where the &^%$#$%^&*() problem occurs.   Anyone saying “you cannot get rid of IPv4 literals” to the extend that it doesn’t bother anyone anymore is mislead.  You just have not tried hard enough (probably because you are distracted seeking solutions elsewhere).

If everyone complaining here, would work towards getting rid of them rather than discussing who’s problem it is to put a workaround in place, we’d probably be half-way done.  We have people crawling the web, people having users and test networks, people who seem to be able to write enough emails on the topic that they could even direct it to the right people.

I could even be more adventurous and say:  give them a 90 day notice, publish it (that’s the important part, so that yur users hear about it as well), and if they don’t get back to you that they’ll fix it (timely) break them.  Isn’t that what people do with major security bugs?  I’d be surprised if major shopping sites and news papers wouldn’t react, once their sales and page views go down by a few % over night, but you need to let them and their users know upfront.

—

---

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 22 Apr 2015 10:20:26 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Bjoern A. Zeeb

[Heatley, Nick] No I said eco-system not platform version. Each ecosystem needs an IPv6-only story. Whether they use 464xlat or let literals fail, they need a story.

NOTICE AND DISCLAIMER

EE Limited

---

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 22 Apr 2015 12:02:47 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Bjoern A. Zeeb
Sent: 22 April 2015 10:15

[Heatley, Nick] Agree that at some point the finger pointing needs to stop.
My criteria though is not about "fixing at source", it is about being least disruptive or disturbing to customers.
The problem with the source of IPv4 literals is that it includes small businesses, mom & pop companies, as well as majors.
I am certainly not interested in sending out any "the sky is falling down" notices to customers, it is more likely they will just shift providers; and I don't want an "no IPv4 literal" flag day.
The problem has to reside with those on the side of providing the service, not punting it to the customers or users.

NOTICE AND DISCLAIMER

EE Limited

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Apr 2015 09:59:58 -0400

> If everyone complaining here, would work towards getting rid of them rather than discussing who’s problem it is to put a workaround in place, we’d probably be half-way done.  We have people crawlin…

The problem is that the people who are using IPv4 literals are not _here_.   If fixing this were up to the people who are _here_, it would already have been fixed.   Nobody _here_ thinks that using IPv4 literals is okay (I suppose I will be corrected if I am wrong).

So while what you are saying would definitely be right if those people were here, since they are not, it isn't practical.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Apr 2015 16:23:14 +0200

Le 22/04/2015 15:59, Ted Lemon a écrit :
>> If everyone complaining here, would work towards getting rid of
>> them rather than discussing who’s problem it is to put a workaround
>> in place, we’d probably be half-way done.  We have people crawling
>> the web, people having users and test networks, people who seem to
>> be able to write enough emails on the topic that they could even
>> direct it to the right people.
>
> The problem is that the people who are using IPv4 literals are not
> _here_.   If fixing this were up to the people who are _here_, it
> would already have been fixed.   Nobody _here_ thinks that using IPv4
> literals is okay (I suppose I will be corrected if I am wrong).
>
> So while what you are saying would definitely be right if those
> people were here, since they are not, it isn't practical.

One path to fixing IPv4 literals is to make inet_pton () return -1 on 
anything which is not RFC5952 "IPv6 textual representation recomm't", 
including IPv4 literals.  Currently it returns 1 on IPv6 and IPv4 
literals.  Or display a warning "not valid after 2020".

That would first be in implementation, second at a Unix API SDO, and 
then maybe at IETF?

Alex

>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Apr 2015 10:30:53 -0400

On Apr 22, 2015, at 10:23 AM, Alexandru Petrescu <[email-masked]> wrote:
> One path to fixing IPv4 literals is to make inet_pton () return -1 on anything which is not RFC5952 "IPv6 textual representation recomm't", including IPv4 literals.  Currently it returns 1 on IPv6 and IPv4 literals.  Or display a warning "not valid after 2020".
> 
> That would first be in implementation, second at a Unix API SDO, and then maybe at IETF?

So you are saying that someone has to break things for their customers, and take the heat.   And the people who would do that have already said they will not, and given good reasons why.   A way forward that requires well-intentioned people in a position to do something to do something that is not in their interests is not going to get consensus.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 22 Apr 2015 10:33:44 -0400

On 4/22/15, 9:59 AM, "Ted Lemon" <[email-masked]> wrote:

>_here_.

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? Ditto CEA and their IPv6 WG - while IETF doesn't have a
formal liaison, we definitely have folks that participate in both v6ops
and CEA that could get the message out.

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

---

From: Ca By <[email-masked]>
Date: Wed, 22 Apr 2015 07:35:49 -0700

On Wed, Apr 22, 2015 at 6:59 AM, Ted Lemon <[email-masked]> wrote:

> > If everyone complaining here, would work towards getting rid of them
> rather than discussing who’s problem it is to put a workaround in place,
> we’d probably be half-way done.  We have people crawling the web, people
> having users and test networks, people who seem to be able to write enough
> emails on the topic that they could even direct it to the right people.
>
> _here_.   If fixing this were up to the people who are _here_, it would
> already have been fixed.   Nobody _here_ thinks that using IPv4 literals is
> okay (I suppose I will be corrected if I am wrong).
>
> So while what you are saying would definitely be right if those people
> were here, since they are not, it isn't practical.
>
>

The key is that:

1) We can only "fix" what is in our control -- as a network operator
464XLAT is in my  toolbox -- thank you IETF / Android / Microsoft.

2) Any solution that involves creating a negative customer experience (xyz
website or abc app does not work), is a non-starter.  Please stop
suggesting pain on paying customers, no network operator will do it. No
appstore will do it (with teeth, in the near term)

3) As Ted noted, the "ipv4-only deployers" are here and they are not
moving.  They include Google (hangouts), Apple (facetime), Spotify,
Netflix, so on and so forth. They understand the issue, and they are not
running to fix it.  So what is an ipv4-poor network to do?  Well, let's
check the tool box:

1) CGN -- tried true, but really just kicks the can down the road -- oh,
and RFC1918 ran out soo....  i hear there is some IPv4 space that is not
announce on the internet i can use .... So, this is a pretty anti-social
option, but it works.

2)  464XLAT / MAP / DS-lite -- Yay!  i can give users unique IPv6 public
addresses, grow the real IPv6 internet, and let ipv4 die on the vine (x
decade process, but real meaningful ipv6 progress now)

3.  Buy IPv4 (does not scale well, also anti-social)

Keep in mind, the tool box only includes these 3 things.  Wishing some
vigilante titan network is going to rain fire down on IPv4-only apps is not
realistic at all.  Same is true for  "mega-mobile-phone eco-system", they
will also not bar IPv4-only apps in a timescale that is helpful.  And, they
too have customers that want to go to http://192.0.1.1 on the public
internet ... and no, they are not going enroll networks to switch to
IPv6-only without IPv4-socket support to reach 99% of internet while other
networks are delivering 100% of the internet.

Regards,

CB

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Apr 2015 10:37:56 -0400

On Apr 22, 2015, at 10:33 AM, George, Wes <[email-masked]> wrote:
> 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).

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Apr 2015 23:44:13 +0900

> networks are delivering 100% of the internet.

What he said. The only question, really, is whether we end up doing #1 or
#2.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 22 Apr 2015 14:46:48 +0000

> On 22 Apr 2015, at 14:35 , Ca By <[email-masked]> wrote:
> 
> The key is that:
> 
> 1) We can only “fix” what is in our control -- as a network operator 464XLAT is in my  toolbox -- thank you IETF / Android / Microsoft.

You control a network. You forward packets or you don’t.

You assuming to have control over my end node device is wrong.  You can only let me on your network or you can’t.   If you are concerned about 1 million IPv4 literals out there, why are you not concerned abut 1 million handsets that will never do IPv6 in the next 5 years and will require IPv4 one way or another from you?

> 2) Any solution that involves creating a negative customer experience (xyz website or abc app does not work), is a non-starter.  Please stop suggesting pain on paying customers, no network operator will do it. No appstore will do it (with teeth, in the near term)

The way no major content provider wanted to turn IPv6 on.  Then they did for a day, and then they did it permanently.

—

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Apr 2015 23:54:52 +0900

On Wed, Apr 22, 2015 at 11:46 PM, Bjoern A. Zeeb <
[email-masked]> wrote:

> If you are concerned about 1 million IPv4 literals out there, why are you
> not concerned abut 1 million handsets that will never do IPv6 in the next 5
> years and will require IPv4 one way or another from you?
>

That *is* what he's concerned about. He's wishing those handsets supported
464xlat.

> > 2) Any solution that involves creating a negative customer experience
> (xyz website or abc app does not work), is a non-starter.  Please stop
> The way no major content provider wanted to turn IPv6 on.  Then they did
> for a day, and then they did it permanently.
>

They were only able to do it because breakage was < 0.05%. That's way lower
than "spotify, google video chat, skype (?), <unknown number of other
apps>, <large number of websites with literals>".

And when you say "permanent" - note that some content providers (like
Google) still don't provide AAAA records all the time to everyone -
precisely because measurements show there is breakage. (Search for
no_aaaa.txt)

---

From: Ca By <[email-masked]>
Date: Wed, 22 Apr 2015 08:12:52 -0700

> for a day, and then they did it permanently.
I am fully open to the  next generation of iThingies  being IPv6-only
mandatory on all networks in the USA, this would achieve a lot in one
stroke.  The USA market is huge, and would shock the entire internet / web
/ apps into compliance "with this one weird trick."

The key is that a unified front is presented by all operators and enforced
by the owner of the ecosystem.  They can kill off IPv4 just like they
killed off Flash.  But, we cannot have free-riders that avoid the
requirement.

My honest opinion is that this alliance cannot be formed.  That said, mark
me as first in line for accepting this requirement if and only if all other
USA networks accept the requirement as well.

CB

---

From: James Woodyatt <[email-masked]>
Date: Wed, 22 Apr 2015 11:34:02 -0700

On Wed, Apr 22, 2015 at 7:35 AM, Ca By <[email-masked]> wrote:

>
> [...]  So what is an ipv4-poor network to do? [...]
>

I thought this thread was about what the IETF should recommend everyone to
do.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Apr 2015 15:55:49 -0400

On Apr 22, 2015, at 2:34 PM, James Woodyatt <[email-masked]> wrote:
> I thought this thread was about what the IETF should recommend everyone to do.

The IETF should recommend that everybody stop using IPv4 literals, if there is a way to do that (it's not clear to me that there is).

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 22 Apr 2015 16:48:34 -0400

On 4/22/15, 3:55 PM, "Ted Lemon" <[email-masked]> wrote:

>The IETF should recommend that everybody stop using IPv4 literals, if
>there is a way to do that (it's not clear to me that there is).

I look forward to reading draft-lemon-ipv4literals-considered-harmful

:)
Lee

---

From: James Woodyatt <[email-masked]>
Date: Wed, 22 Apr 2015 15:36:37 -0700

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.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Apr 2015 09:30:09 +1000

In message <CADhXe52acGYR-y7VNpfXt=[email-masked]>, James Woodya
> don't think that's an unreasonable position to start.

Part of that is getting the Advanced Socket API recognised by POSIX.
As a developer it is a right pain in the backside that it isn't and
you have to do different magic incantations to make the Advanced
Socket API visible on different platforms.

Making "socket(AF_INET,...)" fail would also be a interesting idea.
You can talk to IPv4 nodes over socket(AF_INET6, ...) using mapped
addresses.

A boring but useful Google Code project would be to go through the
OSS that is still IPv4 only and add IPv6 support.   Adding fast
failover to the next address would also be useful at the same time.
Pick a something like FreeBSD ports and bring all current ports up
to scratch.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Apr 2015 21:46:09 -0400

On Apr 22, 2015, at 6:36 PM, James Woodyatt <[email-masked]> wrote:
> 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.

I think this is a very reasonable position.   However, not everybody in the IETF thinks we should be defining APIs, and there's the rub.   Nominally, APIs of this sort are a POSIX thing.

---

From: James Woodyatt <[email-masked]>
Date: Thu, 23 Apr 2015 11:45:40 -0700

Ted—

I'm not saying IETF should obsolete the excellent work that POSIX has
already done. I'm simply saying that IETF is probably the better place to
define what the POSIX network programming interfaces for IPv4 are expected
to do on hosts with IPv6 network interfaces and an integrated CLAT
function. I further think this work would be more suitable for 6MAN than
V6OPS, and until I see a standard track draft adopted, I'm going to be
opposed to V6OPS adopting a work item to produce a BCP for host operating
systems to implement a CLAT function.

On Wed, Apr 22, 2015 at 6:46 PM, Ted Lemon <[email-masked]> wrote:

> I think this is a very reasonable position.   However, not everybody in
> the IETF thinks we should be defining APIs, and there's the rub.
>  Nominally, APIs of this sort are a POSIX thing.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Apr 2015 17:17:00 -0400

On Apr 23, 2015, at 2:45 PM, James Woodyatt <[email-masked]> wrote:
> I'm not saying IETF should obsolete the excellent work that POSIX has already done. I'm simply saying that IETF is probably the better place to define what the POSIX network programming interfaces for IPv4 are expected to do on hosts with IPv6 network interfaces and an integrated CLAT function. I further think this work would be more suitable for 6MAN than V6OPS, and until I see a standard track draft adopted, I'm going to be opposed to V6OPS adopting a work item to produce a BCP for host operating systems to implement a CLAT function.

Would you be willing to co-author such a document?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 23 Apr 2015 22:04:02 +0000

> On Apr 3, 2015, at 2:15 PM, James Woodyatt <[email-masked]> wrote:
> 
> I think the former entails the latter. I think we get away from running IPv4 by deliberately and carefully removing support for IPv4 from application developers and users in a way that continuously makes forward progress at a manageable and predictable expense. If we deploy CLAT everywhere, then we will be making IPv4 more difficult to displace by removing support for it in the network.

I 75% agree. I think we move from IPv4 to ipv6 by making applications version agnostic (e.g., use getaddrinfo() rather than gethostbyname()), and getting networks to turn on IPv6 in the infrastructure. Given that, at someone economics kicks in. It’s cheaper to run one network than two.

---

From: Ca By <[email-masked]>
Date: Thu, 23 Apr 2015 19:27:30 -0700

On Thursday, April 23, 2015, Fred Baker (fred) <[email-masked]> wrote:

>
> On Apr 3, 2015, at 2:15 PM, James Woodyatt <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> I 75% agree. I think we move from IPv4 to ipv6 by making applications
> version agnostic (e.g., use getaddrinfo() rather than gethostbyname()), and
> getting networks to turn on IPv6 in the infrastructure. Given that, at
> someone economics kicks in. It’s cheaper to run one network than two.
>

What is the estimated time to turn the ship via this method? Meaning, when
will tangible results be delivered such that a network operator could
deploy ipv6-only?  You mentioned ecomomics, will the audiance for the api
change have a money benefit directly, or is this another case of misaligned
work / benefit ?

b4 and clat are already deployed at a meaningful scale on multiple
continents enabling ipv6 only. The network operators have done the work and
realized the benefit of ipv6-only.

I dont want to waste ietf time on re-inventing the wheel and writie docs of
an audience that wont read it.  we know how to do ipv6-only access networks
in the real world at scale with the work / benefit aligned.

CB

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 24 Apr 2015 03:39:01 +0000

> On Apr 23, 2015, at 7:27 PM, Ca By <[email-masked]> wrote:
> 
> 
> 
> On Thursday, April 23, 2015, Fred Baker (fred) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Apr 3, 2015, at 2:15 PM, James Woodyatt <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> 
> What is the estimated time to turn the ship via this method? Meaning, when will tangible results be delivered such that a network operator could deploy ipv6-only?  You mentioned ecomomics, will the audiance for the api change have a money benefit directly, or is this another case of misaligned work / benefit ?
> 
> b4 and clat are already deployed at a meaningful scale on multiple continents enabling ipv6 only. The network operators have done the work and realized the benefit of ipv6-only.
> 
> I dont want to waste ietf time on re-inventing the wheel and writie docs of an audience that wont read it.  we know how to do ipv6-only access networks in the real world at scale with the work / benefit aligned.
> 
> CB

Well, I think your question is really for James. But I’m with you, as you’ll note from the discussion we had in IETF 92.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Apr 2015 13:00:01 +0900

On Thu, Apr 23, 2015 at 7:36 AM, James Woodyatt <[email-masked]> wrote:

> 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

I don't think such a fine-toothed-comb endeavour makes sense. 464xlat is
just an unnumbered point-to-point link. That directly implies that the
answers to your questions are "there's no reason not to support IP_PKTINFO,
and no extra work required to do so", "link-local scope addresses are not
supported because it's an unnumbered point-to-point link", and
"SO_REUSEADDR means exactly what it means on any other IP address on the
system".

I suppose we can always write a document saying the above, plus
recommending that there be a different local clat IP address for every
interface on the system. Such a document wouldn't be very long, but I
suppose it might be helpful.

I don't think there is a need to go through POSIX.1. looking for corner
cases.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 24 Apr 2015 13:33:13 +0000

See below

> From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Wednesday, April 22, 2015 9:38 AM
> To: George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> > 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

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 24 Apr 2015 14:27:30 +0000

Dan, those options are costly, unsustainable in the long term, and drive customers away from the network.
It doesn't matter what helpdesk staff blame it on, what matters is that call has cost time and money.

-----Original Message-----
From: v6ops [mailto:[email-masked]] 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

> Subject: Re: [v6ops] The need for local-ipv4 socket transition 
> solutions --
> NAT64/DNS64 remains insufficient
> 
> > 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?
> 
> 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

[DJM]

- Dan Metzler

 

EE Limited

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 24 Apr 2015 10:38:06 -0400

On 4/24/15, 9:33 AM, "Metzler, Dan J" <[email-masked]> wrote:

>>in the

I think I read consensus on that statement.
I'm not sure there is consensus that the IETF is the right place to make
such a statement. There might be; I think we need a document to discuss to
see if there is consensus.
Somebody needs to write it for us to discuss it. Hint, hint.

>
>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.)

I don't know whether all of this needs to be in the draft. The note that
one person's use of bad practices means others have to decide whether and
how to deal with it is worthwhile.

>
>
>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.

That's back to the question of whether the IETF is the right place to say
something. It might be that we believe this is more appropriate somewhere
else.

Lee

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 24 Apr 2015 16:08:44 +0000

> On 24 Apr 2015, at 14:38 , Howard, Lee <[email-masked]> wrote:
> 
> 
> 

Yeah, sunset4 got as far as that to my understanding:

http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-07#section-7

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Apr 2015 18:14:04 +0200

Hi,

> I think I read consensus on that statement.

+1  :)

> Somebody needs to write it for us to discuss it. Hint, hint.

I think the IETF is the right place to say so.  We document operational
problems, and we document how to move networks to dual-stack or IPv6-only,
and using IPv4 literal is a very clear operational problem.

As for the document: it could be a very short one ("do not use IPv4 literals
for services that are expected to work over the Internet, which contains
islands that use IPv4/IPv6 translation today, as it risks breaking your
service, or imposes operational costs elsewhere to work around it"), or a
longer one ("application programmers really should... IP agnostic API...
avoid this, avoid that... best practices like <see RFCxxx, RFCyyy, RFCzzz>").

I think both documents have merit, but the first one has a much higher chance
of actually getting anywhere in the near future.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "George, Wes" <[email-masked]>
Date: Fri, 24 Apr 2015 14:00:37 -0400

>http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-07#section-7

WG] Question for those discussing this: does there need to be more text
there to cover the discussion? Send comments to [email-masked] or to the
draft authors.

More generally, *IP* Address literals are harmful, because they make bad
assumptions about what address family is supported on their users'
networks. It's just that we don't have a problem with people breaking
IPv4-only users by trying to use IPv6 address literals. Perhaps that
should be the statement in a standalone document?

Wes George

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Apr 2015 20:06:19 +0200

Hi,

> should be the statement in a standalone document?

True, but I would actually emphasize that IPv4 literals are a real problem
today, while nobody is daft enough to put IPv6 literals anywhere (in more
polite words).

Gert Doering
        -- NetMaster

---

From: James Woodyatt <[email-masked]>
Date: Fri, 24 Apr 2015 11:21:20 -0700

Lorenzo—

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.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Sat, 25 Apr 2015 19:43:23 +0000

Nick, see responses inline.

> From: Heatley, Nick [mailto:[email-masked]]
> Sent: Friday, April 24, 2015 9:28 AM
> To: Metzler, Dan J; Ted Lemon; George, Wes
> Subject: RE: [v6ops] The need for local-ipv4 socket transition solutions --
[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
[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.

> 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
> 
> >
> 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Apr 2015 10:37:33 +0900

> 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"?

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Apr 2015 11:09:13 +0200

Le 27/04/2015 03:37, Lorenzo Colitti a écrit :
> On Sat, Apr 25, 2015 at 3:21 AM, James Woodyatt <[email-masked]
> <mailto:[email-masked]>> 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"?

IPv4-only or IPv6-only? (I may have missed something).

Alex

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 27 Apr 2015 09:18:14 +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:[email-masked]] 
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

[DJM]

[DJM] 

NOTICE AND DISCLAIMER

EE Limited

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Apr 2015 07:22:53 -0400

On Apr 26, 2015, at 9:37 PM, Lorenzo Colitti <[email-masked]> wrote:
> 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"?

You're right, that makes it trivial.   Most applications are used to dealing with unnumbered IPv4-only point-to-point tunnels, so there's no explanation needed!   ;)

Seriously, I have to say that if I saw that explanation, I would have no idea what it meant.   My understanding, having never actually _used_ 464xlat knowingly, is that you open a socket and send on it and it just works, and that since most applications don't try to figure out what their source address is this isn't a problem.   But that's not what I would take your proposed text to mean.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Apr 2015 20:27:51 +0900

On Mon, Apr 27, 2015 at 8:22 PM, Ted Lemon <[email-masked]> wrote:

> You're right, that makes it trivial.   Most applications are used to
> dealing with unnumbered IPv4-only point-to-point tunnels, so there's no
> explanation needed!   ;)
>

Yes, they are. One such tunnel is PPPoE.

Seriously: in IP, typical applications don't know and don't care about the
link types they operate on. Your browser neither knows nor cares whether
you're on Ethernet, cellular data, or on an IPv6-in-IPv4 tunnel. They call
the sockets API and stuff works.

Seriously, I have to say that if I saw that explanation, I would have no
> idea what it meant.   My understanding, having never actually _used_
> 464xlat knowingly, is that you open a socket and send on it and it just
> works, and that since most applications don't try to figure out what their
> source address is this isn't a problem.

Yes, it just works. It's not a problem even if they try to figure out what
their source address is, either - it's 192.0.0.4.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Apr 2015 09:01:23 -0400

> On Apr 27, 2015, at 7:27 AM, Lorenzo Colitti <[email-masked]> wrote:
>> Seriously, I have to say that if I saw that explanation, I would have no idea what it meant.   My understanding, having never actually _used_ 464xlat knowingly, is that you open a socket and send on it and it just works, and that since most applications don't try to figure out what their source address is this isn't a problem.
> 
> Yes, it just works. It's not a problem even if they try to figure out what their source address is, either - it's 192.0.0.4.

Well and good, but I think you missed my point, which is simply that your explanation isn't going to help the people we need to help.   If indeed there is no API extension required, that's great, but I think the base of James' request was simply to have the IETF say what needs to be done to make 464XLAT work.   Either we've already said that, and James doesn't know what document to read, or we haven't, and there's a problem we could solve.   If the document is only a page, that makes solving the problem pretty easy.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Apr 2015 09:10:59 -0400

On Apr 27, 2015, at 9:01 AM, Ted Lemon <[email-masked]> wrote:
> I think the base of James' request was simply to have the IETF say what needs to be done to make 464XLAT work.

That is, what needs to be done by operating system vendors.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 27 Apr 2015 11:21:19 -0700

On Mon, Apr 27, 2015 at 4:22 AM, Ted Lemon <[email-masked]> wrote:

> 464xlat that cannot be immediately answered by just saying that "464xlat is
> an unnumbered IPv4-only point-to-point link"?
>

I'll provide the beginning of an answer to Lorenzo's specific question
below, but I think the topic would be better handled at the IETF 93 meeting.

Also, I'm not trying to stall the conversation. I'm actually trying to
provoke what I think would be a reasonable way to keep the conversation
going in a productive direction: by improving the situation for application
programmers and host operating systems maintainers who will be forced to
live with 464XLAT for the foreseeable future if the recommendation in this
proposed BCP is widely adopted.

> source address is this isn't a problem.   But that's not what I would take
> your proposed text to mean.
>

Most applications don't even really want to know they are using TCP/IP,
much less which version of it. The whole point of 464XLAT is to cover the
special category of applications that do not make the usual assumptions and
use the corner cases of the IPv4-only application programming interfaces in
the host operating system. There are a lot of corner cases. So, here are
some example questions.

1. What about MIF? It's not sufficient to simply say put an IPv4 address on
the point-to-network pseudo-link for each provider. How does an application
that cares about which interface it's using know which IPv4 address belongs
to which interface? Does the getifaddrs() [not POSIX, but commonly
implemented] return results showing them all on the same interface? Or
different interfaces? How does an application sending a packet from a UDP
socket without a source address bound use IP_PKTINFO to specify which
source interface to use if ipi_spec_dst is zero? What about dual-stack
applications that care about which IP addresses are attached at which
interfaces over time? How do they know what IPv4 addresses are associated
with which interface if all the CLAT IPv4 addresses are attached to a
point-to-network pseudo-link instead of the interface where the CLAT IPv6
address is attached?

2. Consider the interaction an IPv6 listener and an IPv4 listener binding
to the same UDP port without using either SO_REUSEADDR option [or the
non-standard SO_REUSEPORT option], where the IPv6 socket is binding to the
same interface address that the CLAT will translate for the interface
address bound by the IPv4 socket? Does only the first socket() call succeed
while the second one fails? Or is there a different semantic? If so, what
is it?

3. Suppose instead the applications in the example above (2) do use
SO_REUSEADDR [and SO_REUSEPORT], and there are now two sockets bound to the
same IPv6 address and port, one of them translated by the CLAT and the
other not. Can these two applications communicate over interface loopback
through the CLAT?

Just saying that the CLAT is "an unnumbered IPv4-only point-to-point link"
tells us nothing about what application programmers can expect in these
sorts of weird corner cases, but the whole point of 464XLAT is to support
applications that don't use the protocol-independent interfaces.

I can understand why one might not want to document the answers to these
questions. Doing so might expose precisely how 464XLAT doesn't actually
deliver IPv4-only equivalence to applications on IPv6-only networks, but I
contend it's important to describe precisely what the CLAT does and doesn't
enable. Explaining what remains broken even after deploying a CLAT in every
host operating system will go a long way toward retaining a sensible
argument for application developers to migrate away from IPv4-only
programming interfaces.