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
- IPv4 Router Alert RFC2113
- FreeBSD basically does the right thing. RA is totally ignored and no special processing takes place. It does not make any real difference to the stack unless the code structure changes, which it may do. Userland routing daemon consumers may set it on outgoing datagrams using the IP_OPTIONS socket option.
- 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.
- 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.
- 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.