At Thu, 7 Nov 2013 18:56:12 +0000, "Fred Baker (fred)" <[email protected]> wrote:
> >> I'm seeing plenty of packets from link-local sources to global > >> destinations which means that: > >> 1) there are hosts with broken default address selection > >> AND > > > > (Probably an off-topic in this context but) this is not necessarily > > accurate. If a host only has a link-local address but somehow knows > > the interface to send packets to a global destination, it would be > > able to send packets with source being link-local and destination > > being global, and validly (not breaking RFC 6724) so. I believe it's > > more likely to be a broken network configuration than a broken host > > implementation. > > I suspect it's some of each. The host should, I should think, set > the hop limit to one on any packet that is to a link-local address, To make it sure: this is about the case of packets "from" a link-local address. > to ensure that the packet is not repeated by a broken router (apart > from protocols that ask to have it set to 255 and have the receiving > host check for that value). Also, upstream network's BCP 38 I'd note, from purely architectural point of view, that it's totally valid a packet that has a link-local address is forwarded, as long as the packet remains in the originating link zone. That would be a very unlikely case in practice, but can still happen, e.g., when a host sends all packets to a router, expecting the router to forward it back to the same link toward the destination. RFC 4007 mentions such cases. That said, I see it should be a very rare case except for implementation or operational errors. So it may make sense to introduce something similar to the IPV6_MULTICAST_HOPS socket option defined in RFC 3493 and define its default value to be 1 for narrower scopes. > implementation sounds suspect, and I'm with Jen in wondering why a > router forwarded the packet in the first place. It's not surprising to me since the source address is not needed as long as routing decision is only made based on the destination address. I noticed one popular router vendor didn't implement this restriction of RFC 4007 correctly many years ago and even reported it to the vendor, but (assuming it's still not fixed) just being "non compliant" is probably not convincing enough for them to introduce additional overhead in their forwarding logic. -- JINMEI, Tatuya _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
