12

I have a network appliance which contains some load balancing features - in my design, these features are only for use internally within the appliance. Nothing should EVER speak to them externally and, additionally, the client is low on IP addresses in the devices IP range.

Would it be acceptable to use the Link-Local range for these features? For example, 169.254.1.1.

NB: The device in question won't allow loopback IP's to be used for these features.

Improve this question
2
  • 1
    If they are only used to communicate from service to service within the same host, is there any reason you wouldn't use a loopback address?
    – YLearn
    Apr 20, 2015 at 19:05
  • @YLearn To be fair - I don't really have any, though I can't shake the feeling that it's not really what a loopback address is about but maybe I'm wrong? Either way, I went to test it and the appliance won't allow you configure anything on the loopback IP's!
    – Dan
    Apr 20, 2015 at 19:38

3 Answers 3

Reset to default
7

No, RFC3927 prohibits manual assignment of addresses within this block.

You should instead use addresses form the blocks provided by RFC1918, 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16. These addresses may be freely used, provided routes are not advertised to the internet. Remember to select a subnet that is not otherwise in use in your environment.

Improve this answer
2
  • 2
    Since you may not know what subnets are in use in the environment, it's best to make it configurable. He could follow the lead of many home routers: pick a default 192.168.x.0/24 subnet, and allow the administrator to change x. Probably shouldn't default to 0 or 1, since those are the common defaults of routers.
    – Barmar
    Apr 22, 2015 at 15:36
  • Strong language within answers, but people reading spec SHOULD know that SHOULD != MUST. Not saying anything whether it is OK/NOK to use such IPs
    – Janis Veinbergs
    Jul 21, 2022 at 7:07
4

The details of RFC3927 seem to think this is not strictly correct.

Yes, go head. The reasons why this is prohibited aren't going to come into play. It's far better than other common situations, such as commandeering 1.1.1.0/24.

If you want to play nice, you could use either 169.254.0.0/24 or 169.254.255.0/24.

2.1. Link-Local Address Selection

When a host wishes to configure an IPv4 Link-Local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255 inclusive.

The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism.

Improve this answer
4
  • Why would you suggest using the two ranges that IANA has reserved for future use? That seems to be bad advice in case the IANA chooses to make use of those reserved ranges for some reason.
    – YLearn
    Apr 21, 2015 at 7:56
  • @YLearn You are correct, it is a violation of the specification. However, the other option involving these addresses is a clear violation. I feel it's better to take the murkier wrong choice.
    – 84104
    Apr 21, 2015 at 16:02
  • 2
    So, to paraphrase your answer and comment, using the reserved addresses is a violation and using a manual assignment from the generated range is a violation. So then the answer should be "No, this is a bad idea. You need to find a better solution." If people were to just ignore the standards and specifications when they are inconvenienced by them, then the standardization, inter-operation, and the whole foundation of networking/the Internet are all at risk..
    – YLearn
    Apr 21, 2015 at 19:08
  • Agree with @YLearn. Link-Local is for automatic host IP assignment when lacking DHCP, not for manual configuration for specific circumstances. Slicing a chunk out of the RFC1918 ranges (even one not currently in use) would be the only valid option.
    – Ashley
    Apr 21, 2015 at 22:26
3

To answer your question, no you should not. RFC3927 in Section 1.6 prohibits this type of use.

Specifically, the last paragraph of this section says this:

Administrators wishing to configure their own local addresses (using manual configuration, a DHCP server, or any other mechanism not described in this document) should use one of the existing private address prefixes [RFC1918], not the 169.254/16 prefix.

This rules out the whole /16 for this type of use so you need to look into a different alternative.

My first suggestion would be to use a loopback interface. Loopback interfaces are perfect for communication between services within the same host that do not require access outside that host. They are used in this way by a number of services, for management interfaces, testing and other purposes.

You mentioned in your comments/edits that the appliance will not let you do this. You don't mention the vendor/model or code versions, so my first recommendation is that you contact the vendor. If this is truly a valid use of the device, they may be willing to adjust their code to allow the use of a loopback interface; they simply may not have considered this use case when writing code to validate IP addresses. Or they may tell you why this is a bad idea and why it should be done another way.

If a loopback interface is truly out of the question, then you should use RFC1918 address space for this purpose. Make sure you work with any relevant IT staff is selecting the IP range to utilize to avoid any other unforeseen problems on the network.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .