168.x.x.x IP address question

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?

Thanks,

Ryan

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...

"Coenraad Loubser" <(E-Mail Removed)> wrote in
news:cpmq3q$dl4$(E-Mail Removed):

> 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...
>
>
>

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


--
Marcin Lukasik
Milea Wireless Communications, http://milea.pl
phone/fax/mobile: (++48) 13 4480070 / 13 4481148 / 509 390 490

,,the only difference between men and boys is the price of their toys''

The Chairman wrote:
> 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?

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: http://support.microsoft.com/kb/q188480/.

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
http://www.ietf.org/internet-drafts/...nklocal-17.txt
(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
Ottawa, Ont
CANADA

Jim Patterson <jim-(E-Mail Removed)> wrote in
news:v_twd.17665$(E-Mail Removed):

> The Chairman wrote:
>> 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?
>
> 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: http://support.microsoft.com/kb/q188480/.
>
> 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
> http://www.ietf.org/internet-drafts/...zeroconf-ipv4-
linklocal-
> 17.txt (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.
>
>

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?" http://www.petri.co.il/what's_apipa.htm

---

On Fri, 17 Dec 2004 08:34:03 GMT, The Chairman <(E-Mail Removed)> wrote:

~ Jim Patterson <jim-(E-Mail Removed)> wrote in
~ news:v_twd.17665$(E-Mail Removed):
~
~ > The Chairman wrote:
~ >> 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?
~ >
~ > 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: http://support.microsoft.com/kb/q188480/.
~ >
~ > 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
~ > http://www.ietf.org/internet-drafts/...zeroconf-ipv4-
~ linklocal-
~ > 17.txt (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.
~ >
~ >
~
~ 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.

On Fri, 17 Dec 2004 00:18:38 -0500, in alt.internet.wireless , Jim
Patterson <jim-(E-Mail Removed)> wrote:

>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.

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

>Apparently, MacOS does the same thing.

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


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

Mark McIntyre wrote:
> On Fri, 17 Dec 2004 00:18:38 -0500, in alt.internet.wireless , Jim
> Patterson <jim-(E-Mail Removed)> wrote:
>
>
>>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.
>
>
> Its NOTHING to do with windows, its what a DHCP client is /supposed/ to do
> it if can't find a server.

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.

>>Apparently, MacOS does the same thing.
>
> And linux, and unix and openvms and..... :-)

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).

--
Jim Patterson
Ottawa, Ont
CANADA

On Fri, 17 Dec 2004 21:17:09 -0500, in alt.internet.wireless , Jim
Patterson <jim-(E-Mail Removed)> wrote:

>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.

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
http://ietfreport.isoc.org/ids/draft...nklocal-17.txt

>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,

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.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----