IPFW Problem with chaotic IPv6 local routing

PMc

Daemon

Reaction score: 685
Messages: 1,381

With IPv4 the handling was simple: all local traffic would go in and out of the lo0 interface, no matter which ip-address was used or on which interface that address would be placed. This gets also obvious from the routing table:
Code:
root@xxxx:~ # ifconfig
vtnet0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 192.168.97.15 netmask 0xffffffe0 broadcast 192.168.97.31
        inet6 fd00::1 prefixlen 64
root@xxxx:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
127.0.0.1          link#2             UH          lo0
192.168.97.0/27    link#1             U        vtnet0
192.168.97.15      link#1             UHS         lo0 <<<<<<

While the network /27 appears with vtnet0, the local address itself is at lo0.
Practically it looks like this:

Code:
root@xxxx:~ # ping 192.168.97.15
ipfw: 1 Accept ICMP:8.0 127.0.0.1 192.168.97.15 out via lo0
ipfw: 1 Accept ICMP:8.0 127.0.0.1 192.168.97.15 in via lo0
ipfw: 1 Accept ICMP:0.0 192.168.97.15 127.0.0.1 out via lo0
ipfw: 1 Accept ICMP:0.0 192.168.97.15 127.0.0.1 in via lo0

root@xxxx:~ # telnet 192.168.97.15 7777
ipfw: 1 Accept TCP 192.168.97.15:52401 192.168.97.15:7777 out via lo0
ipfw: 1 Accept TCP 192.168.97.15:52401 192.168.97.15:7777 in via lo0
ipfw: 1 Accept TCP 192.168.97.15:7777 192.168.97.15:52401 out via lo0
ipfw: 1 Accept TCP 192.168.97.15:7777 192.168.97.15:52401 in via lo0

All traffic goes thru lo0 (and there we could filter it if e.g. we want to filter between non-vimage jails).

But now look at IPv6:

Code:
root@xxxx:~ # ping fd00::1
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] in via lo0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] in via lo0

root@xxxx:~ # telnet fd00::1 7777
ipfw: 1 Accept TCP [fd00::1]:53821 [fd00::1]:7777 out via lo0
ipfw: 1 Accept TCP [fd00::1]:53821 [fd00::1]:7777 in via vtnet0  <<<<<
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:53821 out via lo0
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:53821 in via lo0

Upsala! What's the 'vtnet0' doing there??

But that's not yet the full story. This is RELEASE 13.0. And now RELEASE 12.2:

Code:
root@yyyy:~ # ping6 fd00::1
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] in via vtnet0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] in via vtnet0

root@yyyy:~ # telnet fd00::1 7777
ipfw: 1 Accept TCP [fd00::1]:60375 [fd00::1]:7777 out via lo0
ipfw: 1 Accept TCP [fd00::1]:60375 [fd00::1]:7777 in via vtnet0
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:60375 out via lo0
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:60375 in via vtnet0

Urgs.

Lets conclude: the behaviour is
  • inkonsistent between incoming and outgoing
  • inkonsistent between originate and answer flow
  • inkonsistent between protocols (ICMP vs. TCP)
  • inkonsistent between releases
And now I have a problem. I'm trying to enhance my graphical frontend to also work with IPv6

But how should I code that, when the behaviour is different with every usecase?

And whom might I ask how it would look if it finally settles? (The ipfw mailinglist seems mostly empty.)
 
OP
PMc

PMc

Daemon

Reaction score: 685
Messages: 1,381

Figured out: this is a "known problem without solution", reported as bug #165190, in 2012 - nobody seemed to give a damn about it during nine years. (So it is apparently not only my patches that get entirely ignored.)
I would suppose the provided patch by Sergey to have the known weakness with linklocal scopes, and have created a different patch. But then what for, as nobody is going to fix it anyway?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,744
Messages: 39,332

Do you have any idea how many PRs are being opened on average? It's not uncommon for some of them to fall through the cracks or disappear off the radar. If it's something you feel is really important you can always ping the developers on the mailing lists and ask about it. Older PRs may still be worthwhile to chase, maybe the patch or the issue became obsolete, in that case the PR should be closed with a proper explanation why it's not relevant anymore.

I remember there was a time when we had regular "bug hunts" you could sign up for. Everybody went through the open PR list to see if things were still relevant or not and if they're still relevant would try to fix the issue.
 

Zirias

Son of Beastie

Reaction score: 1,701
Messages: 2,870

So, doesn't ipfw have a concept similar to self in pf? With that, the interface used really doesn't matter much…
 
OP
PMc

PMc

Daemon

Reaction score: 685
Messages: 1,381

Yes it has, "me" and "me6".

But, how do you make a large rule list faster? By splitting it into branches, so that each packet runs only thru a part of it.
And what is a good and practical approach to branches? In/Out per interface.

And then there is the problem, because the local packet then suddenly runs thru the rules for an externally inbound packet, where it normally will not be allowed. :(
 

Zirias

Son of Beastie

Reaction score: 1,701
Messages: 2,870

Ok well, you can still split after a common "whitelist" for local connections. Maybe not perfect, but would work. I'm not even sure a routing table entry for every local address through lo0 is obligatory? And what happens if some program binds to the local address of one interface and connects to the local address of a different one – isn't that considered "local" any more?
 
OP
PMc

PMc

Daemon

Reaction score: 685
Messages: 1,381

Do you have any idea how many PRs are being opened on average? I
Not on average, but I rememebr that with sendmail it took less than 24h for patches sent by mail to end up in HEAD (and get a personal answer). Whereas with AIX it required +1year to discuss with various people about the definition of the word "bug".

So, back in these times, I noted that as the major difference between commercial stuff and the free zone.

But, what has happened interim: the whole internet is just advertisments and crap, the whole free zone has gone commercial - and it now behaves just like that. It's a matter of attitude.

t's not uncommon for some of them to fall through the cracks or disappear off the radar. If it's something you feel is really important
It's not on me to decide what is important.

I remember there was a time when we had regular "bug hunts" you could sign up for. Everybody went through the open PR list to see if things were still relevant or not and if they're still relevant would try to fix the issue.
Yes that was the good old times when I occasionally got mail about a bug I had filed 2-3 years ago. And maybe I still had that hardware or maybe not.
 
OP
PMc

PMc

Daemon

Reaction score: 685
Messages: 1,381

Ok well, you can still split after a common "whitelist" for local connections. Maybe not perfect, but would work
Yes, that might work. I thought about it, but it would need me to rewrite the code that creates the rules from the flow table in the database.
And then it was easier to fix it in the kernel code.

I'm not even sure a routing table entry for every local address through lo0 is obligatory? And what happens if some program binds to the local address of one interface and connects to the local address of a different one – isn't that considered "local" any more?
Sure it is local. It all works automatically the right way, with IPv4 - and it does so here for at least since 2007 when I started to do things with jails.

There is only and precisely something different with IPv6, and that is what the bugreport is all about.
And that is intentionally so, because of interface specific scoping: if you route thru fe80::1%vtnet0, and that is a local address, then it must route thru lo0 but keep the scoping from vtnet0.
A few people have tried to fix that in general, and gave up on it. Consequentially at least this bogus reporting should be fixed.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,744
Messages: 39,332

It's not on me to decide what is important.
It's important to you because you appear to be running into that bug. So yes, you do have a say in this.
 
Top