On 12/31/25 20:23, David Higton wrote:

In message <10j3tmk$29ec2$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

On 12/31/25 11:36, The Natural Philosopher wrote:

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

Linux IPv6 does appear to use random IPv6 address for outbound
connections, which have a limited lifespan. This appears to be something
like 1-7 days, but if very short lifespans were used it could offer a
protection similar to NAT. I need to investigate a bit further, but I
don't think IPv6 needs to be inherently less safe.

I use Ubuntu, which gives itself two routable IPv6 addresses. One is
always the same (good if you have an internet-accessible server) and
the other is new each reboot (good for privacy). Maybe it's the same
for you?

Yes, I'm using an Ubuntu derivative. That is what I had. I had the IPv6 address DHCPv6/RA assigned, plus there was a temporary one. Most
external connections to the WAN went over the temporary one. I guess
this is to not expose my permanent routable IPv6 address, the one I'm
likely to have open ports on.

AIUI, the temporary IPv6 address is preferred for one day, but hangs
around for 7 days.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/31/25 20:19, David Higton wrote:

In message <10j3tdq$29dt0$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

I'm surprised. Accepting that you do not do some of the things I do,
like policy routing rules based upon a host computer IP, I'm still
seeing servers on the internet that advertise they should work with IPv6
but don't. This means they don't fall back to IPv4.

I'm not far enough along in my understanding to be entirely confident,
but I would be surprised if I were wrong.

I've not encountered anything that's more difficult in IPv6 than in IPv4.

In general, I'm not claiming IPv6 is more difficult. However, I have 30+
years of dealing with and solving the problems of IPv4. Switching to
dual stack IPv6 is introducing new problems, which I need to understand
and solve.

The reason I was looking at IPv6 was to solve some poorly understood
problems I appear to have with a new VoIP SIP provider.

I'm certain that IPv6 works just as well and as reliably as IPv4; after
all, it's been in global-scale use for many years now, so all the issues
have been solved. But there's always scope for something to go wrong,
like in the example I quoted earlier where there was an IPv6 interface
that didn't previously exist, and configuring it (which was no more
difficult than the original IPv4 config, which was done so long ago that everyone had forgotten it) simply hadn't been done. Since everything mainstream now defaults to IPv6, there were two fault symptoms, depending which browser and OS were in use:

1) The site appeared unavailable;

2) The site was reached, but only after a delay.

Nothing about it was a problem of IPv6 per se.

But in practice, I am having IPv6 problems. Not caused by IPv6 itself,
but apparently by third party misconfiguration. It is no good IPv6 being
good, or my routing implementation being good, if in practice I'm
banging my head against third party problems.

At this stage it is quite possible I have misconfigured something, but
it takes a lot of effort for me to understand each problem, so I discuss
my experience in this public forum to gauge other people's practical experience.

I'd be interested to know what "policy routing rules based upon a host computer IP" you're using. My router runs OpenWRT. Everything gets
its IPv6 address via DHCPv6. The traffic rules pick up the device by
name, so, if the IPv6 address changes, the rules change automatically
to match.

I use permanent VPN tunnels to access the WAN, something like NordVPN.
Some LAN services I specifically want to route through the VPN, some I specifically want to route over the standard WAN. One way I have
traditionally done this is to using a pfSense router to use a service
internal LAN IP address to decide which external gateway to route over.
Other people might do something similar using VLANs, but my switch
hardware strips VLAN tags.

For the avoidance of doubt, I'm relatively naive w.r.t. networking. I
just knock up the first thing that works, rather than do something
technically orthodox.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> writes:

On 31/12/2025 20:18, Richard Kettlewell wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

The Natural Philosopher wrote:

David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

Linux IPv6 does appear to use random IPv6 address for outbound
connections, which have a limited lifespan. This appears to be
something like 1-7 days, but if very short lifespans were used it
could offer a protection similar to NAT. I need to investigate a bit
further, but I don't think IPv6 needs to be inherently less safe.

NAT does not offer any protection. The reason that a typical domestic
NAT-equipped router protects you from inbound connections is that it
has a firewall as well. (Getting a packet addressed to your internal
addresses to your external interface is inconvenient for many
attackers, for sure, but straightforward for your ISP or anyone who
can hack or coerce them.)

How?
Genuine question.

Same as routing any other packet. Make sure there?s an appropriate
routing table entry for the customer addresses on the ISP?s
customer-facing router (and whatever intermediate routers there are
between that and the attack source), then call socket/connect/write.

The question is then what the customer router does with it.

* If it follows the strong end system then the packet is discarded
before NAT even comes into the question.
Linux follows the weak end system model by default, so this
possibility doesn?t apply to Linux-based router unless someone has
taken the trouble to change its behavior somehow.

* If there?s a basically competent firewall on the customer router then
the packet is discard by that.

* If there?s a NAT then it gets to look at the packet, but it won?t
match any of the rules that enable translation, so it will not be
modified at this stage.

* All that?s now left is normal routing, so the packet passes on to its
destination on the customer network.

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 01/01/2026 12:26, Richard Kettlewell wrote:

The internal network destination address_is_ in its routing table.

But not its port. And not in its NAT table,

The essence of NAT is that the originating port cannot be accessed directly.

And that *everything* gets translated, There is no concept of 'allowing
some shit through even though it's not in my NAT tables' beyond
theoretical.

Whether that is a feature of NAT or a firewall, is semantics, but *in practice* it is not a security risk.

If the police want to examine my server, they simply knock on the door
with a warrant. No matter what protocol is on the interface



--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-31 at 17:50 AST, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

Given that this mystery IP didn't show up the next time I rebooted (or
again just now (to test)), I consider that unlikely. And grepping through >> /etc I don't see any unexpected instances of either (a) the mystery IP, or >> (b) the string "wlan". Not that this is an exhaustive hunt.

Linux has had a fit about the naming of interfaces. wlan seems deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All of my machines (RPi and otherwise) have "wlan0". But I have seen more exotic
names on some distros.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-31 at 17:09 AST, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Wed, 31 Dec 2025 16:00:45 -0400, Jim Diamond wrote:

rpi4-4b ls -l /etc/systemd/network
total 0
lrwxrwxrwx 1 root root 9 Dec 5 2023 73-usb-net-by-mac.link -> /dev/null
lrwxrwxrwx 1 root root 9 Dec 5 2023 99-default.link -> /dev/null

Interesting that you have anything in that directory at all; the one
on my Debian Unstable system is empty.

I didn't (explicitly) put those there. I don't know whether they were put there in the installation image or whether some initial configuration I did added those.

This symlinking to /dev/null is called ?masking?. It explicitly
disables those service entries (originals present in
/lib/systemd/network in this case) so they cannot be
(easily/accidentally) enabled.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> writes:

On 01/01/2026 12:26, Richard Kettlewell wrote:

The internal network destination address_is_ in its routing table.

But not its port. And not in its NAT table,

Irrelevant.

I literally did the experiment, you can see the results in the link
posted earlier.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> writes:

On 01/01/2026 11:34, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

On 31/12/2025 20:18, Richard Kettlewell wrote:

NAT does not offer any protection. The reason that a typical domestic
NAT-equipped router protects you from inbound connections is that it
has a firewall as well. (Getting a packet addressed to your internal
addresses to your external interface is inconvenient for many
attackers, for sure, but straightforward for your ISP or anyone who
can hack or coerce them.)

How?
Genuine question.

Same as routing any other packet. Make sure there?s an appropriate
routing table entry for the customer addresses on the ISP?s
customer-facing router (and whatever intermediate routers there are
between that and the attack source), then call socket/connect/write.
The question is then what the customer router does with it.
* If it follows the strong end system then the packet is discarded
before NAT even comes into the question.
Linux follows the weak end system model by default, so this
possibility doesn?t apply to Linux-based router unless someone has
taken the trouble to change its behavior somehow.
* If there?s a basically competent firewall on the customer router
then
the packet is discard by that.
* If there?s a NAT then it gets to look at the packet, but it won?t
match any of the rules that enable translation, so it will not be
modified at this stage.

Ah. I misunderstood your original post. Sure the ISP can send an
internally addressed packet to your router. If it wants to lose its
customer base.

* The police turn up with a warrant and inform you that if you don?t
help them break into a certain customer?s network, you will go to
prison.

* The mafia turn up with a gun, and inform you that if you don?t help
them break into a certain customer?s network, you will be shot.

* A teenager who follows full-disclosure exploits the latest zero day to
break into the ISP?s network, and from there to as many customers as
they can reach.

* An ISP staff member suspects that a friend who happens to be a
customer is having an affair with their wife. Overwhelmed by jealousy
they decide to attempt to hack the customer?s computers.

You can probably imagine more scenarios.

But will that get forwarded along?

* All that?s now left is normal routing, so the packet passes on to its
destination on the customer network.
https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

I can't believe that my router would accept arbitrary packets with
an internal destination address on its external facing port...

It probbaly doesn?t: it might use the strong end system model, and if
not it might have a firewall preventing it. But whatever its
configuration, it?s not NAT that stops it.

if the destination is not in its tables, it will be automatically discarded...

The internal network destination address _is_ in its routing table.
That?s how it sends legitimate packets back to the internal network
(e.g. when an internal host pings the router).

On my router:

$ ip route show|grep 172.17.207.0
172.17.207.0/24 dev br0 proto kernel scope link src 172.17.207.1

(172.17.207.0 is my internal network.)

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 01/01/2026 17:54, Richard Kettlewell wrote:

Jim Diamond <zsd@jdvb.ca> writes:

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

Given that this mystery IP didn't show up the next time I rebooted (or >>>> again just now (to test)), I consider that unlikely. And grepping through >>>> /etc I don't see any unexpected instances of either (a) the mystery IP, or >>>> (b) the string "wlan". Not that this is an exhaustive hunt.

Linux has had a fit about the naming of interfaces. wlan seems
deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All
of my machines (RPi and otherwise) have "wlan0". But I have seen more
exotic names on some distros.

TNP is thinking of the ?predictable interface names? scheme, which is a misnomer since predicting the name depends on information you don?t necessarily have readily to hand. Really it is about keeping the mapping between names and specific hardware interfaces stable, which is valuable
in some situations and inconvenient in others.

Er no. On my HP laptop the interface is something like (runs to laptop
and returns) "wlo1"...

IMHO they should have taken a lesson from filesystem naming, and allowed interfaces to be identified by their attributes, rather than depending
on a unique name.

--
"Fanaticism consists in redoubling your effort when you have
forgotten your aim."

George Santayana


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Jim Diamond <zsd@jdvb.ca> writes:

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

Given that this mystery IP didn't show up the next time I rebooted (or
again just now (to test)), I consider that unlikely. And grepping through >>> /etc I don't see any unexpected instances of either (a) the mystery IP, or >>> (b) the string "wlan". Not that this is an exhaustive hunt.

Linux has had a fit about the naming of interfaces. wlan seems
deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All
of my machines (RPi and otherwise) have "wlan0". But I have seen more
exotic names on some distros.

TNP is thinking of the ?predictable interface names? scheme, which is a misnomer since predicting the name depends on information you don?t
necessarily have readily to hand. Really it is about keeping the mapping between names and specific hardware interfaces stable, which is valuable
in some situations and inconvenient in others.

IMHO they should have taken a lesson from filesystem naming, and allowed interfaces to be identified by their attributes, rather than depending
on a unique name.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31.12.2025 22.09, Jim Diamond wrote:

On 2025-12-31 at 09:15 AST, Richard Kettlewell <invalid@invalid.invalid> wrote:

druck <news@druck.org.uk> writes:

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC)

MAC's aren't just Ethernet, WiFi and Bluetooth interfaces also have them. >>>

address, whereas the "proper" address is (currently) paired with the
same ethernet address, except the last octet is 8C instead of 8D.
This makes me think that it is showing "Connected" or "Disconnected"
according to the ethernet address which is working, and it is not
careful about pairing that with the correct IPv4 address.

You often see a difference of 1 when something creates a virtual
network interface for use by a virtual machine or container. The
virtual network card is assigned the second IP address and can operate
independently from anything using the hosts primary interface and IP
address.

At least on my 3B and 4B, the wired and wireless interfaces have
adjacent MACs.

PS C:\Users\rjk> ssh shairo ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether dc:a6:32:cb:73:6b brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000
link/ether dc:a6:32:cb:73:6c brd ff:ff:ff:ff:ff:ff

If both interfaces were connected to the same network then I might see
something similar to Jim?s situation.

I did ask Jim for ?ip addr show? output but it has not appeared.

Mea culpa, I thought I did.

Here is today's output... but I have long since gotten rid of that extra
IP, so I'm not sure if this is at all interesting:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether dc:a6:32:37:93:8c brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether dc:a6:32:37:93:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.2.74/24 brd 192.168.2.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80::d10a:4386:b7f7:43f9/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Should it happen again I'll capture this output in case it helps find the source.

Jim

If your system is running NetworkManager, it is the culprit.

In my RasPi3B+ router, I disabled and stopped NetworkManager.
systemd-networkd is perfectly capable to handle the DHCP
client duties.

After this, you have to create the needed interface and
network descriptions into /etc/systemd/network, and that's it.

The two links in the directory are fine, do not mess with them.

--

Tauno Voipio


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 01/01/2026 11:34, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

On 31/12/2025 20:18, Richard Kettlewell wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

The Natural Philosopher wrote:

David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not >>>>>> necessary

So making the implementation of a firewall absolutely mandatory

Linux IPv6 does appear to use random IPv6 address for outbound
connections, which have a limited lifespan. This appears to be
something like 1-7 days, but if very short lifespans were used it
could offer a protection similar to NAT. I need to investigate a bit
further, but I don't think IPv6 needs to be inherently less safe.

NAT does not offer any protection. The reason that a typical domestic
NAT-equipped router protects you from inbound connections is that it
has a firewall as well. (Getting a packet addressed to your internal
addresses to your external interface is inconvenient for many
attackers, for sure, but straightforward for your ISP or anyone who
can hack or coerce them.)

How?
Genuine question.

Same as routing any other packet. Make sure there?s an appropriate
routing table entry for the customer addresses on the ISP?s
customer-facing router (and whatever intermediate routers there are
between that and the attack source), then call socket/connect/write.

The question is then what the customer router does with it.

* If it follows the strong end system then the packet is discarded
before NAT even comes into the question.
Linux follows the weak end system model by default, so this
possibility doesn?t apply to Linux-based router unless someone has
taken the trouble to change its behavior somehow.

* If there?s a basically competent firewall on the customer router then
the packet is discard by that.

* If there?s a NAT then it gets to look at the packet, but it won?t
match any of the rules that enable translation, so it will not be
modified at this stage.

Ah. I misunderstood your original post. Sure the ISP can send an
internally addressed packet to your router. If it wants to lose its
customer base.

But will that get forwarded along?

* All that?s now left is normal routing, so the packet passes on to its
destination on the customer network.

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

I can't believe that my router would accept arbitrary packets with an internal destination address on its external facing port...if the
destination is not in its tables, it will be automatically discarded...



--
"In our post-modern world, climate science is not powerful because it is
true: it is true because it is powerful."

Lucas Bergkamp


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-30 at 18:26 AST, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 30 Dec 2025 17:50:15 -0400, Jim Diamond wrote:

On 2025-12-30 at 01:42 AST, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

I wonder why you would use an ISP-supplied router -- don?t you get
to connect your own?

No. The fiber comes into a box and the box also has the wifi router.

Here in NZ, the fibre terminates in a separate box called the ?ONT?.

When I first got fiber, I had two separate boxes, one for fiber<->ethernet,
and a wifi router.

Everything up to and including that box is the responsibility of a
company called ?Tuatahi Fibre?, which is *not* an ISP (and is not
allowed to become one). Basically they provide a layer-2 connection
between my house and the routers/switches/whatever for the service
providers, and their job is to treat all service providers equally.

Interesting! That sounds good, although perhaps there are some down sides
to that as well. (Do you think there are such downsides?)

Also, that box is to be considered part of the fittings of the house, so
it stays with the house, and doesn?t move if/when the residents move
house. The installation of the box (and the physical fibre connection to
it) was done free of charge, under a Government-funded plan.

Also interesting. Is that NZ-wide? Or just in certain areas?

Someone I know moved (from Canada) to NZ a few years ago, and we have never talked about internet infrastructure. I might have thought that had there
been something interesting there, he would have mentioned it. But maybe not.

The particular ONT box in my house has 4 Ethernet ports and 2
telephone landline ports. These can be independently assigned to
different services, coming from different providers. E.g. the one
that?s live for my ISP connection has an Ethernet cable running
between it and my actual router, which I bought from a local store.

My ISP heavily flogs their TV service, which the "all in one" box also
handles. Can you get TV through this? If so, does the TV just stream over
the ethernet like a "normal" network connection (as opposed to something
like a coax cable carrying many channels)?

I could try turning off the DHCP server in the ISP's box. However, they
have a habit of resetting and updating the software in their box, and I'm
not sure how long turning off that DHCP server would last. I am not sure
what would happen when two DHCP servers are on the same LAN, but I imagine >> Bad Things would happen.

Hmmm ... I?m thinking it might be possible to isolate that box on a
dedicated Ethernet port on a Linux box, so you could use a packet
filter to block anything DHCP-related, and only let through the stuff
you want

Yes, I could probably do something along those lines.

They upgraded the s/w in the router so that it isn't quite brain dead as it used to be. Formerly, if you wanted to tell it to reserve a particular IP
for a particular MAC address, 19 times out of 20 it wouldn't do it, which really pissed me off. The "support" (insert bitter laugh here) from the
ISP for anything like that was laughably bad, and there was no getting any
help from them on fixing their horrible router software. But it is less
bad recently.

Jim

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 01 Jan 2026 17:54:34 +0000, Richard Kettlewell wrote:

IMHO they should have taken a lesson from filesystem naming, and
allowed interfaces to be identified by their attributes, rather than depending on a unique name.

What attributes would you use?

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-01 at 16:37 AST, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

On 31.12.2025 22.09, Jim Diamond wrote:

On 2025-12-31 at 09:15 AST, Richard Kettlewell <invalid@invalid.invalid> wrote:

druck <news@druck.org.uk> writes:

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC) >>>>

MAC's aren't just Ethernet, WiFi and Bluetooth interfaces also have them. >>>>

address, whereas the "proper" address is (currently) paired with the >>>>> same ethernet address, except the last octet is 8C instead of 8D.
This makes me think that it is showing "Connected" or "Disconnected" >>>>> according to the ethernet address which is working, and it is not
careful about pairing that with the correct IPv4 address.

You often see a difference of 1 when something creates a virtual
network interface for use by a virtual machine or container. The
virtual network card is assigned the second IP address and can operate >>>> independently from anything using the hosts primary interface and IP
address.

At least on my 3B and 4B, the wired and wireless interfaces have
adjacent MACs.

PS C:\Users\rjk> ssh shairo ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether dc:a6:32:cb:73:6b brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000
link/ether dc:a6:32:cb:73:6c brd ff:ff:ff:ff:ff:ff

If both interfaces were connected to the same network then I might see
something similar to Jim?s situation.

I did ask Jim for ?ip addr show? output but it has not appeared.

Mea culpa, I thought I did.

Here is today's output... but I have long since gotten rid of that extra
IP, so I'm not sure if this is at all interesting:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether dc:a6:32:37:93:8c brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether dc:a6:32:37:93:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.2.74/24 brd 192.168.2.255 scope global noprefixroute wlan0 >> valid_lft forever preferred_lft forever
inet6 fe80::d10a:4386:b7f7:43f9/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Should it happen again I'll capture this output in case it helps find the
source.

Jim

If your system is running NetworkManager, it is the culprit.

Given that all of my systems have been running NetworkManager for many
years, and that I have only seen this happen once, I'm having a hard time seeing why you can make such a definitive statement. Care to elaborate?

In my RasPi3B+ router, I disabled and stopped NetworkManager. systemd-networkd is perfectly capable to handle the DHCP
client duties.

I run a number of systemd-free systems, and having as much commonality as possibly reduces admin time. So, for me, I would prefer to stay away from switching network configuration tools if at all possible. YMMV.

Jim


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 02/01/2026 15:39, druck wrote:

... and unique names (such as wl0sp3 on my laptop)

On my Thinkpad its wlp3s0. Those two couldn't possibly cause any
confusion for anyone, I'm sure!

--
Cheers,
Daniel.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In message <10jdt2m$22a2d$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

On 1/1/26 11:34, Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an example of
a website that fails to load when I use IPv6 but works fine under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html times out.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]

Curious. The curl -6 command works for me (and comes in like a rocket!)
and the link also works in Firefox, and I know that IPv6 is preferred.

That's the first instance I've hear of something failing to work correctly
in IPv6 with no obvious explanation.

David

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Pancho <Pancho.Jones@protonmail.com> writes:

Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an
example of a website that fails to load when I use IPv6 but works fine
under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html
works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html
times out.

It works for me from a couple of locations (one with native IPv6 and
the other via a Hurricance Electric tunnel). traceroute -6 might reveal
where your problem is.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]

AFAICT that just means you started tracing part way through a session.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/1/26 11:34, Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an example
of a website that fails to load when I use IPv6 but works fine under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html
works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html
times out.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 04/01/2026 19:02, druck wrote:

On 02/01/2026 17:32, Daniel James wrote:

On 02/01/2026 15:39, druck wrote:

... and unique names (such as wl0sp3 on my laptop)

On my Thinkpad its wlp3s0. Those two couldn't possibly cause any
confusion for anyone, I'm sure!

Actually mine is wlp3s0 too, I remembered it wrong!

Yes, it would be.

I wasn't thinking when I replied, but wl0sp3 isn't in the right format.

Also as someone else mentioned, it's actually predicable names rather
than unique names.

Yes, for some strange value of "predictable" that requires you to know
the naming scheme and also to know the hardware rather more intimately
than most people usually have any need or desire to do.

See:

https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html

--
Cheers,
Daniel.




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 27/12/2025 17:34, Jim Diamond wrote:

I was looking at my network and discovered an IP which I didn't know about; after a few seconds of investigation I discovered that one of my Pis (which is on wifi only, and only has one wifi card) has two IPs.

Two of my other Pis are running the same version of Raspberry Pi OS (i.e., "Debian GNU/Linux 12 (bookworm)"). They don't do this.

Looking around the net, there are claims that this is because Pis might try to netboot, and that later on in the boot process they also get their usual IP the "usual" way. (In my case I am using networkmanager.)

I can't imagine what I did to make one of my Pis want to (try to) netboot.

Has anyone here seen this, and, if so, know what grievous sins I have committed to make this happen? And how to make it stop?

Thanks.
Jim

I had smililar problem when I upgraded to Bullseye. My solution was
deleted connman package.

Refer to https://raspberrypi.stackexchange.com/questions/133318/how-to-disable-the-dynamic-ip-address-after-assigning-a-static-ip-in-bullseye

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 5 Jan 2026 12:37:23 +0000, Daniel James wrote:

On 04/01/2026 19:02, druck wrote:

Also as someone else mentioned, it's actually predicable names
rather than unique names.

Yes, for some strange value of "predictable" that requires you to
know the naming scheme and also to know the hardware rather more
intimately than most people usually have any need or desire to do.

I had a look on my system, to see where network interface names come
from. I found those names used inside /sys/class/net, which is
low-level information directly from the Linux kernel, not obtained
from udev rules or systemd or any other such userland source.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/4/26 15:20, Richard Kettlewell wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an
example of a website that fails to load when I use IPv6 but works fine
under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html
works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html
times out.

It works for me from a couple of locations (one with native IPv6 and
the other via a Hurricance Electric tunnel). traceroute -6 might reveal
where your problem is.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]

AFAICT that just means you started tracing part way through a session.

Thanks both of you, that gave me confidence to investigate further.

I'm guessing it is due to a split TCP packet. TLS asks for a change of cipher, which is a big packet, and then it all goes wrong.

Anyway, setting MTU=1444 fixes the problem. Internet tells me that the
root problem is because the firewall is blocking ICMP too big, breaking
Path MTU Discovery (PMTUD) . I can't see where, so now I have to
understand that.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-05 at 18:21 AST, attend <attend@homesrv.net> wrote:

On 27/12/2025 17:34, Jim Diamond wrote:

I was looking at my network and discovered an IP which I didn't know about; >> after a few seconds of investigation I discovered that one of my Pis (which >> is on wifi only, and only has one wifi card) has two IPs.

Two of my other Pis are running the same version of Raspberry Pi OS (i.e., >> "Debian GNU/Linux 12 (bookworm)"). They don't do this.

Looking around the net, there are claims that this is because Pis might try >> to netboot, and that later on in the boot process they also get their usual >> IP the "usual" way. (In my case I am using networkmanager.)

I can't imagine what I did to make one of my Pis want to (try to) netboot.

Has anyone here seen this, and, if so, know what grievous sins I have
committed to make this happen? And how to make it stop?

Thanks.
Jim

I had smililar problem when I upgraded to Bullseye. My solution was
deleted connman package.

Refer to https://raspberrypi.stackexchange.com/questions/133318/how-to-disable-the-dynamic-ip-address-after-assigning-a-static-ip-in-bullseye

Thanks for the pointer, but that wasn't it.

The system in question (as well as my other systems) doesn't (respectively, don't) have connman installed.

(I have a feeling I might not have named a piece of software "connman",
even though I can imagine where they got that name.)

Jim

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

That could also be handled with a VLAN.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 14/01/2026 17:49, Anssi Saari wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

I'm surprised. Accepting that you do not do some of the things I do,
like policy routing rules based upon a host computer IP...

I actually do that. I route my IPTV boxes out via an alternate interface
due to some stupid contractual issues. So all I did was add routing
rules with ip -6 rule add from $addr table Magic and all the Magic table
has is a defaultroute out via the other interface. Same as IPv4. But
maybe your policy routing is something different?

For sure this would be a problem if the IPv6 addresses were changing all
the time but they haven't.

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

John


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Pancho <Pancho.Jones@protonmail.com> writes:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

I'm surprised. Accepting that you do not do some of the things I do,
like policy routing rules based upon a host computer IP...

I actually do that. I route my IPTV boxes out via an alternate interface
due to some stupid contractual issues. So all I did was add routing
rules with ip -6 rule add from $addr table Magic and all the Magic table
has is a defaultroute out via the other interface. Same as IPv4. But
maybe your policy routing is something different?

For sure this would be a problem if the IPv6 addresses were changing all
the time but they haven't.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/14/26 17:49, Anssi Saari wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

I'm surprised. Accepting that you do not do some of the things I do,
like policy routing rules based upon a host computer IP...

I actually do that. I route my IPTV boxes out via an alternate interface
due to some stupid contractual issues. So all I did was add routing
rules with ip -6 rule add from $addr table Magic and all the Magic table
has is a defaultroute out via the other interface. Same as IPv4. But
maybe your policy routing is something different?

For sure this would be a problem if the IPv6 addresses were changing all
the time but they haven't.

Yes, that is the kind of thing but.. there was a bug in the pfSense
firewall rules. pfSense is a freeBSD firewall/router.

The bug was that pfSense allows you to predicate firewall rules on an
"alias", which can be a list of Full Qualified Domain Names. Something
like if the source host FQDN is in this alias, route over this gateway
to the WAN. The FQDNs resolve to an IPv4 and IPv6 addresses and then
checks the IP value in a packet and routes accordingly. This works fine
for a WAN FQDN, like e.g. www.google.com, it includes both IPv4 and IPv6 addresses. However, for hosts on my LAN, e.g. myhost.home.arpa if there
was an IPv4 address it gave only IPv4 and ignored the IPv6 one. I can
work around it by creating an extra FQDN for IPv6 e.g.
myhost.ipv6.home.arpa, but it takes time to understand why things don't
work.

Then there is the issue of the extra random IPv6 addresses it was
creating, which aren't included in DNS, in the FQDN at all.

That is the second IPv6 bug in pfSense, after the MTU/packet
fragmentation bug I mentioned earlier, which I'm still trying to get to
the bottom of.

IPv6 seems surprisingly hard. Surprising if a significant proportion of
people are using it.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 15 Jan 2026 01:17:23 +0000, Pancho wrote:

That is the second IPv6 bug in pfSense, after the MTU/packet
fragmentation bug I mentioned earlier, which I'm still trying to get
to the bottom of.

IPv6 seems surprisingly hard.

pfSense is built on FreeBSD and uses that network stack instead of
Linux, isn?t it?

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/15/26 05:10, Lawrence D?Oliveiro wrote:

On Thu, 15 Jan 2026 01:17:23 +0000, Pancho wrote:

That is the second IPv6 bug in pfSense, after the MTU/packet
fragmentation bug I mentioned earlier, which I'm still trying to get
to the bottom of.

IPv6 seems surprisingly hard.

pfSense is built on FreeBSD and uses that network stack instead of
Linux, isn?t it?

Yeah, I wasn't pointing out the bugs as directly relevant to Linux. I
was mentioning them to support my suspicions about a general lack of
maturity of IPv6 in products.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/14/26 21:13, Lawrence D?Oliveiro wrote:

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

That could also be handled with a VLAN.

If your network hardware handles VLAN tags.

I have numerous switches (unmanaged) and WiFi access points, none of the
ones I tested were compatible with VLAN tags (i.e. The network device
stripped the VLAN tag off packets rather than dumbly passed the packet
through with VLAN tag intact).

VLANs also aren't ideal as you may wish to implement policy routing on a protocol (e.g. VoIP) or WAN destination, not just upon a LAN host.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/01/2026 13:33, Pancho wrote:

On 1/14/26 21:13, Lawrence D?Oliveiro wrote:

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

That could also be handled with a VLAN.

If your network hardware handles VLAN tags.

I have numerous switches (unmanaged) and WiFi access points, none of the ones I tested were compatible with VLAN tags (i.e. The network device stripped the VLAN tag off packets rather than dumbly passed the packet through with VLAN tag intact).

VLANs also aren't ideal as you may wish to implement policy routing on a protocol (e.g. VoIP) or WAN destination, not just upon a LAN host.

There does seem to be a lot of variation in how different switches
behave. The HP 1820 and 1810 series web managed switches along with
a variety of Netgear web managed switches all propagate vlan tags in
their default state.
They can can be configured to detag vlans on specific ports if
necessary.
I have some Allied Telesis managed switches that block vlans by default.

John


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 15 Jan 2026 13:33:44 +0000, Pancho wrote:

On 1/14/26 21:13, Lawrence D?Oliveiro wrote:

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing
rules which nicely overcomes the problem with varying IPv6
addresses.

That could also be handled with a VLAN.

If your network hardware handles VLAN tags.

I?m sure this could be done using a Linux box as your network
switch/router.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

John R Walliker <jrwalliker@gmail.com> writes:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

Indeed. I wish I could do that easily in Linux but it seems a bit of a
chore. But looks like nftables packet marking and policy based routing
together can accomplish it. So all I need is the marking part and a
little tweaking of my policy routing to use those marks instead of
source IPv6 addresses.

Something to do later, I'm working on something else right now.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)