A special
hierarchy of
IP addresses
reserved for
local,
non-public networks. Any IP address beginning with 192.168, for example 192.168.0.1, is not
routable on the general
internet. Anyone can assign and use these addresses for computers on
local networks, and any computer with one of these addresses cannot talk to the rest of the internet using that address unless some sort of special IP sharing has been set up.
There are two other IP blocks (see Nonroutable IP Addresses that behave the exact same way as 192.168.*: 172.16.*, and 10.*. 10.* is where routers, dsl modems, and similar such things tend to like to live, since they consider themselves to be only important as local beasts. (thanks m_turner)
Most of the time when you see a computer with a 192.168.* address, a proxy or ip masquerade has been set up somewhere on the network in order to allow the computers on the local network to communicate with the outside world by sending all their traffic to the proxy computer-- which has a real, non-192.168.* address-- which shares its IP with the local computer, retrieves the information the local computer needs, and forwards it back to the computer. This is all generally totally transparent, and you see it done a lot at colleges and some businesses that don't want to pay for an IP address for each computer. Computers with a 192.168.* address generally can't be used for web, ftp or telnet servers-- the computers on the local network will be able to talk to that server, but the rest of the internet will be unable to get inside of and talk to the 192.168.* network unless inbound port mapping has been set up.
Under IPv6 none of this should be a problem.
This node was originally titled "192.168.*". The "*" was meant to be a wildcard, in the UNIX tradition of using a * to describe the idea of "you can put anything you like here". At one point, this node was renamed for an editor to "192.168.0.0/16". I was not notified as to why, and didn't understand the significance of the /16, so i posted a request for someone to explain this. Shannara256's writeup below was the reply.
Ocelotbob points out that if you want to understand this all in detail, you can see RFC 1918.