Local IPv6 traffic not send over loopback?

Wed Feb 15 22:53:57 UTC 2012

Julian Elischer wrote:

> can you actually put them in an official bug report?

Done for the first report. I'll follow up once it is approved.

Do you have any comments about the second problem?
(unlike the first, that only seem to occur with ICMPv6 traffic).

The bug report page was new; I was surprised not to see a reference to
the problem reassemlbing fragemented IPv6 traffic, are reported last
year:
http://lists.freebsd.org/pipermail/freebsd-ipfw/2011-October/004918.html
Am I overlooking something, or should I try to examine a bit further and
file a bug report for that as well?

Regards,
Freek

>> _ ______________________________________________
>>
>> Report #1: ipfw reports wrong interface for IPv6 loopback traffic
>>
>> Summary:
>> ipfw matches and reports incorrect interface for IPv6 traffic between
>> through the lookback interface in case the source/destination IP is
>> not ::1.
>>
>> 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
>  there is the bug:  lo0 is not marking ipv6 packets.
> 
>>> 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"
>> fails
>>
>> Hence, the MTU is 16336 bytes payload + 48 byte overhead = 16384 bytes,
>> so that indicates the actual interface used is lo0, not em0.
>>
>> Since a packet of 16384 bytes comes through, and em0 has a MTU of 1500
>> bytes, this also means that em0 is really not used, and the receiving
>> interface as reported and matched by ipfw is wrong.
>>
>> _ ______________________________________________
>>
>> Report #2: ipfw matches recv data for outgoing ICMPv6 replies.
>>
>> Summary:
>> When a host creates an IPv6 reply packets and sends it out, the packet
>> is matched by a ipfw rule with a "recv" pattern.
>>
>> Steps to reproduce:
>> 1. Determine the IPv6 addresses of two hosts, and make sure they can
>> ping each other over IPv6.
>> 2. On one host, add the following rules to ipfw:
>> # ipfw add 10 count log icmp6 from any to me
>> # ipfw add 11 count log icmp6 from any to me recv \*
>> # ipfw add 12 count log icmp6 from any to me xmit \*
>> # ipfw add 13 count log icmp6 from any to me in recv \*
>> # ipfw add 14 count log icmp6 from any to me out recv \*
>> # ipfw add 15 count log icmp6 from any to me out xmit \*
>> # ipfw add 20 count log icmp6 from me to any
>> # ipfw add 21 count log icmp6 from me to any recv \*
>> # ipfw add 22 count log icmp6 from me to any xmit \*
>> # ipfw add 23 count log icmp6 from me to any in recv \*
>> # ipfw add 24 count log icmp6 from me to any out recv \*
>> # ipfw add 25 count log icmp6 from me to any out xmit \*
>> 3. From the other host, ping the first host (with the ipfw rules), e.g.:
>> % ping6 -c 1 2001:610:767:4ec1::1
>> 4. examine the IPFW log file.
>>
>> Expected result:
>>> ipfw: 10 Count ICMPv6:128.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 11 Count ICMPv6:128.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 13 Count ICMPv6:128.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 20 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 22 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 25 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>> Actual result:
>>> ipfw: 10 Count ICMPv6:128.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 11 Count ICMPv6:128.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 13 Count ICMPv6:128.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 20 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 21 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 22 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 24 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 25 Count ICMPv6:129.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>> Further analysis:
>> It seem that the outgoing ICMP reply (ICMPv6:129) matches the rules with
>> "recv" match as well. This is unexpected, as the ICMPv6 reply originates
>> at the first host, and the man page of ipfw clearly states: "packets
>> originating from the local host have no receive interface"
>>
>> This behaviour only seem to occur with ICMPv6 replies. ICMPv6 requests
>> work fine, as can be seem from this result to ping host two from host
>> one:
>> % ping6 -c 1 2001:610:767:4ec1::6
>>> ipfw: 20 Count ICMPv6:135.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 22 Count ICMPv6:135.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 25 Count ICMPv6:135.0 [2001:610:767:4ec1::1]
>>> [2001:610:767:4ec1::6] out via em3
>>> ipfw: 10 Count ICMPv6:136.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 11 Count ICMPv6:136.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>>> ipfw: 13 Count ICMPv6:136.0 [2001:610:767:4ec1::6]
>>> [2001:610:767:4ec1::1] in via em3
>> Not all incoming traffic is affected. The following excerpt is from a
>> SSH session that the second host initiates, connecting to the first host:
>> % ssh -6 2001:610:767:4ec1::1
>>> ipfw: 10 Count TCP [2001:610:767:4ec1::6]:55370
>>> [2001:610:767:4ec1::1]:22 in via em3
>>> ipfw: 11 Count TCP [2001:610:767:4ec1::6]:55370
>>> [2001:610:767:4ec1::1]:22 in via em3
>>> ipfw: 13 Count TCP [2001:610:767:4ec1::6]:55370
>>> [2001:610:767:4ec1::1]:22 in via em3
>>> ipfw: 20 Count TCP [2001:610:767:4ec1::1]:22
>>> [2001:610:767:4ec1::6]:55370 out via em3
>>> ipfw: 22 Count TCP [2001:610:767:4ec1::1]:22
>>> [2001:610:767:4ec1::6]:55370 out via em3
>>> ipfw: 25 Count TCP [2001:610:767:4ec1::1]:22
>>> [2001:610:767:4ec1::6]:55370 out via em3
>> I would expect ICMPv6 replies to behave (with regard to matching "recv"
>> patterns) the same as other packets originating from a host, and never
>> matches.
>>
>> _ ______________________________________________
>> _______________________________________________
>> freebsd-ipfw at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>>
> 
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
> 