[IPv6]Re: Fe80::/10 sources

[Mark Smith <[e-mail]>]

Hi,

On Wed, 9 Apr 2025, 13:10 David Farmer, <[e-mail]> wrote:

> UOn Tue, Apr 8, 2025 at 18:11 Mark Smith <[e-mail]> wrote:
>
>>
>> On Wed, 9 Apr 2025, 08:18 Jared Mauch, <[e-mail]> wrote:
>>
>>> On Tue, Apr 08, 2025 at 08:39:47PM +0200, Ted Lemon wrote:
>>> >    That’s a bug in the mdns implementation. It should be fixed rather
>>> than
>>> >    worked around.
>>> >    But I do agree that generally blocking packets with bogus source
>>> addresses
>>> >    at the router is better than requiring hosts to do the right thing,
>>> not
>>> >    because we shouldn’t but because hosts get hacked, sometimes en
>>> masse, and
>>> >    so the routers still have to do the right thing. In which case
>>> having
>>> >    hosts do the wrong thing actually is good because it exercises
>>> this.
>>>
>>>         Not arguging with your scenario at all, but should hosts send
>>> traffic out with LL source and HOP_LIMIT NOT IN (1,255)?
>>
>>
>> If the HL is set to 1, and a router receives it, per RFC8200 the router
>> will then drop the packet after decrementing the HL to zero. The router
>> will then generate an ICMPv6 Time Exceeded Message.
>>
>
> What about a compromise, setting HL = 2? If the host forwards the packet
> to the router, the router can send it back to the local interface if
> appropriate. But if it forwards it onto another router, inappropriately, it
> will have HL = 1 and the next router will decrement to HL = 0 and drop the
> packet.
>

That router won't just drop the packet, it will also generate an ICMPv6
Packet Too Big message, destined to the LLA DA that is unreachable, so the
PTB will never be reach the node that sent the LLA SA packet that triggered
it, because the LLA is one hop away in the reverse direction.

Each of those ICMPv6 PTBs is control plane load. With enough of these
packets that could have a control plane processing impact.

Another issue is that ICMPv6 is rate limited. These LLA SA packets that are
generating PTBs on the 2nd hop upstream router could exceed the ICMPv6 rate
limit, and that could mean either no ICMPv6 messages from that router, or
no ICMPV6 PTBs where those PTBs would reach the node that triggered them
(i.e. GUA or ULA SA trigger packets).

Are these LLS SA packets really that much of an issue? They've come up
before on the mailing lists, perhaps about 10 years ago. I've seen them in
production about 5 years ago.


Regards,
Mark.




> Not a perfect solution, but at least it contains how far the forwarded
> Link-Local packet gets, even if the routers don't implement RFC4291,
> section 2.5.6 correctly.
>
> Can we work with that?
>
> Thanks
>
> The HL 255 trick only works if the receiving node checks for a HL of 255.
>> In this situation it would be a router having to check each and every
>> packet it receives for possible forwarding for both an LLA SA and a HL ==
>> 255.
>>
>> I think ingress ACL checking SAs or BCP38 filters is a more effective
>> solution than updating all IPv6 hosts to either HL=1 and HL=255 for this
>> situation.
>>
>> Regards,
>> Mark.
>>
>>
>>   I'm not
>>> convinced the host doesn't have an equal partnership in this ecosystem.
>>>
>>>         There appears to be wrong and bad behavior all over, and this is
>>> one of the threads that I'm pulling on related to the behavior.  To be
>>> clear this is a real observed behavior, not some hypothetical straw-man.
>>>
>>>         - Jared
>>
>>
>>>
>>> --
>>> Jared Mauch  | pgp key available via finger from [e-mail]
>>> clue++;      | http://puck.nether.net/~jared/  My statements are only
>>> mine.
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>>> --------------------------------------------------------------------
>>>
>>