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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
