Mailing List Archive

> 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

Is that a faux pas?

On 13 January 2024 9:15:11?am ACDT, Randy Bush <randy@psg.com> 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

I go into my cave to finish the todo list for the week, and I come out to
see Mr. Chen :
- Telling Randy Bush he should "read some history" on IPv6
- Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46?PM Randy Bush <randy@psg.com> 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
>

On Fri, Jan 12, 2024 at 2:47?PM Randy Bush <randy@psg.com> 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
>

OMFG, that just made my afternoon. :D :D
Someone calling Randy Bush "too young".

If Randy Bush is too young, the rest of us must still need our diapers
changed on a regular basis. :P

Matt

> I go into my cave to finish the todo list for the week, and I come out
> to see Mr. Chen :
> - Telling Randy Bush he should "read some history" on IPv6
> - Implying that Vint Cerf ever said anything about EzIP
>
> Fairly impressive sequence of self ownage.

but it sure is a change to have a n00b troll.

i was really looking forward to it making me young. sigh.

randy

Wow... There is some serious learning about the internet to be done here!

When Randy was deploying IPv6 across the IIJ backbone, I was running around
in kindergarten. I didn't even know what the internet was back then.

Amazing what can happen in 26 years...

Regards,
Christopher Hawker

On Sat, 13 Jan 2024 at 09:35, Abraham Y. Chen <aychen@avinta.com> wrote:

> Hi, Randy:
>
> 1) " ... dual-stack mess ... it was intended. it was the original
> transition plan. ":
>
> 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.
>
>
> Regards,
>
>
> Abe (2024-01-12 17:34)
>
>
>
> On 2024-01-12 00:11, Randy Bush wrote:
>
> We don't need to extend IPv4, we need to figure out why we are in this
> dual-stack mess, which was never intended, and how to get out of it.
>
> it was intended. it was the original transition plan. like many things
> about ipv6, it could have been a bit better thought out.
>
> 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>
> <#m_-2764172948748324147_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

interesting side note:

when iij was deploying the v6 backbone in '97, commercial routers did
not support dual stack. so it was a parallel backbone built on netbsd
with the kame stack, which was developed in iij lab.

we remember itojun.

randy

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



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

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>
> <#m_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

> ??? My apologies! For an uninitiated, I misread your message as if
> IPv6 was originally designed with a plan to assure smooth transition
> from IPv4.

i'll try again

there was a transition plan; it was dual stack. i did not say it was a
*good* transition plan.

the plan's fatal flaw was that it assumed there was sufficient ipv4 to
be congruent until ipv6 was widely enough deplayed that the ipv4 could
be turned off. this was in the face of very real data (props to frank
kastenholz) projecting the ipv4 run out rate.

the v6 fantasy was that ipv6 would be quickly deployed. i guess it has
been from the perspective of geologic time.

randy

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.

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.

    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.

    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.


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>
>
>
> <#m_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On 1/15/24 09:37, Abraham Y. Chen wrote:

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

Actually, Bell had a multifrequency interoffice signaling system long
before Touch-Tone was introduced to the public. Many of us old-timers
were *very* familiar with this, much to the discontent of the Bell System.

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

In the early days of deployment, DTMF was not free. It was typically $1
more per month. IIRC, there was at one time an upcharge for 12-button
vs. 10-button Touch-Tone pads. I have never seen a tariff with an
upcharge for pulse dialing.

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

With step-by-step, XY, or panel offices the DTMF receiver was an add-on
that buffered the digits and outpulsed them at rotary dial speed. Pulse
dialing always worked. Crossbar was also an add-on but with a crossbar
marker the delay of converting to pulse was avoided. By the time ESS
came around both pulse and DTMF were built in.

Again, when and where was there ever an upcharge for pulse dialing?

>     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 purpose of these phones was actually the opposite. It allowed a
"modern" keypad-equipped phone to function on older lines not equipped
with a Touch-Tone receiver. In GTE territory with Strowger switching,
the digits from DTMF phones were buffered in the CO and outpulsed as
rotary dialing. Bang out the number with Touch-Tone and you could hear
the tick-tick of the digits being sent while you waited.

These days people get upset with post-dial delay of more than a couple
of seconds. It used to be substantially more, especially with
interoffice calls.

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

TTBOMK, every common BORSCHT chip accepts both.

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

Yes, because TTBOMK, telco central offices have always accepted pulse
dialing and still do. SIP ATAs, on the other hand, mostly don't, with
the exception of some older Grandstream units.

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Yes, some folks made Bell very umm... blue at times.

Indeed I remember a Touch Tone fee on our bills until the 90's.  In fact, at one point I couldn't believe it was still a charge, as rotary phones had largely been replaced either as a choice or through attrition.

Consumers WANTED Touch Tone.  There didn't NEED to be a "strategy" to eliminate pulse dialing, as it cost the Baby Bells nothing to support it.  After deregulation the appearance of 3rd party devices with a DTMF pad and a pule/tone switch wasn't to help customers work around this "scheme" of AT&T.  The 3rd parties, in general, wanted to produce inexpensive sets that featured a pulse option for those people/areas stuck in the past.  You couldn't do that inexpensively trying to replicate the clunky rotary dial, and again, no one/few WANTed them.

I get the whole desire to promote EzIP as the greatest thing since NAT itself, but fabricating a bizarre hot take on the implementation of Touch Tone/DTMF as an attempted parallel to IPv6 vs IPv4 is kinda "out there".  The *corrected* history of Jay's actual does draw parallels, but more as a tale of how some people will do anything to save $1 (a month) even if the tech is highly beneficial.


Danny Messano
On Jan 15, 2024 at 14:12 -0500, Jay Hennigan <jay@west.net>, wrote:
> On 1/15/24 09:37, Abraham Y. Chen wrote:
>
> > 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.
>
> Actually, Bell had a multifrequency interoffice signaling system long
> before Touch-Tone was introduced to the public. Many of us old-timers
> were *very* familiar with this, much to the discontent of the Bell System.
>
> >     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.
>
> In the early days of deployment, DTMF was not free. It was typically $1
> more per month. IIRC, there was at one time an upcharge for 12-button
> vs. 10-button Touch-Tone pads. I have never seen a tariff with an
> upcharge for pulse dialing.
>
> >     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.
>
> With step-by-step, XY, or panel offices the DTMF receiver was an add-on
> that buffered the digits and outpulsed them at rotary dial speed. Pulse
> dialing always worked. Crossbar was also an add-on but with a crossbar
> marker the delay of converting to pulse was avoided. By the time ESS
> came around both pulse and DTMF were built in.
>
> Again, when and where was there ever an upcharge for pulse dialing?
>
> >     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 purpose of these phones was actually the opposite. It allowed a
> "modern" keypad-equipped phone to function on older lines not equipped
> with a Touch-Tone receiver. In GTE territory with Strowger switching,
> the digits from DTMF phones were buffered in the CO and outpulsed as
> rotary dialing. Bang out the number with Touch-Tone and you could hear
> the tick-tick of the digits being sent while you waited.
>
> These days people get upset with post-dial delay of more than a couple
> of seconds. It used to be substantially more, especially with
> interoffice calls.
>
> >     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.
>
> TTBOMK, every common BORSCHT chip accepts both.
>
> >     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!
>
> Yes, because TTBOMK, telco central offices have always accepted pulse
> dialing and still do. SIP ATAs, on the other hand, mostly don't, with
> the exception of some older Grandstream units.
>
> --
> Jay Hennigan - jay@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

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

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

Owen DeLong wrote:

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

True, yet there's a missing piece to that description: ROI.
In the regulated environment with a mandated X% Return On Invest-
ment (X ? 15 IIRC) a bigger expense pie was a better pie because
a bigger expense pie meant a bigger return. This was an inexorable
force that influenced every substantive decision. An expanding
rate base was the One True Path to advancing against the demon
competitors: AT&T and other RBOCs.

In the Bell System setting, before and after Divestiture, a
perpetual and costly migration from IPv4 to IPv6 with all the
attendant cost burdens would have been well tolerated, even
welcomed, in the "C Suite" anyways.

--
Charles Polisher

> On Jan 19, 2024, at 09:21, Charles Polisher <chas@chasmo.org> wrote:
>
> Owen DeLong wrote:
>
> > 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.
>
> True, yet there's a missing piece to that description: ROI.
> In the regulated environment with a mandated X% Return On Invest-
> ment (X ? 15 IIRC) a bigger expense pie was a better pie because
> a bigger expense pie meant a bigger return. This was an inexorable
> force that influenced every substantive decision. An expanding
> rate base was the One True Path to advancing against the demon
> competitors: AT&T and other RBOCs.

You’re missing the fact that this particular set of events predates the formation of RBOCS or competitors in general. There was AT&T, there was GTE, and there were a handful of other ILECs sprinkled around the country, but each had 100% territorial exclusivity and monopoly and AT&T at the time was pretty much the only LD carrier, period.

> In the Bell System setting, before and after Divestiture, a
> perpetual and costly migration from IPv4 to IPv6 with all the
> attendant cost burdens would have been well tolerated, even
> welcomed, in the "C Suite" anyways.

Absolutely, I’m actually surprised that the DTMF forced conversion and its attendant cost wasn’t foisted on the unsuspecting public, TBH. I really don’t understand how AT&T missed that opportunity. Sure, it would have lowered costs long term to a small extent, but the handset replacement process alone would have been a huge cost for several years.

Let’s face it, those old AT&T phones were rock solid and in a pinch you could use one as a forging hammer. ;-)

Owen