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

[Brian E Carpenter <[e-mail]>]

On 08/11/2013 07:56, Fred Baker (fred) wrote:
> On Nov 7, 2013, at 10:42 AM, 神明達哉 <[e-mail]>
>  wrote:
> 
>> At Thu, 7 Nov 2013 17:58:56 +0100,
>> Jen Linkova <[e-mail]> wrote:
>>
>>> Looks like we (finally) have a chance to enforce the requirement from
>>> RFC4007, Section9:
>>>
>>> "If transmitting the packet on the chosen next-hop interface
>>> would cause the packet to leave the zone of the source
>>> address, i.e.,
>>> cross a zone boundary of the scope of the
>>> source address, then the packet is discarded. "
>>>
>>> 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 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 implementation sounds suspect, and I'm with Jen in wondering why a router forwarded the packet in the first place.

Are you sure these packets come from hosts? There is a known case
which is a router generating ICMP reply packets that has no GUA
configured since all its peers are link-local.

   Brian