Thank you all for your comments - it appears that there is no consensus
on how this should be done.
Thank you for the reference to this draft, Marco - and to Ron as well.
Both RFC3627 and this draft appears to be stating that these issues a
implementation-specific.
E.g. whether an implementation will perform subnet-router-anycast on a
small subnet, whether Neighbor-Discovery-messages are rate-limited etc.
Does anyone have any information on how different vendors handle this -
even in older software?
/126 appears to be the middle path - which is reserving the
subnet-router-anycast address while keeping the subnet as small as
possible. This appears to address both issues - at least for Ethernet
links.
(one free address will hardly constitute a potential Neighbor Cache
Exhaustion issue).
Best regards,
/Lasse
-----Oprindelig meddelelse-----
The best piece of advice I received when asking similar questions in
the past is to allocate a /64 for every network regardless of it's
potential size. Loopbacks, point-to-point, hosting VLANs etc. Then
assign whatever size you are currently comfortable with.
We've used /128s for loopbacks, safe in the knowledge that we can
expand them all to /64s without renumbering (in case someone comes up
with a good idea why /64s on loopbacks are necessary.)
We've gone unnumbered on point-to-points, as a way of deferring that
particular decision. Admittedly this reduces useful diagnostics
available from traceroutes, although I quite like seeing loopbacks in
traceroutes anyway. Unnumbered does reduce control-plane address space
surface, which might be seen as a useful benefit (I'm sure someone
will tell me why that's a bad idea.)
My point is, if you do your number plan right, you should have some
flexibility to make changes in the future without pain.