Bug #6826
closed
DNS forwarder is sending packets with link-local IPv6 source address to global unicast address
0%
Description
- Install pfsense 2.3.2. WAN and LAN interfaces. No global IPv6 address assigned to WAN interface (but see NOTE below)
- Run tcpdump on the WAN interface
- From a client on the LAN side, try to resolve a name which has IPv6 nameservers, e.g. "www.nsrc.org"
Result: for the first 2 seconds it is trying to send IPv6 packets with a link-local source address, which is pointless.
13:53:56.668772 IP6 fe80::5054:ff:fe45:78d7.13607 > 2001:468:d01:3c::80df:3c16.53: 21553% [1au] A? www.nsrc.org. (41)
13:53:57.421973 IP6 fe80::5054:ff:fe45:78d7.27340 > 2001:468:d01:3c::80df:3c16.53: 39295% [1au] A? www.nsrc.org. (41)
13:53:58.175041 IP 10.69.255.66.54197 > 147.28.0.39.53: 2501% [1au] A? www.nsrc.org. (41)
13:53:58.331785 IP 147.28.0.39.53 > 10.69.255.66.54197: 2501*- 2/3/5 CNAME nsrc.org., A 128.223.157.25 (785)
13:53:58.332289 IP 10.69.255.66.28896 > 128.223.60.22.53: 53214% [1au] A? nsrc.org. (37)
13:53:58.515788 IP 128.223.60.22.53 > 10.69.255.66.28896: 53214*- 1/3/5 A 128.223.157.25 (221)
NOTE: the test network does have an upstream router sending out IPv6 router advertisements, but without SLAAC or DHCPv6 enabled. I believe this is a perfectly reasonable situation: I have this because I only want manually-configured devices to have an IPv6 address.
It means that the routing table does pick up an IPv6 default gateway (with a link-local next hop)
[2.3.2-RELEASE][admin@class-gw.ws.nsrc.org]/root: netstat -rn6
Routing tables
Internet6:
Destination Gateway Flags Netif Expire
default fe80::9e97:26ff:fe0b:6e19%vtnet1 UGS vtnet1
::1 link#6 UH lo0
fe80::9e97:26ff:fe0b:6e19 fe80::9e97:26ff:fe0b:6e19%vtnet1 UGHS vtnet1
fe80::%vtnet0/64 link#1 U vtnet0
fe80::5054:ff:feda:957d%vtnet0 link#1 UHS lo0
fe80::%vtnet1/64 link#2 U vtnet1
fe80::5054:ff:fe45:78d7%vtnet1 link#2 UHS lo0
fe80::%lo0/64 link#6 U lo0
fe80::1%lo0 link#6 UHS lo0
ff01::%vtnet0/32 fe80::5054:ff:feda:957d%vtnet0 U vtnet0
ff01::%vtnet1/32 fe80::5054:ff:fe45:78d7%vtnet1 U vtnet1
ff01::%lo0/32 ::1 U lo0
ff02::%vtnet0/32 fe80::5054:ff:feda:957d%vtnet0 U vtnet0
ff02::%vtnet1/32 fe80::5054:ff:fe45:78d7%vtnet1 U vtnet1
ff02::%lo0/32 ::1 U lo0
However, I do not believe that a host should ever send a packet to a global unicast address using a link-local source address.
Updated by Jim Thompson about 8 years ago
- Category set to DNS Forwarder
- Assignee set to Jim Pingle
Updated by Jim Pingle about 8 years ago
- Status changed from New to Rejected
This appears to be how FreeBSD behaves and is not specific to the DNS resolver or forwarder, the same happens even with ping. The client will attempt to send the packet, then it receives back a "destination unreachable, beyond scope" message from the next hop and stops.
If you'd like to advocate for a change in the behavior, you can bring it up with FreeBSD directly.
If you'd like to enforce the behavior you prefer, you could setup floating rules to block the unwanted traffic outbound as it attempts to leave, but I'm not sure it's worth the effort for us to attempt to automatically set that up at this point in time.
Updated by Brian Candler about 8 years ago
Thanks. ping is a special case since it is protocol-aware (separate ping, ping6), but it looks like FreeBSD doesn't implement RFC 6724 properly.
"if the node has assigned only a link-local IPv6 address and a global
IPv4 address, then IPv4 is the best choice for communication."And example:
Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src
fe80::1) (prefer matching scope)This appears to come from /etc/rc.d/ip6addrctl. I'll report upstream when I get a chance.