Re: Saying goodnight to my GSR

[Daniel Sterling]

On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie baconzom...@gmail.com wrote:

 So when was the last time you patched this internet facing device?

Isn't the better response, thank you for decommissioning it?

Can someone from cisco set up a poll or release whatever numbers they
have about how many of these old devices are still in service?

Thanks,
Dan

Re: Saying goodnight to my GSR

[Daniel Sterling]

Again, you're focusing resentment towards someone who did the right
thing. Negative reinforcement will discourage others from taking
action and will discourage them from encouraging others to take
action.

Let's focus on who still has vulnerable equipment and how to help
them. Let's not shame people who did the right thing

Thanks,
Dan


On Sat, Sep 20, 2014 at 1:59 PM, Bacon Zombie baconzom...@gmail.com wrote:
 OK thank you for decommissioning this.*

 * Only if you either had authority to do so for max 1 year or had no
 authority but were fighting to have it patches or replaced for years.
 On Sep 20, 2014 7:54 PM, Daniel Sterling sterling.dan...@gmail.com
 wrote:

 On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie baconzom...@gmail.com
 wrote:

  So when was the last time you patched this internet facing device?

 Isn't the better response, thank you for decommissioning it?

 Can someone from cisco set up a poll or release whatever numbers they
 have about how many of these old devices are still in service?

 Thanks,
 Dan

Re: IP => Location on the planet

[Daniel Sterling]

Turn on all the google tracking bugs on the phone and get a GPS fix outside.

http://android.stackexchange.com/questions/4715/how-may-i-submit-a-wifi-hotspot-to-androids-database-for-a-better-triangulation/4716#4716

On Fri, Oct 30, 2015 at 4:14 PM, Alan Clegg  wrote:

> On 10/30/15 3:31 PM, Laurence F. Sheldon, Jr. wrote:
> > No follow up required or expected.
> >
> > FYI geo-location fans.
> >
> > While sitting on a toilet in a hotel in Kansas City, Missouri, US of A,
> > I chanced to log-on to Facebook from my Kindle, and the lap-top in the
> > on the desk in another room, Facebook alerted that I had logged on from
> > Caracas, Venezuela.  I have not checked--we might be in the same
> time-zone.
>
> That's OK.  I purchased a WAP from someone in Virginia and now I can't
> get the Google App on my phone to admit that I'm still at home and not
> in Broad Run.
>
> If anyone has any idea how to "unglue" a MAC address from an incorrect
> location in the guts of Google (I've done the skyhook thing
> http://www.skyhookwireless.com/submit-access-point), please let me know
> (this is an invitation for a followup).
>
> AlanC
> --
> When I do still catch the odd glimpse, it's peripheral; mere fragments
> of mad-doctor chrome, confining themselves to the corner of the eye.
>
>

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Mon, Mar 2, 2020 at 4:29 PM Daniel Sterling
 wrote:
> Also: I think ipv6 isn't working for me cuz it's being dropped by a switch 
> I'm using!
>
> I will swap that out / remove that and try ipv6 again

OK, ipv6 is working for me now.

The switch that was dropping ipv6 traffic was: Windows 10 (1909)
hyper-v switch! I was running Windows -> hyper-v -> openwrt, since
openwrt's kernel didn't have support for a USB NIC I'm using. I know,
this is ridiculous.

I switched to ubuntu 19.10 -> kvm -> openwrt, and ipv6 works out of the box.

Next step may be to see if I can get ipv6 working with just plain
ubuntu (and to stop using USB NICs)

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

No voice service on my line, or TV. Just gigabit internet.

Also: I think ipv6 isn't working for me cuz it's being dropped by a switch
I'm using!

I will swap that out / remove that and try ipv6 again

-- Dan

On Thu, Feb 27, 2020, 9:10 AM Hiers, David  wrote:

> We find that they usually impose pretty harsh QOS on a link that has an
> ATT voice service.
>
> David
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jay Hennigan
> Sent: Thursday, February 20, 2020 12:13 AM
> To: nanog@nanog.org
> Subject: Re: QUIC traffic throttled on AT residential
>
> On 2/18/20 18:40, nanog-l...@contactdaniel.net wrote:
>
> > Growing prevalence of IPv6-only
> > sites is probably the only thing that will get a lot of access
> > networks to support v6.
>
> I recall a similar idea called "The Great IPv6 Experiment" back in 2007.
> ;-)
>
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
> --
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Tue, Feb 18, 2020 at 7:20 PM Dan Wing  wrote:
> For all we know, you and the others noticing the issue have fallen into the 
> pit of A/B testers checking for their current throttling, and others aren't 
> being throttled.

Ouch, I hope not -- do A/B tests that result in extreme performance
degradation continue indefinitely ?

> Youtube/Google is hoping customers complain to AT

It seems like this is one area where AT has no reason to care
(unless management decides to get involved). The default stance from
support would be, I assume: "Google is slow for you? Well obviously it
can't be Google's fault. Have a new NAT box"

I would bet dollars to donuts that if Google took a proper look at
their stats they would see this issue manifesting as users simply not
using services that have been QUIC-holed.

-- Dan

QUIC traffic throttled on AT residential

[Daniel Sterling]

I've AT fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic
from google (esp. youtube) becomes very slow after a time.

This especially occurs with ipv4 connections. I'm not the only one to
notice; a web search for e.g. "Extremely Poor Youtube TV Performance"
notes the issue.

I assume traffic is being throttled on AT's side. And it's not done
with their CPE; I'm bypassing their NAT box and connecting my laptop
directly to the ONT.

A quick google search shows people are aware that QUIC can look like
DoS traffic -- but how widely known is this problem? It may become
worse if / when sites transition to HTTP/3

For now I reject UDP 443 on the client firewall. Applications using
QUIC client libraries then fallback to TCP. This works well and I have
no issues with latency or throughput when using TCP.

May I naively ask if Google staff are working with AT to address this?

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

9On Tue, Feb 18, 2020 at 7:07 PM Ross Tajvar  wrote:
>
> Are you suggesting that ATT block all QUIC across their network?

One might argue they already *are* doing so; QUIC is essentially
unusable on my AT ipv4 residential connection (and a web search
suggests I'm not alone).

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Wed, Feb 19, 2020 at 12:51 AM Damian Menscher  wrote:
> [snip impressive debugging story]

lol fair. I didn't umm mean to just brag -- my point was that:
generally available SoHo internet is worse than mobile networks esp.
for UDP traffic!

> Rather than hobble your home network to work around a misbehaving ISP, have 
> you considered simply getting a new ISP?

I could get a leased line, sure, or route all my traffic through a
UDP/TCP VPN -- but the average user won't and can't, no.

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Tue, Feb 18, 2020 at 8:05 PM Michael Brown  wrote:
> Blocking a (for you) undesirable option when an established fallback
> exists is a much better end user experience than introducing breakage
> into that option

> Or: I no longer use my ISP's IPv6 access (via 6rd) since it would cause
> terrible slowdowns due to packet loss when it broke

All the +1s.


I have one goal for my home internet: it should work better than my cell phone!

In our house, "screen time" is "all the time". Everyone is on their
phone non-stop. So you'd think getting fiber, installing UBNT APs and
swapping out AT's CPE for a Core i5 linux box would provide a better
internet experience than a tree-obstructed cell tower a mile or two
down the road.

But you'd be wrong.


Everyone in the house was, on a daily basis, turning off wifi in favor
of AT LTE!

Why was everyone switching off wifi? I couldn't blame them -- I was
toggling it on and off myself to get the occasional website or IM
conversation to load. Why was my network broken?? How was it possible
that a fairly high-latency mobile connection could provide a better
experience than 802.11ac to an AP in the same room backed by a gigabit
PON?


I banged against this for *years*. I punted on using my own router and
tried just AT's CPE (reset to factory defaults). That does work
decently, but there are some maddening quirks, not least of which is
insanely high jitter.

I tried SoHo devices running vendor stock firmware driving hardware
NAT. Those also work well -- until they inevitably crash.


I tried ddwrt and openwrt. I tried AQM; I tried QoS. I tried NUCs
running upstream kernels; downstream kernels; I tried custom patches.
I tried HFSC and CoDel; I compiled iproute2 so I could have some
tc_cake.


On the link-layer (wifi) side I tried one AP; two APs; three APs. I
tested any number of combinations of SSID name, channel frequency and
width. I tried with ipv6; no ipv6; I put all 2ghz devices on their own
AP; in desperation I even tried dedicating one AP and an entire 5ghz
frequency range for just one phone.

But nothing mattered until I finally figured it out:

It was DNS. Of course it was DNS. It's always DNS.


When DNS was solid and fast, everything else fell into place. Toggling
wifi worked because it was the same as re-querying DNS! And the DNS
service on mobile works well -- better than the average CPE.

*** I cannot stress this enough. No manner of tuning or tweaking to my
home network stopped users from fleeing it, until I had solid DNS. ***


For fast DNS, you of course need fast UDP. And, as we've empirically
discovered, well-behaved UDP is by no means guaranteed on residential
connections.

It turns out dnsmasq has a couple of tunables that can make a huge
difference to home internet DNS performance. First, you need to be
querying the DNS servers AT tells you to via DHCP. They're the least
likely to be throttled, unfortunately. But I've found even that alone
isn't enough.

You need to set dnsmasq's "query-port" option. By default it's random
to protect against CVE-2008-1447, but apparently sending a ton of
random-source-port UDP traffic does not impress the AT network flow
control systems, and your DNS traffic becomes unbearably slow (or is
simply dropped entirely).


AT gives you two DNS servers via DHCP. You can query more --
8.8.8.8, 4.2.2.2, 2606:4700:4700:: -- but if you do, you'll want
to enable dnsmasq's "all-servers" option. Packets are cheap -- send a
query to every server on your list and use whatever comes back first.
If you've angered the UDP flow restrictor, no matter -- with luck at
least one of your packets is going to a server that's up and not
throttled or overloaded!


Of course DNS is just the beginning -- you still need a proper gateway
device with a good NAT stack and/or firewall; you still need a strong
wifi signal; you still need tc_cake so everyone can watch Netflix at
the same time.

But DNS is the *core*. Nothing works well until DNS works well. That
means nothing works well unless UDP works well. And if I have learned
anything about AS7018, it's that UDP -- especially its v4 UDP -- Does.
Not. Work. Well.


Enter QUIC. It may be the perfect transport-layer protocol; but by
putting it on top of UDP it's hobbled. It breaks extant v4 internet in
a way that nothing else we've yet seen does -- it takes what would be
your TCP traffic and gives it inconsistent and intermittently poor
performance. Maybe it's sometimes fast. Maybe it is. But I can tell
you, it sometimes Is Very Much Not So.


As much as I would on principle rather not stick to a legacy, TCP-only
home network --

I can say that right now, my home internet, blocking UDP 443, and
making tons of insecure DNS queries -- is the most stable, fastest,
most usable and enjoyable home internet I've ever had. And my users
agree -- they no longer turn off wifi.


May I naively ask if Google staff have considered scrapping using UDP
and instead proposing a new, first-class transport protocol 

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Thu, Feb 20, 2020 at 2:11 PM Jared Mauch  wrote:
> As a network operator my goal was always to ensure customers receive
> the traffic they expected, high rates of UDP were often not what they wanted.

Well, I wouldn't say I *want* UDP traffic, but if everyone is bound
and determined to send it to me for web / video traffic unless I block
it, I suppose we should all work together to improve my (average v4
end-user) experience.

I set up a rolling tcpdump to capture QUIC / HTTP/3 traffic.

tcpdump -C 100 -w quic -W 100 -i eth1 'udp and port 443'

I can make this dump available for inspection if (when) I organically
experience the issue again.

Is there anything else I can do to help Google or AT improve things?
Any magic debugging I can turn on on the client side?

Feel free to ping me off list...

I don't particularly *want* to block or advocate blocking QUIC, but if
I keep hitting the issue and can't help people troubleshoot, what
other sane option have I?

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Wed, Feb 19, 2020 at 2:55 PM Blake Hudson  wrote:
> I'm guessing ATT doesn't disclose this policy transparently either.

they disclose it pretty transparently to their customers in the form
of very slow youtube traffic when using v4 QUIC ;)

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Wed, Feb 19, 2020 at 3:34 PM Blake Hudson  wrote:
> Yeah, that was a nice surprise to find that my tethered LTE connection
> was out performing my wired cable modem service. Of course, I had
> already signed up for a year of service and there were early termination
> fees for cancelling... that and there are no other wireline providers
> available at my home (not even ATT).

So we're left with some questions:

1. It's clear I'm not the only one experiencing this issue. How
widespread is this problem, really? Has it gotten rather worse over
the past ~year?

2. Are customers of larger ISPs much more impacted than customers of
smaller ones that (assumedly) don't have to deprioritize UDP so much?
2a. If users *are* impacted, as Blake notes, they may not be able to
switch ISPs to improve their lot.. will customers complain to their
ISP or to Google?

3. How much worse is the problem when using v4 UDP QUIC vs v6? If QUIC
only works on v6 (and if it in fact continues to actively BREAK
v4-only users), then is this v6's "killer app" that will drive
adoption?
3a. Or will this issue hinder HTTP/3 deployment (or cause mass
blocking of UDP on clients)?

4. Will ISPs be willing to give UDP traffic higher priority to improve
user experience? Will that only happen once HTTP/3 is widely deployed?

5. We can only assume Google is aware of this issue; will Google work
to improve QUIC fallback to TCP, or will they work with ISPs to get
QUIC (esp v4 QUIC) prioritized, or will they do nothing, or will they
actively encourage QUIC to break v4 at the expensive of current user
experience?
5a. Will another company that wants HTTP/3 to succeed take the mantle
and work with ISPs to improve the situation? I'm reminded of when
Microsoft worked with ISPs to ensure xbox UDP traffic would transit
properly

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Thu, Feb 20, 2020 at 2:57 PM Jared Mauch  wrote:
> if the question is will the browser vendor (google) or the broadband provider 
> (att)
> move first, i can already predict the answer.  my experience (again) with the 
> quic
> wg is they seem to think there's many options and bad providers will be 
> replaced
> which seems disconnected from reality.

Agreed. Since I'm in RTP, I *am* lucky enough to live in an area where
there are multiple ISPs.

But not everyone is, and local-loop unbundling is no longer a thing :(

The average user is at the mercy of their local ISP. So the major
providers should (but may not have much incentive to) provide decent
service.

As has been continually noted, this issue goes away if you use v4 TCP or v6 UDP.

And one may argue that most users *will* by default have v6 UDP
connectivity from their ISP -- to Google at least.

But HTTP/3 is coming -- and site operators may not realize deploying
HTTP/3 on v4 only will break connectivity for their users.

We're currently in a limbo where v4, which had been working fine, has
been *broken* -- and not everyone uses v6.

Site operators aren't used to deploying services that break when
served over ipv4. HTTP/3 will be the first widely-deployed service
that only properly works when served from v6.

So something is going to give:

* site operators will have to deploy v6 before they deploy HTTP/3, or

* network operators will have to make v4 UDP as reliable as v4 TCP (or
block HTTP/3)

If neither happens, then as more sites start pushing v4 UDP, more and
more users will start seeing issues, even if they *do* have v6 working
well at their house.

It may become common practice to block HTTP/3 on the client side to
improve connectivity to v4-only services.

Exciting times lay ahead, indeed

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Wed, Feb 19, 2020 at 8:27 PM Masataka Ohta
 wrote:
> A problem of QUIC with NAT is that existing NAT can not detect
> graceful shutdown of QUIC and must depends on timeout.
>
> So, port numbers may be used up before timeout.

Hmm, this is not what is happening.

I managed to (fairly easily!) reproduce the issue earlier tonight. I
generated a fair bit of UDP traffic via xbox, a corporate VPN, and
youtube over quic.

Sure enough, after about 45 minutes, the YouTube app on my iPad paused
and then auto-reset the stream quality to "144p" resolution.

I was able to set it back to 720p60, but that only lasted about 2
minutes before the stream stopped playing. I waited several minutes
for it to resume; it did not. So, I then blocked UDP 443 on my router.
The video then *immediately* resumed at 720p60.

I didn't run tcpdump but I did grab some screenshots of iftop. It
looks like my iPad connected to AS15169 with a single UDP connection.
I see one consistent source and dest IP / port combo for those 10s of
minutes, up until UDP is blocked. Local port 58053, remote port 443 on
the same IP for the whole time.

At first the connection averages around 2mbps; when the issue occurs,
I see it has dropped to a rate of under 200kbps.

I've no idea what to make of that. Surely Google isn't throttling
their traffic to me? If so why allow a fallback to TCP?

When I originally discovered this issue, I was of course not trying to
do anything odd with my internet connection. And I didn't immediately
know QUIC was the issue.

Only after it happened several times did I dig into the traffic and
then block QUIC, and I was shocked to see that both resolve the issue
and prevent its recurrence.

So again -- I hit this issue repeatedly without trying to --

And just now, I was able to reproduce it simply by generating a bit of
UDP traffic on purpose!

I only wish I were insane; but from where I'm sitting, QUIC has broken
my internet, and the resolution is blocking QUIC.

-- Dan

Re: QUIC traffic throttled on AT residential

[Daniel Sterling]

On Tue, Feb 18, 2020 at 11:47 PM Daniel Sterling
 wrote:
> random-source-port UDP traffic does not impress the AT network flow
> control systems, and your DNS traffic becomes unbearably slow (or is

I received a comment that maybe the issue is not AT's "core"
network, but rather to do with the NAT device in my house.

Oh, I wish this were the case!

Unfortunately, there is no NAT CPE from AT involved:

I've taken AT's RG CPE out completely. That device, which otherwise
would indeed be my gateway, is unused on my home network, completely
unpowered and unplugged.

Instead I've got a linux box hooked directly up to the ONT. This works
fine; occasionally I *do* have do reconnect their RG and let it
re-auth to the PON, but once the connection is live, I fully unplug
their RG again, and plug my laptop (spoofing its MAC) back in directly
to the ONT.

The laptop is running ubuntu 19.10, so there should be no artificial
limits. It's running NAT directly from the v4 IP I get from DHCP.


You may have noticed v4 is a theme here. I have nothing against using
v6 -- , I must admit the truth is I have no idea how to make ubuntu
acquire a v6 -- address? block ? I don't even know the right term --
from uverse.

I know v6 works cuz AT's device supports it, and openwrt does it out
of the box-- but heck if I know how it works. At the risk of asking
this list for tech support -- does anyone want to ping me off list and
point me in the right direction?? Maybe somebody from Google -- you
can make up for breaking my v4 internet!!

Thanks,
Dan

Re: Gaming Consoles and IPv4

[Daniel Sterling]

Matt Hoppes raises an interesting question,

At the risk of this being off-topic, in the latest call of duty games I've
played, their UDP-NAT-breaking algorithm seems to work rather well and
should function fine even behind CGNAT. Ironically turning on upnp makes
this *worse*, because when their algorithm probes to see what ports to use,
upnp sends all traffic from the "magical xbox port" to one box instead of
letting NAT control the ports. This does cause problems when multiple
xboxes are behind one NAT doing upnp. If upnp is on and both xboxes are
fully powered off and then turned on one at a time, things do work. But
when upnp is off everything works w/o having to do that.

There are many other games and many CPE NAT boxes that may do horrible
things, but CGNAT by itself shouldn't cause problems for any recent device
/ gaming system.

It is true that I've yet to see any FPS game use ipv6. I assume that's cuz
they can't count on users having v6, so they have to support v4, and it
wouldn't be worth their while to have their gaming host support dual-stack.
just a guess there

-- Dan



On Sun, Sep 27, 2020 at 7:29 PM Mike Hammett  wrote:

> Actually, uPNP is the only way to get two devices to work behind one
> public IP, at least with XBox 360s. I haven't kept up in that realm.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Matt Hoppes" 
> *To: *"Darin Steffl" 
> *Cc: *"North American Network Operators' Group" 
> *Sent: *Sunday, September 27, 2020 1:22:51 PM
> *Subject: *Re: Gaming Consoles and IPv4
>
> I understand that. But there’s a host of reasons why that night not work -
> two devices trying to use UPNP behind the same PAT device, an apartment
> complex or hotel WiFi system, etc.
>
> On Sep 27, 2020, at 2:17 PM, Darin Steffl  wrote:
>
> 
> This isn't rocket science.
>
> Give each customer their own ipv4 IP address and turn on upnp, then they
> will have open NAT to play their game and host.
>
> On Sun, Sep 27, 2020, 12:50 PM Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
>
>> I know the solution is always “IPv6”, but I’m curious if anyone here
>> knows why gaming consoles are so stupid when it comes to IPv4?
>>
>> We have VoIP and video systems that work fine through multiple layers of
>> PAT and NAT. Why do we still have gaming consoles, in 2020, that can’t find
>> their way through a PAT system with STUN or other methods?
>>
>> It seems like this should be a simple solution, why are we still opening
>> ports or having systems that don’t work?
>
>
>

Re: Gaming Consoles and IPv4

[Daniel Sterling]

On Wed, Sep 30, 2020 at 12:47 PM Owen DeLong  wrote:
> Games want to go peer-to-peer.

That was true up until about 2012.

As Martijn Schmidt noted, Activison contracts out to multiple managed
hosting companies to provide servers across the globe. If you launch
any recent call of duty game and hit "multiplayer"  , your system will
be looking for a managed server host to connect to.

>From 2013 and on, all the call of duty games are
managed-server-host-only for general multiplayer. You have to go well
out of your way to do P2P FPS gaming recently -- at least with CoD.
not sure about other games.

> The real question IMHO is why are game console companies so stupid about IPv6?

Just a guess, but I imagine since they can't count on users having v6,
their hosts have to support v4 and they don't bother making them
dual-stack.

Re: Gaming Consoles and IPv4

[Daniel Sterling]

On Wed, Sep 30, 2020 at 3:09 PM Vincent Bernat  wrote:
> Not sure about that. To avoid cheaters, multiplayer games are likely to
> be mediated by a server running the same game engine to manage state of
> each player.

Probably veering off topic for the list here, but yes -- the advantage
to playing on an xbox is Microsoft has Locked Down the system, so you
encounter essentially no cheaters if you're connected to Microsoft's
multiplayer service (xbox live) and using dedicated FPS hosts.

MS seems to have successfully locked down xbox enough so that no one
has figured out a way to get on xbox live with a "hacked" xbox (one
running non-MS code). or if they have, that's a big enough zero day
they're keeping it to themselves.

Having a locked down system that prevents cheaters is a big plus for
CoD, which otherwise is indeed rife with "hacked lobbies" and even PCs
running hacked clients that connect to and successfully mess up the
state of a managed dedicated Activision server.

Re: Gaming Consoles and IPv4

[Daniel Sterling]

On Wed, Sep 30, 2020 at 2:50 PM Josh Luthman
 wrote:
> Based on packet captures and customer experiences, that doesn't seem to be 
> the case.

Aye, you're right I'm sure. Thank you for the correction.

Where P2P does NOT come into play is:
1. on xbox
2. standard multiplayer
3. CoD games since at least 2013
4. in the US

That is, I haven't seen a non-dedicated-server host match in standard
multiplayer on xbox since CoD version 2013, and I've been looking.
That's just one datapoint from one user, but I haven't played on a
non-dedicated server since 2013 in xbox standard multiplayer.

P2P DOES come into play:
1. on PC
2. non-standard multiplayer (custom games) on any platform probably
3. maybe on xbox if you're not near any dedicated server. unsure on this

So yes it would seem to make sense for CoD to use ipv6 for those P2P
games. But then -- would they have to implement dual-stack for the
game on your PC? That seems even more complex than dual-stack on a
hosted server

-- Dan

understanding IPv6 (was: Re: QUIC traffic throttled on AT residential)

[Daniel Sterling]

On Wed, Feb 19, 2020 at 7:51 PM Mark Andrews  wrote:
> > I have nothing against using
> > v6 -- , I must admit the truth is I have no idea how to make ubuntu
> > acquire a v6 -- address? block ? I don't even know the right term --
> > from uverse.
>
> It should just be a DHCPv6 PREFIX DELEGATION (PD).  See RFC 8415.

Mark -- thank you so much for this information.

Knowing that I needed to understand something called "DHCP PD" was the
most valuable thing I've learned about ipv6 in the past decade.

At $WORK we don't use v6 at all. (Fortune 500 company; I can deploy v6
as much as I want on the segments I control, but the larger company
does nothing with it.) So while I know how to set up and use ipv4
pretty well, I knew essentially nothing about v6 other than what I'd
read on my own time.

Not knowing how my home ISP equipment even acquired a v6 address (must
less how it handed them out to my home LAN devices) was very
frustrating, and reading about v6 in general was not very enlightening
for me. So this nugget of info -- "DHCP PD" -- was a godsend. By
looking up information related to it I was able to dramatically
increase my understanding of v6.

So again, thank you!

-- Dan

Re: understanding IPv6 (was: Re: QUIC traffic throttled on AT residential)

[Daniel Sterling]

On Sun, Jun 7, 2020 at 2:00 AM Fred Baker  wrote:
> I'm sorry you have chosen to ignore documents like RFC 3315, which is where 
> DHCP PD was first described (in 2003). It's not like anyone's hiding it.

I am sorry as well!

I openly admit I am not the smartest bear in the woods. I struggle to
read through RFCs. Researching IPv6 for me means doing a web search
for "what ipv6 halp", to which google frustratingly returns: No
results found for "what ipv6 halp".

In all seriousness, I have been trying to understand IPv6 for a long
time, and the documentation that I read (again, admittedly not often
RFCs, but certainly Wikipedia, linux distro docs, etc) never mentioned
DHCP PD, or at least never mentioned it as something important for how
end-users would use IPv6.

So while it may be true that no one is hiding this information, in my
experience no one is shining a spot light on it either, and until I
was told about it, I was simply unable to understand IPv6.

Once we know something we can forget that everyone else doesn't know
that same information, and figuring out what inexperienced people need
to know to understand a topic can be difficult. So I am offering to
the community that "DHCP PD" is such a thing: it's something that
everyone who already knows how things works takes for granted.

So when someone points me in the right direction by mentioning such an
important piece of the puzzle, I am genuinely grateful!

-- Dan

Re: understanding IPv6

[Daniel Sterling]

On Sun, Jun 7, 2020 at 7:17 AM Bjørn Mork  wrote:
> Sorry, but I have some problems understanding this. AFAICT, you can't
> read anything about configuring IPv6 access without seeing DHCPv6-PD
> mentioned.

The point isn't that I couldn't read about DHCP PD; the point is that
I didn't know that I needed to understand DHCP PD to also understand
how IPv6 is widely deployed, until someone who did know very kindly
pointed me in the right direction.

>   * Automatic bootstrap from SLAAC, stateless DHCPv6, stateful DHCPv6,
> DHCPv6-PD and any combination

I was overwhelmed with this information. Remember, I'm trying to learn
about IPv6 because I *want* to know more; I don't want to be ignorant.
I really, really am honestly trying, and I'm telling you it was hard.
If I'm *looking* to learn and still can't figure it out, what does
that say about all the people who don't care as much?

-- Dan

Re: Disney+ Geolocation (again)

[Daniel Sterling]

On Fri, Nov 20, 2020 at 6:55 PM Josh Luthman 
wrote:

> OK so an email address that isn't supposed to be used but works or a phone
> call that should be used and is pointless for the purposes of this issue?
>

Are you just asking to confirm this is disney’s position?  it appears
so!

As an outsider who lurks and normally sees these issues resolved swiftly
off list I find this all fascinating and hilarious.

Who is a manager or high level engineer in charge at Disney streaming? I
would like to make fun of them

— Dan

>

hulu IP issue

[Daniel Sterling]

I changed my hulu passwd and got this email from hulu (see below).

It notes what IP I used to change the passwd, but it's an internal IP!
Probably not as intended :)


email:

You've Changed Your Password
Hi Daniel,

As requested, your password has been changed. From now on, you'll use
this new password to log in to Hulu.

The password was changed from the IP address 10.35.33.117.

Re: jon postel

[Daniel Sterling]

One of the best things about this list is first hand accounts of our
internet lore

Does anyone have any stories about working with or near John they would
like to share with the list? It would definitely make my day to hear more
about the early internet

Thanks,
Dan

On Sun, Oct 16, 2022, 8:01 PM Nathan Angelacos  wrote:

>
> >
> > Early unix had a similar philosophical debate. Everything is a simple
> > file (including most devices), make commands which do one thing and
> > do it well so they can be connected together in new ways (an almost
> > prescient view on the ubiquity of multi-cpu/core systems), when in
> > doubt generalize and let the user specialize for their needs, don't
> > try to guess everything your program will be used for.
>
>
>
> Oh. you mean SaaS?  or WebSockets?  or REST? or :)
>
> I remember an old guy I worked with.   We were decommissioning our
> Prime for this new thing called "Novell 286"
>
> He said "The computer industry is like the car industry in the 50's.
> We add more grille, more fenders, more wings.   But it is still a car."
>
>

intuit DNS

[Daniel Sterling]

Someone at Intuit please look into why your DNS for this A record
hasn't been consistently resolving, this has been going on for several
days if not weeks

https://dnschecker.org/#A/smartlinks.intuit.com

-- Dan