OSPFV3 uses IPv6 link local to build adjacencies .
OSPFv3 carries the instance-id inside its packets this makes possible things that were not possible in OSPFv2 for IPv4:
a) you can have the same logical interface running on two different OSPF process-ids using the same area
b) at some point someone realized the potential of the instance id: using the instance-id and having an underlying IPv6 topology "plug and play" OSPFv3 could become multi families like IS-IS. This makes OSPFv3 with AFs interesting for enterprises running dual stack IPv4/IPv6.
instance 0 IPv6 unicast
instance 1-31 other topologies IPv6 unicast
Instance ID zero is already defined by default for the IPv6 unicast
AF. When this specification is used to support multiple AFs, we
define the following ranges for different AFs. The first value of
each range is the default value for the corresponding AF.
Instance ID # 0 - # 31 IPv6 unicast AF
Instance ID # 32 - # 63 IPv6 multicast AF
Instance ID # 64 - # 95 IPv4 unicast AF
Instance ID # 96 - # 127 IPv4 multicast AF
Instance ID # 128 - # 255 Unassigned
OSPFv3 Instance IDs
For all the rest OSPFv3 behaves like OSPFv2 so the generation of LSA type 9 when a virtual link is created is not a surprise it is expected.
What a virtual link is : a tricky way to connect to area 0.0.0.0 a device that is connected to area Y via a different standard area
R4 ----- area 54 must be standard ----- R3 ------ area 0.0.0.0
<-------------VL = p2p unnumbered link -------->
When setting up a VL notice it is down the VL is an unnumbered point to point link to area 0.0.0.0
This way you see why the LSA type 9 is generated the same would happen in OSPFv2 with virtual links.
It was a surprise for me to discover that even with not advertised OSPF RIDs VL could form in OSPF2 IPv4. In an Ask the expect session @Vinit Jain explained us what I have described.
All this is well described in the book by @Peter Palùch CCIE R/S Cisco press vol I
Hope to help
Hope to help