Bug 165190 - ipfw(4): lo(4) loopback interface is not marking IPv6 packets
Summary: ipfw(4): lo(4) loopback interface is not marking IPv6 packets
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ipfw (Nobody)
Keywords: ipv6
Depends on:
Reported: 2012-02-15 22:30 UTC by public
Modified: 2023-09-13 06:15 UTC (History)
3 users (show)

See Also:

nd6.c.diff (389 bytes, patch)
2012-02-19 23:18 UTC, Sergey Matveychuk
no flags Details | Diff
see coment #5 (518 bytes, patch)
2021-12-29 13:15 UTC, Peter Much
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description public 2012-02-15 22:30:10 UTC
ipfw matches and reports the incorrect interface for IPv6 traffic via the loopback interface.

> ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0
> ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0
(the in via em0 should be in via lo0).


Suggested by Julian Elischer: lo0 is not marking ipv6 packets.
How-To-Repeat: Steps to reproduce:
1. Determine a global IPv6 address of your host. In this report, 2001:610:767:4ec1::1 is used.
2. Verify that the routing table has an entry associating this IP address with the loopback interface. E.g.:
% route get -inet6 2001:610:767:4ec1::1
   route to: 2001:610:767:4ec1::1
destination: 2001:610:767:4ec1::1
  interface: lo0
3. Add the following rules to ipfw:
# ipfw add 1 count log ipv6 from me6 to me6 recv lo0
# ipfw add 2 count log ipv6 from me6 to me6 not recv lo0
4. Run sudo sysctl net.inet.ip.fw.one_pass=0
5. Ping the local IP:
% ping6 -c 1 2001:610:767:4ec1::1
6. examine the IPFW log file.

Expected result:
I expected rule 1 to match:
> ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0
> ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0
> ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0
> ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0

Actual result:
Rule 2 matched:
> ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0
> ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0
> ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0
> ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0

Further analysis:
Adding rules for "xmit lo0" and "not xmit lo0" clearly show that according to ipfw, the packet is "xmit lo0 recv em0".

Beside using "route get" in step 2 above, there is another method to determine the interface that is used by the packet, the MTU size.
By default, the MTU of lo0 is 16384 bytes, and other interface have a MTU of 1500 bytes:
% ifconfig:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

% ping6 -c 1 -D -s 16336 -b 32000 "2001:610:767:4ec1::1"
works fine
% ping6 -c 1 -D -s 16337 -b 32000 "2001:610:767:4ec1::1"

Hence, the MTU is 16336 bytes payload + 48 byte overhead = 16384 bytes, so that indicates the actual interface used is lo0. It also indicates that em0 is not used: if both lo0 and em0 would be used, the smaller MTU of em0 would block larger packets, and this is not the case. Hence, em0 seems not used all, despite the reporting of ipfw.
Comment 1 Julian Elischer freebsd_committer freebsd_triage 2012-02-15 23:46:19 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-net

is a network problem not a 386 problem
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2012-02-19 19:40:00 UTC
Responsible Changed
From-To: freebsd-net->freebsd-ipfw

fix assignment.
Comment 3 Sergey Matveychuk freebsd_committer freebsd_triage 2012-02-19 23:18:13 UTC
Julian wrongs here.

Try the patch please.
I've found the superfluous code in nd6.c when wrote a patch for 
divert(4) and was very annoyed this loopback behaviour.
For unknown reasons KAME authors decided to fake interface for loopback. 
It differs from IPv4 code, so, I guess, it should be fixed. But I could 
not proof it. Your example is better for this.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:53 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 5 Peter Much 2021-12-29 13:11:50 UTC
This issue seriousely fails my firewall processing.

Since review D3868 did not get acceptance, and, as I might assume, Sergey's patch above might suffer the same problem (linklocal scopes not handled), I went for a different fix, as attached, that appears to work for me.
Comment 6 Peter Much 2021-12-29 13:15:21 UTC
Created attachment 230537 [details]
see coment #5
Comment 7 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:35:49 UTC

or  patch-ready

– in lieu of summary line prefix: 


* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

Comment 8 Graham Perrin freebsd_committer freebsd_triage 2022-12-08 12:37:55 UTC

* add keywords

* avoid summary line tags.
Comment 9 Graham Perrin 2023-09-13 06:15:27 UTC

a) assign to ipfw@

b) remove an incorrect keyword – ipfilter is not ipfw (fault: mine).