This section is about assigning addreses, including:

Perhaps quite similar in nature to these things would be how a host finds the router to use, although that is covered in more detail by the section on traffic routing.

Some pages which may be similar in nature are seeing who is using a public network address (including details about how some large public address ranges have been allocated) and network documentation. (Although network documentation is not public, such documentation is mentioned anyway because of a high likelihood that such documentation exists and may have more details about a network, and so may be a resource which is likely to be helpful for technicians who work on a network.) Determining addresses at different networking layers discusses ARP and similar/related.

Plans/Methods for addressing

Before assigning addresses, it naturally makes sense to determine what addresses will be used to assign. Certainly some consideration is provided for making sure that devices are within the desired subnets. However, what about the subnets themselves? All too often the general advice given is to simply use sections of private addressing, starting from the beginning, and so many technicians may not even be familiar with other techniques. However, are there better ways?

This is simply some generalized advice about choosing addresses that may then be used for assigning (whether that assigning is done rather manually or whether it is done through automatic protocols). This advice does not strictly need to be followed just to have a working network, although there may be some advantages to following the provided guidelines. It is certainly possible that someone who does not follow these guidelines may end up, correctly or accidentally, creating a network which works just fine. However, in the case of accidental luck, chances are there may be some problems down the road, such as wanting to expand with a smaller chance of needing to perform renumbering.

Things to be aware of regarding link-local addresses

The usefulness of link-local addresses is quite different when comparing most common IPv6 link-local addresses to most common IPv4 addresses. However, before getting into many of those differences, here is some information about address ranges, followed by some some characteristics which are the same for both types of link-local addresses.

IPv6's range for Unique Local Unicast Addresses are addresses in the fe80::/10 range. For IPv4, the range is most of the IPv4 169.254/16 address range.

Realize that some automatically assigned addresses, ones that use either the unique local IPv6 Unicast Addresses from the fe80::/16 range, or IPv4 Link-Local” addresses from the 169.254/16 range, are addresses that may be assigned using a value which is not easy to manually determine. (The difficulty in manually determining the value may be because some randomness is used, or the value assignment may involve using the current time and using precision that is notably more exact than a second. For example, the example algorithm from RFC 4193 section 3.2.2 uses the current time when an address is assigned. That time may differ each time the network card is automatically assigned its address.) (There may be some ways to determine such an address.)
[#lnlcltmp]: Temporary

(At least some of this text may also apply to types of temporary addresses other than just link-local addresses. Such text may be moved to section where long term addresses are set.) This hyperlink anchor may itself be temporary?

Even though automatically assigned link-local addresses may appear to be valid, it should be remembered that (at least with some popoular protocols) such an address may be different in the future, especially after the system reboots. Therefore, such addresses should not be relied upon long term. Documenting them for long term usage may not be sensible.

However, if temporary short term addresses are known, they may be useful in the short term and their use may provide some long term benefit. For example, if remote access can be set up quickly (or if remote access is already set up), then such temporary addresses may be effectively (temporarily) used with remote access software. The short term ability, to use remote access with the specific temporary address, may be usable to change the network address that will be used long term.

If the plan is to use a short term, temporary address for some length of time, just remember that automatically assigned addresses may get changed when an automatic addressing protocol refreshes the (leased/assigned) addresses. Therefore, if there is not yet a known long term address set up, then setting up a known long term address fairly quickly is recommended.

As an example, the minimum lease time of one hour for DHCP was stated by the last sentence of the first paragraph of RFC 1541 (Older DHCP(v4) RFC) section 3.3 (“Interpretation and representation of time values”). This minimum is no longer considered a requirement by implementations adhering to the newer RFC 2131: DHCP(v4). Still, even if it is not a requirement, it may still be a good idea. For production systems, MS KB 301309 (formerly at ) recommends lease times be at least an hour.

Clearly, a more desirable address to use will be an address that may be relied on to allow long term accessibility to the system. Hopefully the remaining lease time used is enough time to get remote access set up, and to use that remote access to assign an address that will be used in the longer term. If the currently used address expires before that is done, a new address may be assigned and may need to be obtained for remote acess to be usable.

In many cases, getting the new address again isn't enough of a waste of time to be critical to avoid. Likewise, racing the expiration time of the lease is generally not worth having a lot of stress over. However, getting a new address is work that may be avoidable by getting the address assignment task done somewhat quickly-ish. Completing that task soon may be worth delaying other activities (including taking a lengthy break or downloading unneeded software).


Realize that such addresses will not typically be easily used to communicate with devices on a different subnet/network. (Although perhaps routing could be forced upon such traffic, by using some fancy method involving NAT, such a technique might be difficult to implement. It may be even more difficult or even impossible to implement such a solution while following recommended standards. It is likely to be easier, simpler, saner, and possibly even faster to just set things up correctly, in a way that will work well in the long term, than to try to quickly implement a short term solution involving such a technique.)

The long term solution is to eventually, perhaps through automated means, set up a different address which is routable. In the meantime, communications (and programs, like remote access solutions, that use such communications) may still effectively work from other machines which are on the same “subnet”. (Determining whether a machine is on the same “subnet” may involve using a standard comparison that involves checking the network prefix length.) Such communications (and the programs using those communications) may work even before other features, like traffic routing/forwarding/tunnelling, are enabled.

The features of an address being stable (rather than temporary), able to be easily predicted (perhaps based on knowing what it was set to before), and being routable are all features that, in the long term, will be desirable. The ideal plan is not to be without those features forever. They may not be required for remote access, though, and so they may be able to be handled after remote access is set up. (Therefore, those features may even be able to be added by using remote access to set up those features.)

Uselessness of IPv4 automatic link-local addresses

Although IPv6 link-local addresses (from the fe80::/16 range) may regularly provide limited benefit to the goal of convenient access, in contrast, IPv4 link-local addresses, in the range of 169.254/16, are even less likely to be useful. (These IPv4 addresses may commonly get assigned by a process described by RFC 3927 or by specific implementations such as Microsoft's APIPA). Both those IPv6 link-local addresses and IPv4 link-local addresses have the limitations from the issue of being non-routable and the issue of the high possibility/likelihood/certainty of the assignment of any such address being very temporary in nature. The reason why the IPv4 addresses are less useful is that, in addition to the those issues, chances are (with IPv4) that the neighboring device(s) with working networking will not have address within the same range. (This is not nearly so true for addresses in the similar IPv6 fe80::/16 range since the neighboring device is required to have such an address in order to be compliant with the IPv6 standard, as noted by section 2.8 of RFC 4291.)

In theory, an option to work around this problem would be to add such an address to a neighboring device. Although that should technically work (and so could be theoretically useful when things aren't working easily), that will still require manually adjusting a machine. However, the approach is generally not recommended as a preferred way to resolve communication difficulties involving a machine's link-local address. Taking that approach would involve adjusting other machines on the network, which may take about the same amount of time as just finding and assigning a more routable address to any machine which may have a link-local address assigned. The exception may be when usage of an automatic addressing service needs to be troubleshot: that may take more time immediately. However, that troubleshooting will likely need to be done at some time anyway (and quite likely that time will be in the very near future), so it is usually worthwhile to just get the troubleshooting over with. With no time savings behind temporarily using a 169.254/16 address, there is little reason left to try to proceed with the usage of such an address.

This isn't to say that such addresses are completely useless. For instance, a mobile computer may connect to another network device (perhaps located in a hotel) and both devices could communicate fine using 169.254/16 addresses. If this mobile computer and the other device are not particularly likely to ever need to communicate with each other again, such an address may work just fine despite being both temporary and non-routable. However, in general, such addresses are not likely worth trying to use (even temporarily) for setting up a remote access method. Instead, it is recommended to set up a good remote access configuration that can be used in the long term, and to have such a positive configuration be set up sooner.

Subnet sizes
Point to point links
IPv4 point to point links

For point to point links, most official documentation will suggest using a /30 for more standards-compliant compatibility. There is a “Standards Track” RFC, RFC 3021, which discusses using /31 instead of /30. In light of that, using /31 might not be considered “wrong”. (If there were major problems with the technique, chances would be high that's page for RFC 3021 would show that RFC 3021 is obsoleted or at least that erratta for RFC 3021 exists, and both are just not the case.)

Having said that, it should be noted that using a /31 may be far less common than using the more wasteful /30 size. A /30 is more likely to be accepted by more professionals in the field, and may be a more accepted answer that would be useful for use by students and other test takers. (Unfortunately, what this is saying is that some academic and similar tests might treat /31 as useless, with such an address block being used up by a network ID and a broadcast address. Such a test might be trying to ensure that the test taker is knowledgable about /31 addresses not being useful, and so might consider any use of /31 to be invalid and wrong, even if an RFC standard documents usability of such a block. Therefore, sadly, in this case, standard practice may not match what is officially documented in the RFCs.)

IPv6 point to point links

These are discussed by RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful. As implied by this title, there isn't a lot of support for trying to use such a long prefix length.

Other subnets

Information about subnetting should be available on the page about Basics page and/or routing traffic. (There might not currently be any such info there, but there should be sometime... soon/soonish?)

Often, a /24 is fairly simple to work with, due in large part to the dotted quad notation of IPv4 addresses.

Duplicate address detection (“DAD”)/Address Conflict Detection (“ACD”)
Duplicate Address Detection (“DAD”) in IPv6
Perhaps the most well known standard related to DAD in IPv6 is RFC 4862: “IPv6 Stateless Address Autoconfiguration”, section 5.4: “Duplicate Address Detection (and similarly, RFC 2462 section 5.4). This may be covered more in the section about SLAAC: see a tad bit of info on intro to IPv6 automatic addressing technologies, and SLAAC. There is also an RFC 4429: “Optimistic Duplicate Address Detection (DAD) for IPv6.
Address Conflict Detection in IPv4
RFC 5227: IPv4 Address Conflict Detection covers this concept when doing more than just dynamic link-local addresses. Section 2.4 of RFC 5227 is a bit of an expansion on the techniques documented by RFC 3927: “Dynamic Configuration of IPv4 Link-Local Addresses”, Section 2.5: “Conflict Detection and Defense”. That RFC 3927 section 2.5 provided some earlier guidelines when using Link-Local addresses. In both RFCs, the guidelines involve network hosts noticing when an ARP packet uses the same logical network (IPv4) address, but using a different physical MAC address.
[#ip4adyrn]: Some general guidelines on selecting private address ranges
[#cmnpvadr]: Do not start off by using: 192.168.0/24, 192.168.1/24, etc., 192.168.168/24
Reason number one: High usage
Reason number two: consider another way
[#coun1219]: An alternate way of counting (using RFC 1219's guidelines)
The numeric patterns
Info includes a reference to Charts of the third octet of a /16, using RFC 1219.
Comparing this method to sequential counting
Use addresses from many large subnets
[#ip6adyrn]: Advice about IPv6 addresses
See: Advice about IPv6 addresses
[#sysadrus]: Usage of addresses for individual services/NICs/computers/systems

Discusses some implementations on how addresses may be allocated to individual services and/or NICs (or, commonly a computer system that has such a NIC and is known to be running a specific service).

Information about what addresses to assign to individual computers is described more by system address usage. That section provides examples of how addresses may be assigned. (Information on how to assign the already-chosen addresses may be found in the automatic addressing section and/or the manual network addressing section.)

[#autoaddr]: Automatic Addressing
[#knwusdad]: Determining a useful address that the machine may currently be used automatically on system startup

When a machine is started up, it may or may not be set to respond to a specific IP address. It is often ideal for a new system that is set up to automatically assign some valid IP addresses to its local network interface(s). Super-ideally, these will be known addresses. Before looking at how to set the IP address after the system is started and operational, it makes sense to know how preparation made in advance might affect what gets automatically assigned later.

If the machine has a known network address, or if the machine is known to not be listening on a network address, then this section will not be of significant use. However, in some cases it may be useful to identify the network address of the remote machine, perhaps so that remote access can be used to re-configure the device's network communications.

Often, the easy way is to use the device and check what network address(es) are in use from the local console. An interface for manually setting a network address will often allow the current address to be seen without finalizing any changes to the network address. (For a command line program, this may simply involve using the same program with different command line parameters.)

However, if a device is set to automatically determine its address, there are some various methods that may be able to determine what that address is. These could possibly prevent a need to log into the machine to manually check the address. Therefore, these steps might preventing the need to locally access the machine's standard video output display. Here are some methods to determine what the automatically-assinged IP address is, or is likely to be:

  • The most definitive of usual/common methods is to configure the automatic addressing server to hand out a specific address whenever the server receives a request from client that is using a specific, known, recognized hardware (EUI-48/MAC/EHA/BIA) address. (If there are mutiple automatic addressing servers, additional servers may also need to be configured.) After the client machine seeks an address, then the address ought to be what is set to be delivered by the automatic addressing server(s). Since client machines tend to seek an address during a startup procedure, this action may be induced by rebooting the client machine.
  • Some automatic addressing servers may be known to hand out a specific address. For example, software that implements a virtual machine may have a built-in server for automatic addressing, and the documentation for that virtual machine software might specify exactly what address is handed out. (Such software may be relatively easy to re-configure so that a different address is handed out.)
  • If the automatic addressing server is expected to hand out an IPv4 range, automatic addressing servers usually start out by handing out the first unreserved, available address. Looking at the current leases might provide some clues as to the address handed out:
    • If there aren't any current leases, the first address in the range may be the one used. If the address is believed to be handed out, use the highest numbered lease (or the highest number before each gap).
    • If the address hasn't been handed out, the address is likely to be the first number after the very last address that is handled out, or perhaps the first number after the start of a gap (or another number in a gap).
    Trying just one address, or a few addresses, by using this method may be be less likely to set off less intrustion detection systems than the likelihood of that happening with a full-blown network scan of a wider range of IP addresses.
  • Monitoring traffic may be an additional method. The best type of traffic to look for, which a machine is most likely to use when the machine is starting up, will be an automatic addressing request. As automatic “service discovery” technologies increase in adoption, that type of behavior may also be a type of traffic to commonly occur. If there aren't many automatic address requests occurring, simply looking for any automatic address request may reveal just one result. Hopefully there will be just one result which isn't identifiable as belong to a different machine, and in that case the one result is likely to be the one of current interest.

If none of the above methods seem feasible for a remote machine, manually accessing the machine's local display may be needed to obtain an initial address. (For a virtual machine, there may be some required steps to view the virtual machine's local display: see Instructions on how to perform the viewing of the virtual machine's local video display on an as-needed basis). Once the local system is used, check what network address(es) are in use and, as needed, manual assignment of network addresses. (However, some time may be gained by delaying any manual assignment of network addresses until some of the upcoming preperatory information is presented.)

(Move this to the remote access section? In some cases, setting up a working remote access solution may break an existing remote access method. For example, setting up a new network address may, at least when doing things simply, make the old address stop working. This may be okay if the new remote access method is preferable. Different methods of remotely accessing a machine may have different amounts of ease of use. For example, some methods may not have a UI that is as easy to perform some tasks, such as integrating with a remote system's clipboard for easy copy and paste operations. Often the simple solution to such inferior remote access methods is often not to improve the inferior methods, but rather to just completely replace them with other remote access methods which do provide such nice features.

[#ip6autad]: Automatic IPv6 network addressing
[#ip4autad]: Automatic IPv4 network addressing
[#dhcp]: Dynamic Host Control Protocol (“DCHP”)
(This info should be expanded on, or, more likely, moved to a sub-page: Win Svr 2008 R2's DHCP server checking if a domain controller lists authorized DHCP servers discusses Win Svr 2008 R2's DHCP server as using a known domain controller, searching for one if needed, and checking if the DHCP server is authorized before it starts running.
[#ip4lnklc]: Using IPv4 link-local addresses
Perhaps see: Wikipedia's page on Zero configuration networking: section on Link-local IPv4 addresses. If there is an interest in using these non-routable addresses, perhaps see: LLMNR which relies on multicast instead of routing.
ICMP router discovery messages
This uses ICMP discovery messages called “Router Advertisements” and “Router Solicitations”. Essentially, the IPv4 version of this, documented by RFC 1256, is equivilent to IPv6 protocol(s) SLAAC (and/or NDP).
[#manetady]: Manual Network Addressing

This is depending on a networking implementation, so largely this ends up being dependant on the operating environment/system being used.

Network Documentation has some tips/examples of network documentation which may be followed when creating many of the entries.

Wikipedia's article on NSAP addresses may describe another alternative.