Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

["Abraham Y. Chen" <aychen () avinta com>]

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 <aychen () 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 <aychen () 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