daemon.notice pppd[29635]: local LL address fe80::b871:3c4c:cf45:1624
daemon.notice pppd[29635]: remote LL address fe80::3cab:1ef3:2158:3be0
The local link address of pppoe interface changes when connect it.
Not all the 64 bits are randomized, but the middle 16 bits. The others are similar to the Ethernet MAC address.
Can I make it fixed?
As far as I know it is random.
What issue is it causing you and you want to make it fixed?
You can configure local and remote interface identifiers, but as usual with ppp it's a negotiation thing so the peer might reject your choices.
Try 'pppd_options "ipv6 ::a,::b"' and see if it works.
Stable interface identifiers are sometimes necessary with DHCPv6 over ppp in my experience. You don't want a new lease just because the ppp link went down and came up with a new ll address.
It doesn't work. If I set ipv6 ::a,::b,I can not get IPv6 address, it seems that my ISP's remote LL address denied. If I set ipv6 ::a,::3be0, my local LL address still changes.
My ISP assigns fixed prefix, but I can not get fixed ipv6 address because of local LL address change.
Mine as well, but binds it to DUID rather than link local address.
Try not to pass the peer IPv6, meaning leave the peer empty.
https://ppp.samba.org/pppd.html
ipv6 <local_interface_identifier> , <remote_interface_identifier>
Set the local and/or remote 64-bit interface identifier. Either one may be omitted. The identifier must be specified in standard ascii notation of IPv6 addresses (e.g. ::dead:beef). If the ipv6cp-use-ipaddr option is given, the local identifier is the local IPv4 address (see above). On systems which supports a unique persistent id, such as EUI-48 derived from the Ethernet MAC address, ipv6cp-use-persistent option can be used to replace the ipv6 , option. Otherwise the identifier is randomized.
What do you mean by 'leave the peer empty'?
I also find that not all the 64bits are randomized, only the middle 16bits are randomized, the others are similar to the Ethernet MAC address.
Leave nothing behind the comma. For example "ipv6 ::a,". This will let you accept any peer interface identifier and still set your own.
Yes, that's the sane thing to do.
My experience was a while ago using a Juniper ERX both as PPP access server and DHCPv6 server on the ISP side. The prefix came from RADIUS and was bound to the PPP username, but the DHCPv6 server would still cache leases based on both DUID and peer LL address. So the DHCPv6 server considered the prefix in use when the same username connected with a new LL address, and refused to reassign the prefix to the "new" client. the Assigning a fixed interface ID (also in the RADIUS account) to each user fixed this.
FWIW our IPv6 over PPP experiment was never put into production. We eventually ended up with DHCPv6 over ethernet and no PPP. And the ERXes have been replaced by Juniper MXes a long time ago...
All this is pretty off topic here, though 
It still changes.
So the problem is, the pppd doesn't use the standard method, insert fffe in the middle, to generate the interface identifier.
The interface identifier is negotiated as part of IPV6CP. The only real restriction is that it is unique on the link, which is pretty easy to comply with given 2 nodes and 64 bits. Just selecting a random number with the global bit unset should be fine.
PPP isn't ethernet, even when it's PPPoE like in this case. You could argue that an EUI-48 based identifier still should have the highest preference according to https://tools.ietf.org/html/rfc5072#section-4.1 But https://tools.ietf.org/html/rfc8064 changed that into
By default, nodes SHOULD NOT employ IPv6 address generation schemes
that embed a stable link-layer address in the IID.
So I believe a random IID is correct, unless configured otherwise.
You could try the stable-privacy method according to https://tools.ietf.org/html/rfc7217 But I've never tested that with PPP, and don't know how to configure it in OpenWrt. The kernel feature is documented in https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt (see stable_secret).