But still, /31 is useful to have to use on a PtP link to conserve IP addresses in the IP space.
/31 actually works on Mikrotik if the Mikrotik is the odd-numbered host.
I tested it in RoS v6.28 with a Cisco router as the even-numbered host, and it works great. OSPF forms adjacency just as it should.
If the Mikrotik is the "network" end, though, it does't work. For that end, you can use /32 as the local address, and set a static route /31 with gateway=etherX interface to put the route into the table. (it won't enter OSPF properly this way, of course)
The actual reason I replied, though, is because there's a way that gives double this amount of IP savings for customer attachment circuit assignments.
1: Black hole route some master network prefix, e.g. 192.0.2.0/24 --> black hole
2: Put 192.0.2.1/32 and 192.0.2.255/32 as IP addresses on a "loopback" bridge interface on ALL routers.
3: Set arp-type=proxy-arp on all interfaces that should participate in this /24.
4: Use normal /30 addresses on active OSPF interfaces - private IP if you want to really squeeze things.
5: For each connected customer, create a /32 route with gateway=etherX interface (or vlanX - whatever interface is the customer's unique interface) and pref-source=192.0.2.1
Note that each router has an anycasted copy of the .1 and .255 addresses, so "broadcast" traffic doesn't get shot all over your network, and pings to the default GW by your customers will be answered by their actual default GW router.
*EDIT:
The above works, but Mikrotik has a slightly simpler way to achieve the same thing. Instead of a black hole route for 192.0.2.1/32, you assign each customer's interface IP as 192.0.2.1/32 and set network=192.0.2.X (where X is the customer's single IP). You do not need the /32 static route with gateway=etherX/vlanX. This /32 IP address method will create a normal "connected" route for the customer's /32 address automatically, and OSPF will detect it as a natural route, thus it won't need to be redistributed into OSPF. You still need to have arp=proxy-arp so that the customer can communicate with the other members of the /24 block.
We called this solution "secret sauce" at the job where I implemented this, and it has many benefits:
It creates no additional entries in the route table as compared with a /31 scheme - but it lets you pack a whopping 253 customers per /24.
Each customer is on their own private layer2 broadcast domain, so there's no way for the customers to attack each other's WAN interfaces with broadcast things like netcut, rogue dhcp, rogue RA (ipv6 equivalent), etc. In fact, IPv6 can be assigned with whatever mechanism you choose to use (/127, /64, link-local-only, etc)
You can assign addresses from this range on any router you choose. (although, keeping them in aggregated clumps is smart for many reasons)
The customer cannot arbitrarily configure any address from the /24 - only the one you created the /32 route for will work.
If the customer wants additional IP addresses, you can route them exactly as many as needed without wasting any on subnets. (add additional IPs to the circuit with more /32 routes to the interface or else route additional addresses using the existing /32 as the next hop)
Now the only wasted address space on P2P links is on your own infrastructure's core links - and there are vastly fewer of these so the lack of /31 shouldn't hurt so much if you use "secret sauce" on your attachment circuits.