When using FRR as Route Server ipv6 next-hop link-local get overwritten with route server link-local address.

[aalmenar]

• FRR VERSION (From Frrouting Debian Repositories)
  8.0.0, 8.0.1, 8.1.0

• OPERATING SYSTEM VERSION
  Debian 10 and Debian 11

• KERNEL VERSION

• 4.19 and 5.10

Describe the bug
When using FRR as a Route Server, with IPv4 everyhing goes smoothly all peers receive as next-hop the one where they should direct their traffic. When using IPv6 the issue arises:

Route Server:

• Link-local: fe80::dc2d:63ff:fe0b:d5eb/64
• Global: 2001:xxx:xxx::f3a8:0:1/48

Peer 1:

• Link-local: fe80::901f:9bff:fe2d:adba/64
• Global: 2001:xxx:xxx::f20a:0:1/48
• Announces: 2axx:3xxx::/32

Peer 2:

• Receives on BGP Update packet 2 addresses:
  Prefix: 2axx:3xxx::/32
  Next-Hop: fe80::dc2d:63ff:fe0b:d5eb (This is the Route Server link local)
  Next-Hop: 2001:xxx:xxx::f20a:0:1 (This is the global from peer 1)

Peer 2 is receiving the wrong link-local next-hop and theres currently no way of overriding this behaviour.

Can be solved partially if peer 2 is a FRRouting and you set a route-map with "set ipv6 next-hop prefer-global", but there are some other equipments that can't make this in their incoming filters.

[x] Did you check if this is a duplicate issue?
[ ] Did you test it on the latest FRRouting/frr master branch?

To Reproduce
Setup a simple route-server and connect two peers.

Expected behavior
To receive the link-local of the real next-hop, not being overwritten by the route server one.

[ton31337]

Fixed in master and backported to 8.x releases.