On 6 July 2013 21:26, Pawel Jurusz <mailing.s...@gmail.com> wrote:
> Hello Marios
>
Hello Pawel,
> DF bit shouldn't be cleared, because it's necessary for PMTUD (Path MTU
> Discovery). There is also nothing amazing, that packets has DF flag set
> (it depends on operating system)
>
I'm aware of the utility of the DF bit. In my case, the original packet has no
fragmentation options (frag headers in IPv6's case), but the DF bit is added
by PF.
I'm assuming it's because of this part from RFC6145:
5.1. Translating IPv6 Headers into IPv4 Headers
[...]
Flags: The More Fragments flag is set to zero. The Don't Fragment
(DF) flag is set to one. In order to avoid black holes caused by
ICMPv4 filtering or non-[RFC2460]-compatible IPv6 hosts (a
workaround is discussed in Section 6), the translator MAY provide
a function as follows. If the packet size is greater than 88
bytes and less than or equal to 1280 bytes, it sets the DF flag to
zero; otherwise, it sets the DF flag to one. The translator
SHOULD provide a method for operators to enable or disable this
function.
The question now becomes "Does PF implement the 'SHOULD' part ?"
Perhaps the translated packets are directly leaving the interface without being
processed by PF any further ?
Marios
>> Hello misc@,
>>
>> I currently have a VM running as a NAT64 gateway.
>> It is running OpenBSD 5.3 with the vio stability patch.
>>
>> I have the following pf.conf:
>>
>> pass in inet6 proto { tcp, udp, icmp6 } from <network> to <pref64>
>> af-to inet from $ipv4_addr
>>
>> While this works fine in one environnment, the same VM
>> moved on a different host doesn't work properly.
>> Specifically, packets are matched by the rule, I can see them
>> leave the interface with tcpdump, but I never receive a response
>> from the remote host.
>>
>> While investigating the issue, I noticed that when sending a ping
>> from a host behind the NAT64 gateway, the IPv4 packet sent contains
>> the DF (don't fragment) flag.
>>
>> I am suspecting the host might be blackholing all packets having the
>> DF flag set,
>> which is why the translation won't work there.
>>
>> I have the two questions below:
>> - Is this behavior expected ? It affects all IPv4 packets created.
>> - Is there a way to clear the DF flag on the packet created by the af-to
>> rule ?
>>
>> I have tried adding the following rule after the pass :
>> match out scrub (no-df)
>>
>> But to no success. I added the 'log' keyword but it seems the match
>> rule is never matched.
>>
>> Thanks,
>>
>> Marios
