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

Fri Jan 19 10:26:08 UTC 2024

> On Jan 15, 2024, at 09:37, Abraham Y. Chen <aychen at 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 at avinta.com <mailto:aychen at 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240119/0e157814/attachment.html>