On Sun, Mar 17, 2019 at 06:43:42PM -0400, Robert Carter wrote: > 169.254.0.0/16 should be a perfectly reasonable management domain, which is > what we are using it for in our product.
Of course it isn't my business how your product works, but over time I've learned to avoid the whole zero-conf auto-IP thing like the plague. First step after fresh Linux install is: apt purge avahi. > My understanding of RFC 3927 is that routers are not to forward link local > traffic, regardless of the TTL. A host shouldn't be banned from sending > multicast traffic to a link local interface. I'm not so sure about that. > PTP needs to "work" over a local 169.254.0.0/16 network. This isn't > unreasonable. Maybe, but the kernel avoids it for some reason. I'd like to understand the root cause. > Please point me to the RFCs that say otherwise. If I'm off in the weeds, I'd > like to know the source. >From the RFC: A set of hosts is considered to be "on the same link", if: ... when any host A from that set sends a packet to any other host B in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified (pages 3-4) IPv4 addresses and names that can only be resolved on the local link SHOULD NOT be forwarded beyond the local link. ... IPv4 Link-Local addresses SHOULD only be sent when a Link-Local address is used as the source and/or destination address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply. (page 7) IPv4 packets with a Link-Local source address MUST NOT be forwarded outside the local link even if they have a multicast destination address. (page 16) Since the PTP multicast destination addresses are global in scope, combining a link-local SA with a PTP DA appears to be prohibited. Anyhow, maybe that is how the kernel sees it. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel