How often does my home's IP address change?

Bruce Ediger

2025-05-30 (Last Modified: 2025-06-02)

Matt Sayar investigated how often his home’s IP address changed. I did the same, inspired by him. Thanks, Matt!

Like Sayar, I have CenturyLink fiber optic networking. Unlike Sayar, I use a Linux computer to interface with CenturyLink’s network. CenturyLink fiber optic connections require the on-premises machine to do PPP over ethernet (PPPoE), and use a VLAN of 201. It’s complicated and leads to inscrutable problems.

From 2022-12-04 to 2025-05-30 I’ve had my Linux machine run a cron job at 16 minutes past the hour, every hour, to track my Linux machine’s IP address (CenturyLink can only manage an IPv4 address). I have over 21,500 data points of what IPv4 address gets assigned to my machine During the data collecting interval, CenturyLink has assigned 110 different addresses, all in 4 CIDRs


70.56.0.0/14	70.56.0.0 - 70.59.255.255	43
75.160.0.0/12	75.160.0.0 - 75.175.255.255	33
97.112.0.0/12	97.112.0.0 - 97.127.255.255	32
216.160.0.0/15	216.160.0.0 - 216.161.255.255	2

I have collected the address of the “peer” on the other side of the PPP connection for a shorter period of time. It has stayed the same from at least 2025-01-03 to 2025-05-31. It’s an IPv4 address in 207.224.0.0/15, which is not one of the dynamic address ranges. I confess I don’t understand PPP, so I don’t have any idea if this is significant in any way.

Intervals of the same address

graphical representation of intervals between new addresses

This kind of cool, kind of incomprehensible, plot shows when CenturyLink gave me new IPv4 addresses (horizontal axis) versus how long an address lasted (vertical axis). The date my computer got a new address is horizontally centered in the boxes.


Mean	719900
Median	619199
Minimum	3600
Maximum	5439599

There’s a few very long intervals that skew the mean long. The intervals cluster around 529200 seconds (147 hours, 6 days). That’s suspiciously close to how often I update and reboot the machine in question.

Relationship to booting

I have last information on reboots of the machine that does PPPoE and routing to CenturyLink’s network stretching from Thu Oct 26, 2023 to Sat May 31, 2025. I don’t know why that machine’s wtmp file starts at that date. According to /var/log/pacman.log, I installed Linux 2020-07-16. It is a Dell R530 that I purchased used from Ebay.

In any case, I have record of 63 reboots, two of which are labeled “crash”. I run Arch Linux (a simple, lightweight distribution) on that system, so I regularly run pacman -Syu by hand, and then systemctl reboot. You can see that behavioral pattern in last output:

reboot   system boot  6.14.6-hardened* Thu May 22 07:52   still running
bediger  pts/0        10.0.20.35       Thu May 22 07:46 - 07:49  (00:03)

My user ID’s login session ends at 07:49. Linux returns enough by 07:52, 3 minutes later, to leave a wtmp entry. A login session with my user ID ends before every system boot entry by 2 or 3 minutes. That’s almost certainly the length of time that my Linux routing machine does not communicate with its PPP “peer”.

last output conveniently includes day-of-week. My boot day-of-week distribution looks like this:


Mon	3
Tue	5
Wed	3
Thu	6
Fri	6
Sat	24
Sun	16

I think that firmly puts me in the “update on the weekend” camp.

This is what pppd logs look like for a boot-to-boot period:

-- Boot d5d8aed41b6e4d88a4d70e512c99206f --
Apr 19 17:49:13 dellr530 systemd[1]: Started PPP link to Centurylink.
Apr 19 17:49:14 dellr530 pppd[906]: Plugin /usr/lib/rp-pppoe/rp-pppoe.so loaded.
Apr 19 17:49:14 dellr530 pppd[906]: Plugin /usr/lib/rp-pppoe/rp-pppoe.so loaded.
Apr 19 17:49:14 dellr530 pppd[906]: RP-PPPoE plugin version 4.0 compiled against pppd 2.5.2
Apr 19 17:49:14 dellr530 pppd[906]: RP-PPPoE plugin version 4.0 compiled against pppd 2.5.2
Apr 19 17:49:14 dellr530 pppd[906]: pppd 2.5.2 started by root, uid 0
Apr 19 17:49:29 dellr530 pppd[906]: PPP session is 2364 (0x93c)
Apr 19 17:49:29 dellr530 pppd[906]: Connected to 78:fe:3d:3a:77:f2 via interface eno3.201
Apr 19 17:49:29 dellr530 pppd[906]: Using interface ppp0
Apr 19 17:49:29 dellr530 pppd[906]: Connect: ppp0 <--> eno3.201
Apr 19 17:49:29 dellr530 pppd[906]: CHAP authentication succeeded
Apr 19 17:49:29 dellr530 pppd[906]: CHAP authentication succeeded
Apr 19 17:49:29 dellr530 pppd[906]: peer from calling number 78:FE:3D:3A:77:F2 authorized
Apr 19 17:49:29 dellr530 pppd[906]: Cannot determine ethernet address for proxy ARP
Apr 19 17:49:29 dellr530 pppd[906]: local  IP address 70.56.0.0/14
Apr 19 17:49:29 dellr530 pppd[906]: remote IP address 207.224.0.0/15
May 10 18:44:53 dellr530 pppd[906]: Terminating on signal 15
May 10 18:44:53 dellr530 pppd[906]: Connect time 30295.4 minutes.
May 10 18:44:53 dellr530 pppd[906]: Sent 9246893030 bytes, received 64679409069 bytes.
May 10 18:44:53 dellr530 pppd[906]: Connection terminated.
May 10 18:44:53 dellr530 pppd[906]: Sent PADT
May 10 18:44:53 dellr530 systemd[1]: Stopping PPP link to Centurylink...
May 10 18:44:53 dellr530 pppd[906]: Exit.
May 10 18:44:53 dellr530 systemd[1]: mypppd.service: Main process exited, code=exited, status=5/NOTINSTALLED
May 10 18:44:53 dellr530 systemd[1]: mypppd.service: Failed with result 'exit-code'.
May 10 18:44:53 dellr530 systemd[1]: Stopped PPP link to Centurylink.
May 10 18:44:53 dellr530 systemd[1]: mypppd.service: Consumed 9.969s CPU time, 7.9M memory peak.
-- Boot 8ddf15becb1445b4900cc0664a7b014b --
May 10 18:47:12 dellr530 systemd[1]: Started PPP link to Centurylink.

PPP connection terminated at 18:44:53, new connection started at 18:47:12. That’s 2:19 where a PPP connection wasn’t established.

PPP daemon logging does indicate that IPv4 address changes with every boot.

Apr 19 09:10:24 dellr530 pppd[909]: local  IP address 97.118.a.b
Apr 19 17:49:29 dellr530 pppd[906]: local  IP address 70.59.c.d
May 10 18:47:27 dellr530 pppd[913]: local  IP address 97.118.e.f
May 16 03:36:42 dellr530 pppd[913]: local  IP address 97.118.g.i
May 16 04:53:54 dellr530 pppd[913]: local  IP address 97.118.h.j
May 22 07:52:18 dellr530 pppd[882]: local  IP address 97.118.k.l

The May 16 address changes at 3:36am and 4:53am (my machine’s timezone is Mountain Time) are not due to some wee hours reboot. I updated and rebooted on May 10 and May 22. The entire 3:36am sequence looks like this:

May 16 03:32:16 monarch pppd[913]: No response to 4 echo-requests
May 16 03:32:16 monarch pppd[913]: Serial link appears to be disconnected.
May 16 03:32:16 monarch pppd[913]: Connect time 7724.8 minutes.
May 16 03:32:16 monarch pppd[913]: Sent 2668866279 bytes, received 25839898342 bytes.
May 16 03:32:22 monarch pppd[913]: Connection terminated.
May 16 03:32:22 monarch pppd[913]: Sent PADT
May 16 03:32:22 monarch pppd[913]: Modem hangup
May 16 03:32:57 monarch pppd[913]: pppoe: Timeout waiting for PADO packets
May 16 03:32:57 monarch pppd[913]: Timeout waiting for PADO packets
May 16 03:34:12 monarch pppd[913]: pppoe: Timeout waiting for PADO packets
May 16 03:34:12 monarch pppd[913]: Timeout waiting for PADO packets
May 16 03:35:27 monarch pppd[913]: pppoe: Timeout waiting for PADO packets
May 16 03:35:27 monarch pppd[913]: Timeout waiting for PADO packets
May 16 03:36:42 monarch pppd[913]: pppoe: Timeout waiting for PADO packets
May 16 03:36:42 monarch pppd[913]: Timeout waiting for PADO packets
May 16 03:36:42 monarch pppd[913]: PPP session is 7949 (0x1f0d)
May 16 03:36:42 monarch pppd[913]: Connected to 78:fe:3d:3a:77:f2 via interface eno3.201
May 16 03:36:42 monarch pppd[913]: Using interface ppp0
May 16 03:36:42 monarch pppd[913]: Connect: ppp0 <--> eno3.201
May 16 03:36:42 monarch pppd[913]: CHAP authentication succeeded
May 16 03:36:42 monarch pppd[913]: CHAP authentication succeeded
May 16 03:36:42 monarch pppd[913]: peer from calling number 78:FE:3D:3A:77:F2 authorized
May 16 03:36:42 monarch pppd[913]: Cannot determine ethernet address for proxy ARP
May 16 03:36:42 monarch pppd[913]: local  IP address 97.118.92.206
May 16 03:36:42 monarch pppd[913]: remote IP address 207.224.0.0/15

This constitutes proof that IPv4 address changes happens between boots. Looks like it took about four and a half minutes to re-establish a PPP session.

If I correlate the last output for system boot and the address change data, I can see that only 2 of the 63 boots I have timestamps for have an address change that’s more than 1 hour later. Those 2 boots show an address change 3661 and 3721 seconds after the time of boot. Because my cron job runs hourly, and cron only guarantees the jobs run in that wall clock minute, that means both time-of-boot and time-of-address-change are probably only good to the nearest minute.

I think most or all reboots cause an address change.

Conclusion

CenturyLink’s fiber optic configuration, which uses PPPoE, probably has a fairly short timeout on validity of an IPv4 address when PPP isn’t connected. In my case, it looks like IPv4 addresses change on every boot, because my Dell R530 takes between 2 and 3 minutes to come back from a reboot. I hypothesize that the CenturyLink timeout is 1.5 or 2 minutes. Occasionally, IPv4 address changes occur even while a particular kernel runs, probably due to statistically infrequent network hiccups.

I got a mean time of 8.33 days between address changes. That agrees with updating my routing machine every weekend.