168.x.x.x IP address question

"Coenraad Loubser" wrote in news:cpmq3q$dl4$ snipped-for-privacy@ctb-nnrp2.saix.net:

Thanks for the reply. I have no problem whatsoever, I was just curious! Thanks.

: Is there any reason that the default Windows IP when I can't connect to my : router is 168.x.x.x? Is this a perfectly usable Class B IP address set, ie : could I set a router with DHCP to use, say, 168.168.1.x as its addresses to : assign and still have a perfectly usable network?

Hi,

There is nothing wrong with that IP address, unless you got a public IP from the same "class". Then you'll not be able to connect to that host, as routing for this class is set for you private network. So it's better to use class C 192.168.1.0/24 I guess..

Martin

When a DHCP server does not respond, the DHCP client picks a random ip in the 169.254.x.x / mask 255.255.0.0 range.

You can tell your DHCP server to use any IP addresses and range, I think. Except special addresses like 0.0.0.0 and 255.255.255.255 and 224.????????

What is your real problem?

Do you have connectivity/ Can you ping the machine/router/modem with the dhcp server on, from a dhcp client on it

Even with DHCP enabled you can still manually override client IP addresses and be connected. This presents a problem when the DHCP server then tries to assign that IP to a newly connected client

Unless it's a 'smart' DHCP server...

A 168. number is unusual. If it's actually a 169.254.xxx.yyy number, this is a standard Windows "auto-configuration" range address, which is used if Windows is set for DHCP but can't locate a DHCP server. Apparently, MacOS does the same thing.

The intention is that if you have several computers on a private LAN with no DHCP server, each will auto-configure, hopefully to different addresses, and will be able to communicate with each other. (The algorithm to assign addresses probes the network looking for duplicates, so if everything is working properly a duplicate won't happen).

There are ways to disable it if it's not useful (if you have a router that is just not working, the auto-configuration isn't helpful, for example, because until the router's up you can't reach the internet anyway). E.g. see this Microsoft support article, which pertains to Windows 98:

The 169.254 address range is not owned by anyone. While it hasn't been designated a "private IP" range like 192.168/16 or 10/8, it's effectively used that way and has been set aside by IANA for use in a "zero configuration" protocol like Windows uses. There's an Internet Draft document describing the process here (it doesn't appear to have become an RFC, though a similar strategy is built into IPv6).

If you read this draft, you'll see that it explicitly recommends that you NOT use this range for a DHCP server, because it can interfere with the duplicate avoidance protocol. Of course, if you have a DHCP server, you shouldn't see this address range, so the preferred course of action is to fix up the DHCP server so your Windows machine won't be auto-configuring itself.

Jim Patterson wrote in news:v_twd.17665$ snipped-for-privacy@news20.bellglobal.com:

You are right about the 169.254 address... I did this from memory, not when I was having a problem.

So, essentially, all the IP address sets are agreed upon, right? 192.168 is only a private network because that's what was agreed upon? It has nothing to do with actual hardware compatability and functionality, it's just a criteria that was agreed on by actual flesh-and-blood people to avoid conflicts on WANs like the "Internet"?

The reason I ask is because I was helping someone with a 15 client network, and they didn't have a DHCP server in place, just a 16 port switch. I noticed that all the IP addresses of the Win 2000 machines were in the 169.254 range, and the network was running fine.

"What's APIPA?"

's_apipa.htm

I agree that it's not really Windows-specific, since any OS could implement the protocol. I guess I've only encountered it on Windows, not being a Mac user. I don't believe that it's what a DHCP client is "supposed" to do, though, as it's outside of the DHCP protocol. I don't find any mention of it in the DHCP RFC (2131). The Internet draft I quoted earlier is basically an add-on to DHCP.

I've certainly never seen my Linux system do it (Slackware 10), but it does seem to be available on other distros. Maybe Slackware's just behind the times.

Personally, I prefer not having it. I can see its utility if I wanted to run a workgroup of computers that only communicated with each other, but as soon as a gateway to the internet enters the picture, something mroe is needed. I've only ever used the 169.254... address as an indication that my router is down. Okay... I admit I did use it once to do a crossover link between two laptops (it saved me assigning some static IPs).

Its NOTHING to do with windows, its what a DHCP client is /supposed/ to do it if can't find a server.

And linux, and unix and openvms and..... :-)

Its defined by the IETF as the required behaviour if operable routable address can be determined. This includes when the host is configured to request an address via DHCP and no server responds within the timeout period. The block is reserved by IANA for 'linklocal'. I belive this is currently covered by

There's quite a bit of s/w that won't work if your machine doesn't have a valid IP. It sounds obvious, but networking software often won't work, and this can stop your machine booting or otherwise starting properly.