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

From: Ca By <[email-masked]>
Date: Thu, 19 Mar 2015 14:27:09 -0700

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 19 Mar 2015 23:50:32 +0000

> On Mar 19, 2015, at 2:27 PM, Ca By <[email-masked]> wrote:
> 
> 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.

</chair>

I guess my question is what you would recommend. This comes across as "give up on the transition; it will never happen." I’d like to believe that there is in fact a way we can make it happen. How do we get there?

One approach would be that we simply let it happen, and folks who deploy IPv4 address literals eventually see market fall-off correlated with IPv6 growth. At some point, that becomes a forcing mechanism. It’s not a tenable one now, however.

draft-osamu-v6ops-ipv4-literal-in-url comments on this in detail and makes a proposal.

In addition:

draft-ietf-sunset4-gapanalysis-05.txt
7.  IPv4 Address Literals

   IPv4 addresses are often used as resource locators.  For example, it
   is common to encounter URLs containing IPv4 address literals on web
   sites [I-D.wing-behave-http-ip-address-literals].  IPv4 address
   literals may be published on media other than web sites, and may
   appear in various forms other than URLs.  For the operating systems
   which exhibit the behavior described in
   [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an
   increase in the broadcast ARP traffic, which may be undesirable.

   PROBLEM 14: IPv6-only hosts are unable to access resources identified
               by IPv4 address literals.

   [I-D.wing-behave-http-ip-address-literals]
              Wing, D., "Coping with IP Address Literals in HTTP URIs
              with IPv6/IPv4 Translators", draft-wing-behave-http-ip-
              address-literals-02 (work in progress), March 2010.

draft-ietf-v6ops-mobile-device-profile-20.txt
   The use of address family dependent APIs (Application Programming
   Interfaces) or hard-coded IPv4 address literals may lead to broken
   applications when IPv6 connectivity is in use.  As such, means to
   minimize broken applications when the cellular host is attached to an
   IPv6-only network should be encouraged.  Particularly, (1) name
   resolution libraries (e.g., [RFC3596]) must support both IPv4 and
   IPv6; (2) applications must be independent of the underlying IP
   address family; (3) and applications relying upon Uniform Resource
   Identifiers (URIs) must follow [RFC3986] and its updates.  Note, some
   IETF specifications (e.g., SIP [RFC3261]) contains broken IPv6 ABNF
   and rules to compare URIs with embedded IPv6 addresses; fixes (e.g.,
   [RFC5954]) must be used instead.

draft-ietf-xmpp-6122bis-19.txt
      jid          = [ localpart "@" ] domainpart [ "/" resourcepart ]
      localpart    = 1*1023(userbyte)
                     ;
                     ; a "userbyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to the
                     ; "UsernameCaseMapped" profile of the PRECIS
                     ; IdentifierClass
                     ;
      domainpart   = IP-literal / IPv4address / ifqdn
                     ;
                     ; the "IPv4address" and "IP-literal" rules are
                     ; defined in RFC 3986, and the first-match-wins
                     ; (a.k.a. "greedy") algorithm described therein
                     ; applies to the matching process
                     ;
                     ; note well that reuse of the IP-literal rule from
                     ; RFC 3986 implies that IPv6 addresses are enclosed
                     ; in square brackets (i.e., beginning with '[' and
                     ; ending with ']')
                     ;
      ifqdn        = 1*1023(domainbyte)
                     ;
                     ; a "domainbyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to RFC 5890
                     ;
      resourcepart = 1*1023(resourcebyte)
                     ;
                     ; an "opaquebyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to the
                     ; "OpaqueString" profile of the PRECIS
                     ; FreeformClass
                     ;

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Mar 2015 06:42:00 +0100 (CET)

> purely IPv6-only socket solution.  As has been previously explored, about

I agree, it isn't now. And this is the same as with most APIs, it takes a 
long time to deprecate old APIs. I believe it'll take at least 10-20 years 
before "open" operating systems will start to deprecate the old IPv4 APIs. 
Until then, the operating system will have to implement functions like 
464XLAT to work around this situation. It's not good, but I'd say this is 
pretty typical transition problem.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Fri, 20 Mar 2015 13:21:57 +0100

> On 19 Mar 2015, at 22:27, Ca By <[email-masked]> wrote:
> 
> 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
> 
If all the smart solutions have failed, what about a dumb one?

Pipe all IPv4 literal requests using IPv6 transport to a big web proxy at the edge of the ISP's IPv6 only cloud. If it's one percent of traffic why isn't that feasible? Assuming the host can detect it has no native IPv4 connectivity and it can perform automatic proxy discovery over IPv6. It works for most enterprises and most enterprise apps....

---

From: Tore Anderson <[email-masked]>
Date: Fri, 20 Mar 2015 13:42:04 +0100

* Mikael Abrahamsson <[email-masked]>

> Until then, the operating system will have to implement functions
> like 464XLAT to work around this situation. It's not good, but I'd say
> this is pretty typical transition problem.

Yep.

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!

Once we can translate IPv4 on our network borders/edges and keep the
network itself IPv6-only we have way to proceed with the transition.
Hopefully it will eventually dawn on the apps and web sites that use of
literals or depending on AF_INET sockets isn't particularly smart if
they want the optimal performance and functionality. (But if they don't
it's no big deal either, they can get the best-effort service level.)

Tore

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Fri, 20 Mar 2015 12:59:11 +0000

This is a reason why OPL do not use DNS64 (domain “ipv4only.arpa” only), and all ipv4 traffic goes via CLAT. We are transitioning  to IPv6-only not only smartphones/tablets , but mobile routers as well.

The standards should be revised with additional scenario -  CLAT/NAT64/DNS for IPv6-only.

BR,
Mcz

From: v6ops [mailto:[email-masked]] On Behalf Of Ca By
Sent: Thursday, March 19, 2015 10:27 PM
To: IPv6 Ops WG
Subject: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Hi Folks,

Thoughts?

CB

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Fri, 20 Mar 2015 16:01:08 +0000

CLAT is already in Windowsphone 8.1 - Pere & All thank you very much :)

Idea of fancy "IPv6 bulding, house, cavern " is interesting but... I would suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com etc. 
"Internet is content" 
Cheers,
tk 

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Friday, March 20, 2015 1:42 PM
To: Mikael Abrahamsson
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

> 464XLAT to work around this situation. It's not good, but I'd say this 
> is pretty typical transition problem.

Yep.

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!

Once we can translate IPv4 on our network borders/edges and keep the network itself IPv6-only we have way to proceed with the transition.
Hopefully it will eventually dawn on the apps and web sites that use of literals or depending on AF_INET sockets isn't particularly smart if they want the optimal performance and functionality. (But if they don't it's no big deal either, they can get the best-effort service level.)

Tore

---

From: Xing Li <[email-masked]>
Date: Mon, 23 Mar 2015 03:59:27 +0800

> Idea of fancy "IPv6 bulding, house, cavern " is interesting but... I would suggest to enable IPv6 on key Microsoft content ie. Bing.com, live.com etc. 
It will be great, if the new versions of all the operating systems can 
support both the CPE function of MAP-T (stateless NAT64 in the core) and 
CLAT for 464XLAT (stateful NAT64 in the core).

Regards,

xing

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

---

From: Ca By <[email-masked]>
Date: Mon, 23 Mar 2015 09:12:25 -0700

On Sun, Mar 22, 2015 at 12:59 PM, Xing Li <[email-masked]> wrote:

>  Kossut Tomasz - Hurt 写道:

Xing,

I agree.  In mobile, Windows Phone and Android both support CLAT.

But there is one major mobile OS missing this feature.

Perhaps the IETF should give guidance via BCP that an IPv6-only solution
that supports IPv4 sockets be supported on hosts

CB

> From: Tore Anderson [mailto:[email-masked] <[email-masked]>]
> * Mikael Abrahamsson <[email-masked]> <[email-masked]>
>
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 18:55:02 +0100

Le 23/03/2015 17:12, Ca By a écrit :
[...]
> Perhaps the IETF should give guidance via BCP that an IPv6-only
> solution that supports IPv4 sockets be supported on hosts

Updating RFC3542 "Advanced Socket API for IPv6"?

Alex

>
> CB
>
>> -----Original Message----- From: Tore Anderson
>> [mailto:[email-masked]] Sent: Friday, March 20, 2015 1:42 PM To:
>> Mikael Abrahamsson Cc: IPv6 Ops WG Subject: Re: [v6ops] The need
>> for local-ipv4 socket transition solutions -- NAT64/DNS64 remains
>> insufficient
>>
>> * Mikael Abrahamsson<[email-masked]>  <mailto:[email-masked]>
>>
>>
>>> like 464XLAT to work around this situation. It's not good, but
>>> I'd say this is pretty typical transition problem.
>>>
>> Yep.
>>
>> 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!
>>
>> Once we can translate IPv4 on our network borders/edges and keep
>> the network itself IPv6-only we have way to proceed with the
>> transition. Hopefully it will eventually dawn on the apps and web
>> sites that use of literals or depending on AF_INET sockets isn't
>> particularly smart if they want the optimal performance and
>> functionality. (But if they don't it's no big deal either, they can
>> get the best-effort service level.)
>>
>> Tore
>>
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked]  <mailto:[email-masked]>
> _______________________________________________ v6ops mailing list
> [email-masked] <mailto:[email-masked]>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 07:53:16 -0500

> (I asked her to add the Windows Server folks to her CC list). Fingers

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 07:54:32 -0500

> that supports IPv4 sockets be supported on hosts

Oh, I see why you started this thread now. Do you expect that the IETF
would be able to reach consensus on such a statement?

---

From: Ca By <[email-masked]>
Date: Tue, 24 Mar 2015 07:11:09 -0700

On Tuesday, March 24, 2015, Lorenzo Colitti <[email-masked]> wrote:

> On Mon, Mar 23, 2015 at 11:12 AM, Ca By <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

Yes. Are you in opposition?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 09:13:05 -0500

> Yes. Are you in opposition?

Oh, of course not. I'm the maintainer of a popular 464xlat implementation,
remember?

---

From: James Woodyatt <[email-masked]>
Date: Tue, 24 Mar 2015 10:06:49 -0500

On the other hand, I would be disappointed if such a consensus were to
emerge. It would mean that we would never be able to sunset IPv4, and as an
endpoint software developer, if every host I want to deploy on has a CLAT
provided by the system, then I'd observe that my incentives to stop writing
IPv4-only software logic would evaporate for all practical purposes.

I expect my opposition would be trammeled by bulldozers, but I would oppose.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 10:26:07 -0500

On Tue, Mar 24, 2015 at 10:06 AM, James Woodyatt <[email-masked]> wrote:

> as an endpoint software developer, if every host I want to deploy on has a
> CLAT provided by the system, then I'd observe that my incentives to stop
> writing IPv4-only software logic would evaporate for all practical purposes.
>

I'm not sure that's true. We have four scenarios, in order of decreasing
incentives (from 100% to 0%) to write IPv4-only code:

   1. IPv4-only device
   2. Dual-stack device (native IPv6 and NAT44 or NAT444)
   3. IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat).
   4. IPv6-only device

Based on personal experience, I know that #3 provides less incentives to
write IPv4-only code than #2. I've heard developers say multiple times,
"Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and
high latency too. What do I need to do to fix my code to support IPv6?" In
contrast, #2 is seen as, "well, we still have IPv4 right? So we can just
continue to use it. You say IPv6 has no NAT? But we deal with NAT today,
and it works fine..."

I think the real discussion here is whether going from #2 to #4 without
passing through #3 is possible at all. If you believe that it's possible,
then #2 makes sense. If you believe it's not possible, then the only thing
that makes sense is to do #3 ASAP.

I don't believe that going from #2 to #4 is possible for the industry. It
may be possible for a tightly-controlled, substantial subset of the
industry (e.g., Apple) to do it, but if we did not have a substantial part
of the industry doing #3 already, we'd likely get stuck.

#3 does provide strong advantages over #2 to operators; in some networks,
#2 doesn't actually fix anything because the problem is private IPv4
address exhaustion. For those networks, the only options are #1 or #3 -
which is why those networks are doing 464xlat.

---

From: Ca By <[email-masked]>
Date: Tue, 24 Mar 2015 08:47:42 -0700

> I expect my opposition would be trammeled by bulldozers, but I would

Rev'ing up the bulldozer (puffs of smoke fill the air)

I agree with your principles, and i believed in them too at one point, but
i became painfully aware that this view is grossly misaligned with
reality.  Once abandoning this view and accepting that i cannot boil the
IPv4 ocean, i experienced a great deal of internal peace as i took control
of my internet numbering destiny.

As we know, in mobile, there are 3 dominate operating systems.  Each and
everyone of them ships with fundamental software -- core functionality --
that cannot operate without IPv4 sockets.  Beyond the IPv4 dependent
software that ships on a clean build, the apps stores are littered with
IPv4 dependencies -- in top 100 apps.  The typical number in the app store
is 20% of the top 100 fail on IPv6 + NAT64/DNS64, recently re-verified by
myself.

Even if these amazingly-wealthy talent-stuffed software factories were able
to clean up their own ipv4-dependent software, and painfully thrust
standards on 3rd party app makers, they cannot clean up the world wide web
(as noted in the first message of the thread).  They cannot clean up
enterprise VPNs.

And no, no ISP / Mobile provider is willing to accept 1% of the web
breaking  (including Alexa top 100 web pages) while their competitors
deliver 100% of the web.

Shorter Cameron:  Failure to deploy a proper IPv6-only solution to the host
is creating real and meaningful harm to IPv6 deployment at large.  The
network that i work at has hit a ceiling on IPv6 deployment due to a single
major host operating system lacking this basic functionality (Windows Phone
and Android support 464XLAT, deployed to 10s of millions of users who have
never heard of IPv4).

IPv4 dependence is hurting the internet and allows for middle-box
proliferation.

So, perhaps a BCP from the IETF would make it clear what is best and what
is not-best.

CB

>> Oh, of course not. I'm the maintainer of a popular 464xlat
>> implementation, remember?
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2015 05:24:27 +1300

On 25/03/2015 04:26, Lorenzo Colitti wrote:
> high latency too. What do I need to do to fix my code to support IPv6?" 

I think this is important. The biggest problem that I see is how to incent
smaller content providers (smaller than Google and Facebook, I mean) that
it is in their own interest to support native IPv6. If they perceive IPv4
as becoming a second-class service for millions of users, that might push
them in the right direction. #3 is useful in that context.

   Brian

> In

---

From: James Woodyatt <[email-masked]>
Date: Tue, 24 Mar 2015 17:22:19 -0500

Cameron, Lorenzo—

Lorenzo writes, "I think the real discussion here is whether going from #2
[IPv6 + IPv4/NAT] to #4 [IPv6-ONLY] without passing through #3 [IPv6 +
464XLAT] is possible at all. If you believe that it's possible, then #2
makes sense. If you believe it's not possible, then the only thing that
makes sense is to do #3 ASAP."

My reply: "I don't agree with that characterization of the discussion. A
very large faction of the Internet community remains convinced to this day
that IPv6-ONLY is neither necessary nor even desirable. I'm partially
sympathetic— I see it as desirable in the long term, absolutely, but I
recognize that I don't yet have convincing arguments that it's strictly
necessary, much less necessary to get there this decade. If IPv6-ONLY is
desirable but not actually necessary, as many people still believe, then
the discussion is about whether IPv6-ONLY is more or less desirable than
IPv6 + IPv4/NAT. Can we honestly say we know which of those outcomes is
better? I can't."

Cameron writes, "IPv4 dependence is hurting the internet and allows for
middle-box proliferation."

My reply: "I agree that IPv4 dependency is hurting the Internet, but I also
view 464XLAT as a scheme to prolong the viability of IPv4-only software. I
also don't agree that IPv4 dependence is any more permissive of middlebox
proliferation than IPv6 is permissive of it. From my view, it looks like
IPv6 is at least as permissive as IPv4 and probably more permissive because
the prevalence of NAT in IPv4 makes some middlebox functions more difficult
to deploy. Shorter james. This middlebox comment smells all kinds of wrong
to me."

Cameron also writes, "So, perhaps a BCP from the IETF would make it clear
what is best and what is not-best."

My reply: "It might make 'somewhat less unclear' what IETF thinks is best
vs. non best. I believe it would make very clear that IETF thinks
developing software that depends on IPv4-ONLY programming interfaces is a
best CURRENT practice, which would make it much more difficult— at a
critical juncture in the transition to IPv6— to communicate to developers
that adopting IPv6-aware programming interfaces is important, and I would
feel compelled to object to that."

---

From: Tore Anderson <[email-masked]>
Date: Wed, 25 Mar 2015 08:07:47 +0100

* Ca By <[email-masked]>

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

Hi Cameron,

You - and anyone else that cares about this topic - might want to read
draft-anderson-v6ops-siit-eam-03 and send any comments or feedback you
might have to the list. Keep in mind that 464XLAT is not a formal
standard, but rather the description of a use case that at least in
some deployment models (e.g., 3GPP networks) requires a non-standard
building block, in particular an SIIT implementation that can work with
non-IPv4-translatable IPv6 addresses.

https://tools.ietf.org/html/draft-anderson-v6ops-siit-eam

The purpose of the the siit-eam draft is to formally add the missing
funtionality to RFC 6145, so that we can ask vendors to «please
implement this standard». If they do so, they will have not only
provided the basic building block that is necessary to implement
464XLAT's CLAT component, but also something that can be used for
other similar transition solutions (SIIT-DC comes to mind).

I'll present the siit-eam draft in the v6ops session tomorrow, and
intend to ask for WG adoption. I'm hoping your hum will be heard loud
and clear all the way to here in Norway. (Through Meetecho, that is.)

Yes, this message is a shameless plug. My apologies.

Tore

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Wed, 25 Mar 2015 09:39:37 +0000

+1

BR,
Mcz

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, March 24, 2015 4:26 PM
To: James Woodyatt
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Tue, Mar 24, 2015 at 10:06 AM, James Woodyatt <[email-masked]<mailto:[email-masked]>> wrote:
as an endpoint software developer, if every host I want to deploy on has a CLAT provided by the system, then I'd observe that my incentives to stop writing IPv4-only software logic would evaporate for all practical purposes.

I'm not sure that's true. We have four scenarios, in order of decreasing incentives (from 100% to 0%) to write IPv4-only code:

  1.  IPv4-only device
  2.  Dual-stack device (native IPv6 and NAT44 or NAT444)
  3.  IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat).
  4.  IPv6-only device
Based on personal experience, I know that #3 provides less incentives to write IPv4-only code than #2. I've heard developers say multiple times, "Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and high latency too. What do I need to do to fix my code to support IPv6?" In contrast, #2 is seen as, "well, we still have IPv4 right? So we can just continue to use it. You say IPv6 has no NAT? But we deal with NAT today, and it works fine..."

I think the real discussion here is whether going from #2 to #4 without passing through #3 is possible at all. If you believe that it's possible, then #2 makes sense. If you believe it's not possible, then the only thing that makes sense is to do #3 ASAP.

I don't believe that going from #2 to #4 is possible for the industry. It may be possible for a tightly-controlled, substantial subset of the industry (e.g., Apple) to do it, but if we did not have a substantial part of the industry doing #3 already, we'd likely get stuck.

#3 does provide strong advantages over #2 to operators; in some networks, #2 doesn't actually fix anything because the problem is private IPv4 address exhaustion. For those networks, the only options are #1 or #3 - which is why those networks are doing 464xlat.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 26 Mar 2015 01:08:00 +0100

> view 464XLAT as a scheme to prolong the viability of IPv4-only software.

One of more reliable ways to drive the IPv4-only software sunset would
be to emit a compiler warning whenever the static analyzer discovers
an AF_INET socket being made.

This warning would come with a corresponding developer page explaining
why AF_INET is the new strcpy(), and give the correct examples of how
to implement the dualstack networking correctly.

But even absent the compiler magic, I would like you to consider the
following logic:

1) One can say "dualstack" access network promotes IPv4-only apps
stronger than "IPv6+CLAT" access network.

2) Universal availability of CLAT would allow the percentage of
"IPv6+CLAT" networks
to increase, because now a network can just flip from IPv4-only to
IPv6-only+CLAT at little or no cost.

3) This would increase the overall share of IPv6 while decreasing the
share of IPv4 *at the same time*

4) This will increase the attractiveness of using AF_INET6.

What do you think ?

--a

---

From: Ca By <[email-masked]>
Date: Wed, 25 Mar 2015 18:21:53 -0700

On Wednesday, March 25, 2015, Andrew 👽 Yourtchenko <[email-masked]>
wrote:

> On 3/24/15, James Woodyatt <[email-masked] <javascript:;>> wrote:
> > Cameron, Lorenzo—
>
>

That would be a nice step.

But that is improbable  and does not solve the non-zero number of websites
in the Alexa 100 that have IPv4 literals in html / xml / js.

It also does not solve the sip / xmpp issue of being completely littered
with IPv4 referrals.

See first post in this thread for the problem

CB

> [email-masked] <javascript:;>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Mar 2015 14:46:01 +1100

In message <CAPi140PQ+TF0rED_bQPeS=[email-masked]>, =?UTF-8?B?
QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= writes:
> > Cameron, Lorenzo

#ifdef KERNEL
#define AF_INET X
#endif

#define AI_DEFAULT      (AI_V4MAPPED | AI_ADDRCONFIG)

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

---

From: James Woodyatt <[email-masked]>
Date: Thu, 26 Mar 2015 11:29:10 -0500

On Wed, Mar 25, 2015 at 8:21 PM, Ca By <[email-masked]> wrote:
>
>
> [...] does not solve the non-zero number of websites in the Alexa 100 that
> have IPv4 literals in html / xml / js.
> with IPv4 referrals. [...]
>

Neither does IPv6+CLAT, which simply admits defeat. The IPv4 literals will
never die, and IPv4 as a service will never be sunset. Yes, I recognize
that entirely shifting the burden of supporting IPv4 onto the operating
system developers, into the unforeseeable future, while the network
operators get a clean transition to IPv6-only, can seem like a "solution"
from certain bell-shaped perspectives, but there is still a world outside
that perspective where some of us are trying to make a living.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 26 Mar 2015 16:46:49 +0000

“Yes, I recognize that entirely shifting the burden of supporting IPv4 onto the operating system developers, into the unforeseeable future, while the network operators get a clean transition to IPv6-only, can seem like a "solution" from certain bell-shaped perspectives, but there is still a world outside that perspective where some of us are trying to make a living.”

-          What does that mean?

IPv4 literals will die off with IPv4, or sooner, whenever that happens.  In other words, “never”, is a long time; probably too long for that statement to be realistic.  What are you advocating?

Thanks,

-          Dan Metzler

From: v6ops [mailto:[email-masked]] On Behalf Of James Woodyatt
Sent: Thursday, March 26, 2015 11:29 AM
To: Ca By
Cc: IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Wed, Mar 25, 2015 at 8:21 PM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:

[...] does not solve the non-zero number of websites in the Alexa 100 that have IPv4 literals in html / xml / js.
It also does not solve the sip / xmpp issue of being completely littered with IPv4 referrals. [...]

Neither does IPv6+CLAT, which simply admits defeat. The IPv4 literals will never die, and IPv4 as a service will never be sunset. Yes, I recognize that entirely shifting the burden of supporting IPv4 onto the operating system developers, into the unforeseeable future, while the network operators get a clean transition to IPv6-only, can seem like a "solution" from certain bell-shaped perspectives, but there is still a world outside that perspective where some of us are trying to make a living.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Mar 2015 11:56:22 -0500

On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt <[email-masked]> wrote:

> Yes, I recognize that entirely shifting the burden of supporting IPv4 onto
> the operating system developers, into the unforeseeable future, while the
> network operators get a clean transition to IPv6-only, can seem like a
> "solution" from certain bell-shaped perspectives, but there is still a
> world outside that perspective where some of us are trying to make a living.
>

As someone who does maintain a 464xlat implementation for the purposes of
supporting IPv4, I don't think it's an unreasonable burden.

It's true that if we have compatibility solutions in place, we might never
completely get rid of IPv4 until all IPv4-only apps are obsolete. But if
the cost of maintaining such solutions is low, what's the harm?

---

From: Tore Anderson <[email-masked]>
Date: Thu, 26 Mar 2015 19:11:06 +0100

* Lorenzo Colitti

> > Yes, I recognize that entirely shifting the burden of supporting
> > IPv4 onto the operating system developers, into the unforeseeable
> > future, while the network operators get a clean transition to
> > IPv6-only, can seem like a "solution" from certain bell-shaped
> > perspectives, but there is still a world outside that perspective
> > where some of us are trying to make a living.
> 
> As someone who does maintain a 464xlat implementation for the
> purposes of supporting IPv4, I don't think it's an unreasonable
> burden.

Agreed.

There's also the fact that the number of network operators in the world
is many orders of magnitude higher than the number of operating system
vendors, so even if the burden of maintaining a 464XLAT implementation
in an operating system is higher than it is to maintain IPv4 access
service in a network, so when you put it in in a bigger perspective,
the total total burden gets *much* lower if the operating system
vendors help out and allow the network operators to transition to
IPv6-only.

But maybe it doesn't have to be an additional burden for the OS vendors
at all? If they follow our recommendation and kill 6to4 in their
products, then maybe they could perhaps simply reallocate the resources
that previously was spent on supporting 6to4 into supporting 464XLAT...

Tore

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 26 Mar 2015 18:23:00 +0000

> On 26 Mar 2015, at 18:11 , Tore Anderson <[email-masked]> wrote:
> 
> * Lorenzo Colitti
> 

However if the network operators would encourage all their customers to use IPv6 (traffic source and sink sides) . . . then everyone could just switch and no one would have to care about the IPv4 noise anymore.

Trying to solve this problem moving users to IPv6 by enforcing a technical solution is using a hammer to slice a tomato.

— 
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: Erik Kline <[email-masked]>
Date: Thu, 26 Mar 2015 13:23:09 -0500

>> purposes of supporting IPv4, I don't think it's an unreasonable

Yeah, I think we're in a "perfect is the enemy of the good" situation.

---

From: James Woodyatt <[email-masked]>
Date: Thu, 26 Mar 2015 17:23:25 -0500

> the cost of maintaining such solutions is low, what's the harm?

I sympathize with your position, Lorenzo, I really do. Nevertheless, I also
hope that Apple continues to resist the pressure it must be experiencing
today to bring 464XLAT to iOS and OS X. Let me explain why.

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.

---

From: Ross Chandler <[email-masked]>
Date: Thu, 26 Mar 2015 22:59:15 +0000

> On 26 Mar 2015, at 22:23, James Woodyatt <[email-masked]> wrote:
> 
> 
> I sympathize with your position, Lorenzo, I really do. Nevertheless, I also hope that Apple continues to resist the pressure it must be experiencing today to bring 464XLAT to iOS and OS X. Let me explain why.
> 
> 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.

IPv6-only+NAT64 networks are not deployed by ISPs. Without the CLAT the only option is IPv4+IPv6. There’s roughly the same low incentive to fix IPv4 literals with IPv4+IPv6 as with 464xlat.

That doesn’t makes sense as Apple’s motivation for not yet supporting 464xlat. It  just harms IPv6 deployment. 

Ross

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 18:44:34 -0500

On Mar 26, 2015, at 5:23 PM, James Woodyatt <[email-masked]> wrote:
> 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.

Just to be clear, am I correct in understanding that this is only an issue for IPv4 literals sent to from the IPv4-only service provider to the IPv6-only host?   It seems to me that there is no way to make it work in the other direction.

---

From: Xing Li <[email-masked]>
Date: Fri, 27 Mar 2015 13:09:42 +0800

Ross Chandler 写道:
>
>> On 26 Mar 2015, at 22:23, James Woodyatt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>> I sympathize with your position, Lorenzo, I really do. Nevertheless, 
>> I also hope that Apple continues to resist the pressure it must be 
>> experiencing today to bring 464XLAT to iOS and OS X. Let me explain why.
>>
>> 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.
>>
>> 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.
>
> IPv6-only+NAT64 networks are not deployed by ISPs. Without the CLAT 
> the only option is IPv4+IPv6. There’s roughly the same low incentive 
> to fix IPv4 literals with IPv4+IPv6 as with 464xlat.
>

+1. xing
>
>
> Ross
>
> ------------------------------------------------------------------------
>

---

From: Xing Li <[email-masked]>
Date: Fri, 27 Mar 2015 13:01:43 +0800

Lorenzo Colitti 写道:
> On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt <[email-masked] 
> As someone who does maintain a 464xlat implementation for the purposes 
> of supporting IPv4, I don't think it's an unreasonable burden.
>
> It's true that if we have compatibility solutions in place, we might 
> never completely get rid of IPv4 until all IPv4-only apps are 
> obsolete. But if the cost of maintaining such solutions is low, what's 
> the harm?

+1 xing

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 28 Mar 2015 13:27:36 +0000

> On Mar 24, 2015, at 10:26 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> IPv4-only device
> Dual-stack device (native IPv6 and NAT44 or NAT444)
> IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat).
> IPv6-only device

From my perspective, I would agree. That said, when dual stack was proposed, I think your #2 and #3 would have both been called “dual stack”; I know Tony Hain saw it coming and commented (negatively) on it. But the choices, from the perspective then, were IPv4 (your #1), IPv4+IPv6 (#2+#3), and IPv6 (#4).

From an evangelistic perspective, I think we’re past the time that telling people NAT is bad. I have been telling people how much money it takes to deploy an application that has to traverse one. Client-Server applications aren’t too hard if the server is on the public side of the NAT, which most are. If you have to cross the NAT from the outside, you have to have one pf three things:
1) persistent presence on the outside that things on the inside can connect to and have their sessions co-opted by the incoming call,
2) something akin to RSIP, or
3) application-specific ALG support in the middleware.

The first takes money, the second takes a standard that ADM providers can find in open source software, and the third takes convincing ODM providers and/or your corporate IT department.

And having IPv6 on bypasses all that.

Yes, I think we have to get to a point in which people that authorize monetary expenditures believe that an IPv6 network works better. We’re going to have to go through a phase in which IPv4 works worse, as perceived by the person using it.

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2015 11:22:07 -0400

On 03/26/2015 12:29 PM, James Woodyatt wrote:
> The IPv4 literals will never die, and IPv4 as a service will never be 
> sunset.

Yep.   Just like I still see .BITNET email addresses everywhere. (except 
that, come to think of it, I don't)

Keith

---

From: James Woodyatt <[email-masked]>
Date: Mon, 30 Mar 2015 13:20:30 -0500

Keith—​

I would have drawn that comparison to Appletalk not BITNET, except
strangely enough— maybe not so strangely— I don't remember seeing a lot of
Appletalk literal addresses littering source code the way you see IPv4
literals still so widely used today. Hmm, I wonder what lessons might be
drawn from such a comparison.

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2015 14:37:28 -0400

Of course, AppleTalk name/service discovery didn't have to work at Internet scale.  But maybe I should try to write an informational RFC on the myriad ways that DNS fails to be an adequate and reliable name lookup service.

Sent from my iPhone

> On Mar 30, 2015, at 2:20 PM, James Woodyatt <[email-masked]> wrote:
> 
> Keith—​
> 
> I would have drawn that comparison to Appletalk not BITNET, except strangely enough— maybe not so strangely— I don't remember seeing a lot of Appletalk literal addresses littering source code the way you see IPv4 literals still so widely used today. Hmm, I wonder what lessons might be drawn from such a comparison.