Hi, Owen:
0) Thanks for sorting out my vague memory, citing some consumer
electronics evolution history and an excellent overview of the current
IPv4/IPv6 landscape.
1) I believe that consumer electronics including PC related products
and services are in a separate category from the IPv4 to IPv6 transition
considerations. The latter is part of global communications systems that
backward compatibility should be regarded a given requirement. The
former normally plays out by free market force such as consumer
preference which are highly influenced by marketing banners and changes
with time. (For example, the vacuum tube stereo amplifiers and vinyl
records recently came back in force, after so many years of obsolescent.
However, going either direction was not a concern of most, except a few
audio enthusiasts.) Maintaining smooth daily operation of the latter
while going through the evolution is very important for everyone. Short
of such, the process will be frustratingly hard to predict.
2) " .... In the case of the DTMF transition, ... AT&T could simply
have shipped replacement phones with instructions for returning the
older phone and done a retrofit operation if they really wanted to drive
the transition.":
Correct, because back then, the station instruments were on long
term lease from Bell Operating Companies. Even so, CO equipment
readiness and the economics (Although DTMF shortened each subscriber
dialing session almost by ~90% which was a big operation saving for the
COs, subscriber could not sense, therefore did not care for the upgrade
from DD.) of such a big replacement process had to be carefully
considered. With the break-up of the Bell System and the consequent
abundance of CPE products on the market, the window of opportunity went
by before anyone realized.
3) The diversity of the Internet constituencies as you outlined make
the transition from IPv4 to IPv6 an even more challenging event. I
believe that the current general consensus of coexistence with
Dual-Stack bridging the two should have settled the debates. From now
on, everyone should focus on his own passion. The continued efforts of
persuading others to move one way or the other are counter-productive
from an overall perspective.
Regards,
Abe (2024-01-19 12:20)
On 2024-01-19 05:26, Owen DeLong wrote:
On Jan 15, 2024, at 09:37, Abraham Y. Chen <ayc...@avinta.com> wrote:
Hi, Christopher"
1) " IPv6 is designed to replace IPv4. ":
Correct. But, this is not like Ten Commandments that God gave to
his children. Even such had not worked out in most cases. In real
life, technical backward compatibility is the only known approach to
achieve graceful replacement of the old. Failing to observe such
discipline, one should not blame others for the disappointment in the
transition. I am an outsider to the Internet development history.
But, the overall appearance at this moment is that somehow IPv6
design failed to properly execute the backward compatibility
requirement. So, IPv6 replacing IPv4 is not given.
This isn’t entirely true… Cassette tapes were not particularly
backwards compatible with LPs or 8-tracks. CDs were not backwards
compatible with LPs, Casettes, or 8-tracks. iPods/etc. were not
backwards compatible with any of the above.
USB-C is not backwards compatible with Lightning is not backwards
compatible with Dock.
What I think has been shown is that the new needs to provide something
compelling to the user being forced to migrate in order to motivate
them to suffer the cost and inconvenience. Unfortunately, between NAT
and Microsoft, instead of demand for an end-to-end network solution,
we have consumers that have come to accept, nay expect the degraded
level of service that is Windows and the Natternet that we have today.
Application developers have all coded to this lowest possible state of
network capability, and even written code which breaks absent NAT in
some cases (I’m pointing at you Philips Hue).
For a little while, there was a bunch of free porn available on
IPv6-only that some hoped would drive IPv6 adoption. Unfortunately,
all it really drove was a large number of IPv4-only free porn sites.
Other apps that were supposed to be v6-only and thus drive adoption
included IPSEC (rapidly back ported as a terrible hack on v4, not only
reducing the incentive to migrate to v6, but giving IPSEC a horrible
reputation for complexity and dysfunction in the process because of
how hacky the v4 implementation has to be) and DHCP-PD (which remains
IPv6-only, but failure to put forth standard mechanisms for the DHCP
server to communicate the necessary delegation data to the router that
need to forward the delegated prefixes reduced the utility of that
particular solution so far).
2) Allow me to share with you an almost parallel event in the
PSTN, to illustrate how tough is to achieve the replacement of a
working service, even under an environment with very strict backward
compatibility disicpline:
A. The Decadic (rotary) Dialing (DD) technique worked well on
the telephone loop to a certain limit of distance for many years that
enabled the automatic telephone switching systems. But, it could not
go beyond the CO (Central Office).
B. So, Bell Labs studied the use of DTMF (Dual Tone
Multi-Frequency) or commonly known as Touch-Tone as trademarked in
US, etc. The work started in mid 1940s.
c. By late 1960s, working demos became available. During the
mid-1970s, it was deployed across the Bell System (and beyond upon
requests from other countries).
D. With end-to-end signally capability of the DTMF signalling,
a lot of services such as remote purchase, airline status checking ,
etc.,grew drastically.
E. However, DTMF was a complete technology from Decadic
Dialing and most phones in the field were still the latter type. COs
had to install dual function line cards on the loop that subscriber
liked to enjoy the DTMF capability. Obviously, the dual function line
cards costed more than that of the basic DD version.
F. Initially, AT&T offered the DTMF service for free (well,
covered by the rental of the new phone) to encourage that adoption.
Then, they raised the monthly service rate for lines still requiring
DD receiver hoping to gracefully forcing the subscribes to wean from
using DD phones.
Actually, I recall that if you wanted DTMF capability on your line,
you had to pay extra for a time, then when they decided to deprecate
DD, they dropped that surcharge. I don’t remember ever having to pay
extra for DD, but I do remember getting notices telling me that they
were turning off “pulse dialing” as of some particular date.
This led to amusing solutions like phones you could buy at Radio Shack
and similar with an easily accessible switch that allowed you to call
whatever service you wanted using pulse dialing, then flip the switch
and use DTMF to talk to said service.
G. Guess what, the inertia of the huge DD phones out there in
the field accumulated through near one century made the strategy
impossible. That is, many subscribers would rather to pay one extra
dollar or so a month to enjoy having the old DD phone around, either
to avoid paying a new DTMF phone or just for the antique look of the
DD phone. This also created a nightmare of three types (DD, DTMF and
combined) line cards in the CO.
H. As this went on, a version of phone with DTMF dial pad but
sending out DD pulses appeared on the open market (thanks to the
deregulation / break up the Bell System). Such novelty phones really
gave phone companies a hard time about the transition plan.
The Carterfone decision was one of the best things to ever happen to
the telephone system in the united states. The courts do occasionally
get something right.
I. In the meantime, IC technology advanced to have single chip
capable of both dialing techniques (even further integrated other
traditional line card functions onto the same chip) making the
transition plan moot.
J Nowadays, almost every line card type chip handles DTMF as
advertised. But, if you try a DD phone on it, chances are, it works
anyway!
K. You may see some parallelism between the above and the current
IPv4 / IPv6 transition issues.
Some, but not a lot. In the case of the DTMF transition, the network
and handsets were all under the central control of a single provider
at a time when they could have forced the change if they really wanted
to. After all, nobody was going to cancel their phone service
altogether (or such a small fraction of subscribers as to count as a
rounding error anyway) over the issue and AT&T could simply have
shipped replacement phones with instructions for returning the older
phone and done a retrofit operation if they really wanted to drive the
transition.
For better (mostly) and worse (sometimes), there is no such central
organization in control of the internet. Instead, there are multiple
competing interest groups with various incentives in different
directions around whether or not to adopt IPv6.
Enterprise is mostly disincentivized because most enterprises don’t
really want an end-to-end internet and prefer the degraded state of
their users that exists at this time. While that same degraded service
can be provided in IPv6, if you don’t want the advantages of IPv6 and
an end-to-end network, there’s really little advantage and a lot of
cost to implementing it in an enterprise scenario. Google’s dug in
stance on DHCPv6 on Android is definitely not helping that situation.
Content providers mostly don’t care, though the larger ones recognize
the necessity and the most advanced ones have actually implemented
v6-only networks with v4 translators at the edge where necessary.
CDNs are providing a great service and mostly dual-stacking the
consumer-facing side of their services while offering to reach origin
content via either protocol, thus allowing content providers to
operate mono stack in either protocol while reaching customers over
both protocols.
Eyeball ISPs vary, with the largest ones being very motivated to get
their customers dependence on v4 reduced as much as possible.
Universities are a mixed bag, some pushing forward ahead of the game
and many thinking “We’ve got enough IPv4 addresses for our needs for
the next 200 years, what do we need with this v6 stuff?”
Backbone providers are mostly dual-stack and mostly don’t care.
Running 2 stacks isn’t significantly worse than running 1 stack for
most of them.
Mobile operators (cellular) are in the same boat with the larger
eyeball ISPs.
Consumers mostly don’t want to know that IP, whether v4 or v6 exists,
they just want their MTyouTickBookTwit. If the porn and the cat videos
keep working, they don’t care what protocol it’s delivered over.
I’m sure there are constituencies I’ve left out here, but I think this
covers most cases.
Owen
Regards,
Abe (2024-01-15 12:37)
On 2024-01-15 00:15, Christopher Hawker wrote:
To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free
to correct me if I'm wrong. There are just short of 4.3 billion IPv4
addresses, where the number of IPv6 addresses is 39 digits long.
Regards,
Christopher Hawker
On Mon, 15 Jan 2024 at 15:18, Abraham Y. Chen <ayc...@avinta.com> wrote:
Hi, Randy:
1) " ... unfortunately i already had grey hair in the '90s and
was in the room for all this, ... ":
My apologies! For an uninitiated, I misread your message as
if IPv6 was originally designed with a plan to assure smooth
transition from IPv4.
Regards,
Abe (2024-01-14 23:17)
On 2024-01-12 17:45, Randy Bush wrote:
Perhaps you are too young to realize that the original IPv6 plan was
not designed to be backward compatible to IPv4, and Dual-Stack was
developed (through some iterations) to bridge the transition between
IPv4 and IPv6? You may want to spend a few moments to read some
history on this.
ROFL!!! if there is anything you can do to make me that young, you
could have a very lucrative career outside of the internet.
hint: unfortunately i already had grey hair in the '90s and was in the
room for all this, and spent a few decades managing to get some of the
worst stupidities (TLA, NLA, ...) pulled out of the spec. at iij, we
rolled ipv6 on the backbone in 1997.
randy
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<x-msg://17/#m_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
