On 24Mar22, Pascal Thubert (pthubert) allegedly wrote:
> Hello Mark:
>
> > Any such "transition plan" whether "working" or "straightforward" is
> > logically impossible. Why anyone thinks such a mythical plan might yet be
> > formulated some 20+ years after deploying any of ipv6, ipv4++ or
On 24Mar22, Vasilenko Eduard allegedly wrote:
> Hence, the primary blocking entity for IPv6 adoption is Google: they do not
> support DHCPv6 for the most popular OS.
No. The primary "blocking entity" is that "legacy" ipv4 works just fine and
adopting ipv6
or ipv4++ or ipv6-lite or ipv-magical
On 24Mar22, Greg Skinner via NANOG allegedly wrote:
> straightforward transition plan
> in-hand working transition strategy
> nor a straightforward transition
Any such "transition plan" whether "working" or "straightforward" is logically
impossible. Why anyone thinks such a mythical plan might
On 23Mar22, Owen DeLong via NANOG allegedly wrote:
> I would not say that IPv6 has been and continues to be a failure
Even if one might ask that question, what are the realistic alternatives?
1. Drop ipv6 and replace it with ipv4++ or ipv6-lite or whatever other protocol
that
magically
On 19Mar22, Matt Hoppes allegedly wrote:
> So, while it's true that a 192.168.0.1 computer couldn't connect to a
> 43.23.0.0.12.168.0.1 computer, without a software patch - that patch
> would be very simple and quick to deploy
Let's call this ipv4++
Question: How does 192.168.0.1 learn about
On 09Feb22, Joe Greco allegedly wrote:
> I dunno. I think I'd find that being unable to resolve a hostname or
> being unable to exchange packets result in a similar level of Internet
> brokenness.
Sure. The result is the same, but as a discriminator for diagnosing the problem
it's quite
On 09Feb22, Joe Greco allegedly wrote:
> So what people really want is to be able to "ping internet" and so far
> the easiest thing people have been able to find is "ping 8.8.8.8" or
> some other easily remembered thing.
Yes, I think "ping internet" is the most accurate description thus far. Or
On 08Feb22, Mike Hammett allegedly wrote:
> Some people need a clue by four and I'm looking to build my collection of
> them.
> "Google services, including Google Public DNS, are not designed as ICMP
> network testing services"
Hard to disagree with "their network, their rules", but we're
On 03Jan21, Brandon Martin allegedly wrote:
> I was thinking more in the original context of this thread w.r.t.
> potential distribution of emergency alerts. That could, if
> semi-centralized, easily result in 100s of million connections to juggle
> across a single service just for the USA.
On 03Jan21, Brandon Martin allegedly wrote:
> On 1/3/21 3:11 PM, Jay R. Ashworth wrote:
> > Well, TCP means that the servers have to expect to have 100k's of open
> > connections; I remember that used to be a problem.
>
> Out of curiosity, has anyone investigated if it's possible to hold open
>
On 13May20, Denys Fedoryshchenko allegedly wrote:
> What about introducing some cache offloading, like CDN doing? (Google,
> Facebook, Netflix, Akamai, etc)
> Maybe some opensource communities can help as well
Surely someone has already thought thru the idea of a community CDN?
Perhaps along the
> We need to keep battery backup requirements, and expand them to all last
> mile IP bits. The need to call 911 has not gone away.
For sure. I was merely observing that the conversion of POTS to VOIP
in Australia didn't create a nation-wide disaster as the
pearl-clutchers once predicted.
In
> wasnt there a hige shit stom in australia for their new national
> broadband network making internet ptrimary and phone secondary, a lot
> of aussies on forums I frequent bitch about its reliability, where
> even their aged copper services worked fine, not to mention prolonged
> outages due to
> Have there been any fundamental change in their network architecture
> that might explain pulling these caches?
Maybe not network architecture, but what if the cache-to-content ratio
is dropping dramatically due to changes in consumer behavior and/or a
huge increase in the underlying content
> What I've seen happen more often than that:
>
> Server goes partly belly-up, queue fills up. Backup process runs, backing up
> the
> queue. (Optionally here: Reboot the server and lose the queue). Much later,
> the
> server hits another issue that requires recovering from backups - and they
> Yep I see this on AT's post paid network with my Pixel 3A XL as well, one
> place I really noticed it causing issues is with Facebook and Instagram
> where Facebook requires constant captions to view any Facebook links I
> receive and embedded Instagram content in news articles and things of
16 matches
Mail list logo
