OSDev.org

Hi all,

I'm working on the network stack and I'm currently figuring out what approach to take in configuring IP addresses. I want to use as little user input as possible, mostly because it shouldn't be necessary for a user to tell me what to do, it should be automatically working.

The idea is to use DHCP when available and a link-local zeroconf when it's not available. The point is that I want it to work as soon as possible after booting, so before the DHCP times out. Typically though, you should have a DHCP address and would prefer to wait the one-two second it takes to get it.

What kind of approach do you think is best for acquiring an IP address and configuration on a network?

With networking not being guaranteed to be available in the first place, it makes no sense to wait with doing the things you would do regardless of having a network connection - like starting the user interface. Things that actually need an internet connection can simply listen to link up/down events and do what they need afterwards.

Also note that, while DCHP is convenient, in some situation the user might want to manually set the network info (I agree they should properly configure dhcp server in any case, but you may really want manual address in rare situation like direct linking two computer).

Zeroconf is good for service discovery and already quite standard.

Hi,

bluemoon wrote:Also note that, while DCHP is convenient, in some situation the user might want to manually set the network info (I agree they should properly configure dhcp server in any case, but you may really want manual address in rare situation like direct linking two computer).

Yes - especially if the computer being booted is the DHCP server.

bluemoon wrote:Zeroconf is good for service discovery and already quite standard.

I don't really understand how zeroconf is useful to begin with. Without things like netmask and gateway IP you'd only be able to communicate with things on the same sub-net; and for that purpose other protocols (e.g. IPX) are simpler and have lower overhead.


Cheers,

Brendan

Brendan wrote:

bluemoon wrote:Zeroconf is good for service discovery and already quite standard.

I don't really understand how zeroconf is useful to begin with. Without things like netmask and gateway IP you'd only be able to communicate with things on the same sub-net; and for that purpose other protocols (e.g. IPX) are simpler and have lower overhead.

I presume you're confusing Zeroconf IP adresses (The 169. things) with Zeroconf/Bonjour/Multicast DNS, the protocol for doing local network name resolution.

Regardless, the benefit of both is that they enable configurationless device to device communication across the local subnet, without having to additionally implement support for an additional legacy protocol (such as the aforementioned IPX) to both the system and every application.

Brendan wrote:I don't really understand how zeroconf is useful to begin with. Without things like netmask and gateway IP you'd only be able to communicate with things on the same sub-net; and for that purpose other protocols (e.g. IPX) are simpler and have lower overhead.

But IPX is an additional protocol to implement and use for everybody, while you could do the same thing with TCP/IP using zeroconf and much less code.

More on zeroconf, as with other "configure-less" protocol like uPnP, it provide convenience and powerful tool for both end-user and developer. However, it is too powerful that without proper configuration (by design!) on most system it impose security issue, then end up disabling all things (I do that for uPnP).

It's a tricky trade between convenience and security.

UPnP, bonjour, DLNA and the whole shebang is that sort of thing that security-minded operators consistently turn off entirely, while uneducated users get the full package of insecurities - there's hardly a middle ground which means that all those kinds of things don't get the attention and safety prescriptions they deserve.

The spambot fridge is an excellent demonstration of why this sort of stuff can go horribly wrong - and already does on a small scale.

Combuster wrote:UPnP, bonjour, DLNA and the whole shebang is that sort of thing that security-minded operators consistently turn off entirely, while uneducated users get the full package of insecurities - there's hardly a middle ground which means that all those kinds of things don't get the attention and safety prescriptions they deserve.

The spambot fridge is an excellent demonstration of why this sort of stuff can go horribly wrong - and already does on a small scale.

UPNP/DLNA is a whole package of protocols, and yes, some of them can cause security issues (e.g. the NAT punchthrough UPNP protocol). Unfortunately, A, UPNP is a horrendous spec full of lots of overcomplicated protocols (would you expect anything else from Microsoft), and B, there are a lot of different protocols here which far too often get lumped together under one umbrella term and checkbox

Bonjour/Zeroconf is a friendly name for combining Multicast DNS (MDNS) and DNS Service Discovery (DNS-SD). An example of this is that I can SSH to my server without needing to know its' IP by just doing "ssh shinji.local" - the OS knows to resolve .local using MDNS, and the server advertises itself using said protocol.

As a further example - on my MacBook, I can go to System Preferences -> Sharing -> Printer Sharing and turn it on. The preferences pane will prod the CUPS daemon, which will then enable sharing and advertise itself over MDNS using DNS-SD. It will advertise an "_ipp._tcp" SRV record to the network; the CUPS daemons on other machines (and Apple's Zeroconf client for Windows) will pick up this advertisement to automatically discover local network printers.

The protocol you might be concerned about with Zeroconf is PCP - the Port Control Protocol. On the one hand, enabling random apps to punch holes through your NAT device is somewhat concerning. On the other, in the IPv6 future there is no NAT. The concerning bit, as far as I'm concerned, isn't so much the ability as the fact that your router can't pop up a dialog box asking if the application had your permission

Combuster wrote:The spambot fridge is an excellent demonstration of why this sort of stuff can go horribly wrong - and already does on a small scale.

I'm a bit confused. This to me sounds like you blaming the front door lock manufacturer when there's a criminal in your house that goes outside. Can you elaborate?

More like something in the grey area between trojan horses and regular exploits. Just simply the fact of having all sorts of things accessible by default can get an uninformed user into trouble.

I've got a bit further now and I'm trying to figure out how to combine multiple network cards with configuration. What should happen if you have two network cards on which you receive a valid DHCP offer / ack , including DNS servers and the lot?

Candy wrote:I've got a bit further now and I'm trying to figure out how to combine multiple network cards with configuration. What should happen if you have two network cards on which you receive a valid DHCP offer / ack , including DNS servers and the lot?

1) If the subnets are exclusive, you have 2 networks, send packets accordingly for "intranet", and pick a default for "internet"
2) If the subnets overlap, pick a default for the overlap, see 1
3) If the subnets are identical, pick a default, and the second card is a failover.

NOTE: If 2 cards receive "identical" info as to their ip and subnets but are actually different networks, the user messed up as far as I am concerned. (I literally can not think of a valid reason to do that.)

- Monk

tjmonk15 wrote: 3) If the subnets are identical, pick a default, and the second card is a failover.

Or, you can load-balance the two cards and use both for improved performance!

tjmonk15 wrote:1) If the subnets are exclusive, you have 2 networks, send packets accordingly for "intranet", and pick a default for "internet"
2) If the subnets overlap, pick a default for the overlap, see 1
3) If the subnets are identical, pick a default, and the second card is a failover.

NOTE: If 2 cards receive "identical" info as to their ip and subnets but are actually different networks, the user messed up as far as I am concerned. (I literally can not think of a valid reason to do that.)

Yeah... I'm trying to get it working well for logical setups and not fail too badly for bad setups.

This doesn't account for the gateway / dns part of it. What happens if you have two DNS servers and two gateways for "other" traffic? That pretty much implies that the "subnet" is identical; both claim to map the entire internet, so every two cards would boil down to #3.

mallard wrote:Or, you can load-balance the two cards and use both for improved performance!

Not without supporting that at the other end as well; it's called bonding and requires you to set that up on both sides.