Re: the ipv4 vs ipv6 growth debate

[Jorge Amodio]

Well hard for them to establish an ipv6 connection, none of the domains for
the urls I posted have an  record :-)

-J


On Mon, Dec 5, 2022 at 1:02 PM Tom Beecher  wrote:

> But IPv6Foo , ast least as far as I could tell by quickly looking at the
> code, cannot tell you if an IPv6 connection WOULD have worked, but IPv4 is
> where it ended up.
>
> With Happy Eyeballs, if the IPv4 TCP session finishes up only a couple ms
> faster than the IPv6 ones, the v4 one wins out. That doesn't give you any
> meaningful signal as to WHY it landed on IPv4 instead.
>
> On Mon, Dec 5, 2022 at 12:32 PM Jorge Amodio  wrote:
>
>>
>> With IPv6Foo you can click on the icon and it will show you a table
>> listing what URLs are serving some piece of a given page with v6 and v4.
>>
>> LinkedIn for example shows the main feed page served via v6 but there are
>> a couple of pieces with v4 from these sites
>>
>> - dpm.demdex.net
>> - lnkd.demdex.net
>> - p.adsymptotic.com
>> - radar.cedexis.com
>> - sb.scorecardresearch.com
>> - trkn.us
>>
>> Some may be feeding ads content, others tracking, market research, etc.
>>
>> Regards
>> Jorge
>>
>> On Mon, Dec 5, 2022 at 11:09 AM Tom Beecher  wrote:
>>
>>> Often lost in the 'debate' about V6 adoption is that for a 100% native
>>> IPv6 experience to work, there are multiple other components that have
>>> nothing to do with the network that ALSO have to work correctly. Any issues
>>> with these are likely going to cause fallback to v4.
>>>
>>> It's very difficult to know how much v4 traffic to a website COULD have
>>> worked just fine on v6, but didn't, and why it didn't.
>>>
>>> On Sat, Dec 3, 2022 at 7:16 PM Matt Corallo  wrote:
>>>
 It would be nice if IPvFoo showed the bytes and connection/request
 count. It's going to be a
 loonnggg time before we can do consumer internet browsing with no v4,
 until then it's about reducing
 cost of CGNAT with reduced packets/connections.

 For twitter, the main site is v4, yea, but abs.twimg.net (Edgecast)
 and pbs.twimg.net (Fastly) make
 up the vast majority of the bytes fetched on the site for me and are
 both v6 now. I don't recall
 when I last checked but they were still v4-only not too long ago.

 The other end of it is v6-only servers that don't accept inbound
 connections. Thos have been
 hampered IME by github not serving git over v6. Supposedly it's coming
 soon but so much modern
 software fetches stuff from Github that that's a major blocker.

 Matt

 On 11/27/22 7:44 PM, Jorge Amodio wrote:
 >
 > I use the same extension on Chrome.
 >
 > I'm surprised that with all the recent hoopla about it, from the
 major social media platforms,
 > Twitter still shows serving their http site over IPv4, Facebook and
 LinkedIn show solid IPv6.
 >
 > -J
 >
 >
 > On Sun, Nov 27, 2022 at 9:29 PM Dave Taht >>> > wrote:
 >
 > I use a web plugin tool called ipvfoo to track my actual ipv4 vis
 ipv6
 > usage. I wish it worked over time. With very few exceptions I am
 still
 > regularly calling ipv4 addresses in most webpages. Has anyone
 done a
 > more organized study of say, the top 1 million, and how many still
 > require at least some ipv4 to exist, and those trends over time?
 >
 > --
 > This song goes out to all the folk that thought Stadia would work:
 >
 https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
 > <
 https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
 >
 > Dave Täht CEO, TekLibre, LLC
 >

>>>

Re: the ipv4 vs ipv6 growth debate

[Tom Beecher]

But IPv6Foo , ast least as far as I could tell by quickly looking at the
code, cannot tell you if an IPv6 connection WOULD have worked, but IPv4 is
where it ended up.

With Happy Eyeballs, if the IPv4 TCP session finishes up only a couple ms
faster than the IPv6 ones, the v4 one wins out. That doesn't give you any
meaningful signal as to WHY it landed on IPv4 instead.

On Mon, Dec 5, 2022 at 12:32 PM Jorge Amodio  wrote:

>
> With IPv6Foo you can click on the icon and it will show you a table
> listing what URLs are serving some piece of a given page with v6 and v4.
>
> LinkedIn for example shows the main feed page served via v6 but there are
> a couple of pieces with v4 from these sites
>
> - dpm.demdex.net
> - lnkd.demdex.net
> - p.adsymptotic.com
> - radar.cedexis.com
> - sb.scorecardresearch.com
> - trkn.us
>
> Some may be feeding ads content, others tracking, market research, etc.
>
> Regards
> Jorge
>
> On Mon, Dec 5, 2022 at 11:09 AM Tom Beecher  wrote:
>
>> Often lost in the 'debate' about V6 adoption is that for a 100% native
>> IPv6 experience to work, there are multiple other components that have
>> nothing to do with the network that ALSO have to work correctly. Any issues
>> with these are likely going to cause fallback to v4.
>>
>> It's very difficult to know how much v4 traffic to a website COULD have
>> worked just fine on v6, but didn't, and why it didn't.
>>
>> On Sat, Dec 3, 2022 at 7:16 PM Matt Corallo  wrote:
>>
>>> It would be nice if IPvFoo showed the bytes and connection/request
>>> count. It's going to be a
>>> loonnggg time before we can do consumer internet browsing with no v4,
>>> until then it's about reducing
>>> cost of CGNAT with reduced packets/connections.
>>>
>>> For twitter, the main site is v4, yea, but abs.twimg.net (Edgecast) and
>>> pbs.twimg.net (Fastly) make
>>> up the vast majority of the bytes fetched on the site for me and are
>>> both v6 now. I don't recall
>>> when I last checked but they were still v4-only not too long ago.
>>>
>>> The other end of it is v6-only servers that don't accept inbound
>>> connections. Thos have been
>>> hampered IME by github not serving git over v6. Supposedly it's coming
>>> soon but so much modern
>>> software fetches stuff from Github that that's a major blocker.
>>>
>>> Matt
>>>
>>> On 11/27/22 7:44 PM, Jorge Amodio wrote:
>>> >
>>> > I use the same extension on Chrome.
>>> >
>>> > I'm surprised that with all the recent hoopla about it, from the major
>>> social media platforms,
>>> > Twitter still shows serving their http site over IPv4, Facebook and
>>> LinkedIn show solid IPv6.
>>> >
>>> > -J
>>> >
>>> >
>>> > On Sun, Nov 27, 2022 at 9:29 PM Dave Taht >> > wrote:
>>> >
>>> > I use a web plugin tool called ipvfoo to track my actual ipv4 vis
>>> ipv6
>>> > usage. I wish it worked over time. With very few exceptions I am
>>> still
>>> > regularly calling ipv4 addresses in most webpages. Has anyone done
>>> a
>>> > more organized study of say, the top 1 million, and how many still
>>> > require at least some ipv4 to exist, and those trends over time?
>>> >
>>> > --
>>> > This song goes out to all the folk that thought Stadia would work:
>>> >
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
>>> > <
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
>>> >
>>> > Dave Täht CEO, TekLibre, LLC
>>> >
>>>
>>

Re: the ipv4 vs ipv6 growth debate

[Jorge Amodio]

With IPv6Foo you can click on the icon and it will show you a table listing
what URLs are serving some piece of a given page with v6 and v4.

LinkedIn for example shows the main feed page served via v6 but there are a
couple of pieces with v4 from these sites

- dpm.demdex.net
- lnkd.demdex.net
- p.adsymptotic.com
- radar.cedexis.com
- sb.scorecardresearch.com
- trkn.us

Some may be feeding ads content, others tracking, market research, etc.

Regards
Jorge

On Mon, Dec 5, 2022 at 11:09 AM Tom Beecher  wrote:

> Often lost in the 'debate' about V6 adoption is that for a 100% native
> IPv6 experience to work, there are multiple other components that have
> nothing to do with the network that ALSO have to work correctly. Any issues
> with these are likely going to cause fallback to v4.
>
> It's very difficult to know how much v4 traffic to a website COULD have
> worked just fine on v6, but didn't, and why it didn't.
>
> On Sat, Dec 3, 2022 at 7:16 PM Matt Corallo  wrote:
>
>> It would be nice if IPvFoo showed the bytes and connection/request count.
>> It's going to be a
>> loonnggg time before we can do consumer internet browsing with no v4,
>> until then it's about reducing
>> cost of CGNAT with reduced packets/connections.
>>
>> For twitter, the main site is v4, yea, but abs.twimg.net (Edgecast) and
>> pbs.twimg.net (Fastly) make
>> up the vast majority of the bytes fetched on the site for me and are both
>> v6 now. I don't recall
>> when I last checked but they were still v4-only not too long ago.
>>
>> The other end of it is v6-only servers that don't accept inbound
>> connections. Thos have been
>> hampered IME by github not serving git over v6. Supposedly it's coming
>> soon but so much modern
>> software fetches stuff from Github that that's a major blocker.
>>
>> Matt
>>
>> On 11/27/22 7:44 PM, Jorge Amodio wrote:
>> >
>> > I use the same extension on Chrome.
>> >
>> > I'm surprised that with all the recent hoopla about it, from the major
>> social media platforms,
>> > Twitter still shows serving their http site over IPv4, Facebook and
>> LinkedIn show solid IPv6.
>> >
>> > -J
>> >
>> >
>> > On Sun, Nov 27, 2022 at 9:29 PM Dave Taht > dave.t...@gmail.com>> wrote:
>> >
>> > I use a web plugin tool called ipvfoo to track my actual ipv4 vis
>> ipv6
>> > usage. I wish it worked over time. With very few exceptions I am
>> still
>> > regularly calling ipv4 addresses in most webpages. Has anyone done a
>> > more organized study of say, the top 1 million, and how many still
>> > require at least some ipv4 to exist, and those trends over time?
>> >
>> > --
>> > This song goes out to all the folk that thought Stadia would work:
>> >
>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
>> > <
>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
>> >
>> > Dave Täht CEO, TekLibre, LLC
>> >
>>
>

Re: the ipv4 vs ipv6 growth debate

[Tom Beecher]

Often lost in the 'debate' about V6 adoption is that for a 100% native IPv6
experience to work, there are multiple other components that have nothing
to do with the network that ALSO have to work correctly. Any issues with
these are likely going to cause fallback to v4.

It's very difficult to know how much v4 traffic to a website COULD have
worked just fine on v6, but didn't, and why it didn't.

On Sat, Dec 3, 2022 at 7:16 PM Matt Corallo  wrote:

> It would be nice if IPvFoo showed the bytes and connection/request count.
> It's going to be a
> loonnggg time before we can do consumer internet browsing with no v4,
> until then it's about reducing
> cost of CGNAT with reduced packets/connections.
>
> For twitter, the main site is v4, yea, but abs.twimg.net (Edgecast) and
> pbs.twimg.net (Fastly) make
> up the vast majority of the bytes fetched on the site for me and are both
> v6 now. I don't recall
> when I last checked but they were still v4-only not too long ago.
>
> The other end of it is v6-only servers that don't accept inbound
> connections. Thos have been
> hampered IME by github not serving git over v6. Supposedly it's coming
> soon but so much modern
> software fetches stuff from Github that that's a major blocker.
>
> Matt
>
> On 11/27/22 7:44 PM, Jorge Amodio wrote:
> >
> > I use the same extension on Chrome.
> >
> > I'm surprised that with all the recent hoopla about it, from the major
> social media platforms,
> > Twitter still shows serving their http site over IPv4, Facebook and
> LinkedIn show solid IPv6.
> >
> > -J
> >
> >
> > On Sun, Nov 27, 2022 at 9:29 PM Dave Taht  dave.t...@gmail.com>> wrote:
> >
> > I use a web plugin tool called ipvfoo to track my actual ipv4 vis
> ipv6
> > usage. I wish it worked over time. With very few exceptions I am
> still
> > regularly calling ipv4 addresses in most webpages. Has anyone done a
> > more organized study of say, the top 1 million, and how many still
> > require at least some ipv4 to exist, and those trends over time?
> >
> > --
> > This song goes out to all the folk that thought Stadia would work:
> >
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
> > <
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
> >
> > Dave Täht CEO, TekLibre, LLC
> >
>

Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Tom Beecher]

Nothing you have said has changed my thoughts or opinions on this proposal.
It still has many direct technical deficiencies , not to mention continuing
to rely on a status change of 240/4, of which there is no forward movement
on actually happening.

I no longer have interest in continuing the conversation because you have
generally replied with hand waved 'solutions' to issues pointed out by many
people who know what they are talking about, and there's no reason to think
that will change.

So again, best of luck to you with this endeavor.

On Fri, Dec 2, 2022 at 10:36 PM Abraham Y. Chen  wrote:

> Dear Mr. Beecher:
>
> 0) Thanks for your reply to close the loop.
>
> 1)" I don't have any interest in continuing this discussion on this
> topic.":I am quite surprised by your nearly 180 degree turn of your
> position from your last MSG. The only thing that I could think of is
> that my last MSG provided the missing information that made the
> difference. I would appreciate very much if you could confirm.
>
> Regards,
>
>
> Abe (2022-12-02 22:35 EST)
>
>
>
> On 2022-12-01 16:34, Tom Beecher wrote:
> > Mr. Chen-
> >
> > I don't have any interest in continuing this discussion on this topic.
> > Best of luck to you.
> >
> > On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen 
> wrote:
> >
> > Dear Tom:
> >
> > Have not heard from you since the below MSG. Could you please let me
> > know if you have seen it, so that we can carry on by avoiding the
> > repeated open-loop situation with this thread?
> >
> > Regards,
> >
> >
> > Abe (2022-12-01 07:44 EST)
> >
> >
> > On 2022-11-22 23:23, Abraham Y. Chen wrote:
> > > Dear Tom:  Please disregard an earlier partial transmission of
> > > this MSG, caused by operator error. ***
> > >
> > > 1) One look at the NANOG archive that you retrieved tells me
> > that we
> > > are the victims of the idiosyncrasies of the eMail system. Unlike
> > > snail mails that are slow but reliable (There was a story that USPS
> > > found a forty years old letter stuck in one of the mail collection
> > > boxes on Boston sidewalk and then delivered it.), eMails are fast
> > > (Once my eMail monitoring account started to receive a long message
> > > that I was sending out, even before it was fully sent.) but
> > > unpredictable from time to time. Unfortunately, most of us are
> > > conditioned with its daily behavior and do not suspect the
> > electronic
> > > system hiccups (As Andrew Grove once said, "It is the software, not
> > > the hardware."). To deal with this kind of issues in none-real-time
> > > communications, I practice a discipline, started from VM and
> > FAX, that
> > > I will do my best to respond within 24 hours. I encourage my
> > > colleagues to start reminding me (either repeat the MSG or using
> > > alternative channels, such as SkyPe - My handle is
> > "Abraham.Y.Chen"),
> > > if they do not hear from me after 48 hours on topics that they
> > expect
> > > my response. This convention prevented much of the disruptions.
> > > Looking at your comments, I definitely would have responded back
> > then
> > > if I saw them. One possibility is that I was in the midst of being
> > > overwhelmed by NANOG posting protocols, such as the digest mode,
> > > uni-code, personal writing styles, etc. and miseed your MSG.
> > Anyway,
> > > allow me to try carrying on.
> > >
> > > 2)   "...Your proposal appears to rely on a specific value in
> > the IP
> > > option header to create your overlay": Not really, as soon
> > as the
> > > 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
> > > serve a very large area (such as Tokyo Metro and such) that becomes
> > > the RAN in EzIP terminology. Since each RAN is tethered from the
> > > existing Internet core by an umbilical cord operating on one IPv4
> > > public address, this is like a kite floating in the sky which is
> > the
> > > basic building block for the overlaying EzIP Sub-Internet when they
> > > expand wide enough to begin covering significant areas of the
> > world.
> > > Note that throughout this entire process, the Option Word
> > mechanism in
> > > the IP header does not need be used at all. (It turns out that
> > > utilizing the CG-NAT configuration as the EzIP deployment
> > vehicle, the
> > > only time that the Option Word may be used is when subscribers
> > in two
> > > separate RANs wishing to have end-to-end communication, such as
> > direct
> > > private eMail exchanges.)
> > >
> > > 3) " ... to drop any packet with an IP option set that you don't
> > > explicitly want because a significant number of routers kick every
> > > packet with options to CPU, ... ": Yes, this was what we were
> > reminded
> > > of when we started our