This is an old revision of the document!
This page will be used to coordinate the effort to make FreeBSD's networking stack comply with various Internet standards. This will include:
- RFCs which we currently implement COMPLETELY.
- RFCs which we currently implement PARTIALLY.
- RFCs which we MUST implement.
- RFCs which we SHOULD implement in future.
- Verify netinet code for RFC 3927 ('Zeroconf') compliance, in progress now.
- RFCs which we SHOULD NOT implement.
Implementation Notes
- Host mode limited broadcast.
- In the past there have been requests for multiple-subnet limited broadcast within FreeBSD, i.e. a feature that causes datagrams with a destination address of 255.255.255.255 to be sent on all interfaces.
- This is RFC 947 type behaviour, which is deprecated.
- Such behaviour is not in accordance with current RFCs. As such any work which was done on such a feature has been removed.
- An application wishing to send or receive on all interfaces should do so manually e.g. by using getifaddrs() to walk the list of configured interfaces in the system.
- FreeBSD has the IP_ONESBCAST socket option for sending limited broadcasts. This is the officially supported and sanctioned way of sending broadcasts to 255.255.255.255; hacks such as using pcap/bpf SHOULD be deprecated.
- IP_ONESBCAST may be deprecated in future if new features such as interface preference, source address selection, and equal-cost multipath are adopted. It exists because historically the only way to select an IP source interface in FreeBSD has been based on the destination IPv4 address of a datagram.
- Router mode broadcast.
- As of March 2007, FreeBSD 7.0 WILL NOT forward directed broadcasts to directly attached local networks.
- This behaviour is compliant with RFC 2644.
- FreeBSD 7.0 WILL forward directed broadcasts to remote networks. The forwarding plane CANNOT reasonably determine that an address is a link directed broadcast address UNLESS it has a network entry in its forwarding trie AND the subnet is marked as a directly attached local network.
- Routing daemons MAY create forwarding trie entries for a particular network broadcast address, with the RTF_BROADCAST flag set, thus causing datagrams with this destination address to be dropped by FreeBSD's forwarding plane. This is NOT MANDATORY.
- RFC 947 may be regarded as deprecated. RFCs 1812 and 2644 explicitly deprecate its behaviour.
- Implications of RFC 1812 section 5.3.5.3: FreeBSD does not treat broadcast addresses as special unless it knows they are broadcast addresses. The presence of a network entry alone does not imply that it is a broadcast network.
- The above should really be announced on a mailing list and merged into documentation.
- Moral of story: IP broadcasting is a headache, which is why they got rid of it in IPv6.