IP addressrange for machine internal use

R

Thread Starter

Rob Hulsebos

Hi List,

I'm running into this issue about assignment of IP-addresses. There's a machine with several embedded PC's connected to a 100 Mbit/s Ethernet. Controlling this machine is a normal PC with two Ethernet-controllers, one for talking to the embedded PC's, and one for talking to the factory LAN.

The customer is allowed to choose the IP-address for the factory LAN interface, and *we* choose the IP-addresses for the embedded controllers. So far, simple.

First I thought to use the addressrange 192.168.0.XXX for use inside the machine. Although working fine, one runs into problems when the controlling PC is connected to a LAN which also uses these same IP-addresses for
intranet use. So 192.68.0.XXX is not a good choice.

But what else?
Of course one can choose another IP-address range,
but there is a chance that another customer has chosen exactly the same IP-addresses. So it is not a 100% solution. Also, the advantage of the 192.168.0.XXX range is that they are non-routable (although I haven't exactly discovered what the run-time advantage of this would be).

Now, I see only a solution where my company (Philips) takes a small range of its own IP-addresses (130.144.XXXX.YYY) and uses that (every machine we will ever make shall use these IP-addresses, even those in use outside Philips).
But we must support a situation where a factory has dozens of our machines, and it is impossible to use unique IP-addresses everywhere (we can't take 30000 IP-address per year !) Another less desirable solution is to have the customer assign the IP-addresses, also those inside the machine, but I don't quite like modifications to the machine's internals.

Has anyone in this list ever encountered this issue of how to distribute IP-addresses in machines world wide?

--

Actually, what is needed is a range of IP-addresses that is reserved for use inside machines, and for which there is a "guarantee" that these addresses are never used for intranet usage. A class "F" IP-addressrange or so...

Sincerely,
Rob Hulsebos
 
A

Alex Pavloff

Non routable address ranges are:

Class Network Address Range
A 10.0.0.0 - 10.255.255.255
B 172.16.0.0 - 172.31.255.255
C 192.168.0.0 - 192.168.255.255

Unfortunately, these is no guarantee for addresses that are never used for intranets. I mean, what if everyone wanted one of them? What if you had two of these "not used for intranet" devices on the same network?

You could make a guess and take one of the 10.x.x.x range and PROBABLY never have problems, but the only real way to make this work is to provide the customer with some configurability.

Since you don't want to mess with the embedded PCs, why can't you have the embedded PCs be DHCP clients and install a DHCP server on the "normal" PC?

Alex Pavloff
Software Engineer
Eason Technology
 
B

Bob Peterson

[email protected] writes:

> Has anyone in this list ever encountered this issue of
> how to distribute IP-addresses in machines world wide?

I use either customer assigned addresses or addresses per our company policy as follows:

"... we should use IP addresses within one of the ranges reserved for internal (private) addressing. These ranges are:

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255"

I prefer to use 10.x.x.x addresses since the 192.168.x.x addresses are typically used by cable modem routers.

Bob Peterson
 
P

Pablo Bleyer Kocik

Hi!

Your problem is a very classical one.

I don't know much about the capabilities of your machine and devices, but my suggestions are:

- Use dynamical IP addresses (with BOOTP or DHCP). The site where your devices
are attached to must have a BOOTP or DHCP server somewhere.
- Put your devices in your own intranet, and export them with IP masquerading.
You will need something like a router or a switch, or a machine doing the same function.

Best wishes.

Pablo Bleyer Kocik
 
C

Curt Wuollet

Hi Rob,

Interesting problem. I have a dim memory that there are also Class A and B "test" ranges that correspond to the 192.168.0.xxx class C. If indeed this is true, I would look into subnetting a class C range from one of those. Not a perfect solution, but it would greatly reduce the chances of conflict. Not many people would need a class A for their intranet. I am drawing a blank on
where I read about these allocations but, it was probably in the Linux Network Admimistrators Guide (free) or perhaps earlier documentation. I'm sure Stevens would cover this. I'll peruse
my UNIX networking docs. (I'm interested now)

Regards

cww
 
Since the master PC has two NICs, or network interface cards(It is "dual-homed".), the customer's LAN shouldn't be bothered by the embedded PCs' IP addresses unless the master PC is configured to route between the two(Machine and LAN)networks. This routing isn't necessary unless one or more of the embedded PCs has to communicate with external LAN-connected devices other than the master PC. If the master PC's OS
permits routing, make sure that it is disabled. If this works, then you should be able to assign and reassign the same range of IP addresses
to the embedded PCs without conflict. At the master PC, assign a 192.168 or other suitable address to the machine-connected NIC and a valid
LAN address to the LAN-connected NIC and disable routing.

The customer will have to assign an IP address for the LAN-connected NIC from their pool, but I agree that allowing or expecting the
customer to assign address for the embedded PCs would be problematic.

Bon Chance;
dan_054
 
Sorry about this "addendum", but I wanted to double-check this other issue before I opened my mouth.

I'm not certain that the reserved address ranges of 10.0.x.x, 172.16.x.x, and 192.168.x.x should be considered "non-routable", and assuming
that they are could lead to problems.

The Internet powers-that-be refer to these addresses as "reserved for private networks", meaning those that aren't connected to the public
Internet. Within the private network, I don't know that these addresses are "non-routable" in the sense that the router people have hard-coded their routers not to pass these along. I'm almost positive that a previous employer did have a routed, private internet using the 192.168 addreses, meaning that they are routable within a private network.

Assuming that these "non-routable" addresses will isolate your embedded PCs regardless of the master PCs routing configuration may be
erroneous.

Any CCIEs listening?
dan_054
 
T

Toni Kaesbeck

Hi:
Can someone on the list explain or give a link, what the standard or convention on the IP addresses ranges are?
Why use 192.168.0.XXX?
Thanks
Toni
 
P

Peter Whalley

Dan

You are right in what you say. A properly configure Internet router would be set up to block IP addressess within these "private" ranges. An internet Firewall should also block these address ranges. Within a private Intranet
you are free to use and route these address ranges at will and in a larger network this is what you would likely do.

Regards

Peter Whalley

Magenta Communications Pty Ltd

Melbourne, VIC, Australia

e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

 
A
dan_054 wrote:

> Sorry about this "addendum", but I wanted to double-check
> this other issue before I opened my mouth.
>
> I'm not certain that the reserved address ranges of 10.0.x.x,
> 172.16.x.x, and 192.168.x.x should be considered "non-routable", and
assuming that
> they are could lead to problems.

You are correct sir. Those addresses could indeed be routable on the private network. They're not (actually, shouldn't be, as I've heard of misconfigured routers allowing this) routable on the internet.

And now, in response to your first post:

> If this works, then you should be able to
> assign and reassign the same range of IP addresses to the embedded PCs
> without conflict. At the master PC, assign a 192.168 or other suitable
> address to the machine-connected NIC and a valid LAN address to the
> LAN-connected NIC and disable routing.

One problem with that -- the PC with the two NICs will have problems if the same IP address exists on both networks. If you assign a 192.168.0.1
address to an embedded PC, and 192.168.0.1 is also a PC on the customer's LAN, the PC with the two NICs will have to pick one or the other.

If the embedded PCs are non-customer configurable, the best solution that I can see is using BOOTP or DHCP on the two-NIC machine to ensure that the embedded PCs are assigned IP addresses that do not conflict with anything on
the customer network.

Alex Pavloff
Software Engineer
Eason Technology
 
B

Blunier, Mark

> Can someone on the list explain or give a link, what the standard or
> convention on the IP addresses ranges are?
> Why use 192.168.0.XXX?

It is one of the IP address ranges that are private. A google search for the RFC that addresses private IP numbers "http://www.google.com/search?q=rfc+ip+private":http://www.google.com/search?q=rfc+ip+private shows the relevant RFC
"http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1918.html":http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1918.html

Mark
Any opinions expressed in this message are not necessarily those of the company.
 
>>I'm not certain that the reserved address ranges of 10.0.x.x,
>>172.16.x.x, and 192.168.x.x should be considered "non-routable",
>>and assuming that they are could lead to problems.

Normal routers don't have a problem routing any IP address, but (referring back to RFC1918) routing information about these addresses is supposed to be ignored by ISP's and not propagated outside the network of enterprises using these address ranges.

So you are correct, these addresses are routable - but their routing scope is supposed to be limited to a single enterprise or single location.

(exact text of the RFC)
Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives
such information the rejection shall not be treated as a routing protocol error.

Enjoy,
Jeff Dean
[email protected]
 
H

Hentschel, Thomas

From RFC1918, which outlines the use of private address space
(ftp://ftp.isi.edu/in-notes/rfc1918.txt
<ftp://ftp.isi.edu/in-notes/rfc1918.txt> ) :
-------
Because private addresses have no global meaning, routing information about
private networks shall not be propagated on inter-enterprise links, and
packets with private source or destination addresses should not be
forwarded across such links. Routers in networks not using private address
space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private
networks. If such a router receives such information the rejection shall
not be treated as a routing protocol error.
-------
Also, if you're using DNS, make sure it doesn't "spill" over your private network.
-Th
 
The IT department will complain, but all DHCP management tools can reserve IP addresses for your embedded PCs. They would prefer not to have to track these special cases. These can be public IP addresses or those reserved for
private networks per RFC 1918
"http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=1918&type=ftp":http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=1918&type=ftp

FYI, from the RFC:

RFC 1918 Address Allocation for Private Internets February 1996

3. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Naturally, it would be best for your control system to use the IT department's DHCP and DNS.

Best,
B.O. Nov. 29, 2001
--
Robert Old, System Architecture, [email protected]
Siemens Building Technologies, Inc., Building Automation
1000 Deerfield Pkwy., Buffalo Grove, IL 60089-4513 USA
Phone: +1(847)941-5623, Fax: +1(847)919-8420
 
D

DAVCO Automation

First appologize for my typing on a handheld here in an arena parking lot in Northern Minnesota........what a world.

There are the three ranges of IP addresses listed on the other responses and these addresses are blocked by default on routers and are totally blocked by routers on the internet......Otherwise there would be a mess.........

Unfortunatelly when you want to become a network archetect/administrator, these are the issues you run into.

You cannot guarantee that if connected on an intranet, that these addresses are not used, therefor the only thing to do is to coordinate with the client.....The other solution is to use any address you want as long as you never connect to the "public/private" network, there is no issue
whatsoever.....but I guarantee someone will connect...

"What is this cable for"................

You can use DHCP or BootP which are basically pools of addresses which are assigned by an ADMINISTRATOR to dynamically assign addresses out of a pool.

Like all things in life, this works if your devices "speak" dhcp or bootp protocols....most do not.

Just like you do not want others messing with your configuration, the intranet or plant network engineer does not want your addresses conflicting
and taking down some plant critical server...........

IP address management is an issue and is why those damn network gurus make the big bucks........TCP/IP is a one week class at CTECS and doesn't even scratch the surface and every cisco class I have attended spent at least
another day on it only to make me see I did not understand........in other words huge let me repeat HUGE topic......you do not even begin to understand how much you do not know about it.....until you dig into it..........questions e-mail.

Dave

DAVCO Autmomation
Blandin Paper Company
UPM-Kymmene
 
R

Rocco F. Dominick

There is a AB document entitled IP Addressing.doc on the Allen-Bradley site. I could not find the URL for this document. If you decide to search for it and cannot find it, please let me know and I will E-mail you a copy.

Best regards,

Rocco F. Dominick
E-mail: [email protected]
 
Top