OSDev.org

I was reading up on RFC3927, IP address auto-configuration, as alternative to DHCP. Reading it has given me the idea to use both its link-local IP address and a dhcp-derived address for one link.

Is there a downside to having a link-local fallback by default configured? Is there an upside?

What are you doing for IP configuration options in your OS?

Hmm, I don't think it makes sense to have a link-local address and a DHCP address assigned to the same NIC (apart from in IPv6, of course, but that's different). The point of a link local address is to give a station a "unique-ish" address it can use if it can't obtain an address by other means. I guess the best question to ask would be whether having a link local address assigned would be of any sort of benefit? I'd presume in an environment with DHCP link-local addresses would be useless. Feel free to prove me wrong though!

As for IP configuration in my OS - we currently don't even do auto-configuration to create a link-local address - just DHCP or (unbelievably hacky) static configuration. Every test environment I've worked in with my stack has had a fully functional DHCP server that I've been able to get addresses from.

pcmattman wrote:As for IP configuration in my OS - we currently don't even do auto-configuration to create a link-local address - just DHCP or (unbelievably hacky) static configuration. Every test environment I've worked in with my stack has had a fully functional DHCP server that I've been able to get addresses from.

Same here. I expect anything to have DHCP servers or to not have DHCP servers - in which case I always use a link-local address. I try to make as few configuration-thingies for users as I can and making everything autoconfig is a good thing.

If you get a link-local address DHCP will keep trying to discover on the background to see if there's a dhcp server, so if you don't have a reliable connection it'll still get a good address.

The idea was, if your dhcp server works & then drops out, should you have a preconfigured backup address (so all the local networking keeps working) or not?

berkus wrote:Once you got address from your DHCP server you don't need to contact it again. Given the most common current configuration of DHCP servers you can cache this address and keep it almost forever until DHCP server is back up. Even across sessions.

I've already found out:

- DHCP lease durations vary from place to place. I've seen places with half-hour leases, those with 10 hour leases, a few ISPs and companies with 3 day leases and a few with "until 2038" leases. There's a value for infinity too but they don't appear to use that. You access the DHCP server shortly before your lease would expire for an extension.
- If you do find a collision, there's a way to tell the DHCP server that you've found a collision for that IP and that you'd like a different one. I'm definitely going to implement that too.

If there's no DHCP server 95% of the time there's no point trying to go beyond your local network. If there is one, or there's a new one, you do need to check and/or re-request your lease before you're supposed to use it.

I guess I'll use the ip addresses until the lease expires in that case and then either
- revert to link-local
- use the ip anyway

Probably the second. That means link-local means that there's no dhcp server. Something to tell the user & to keep trying dhcp discovering.

IPv4 link-local just doesn't make sense, AFAIK the only OS actually using it is Windows, personally I'd prefer either dynamic configuration(DHCP) or static-only configuration(Manual).

The OS shouldn't make assumptions about networking, and it definitely shouldn't pretend to configure an address.. for "new users" it only serves to deceive them into believing things were configured properly.

It's nearly as bad as someone joining someones network with an active DHCP daemon/server, it's a sign of misconfiguration and laziness.

Just my not so humble opinion.

What you probably need to clarify (to us, if you already have to yourself) is exactly who your OS is targeting.

The average consumer will have a DHCP server on their network, and have no idea it exists. For these kind of users, "it just works" is enough. Granted, a link-local address means they can't usually access the internet etc, but usually they know enough to switch off the little box the ISP gave them and switch it back on again and "everything works".

Power users probably want to configure a static IP at some point for video gaming or something like that. They may also have a few servers to play with.

Network administrators do everything from configuring DHCP to static IP addresses regularly. They'll also want to configure their servers, and they probably don't want DHCP for that.

Of course, you also need to figure out what'd happen if your OS ended up being the DHCP server

Anyway..

- DHCP lease durations vary from place to place. I've seen places with half-hour leases, those with 10 hour leases, a few ISPs and companies with 3 day leases and a few with "until 2038" leases. There's a value for infinity too but they don't appear to use that. You access the DHCP server shortly before your lease would expire for an extension.
- If you do find a collision, there's a way to tell the DHCP server that you've found a collision for that IP and that you'd like a different one. I'm definitely going to implement that too.

The Windows DHCP server and "dhcp3-server" (debian) both keep track of "assigned" leases and gives that lease back to a machine when it requests an address. It should allocate from the pool before reusing an address in its database of "previous clients". Not that you should depend on that behaviour or anything... but generally stuff like that is done to avoid collisions.

Of course, Windows (and Linux AFAIK) also remembers the last lease address and asks for it again - this is unrelated to the DHCP server's database.

If there's no DHCP server 95% of the time there's no point trying to go beyond your local network. If there is one, or there's a new one, you do need to check and/or re-request your lease before you're supposed to use it.

For the average consumer, that's basically true. Whether this is a valid assumption to make depends on your audience (as above).

Same here. I expect anything to have DHCP servers or to not have DHCP servers - in which case I always use a link-local address. I try to make as few configuration-thingies for users as I can and making everything autoconfig is a good thing.

An optional configuration-thingy to specify a static IP configuration would be a nice feature

The idea was, if your dhcp server works & then drops out, should you have a preconfigured backup address (so all the local networking keeps working) or not?

Windows allows you to set an "alternative configuration" in case for some reason the "primary configuration (dhcp)" fails. Means you can still get connectivity if only the DHCP server is down and stuff like the gateway and DNS severs are up.

I think the hardest thing to do right with this kind of thing is to make an implementation that's "smart enough" to cater for users who don't care, and "complex enough" to cater for users who want to tweak. Balancing smart vs complex can be tough

pcmattman wrote:What you probably need to clarify (to us, if you already have to yourself) is exactly who your OS is targeting.

Basically, my target is the "guy who sits at home with a local network that consists of N machines plain tied together, there's a dhcp on each subnet and all of them go to the internet". IE, regular home networks. Alternative is corporate networks, which I've noticed qualify for the "single-subnet with dhcp and router / gateway for inet access" too. I generalized it to "if you're not that come & complain". Third option I want to support is link-local services (DNS-SD, mDNS). Static IP is out. If you want a static IP address, make a dhcp server tell you about it. No manual gateway or dns config either. Also, "lanning" - connecting computers & expecting exchange is a requirement.

What I want is an OS that is much like Windows, in that it configures your network easily, but with as few settings to **** up as possible. So, if I can make a network config that works for my target (above) without a single setting that's best. The only reason people dislike 169.254 addresses is that most of the time when Windows configured it (like, 99% of the time) it was your DHCP server not working or a faulty cable. So, people associate 169.254.* with "not working". That's plain wrong.

I was thinking of indicating network connectivity in 4 levels:
- 0% full, no connectivity because the cable's unplugged or I haven't found a usable IP yet
- 33% full (red), limited connectivity because I have an ip address but haven't heard *anything* from other machines on the network
- 66% full (yellow), limited connectivity because I can't find a dhcp server, but I can reach other computers
- 100% full (green), full connectivity (have a dhcp ip address & a gateway to access the internet through). No probes are sent to the "internet" to see if it's the internet as we now know; shielded corporate networks and intranets should also show fully green.

That separates the "cable problem" from the "no dhcp server situation" and should make people more confident in that it works. mDNS gives your pc a name instead of a number (and should be the preferred way of accessing your computer - by name).

Power users probably want to configure a static IP at some point for video gaming or something like that. They may also have a few servers to play with.

Network administrators do everything from configuring DHCP to static IP addresses regularly. They'll also want to configure their servers, and they probably don't want DHCP for that.

Not sure why power users or network admins need to configure static IPs.

Of course, you also need to figure out what'd happen if your OS ended up being the DHCP server

I'm not creating a one-size-fits-all OS and I intend it never to be used for a dhcp server location. Not an issue.

The Windows DHCP server and "dhcp3-server" (debian) both keep track of "assigned" leases and gives that lease back to a machine when it requests an address. It should allocate from the pool before reusing an address in its database of "previous clients". Not that you should depend on that behaviour or anything... but generally stuff like that is done to avoid collisions.

Of course, Windows (and Linux AFAIK) also remembers the last lease address and asks for it again - this is unrelated to the DHCP server's database.

They do. The reason I want to extend a lease is to avoid the dodgy-but-still-dhcp-compliant devices. Same reason I trigger about 0.1% or at least 3 minutes before the deadline; desynced clocks will make your lease expire on the dhcp server before you think it does.

An optional configuration-thingy to specify a static IP configuration would be a nice feature

With what goal? For any of my target audience, it's either dhcp or link-local.

I think the hardest thing to do right with this kind of thing is to make an implementation that's "smart enough" to cater for users who don't care, and "complex enough" to cater for users who want to tweak. Balancing smart vs complex can be tough

Tweakers get to tweak their dhcp server. I'm not making a tweaker's OS. There are enough Linuxes out there already.


I have thought of another reason for link-local address beside the global IP. Link-local services should always work as soon as you start up your device. That means you need a link-local IP to talk mDNS and to send stuff to your printer - so it's multihomed. There's no reason to make it not multihomed by the way.

Candy wrote:Not sure why power users or network admins need to configure static IPs.

Because quite often you're on a network connection from someone else and they don't run a DHCP server (i.e. a datacentre)

Candy wrote: They do. The reason I want to extend a lease is to avoid the dodgy-but-still-dhcp-compliant devices. Same reason I trigger about 0.1% or at least 3 minutes before the deadline; desynced clocks will make your lease expire on the dhcp server before you think it does.

What do you do if you get a <3 minute lease?

I have a device here which gives out 10 second leases!

There are most definitely reasons for statically configuring networks, it's quite ignorant to think otherwise, even Windows/OS X, "mainstream" OS's, support this.

Some ISP's "business tiers" and collocation services, as suggested by Owen, require manual configuration.

I'm guessing you won't permit users to change the routing tables either then? honestly, an OS with artificially reduced functionality won't be appealing to anybody.

You really shouldn't prevent the user from making stupid mistakes, just because you believe that's all that they will do.