Re: [v6ops] [homenet] Tsinghua work on source/destination routing

[神明達哉 <[e-mail]>]

At Thu, 7 Nov 2013 18:56:12 +0000,
"Fred Baker (fred)" <[e-mail]> 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