universally invalid tcp endpoints (destination addresses)

[al_9x]

that result in an immediate error/termination of the connection, producing no packets or timeouts

First, I should point out that the following is wrong:

Any address ending with 0 is invalid as a TCP endpoint

Network and broadcast addresses that the system knows are evidently invalid (instantly rejected) tcp endpoints (broadcast addresses are valid for udp) , but not every address ending with a 0 or 255 is a network or a broadcast.

For example, in a 192.168.0.0/16 network (192.168.0.1 - 192.168.255.254), the network and broadcast addresses are 192.168.0.0 and 192.168.255.255, but 192.168.1.0 and 192.168.0.255 are valid ips/endpoints.

Also, other .0 and .255 ips outside the 192.168 network would also be valid endpoints, since they are not known to be networks and broadcasts.

So here is the list as far as I can make it out, confirmed on xp with iperf and a sniffer:

1. 0.0.0.0 - though not only a network address (refers also to a "this" host), explicitly defined to be an invalid destination

   Can only be used as a source address

2. 255.255.255.255 - local broadcast
3. 127.0.0.0 - is a well known network address (127.0.0.0/8) configured on every system, therefore should be universally invalid
4. 127.255.255.255 - corresponding broadcast
5. 224.0.0.0 - 239.255.255.255 - multicast range, rejected for tcp
6. 240.0.0.0 - 255.255.255.254 - reserved range, defined to be invalid

   No addresses are allowed with the four highest-order bits set to 1-1-1-1. These addresses, called "class E", are reserved.

[Alan Baxter]

that result in an immediate error/termination of the connection, producing no packets or timeouts

First, I should point out that the following is wrong:

Any address ending with 0 is invalid as a TCP endpoint

Network and broadcast addresses that the system knows are evidently invalid (instantly rejected) tcp endpoints (broadcast addresses are valid for udp) , but not every address ending with a 0 or 255 is a network or a broadcast.

I've read the rest of this post too, and I'm trying to see if it has any information I need to know. In particular, are you saying that Giorgio's recommendation to use 0.0.0.0 to terminate a connection in a hosts file is incorrect and inconsistent with an RFC? I can't tell for sure.

By the way, if the subject of your post contains info that's needed for the body to make sense, could you include it in the body too? For example, put "universally invalid tcp endpoints that result in an immediate error/termination of the connection" in your actual post instead of just "that result in an immediate error/termination of the connection". It makes your post easier to read and quote. Thanks.

[al_9x]

are you saying that Giorgio's recommendation to use 0.0.0.0 to terminate a connection in a hosts file is incorrect

No, how did you get that idea? 0.0.0.0 is the first item on my list of tcp invalid destination addresses.

[Tom T.]

No, how did you get that idea? 0.0.0.0 is the first item on my list of tcp invalid destination addresses.

Agree, and think it's the best (and shortest). Changed my Hosts from the host-file service's 127.0.0.1 to 0.0.0.0 at Giorgio's recommendation, and it works beautifully. With 15k+ entries, cuts 30k off the file size, too.

[Alan Baxter]

are you saying that Giorgio's recommendation to use 0.0.0.0 to terminate a connection in a hosts file is incorrect

No, how did you get that idea? 0.0.0.0 is the first item on my list of tcp invalid destination addresses.

Thank you for the clarification.

[al_9x]

Just noticed that Sun's Java VM (1.6.0_18) on xp treats 0.0.0.0 as a valid destination address and actually tries to connect on the primary interface. It appears to substitute the primary interface ip for 0.0.0.0 before passing the call to the os. 127.0.0.0 works as expected.