I'm thinking of using (link-local) addresses on OSPF transit links for increased security together with prefix-supression. This way the links are not reachable from any other non directly connected subnet. Do you see any problems with this?

2 Answers 2


This network is designed for local links. You will need to take steps to make sure that OSPF doesn't include these addresses in what it advertises to other routers.

Also, "The 169.254/16 address prefix MUST NOT be subnetted". This means that only one interface in this range per router since the router will complain that this network is already in use when you try to add it to another interface.

See RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses


Technical side was already discussed, let's observe the question from a conceptual perspective: what you propose seems to be "security by obscurity" and thus can not be recommended. Generally in the IT, but especially in the security area, the so-called 'best practices' play super important role; personally I, for example, haven't heard of using APIPA addresses as a (well-known and widely accepted) security measure. So explore the best practices for your particular task (they definitely exist) and adhere to them. As you haven't given the details of your task, it's difficult to provide concrete recommendations; for example, it's possible to employ IPsec to encrypt OSPF communications.

  • The purpose was not to secure OSPF, but to avoid any remote IP communication to the transit links i.e port scanning of the routers. That said it still does not make it completely secure. Just one extra step. With IPv6 you use link-local addressing on transit-link which make it impossible to reach them remotely, my idea was to do something simliar with IPv4. I'm using RFC 1918 addresses on the transit links today with prefix-supression so they are still not routed/accessible.
    – user20131
    Nov 3, 2015 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.