8

I'm building an appliance consisting of several subdevices connected by ethernet inside the appliance. The appliance will connect to the customer network. The customer network can be using private IP addresses. An address conflict with the internal network would be a problem (the subdevice connected to both networks would be confused). IPv6 is not an option.

Should I buy IPv4 addresses? Or maybe I can get away with using TEST-NET-3 (203.0.113.0/24) or something like that? What is the best practice?

Improve this question
5
  • 1
    Will the customer network need access to the subdevices directly or will they connect to the appliance only via a "management" type LAN port on the appliance? I ask because EMC and others use private fiber IP communications on their SANs for their controllers/etc with a dedicated management NIC that is connected to the customer network. The mgmt NIC either gets a DHCP address from the customer LAN or is statically assigned to reside on the customer network.
    – TheCleaner
    Jan 22, 2014 at 16:12
  • 1
    Do you have to use TCP/IP stack for communication between your 'subdevices'? If you stay on layer two you won't have any issues with IP conflicts.
    – jlehtinen
    Jan 22, 2014 at 17:18
  • The customer network is just the means for connecting to the cloud service. Thus the customer's default gateway should not overlap with the internal network, or the outward looking subdevice would misroute the packets. One of the subdevices is IPv4 only, no other way to control it.
    – proski
    Jan 22, 2014 at 20:25
  • 3
    "IPv6 is not an option." We have 2014 now. It should be an option. "Should I buy IPv4 addresses?" Well, if you can - in Asia, they are exhausted, in Europe as well, ...
    – glglgl
    Jan 23, 2014 at 12:51
  • 1
    If devices don't support IPv6, I won't even consider buying them, because I would then have to replace them well before the expected lifetime of the device, with something that does support IPv6. (Well, for customers anyway. On my networks, which are already dual stack, a device that doesn't support IPv6 is considered not fit for purpose.)
    – Michael Hampton
    Jan 23, 2014 at 23:36

7 Answers 7

Reset to default
9

@yoonix has sent a link that might have a solution.

Link-local, also known as APIPA.

169.254.0.0/16 - This is the "link local" block. As described in RFC3927, it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found.

If I were your customer, I'd sure as hell want to have the option to configure this myself and/or use DHCP (which is, I don't know, maybe a long-established standard?), but in the absence of those, this is exactly what APIPA is supposed to be used for.

Edit - Given that you now state that the IP addresses must be static for individual hosts in your solution because those will correspond to firewall rules in your gateway device, I suppose that would take a bit of effort on your part to make that work with link local IPv4 addressing; effort you say you won't expend. So, you essentially have to make this configurable. You could ship it with a default, one that is less likely to be used by a client, but you must have a mechanism by which it can be changed in case of a conflict. Either by the client, or by you as part of implementation/UAT.

Improve this answer
7
  • The appliance is using DHCP on the internal network for one of the subdevices (it's very hard to configure without DHCP). I don't feel comfortable to have the DHCP server hand out IP addresses in the link local range, as it's explicitly prohibited: tools.ietf.org/html/rfc3927#section-1.6 If we didn't have to use DHCP internally, it would have been my first choice.
    – proski
    Jan 22, 2014 at 22:24
  • No no no, as I explicitly quoted, APIPA (link-local) addresses are what devices will assign to themselves if a DHCP server can't be found. I didn't suggest that you use DHCP to assign APIPA addresses.
    – mfinni
    Jan 22, 2014 at 22:42
  • The subdevices have specific roles and the router has to configure iptables according to those roles. I don't want the router to discover the addresses and change iptables accordingly. Also, assigning random IP addresses means that there will be address conflicts, and I'm not sure the hardware is smart enough to resolve them.
    – proski
    Jan 23, 2014 at 18:38
  • Read this : tools.ietf.org/html/rfc3927 - anything that is using link local needs to implement conflict detection.
    – mfinni
    Jan 23, 2014 at 19:16
  • I know that. There is no way this would be implemented in the product. The subdevices have their roles and there are specific iptables configurations for them.
    – proski
    Jan 23, 2014 at 21:02
5

  1. From Wikipedia: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly. - This tells me that you should not use TEST-NET-3.

  2. One thing you appear to be overlooking: How do you suppose that you'll be able to communicate with the device or that the device will be able to communicate with other devices and vice versa if you don't configure the ip address of the device FOR the client network? If you assign an ip address in a network that isn't in use in the client network (You: 192.168.1.0/24 - Them: 10.0.0.0/8) then how do you suppose that network communication is going to work? This is why you should configure the device to use DHCP out of the box and allow for the client to statically configure it afterward.

If you can't use DHCP then use APIPA.

Improve this answer
6
  • There will be no public use. The internal addresses would never be exposed to the outside. The communication uses NAT. But I cannot do NAT when both networks use overlapping addresses.
    – proski
    Jan 22, 2014 at 22:30
  • 1
    OK, but my answer isn't about NAT. How will your device communicate with other devices on the same internal network if it is using an ip address that isn't in the same subnet as the internal network?
    – joeqwerty
    Jan 22, 2014 at 22:55
  • Obviously, the appliance includes a router that has addresses on both networks. The router does NAT. The customer only talks to the appliance through a cloud service.
    – proski
    Jan 23, 2014 at 18:56
  • I'm not trying to be snarky, but how is that obvious? We only know as much as you tell us in your question and you never mentioned that fact.
    – joeqwerty
    Jan 23, 2014 at 19:01
  • 1
    Maybe it's me. I certainly don't mean any offense and maybe this is going to come off as rude but how does the statement "the subdevice connected to both networks would be confused" imply that the device has a built in router or has routing functionality? My computer has two network interfaces, each connected to a different network, but my computer is not a router. Maybe I'm just stupid. I don't read anything in your question that leads me to believe that your device has a built in router or has routing capability. At any rate, this rant doesn't serve to help you so I'll drop it at this point.
    – joeqwerty
    Jan 23, 2014 at 21:10
4

Make it configurable.

Should I buy IPv4 addresses?

Yeah. TRY THAT. First, you do not buy them, you "lease" them by membership. Second this requires an AS and 2 uplinks. Third, this requires a reason and "we do not want to suppose a proper network infrasctructure" is a reason resulting in laughter (and a rejection), not you getting IP addresses allocated.

Or maybe I can get away with using TEST-NET-3 (203.0.113.0/24)

Possibly. Until the day someone asks oyu for the cost of fixing things because of gross neglect.

What is the best practice?

Make it configurable. Or use IPV6 - there you can get away with some reservations.

Improve this answer
11
  • Getting IPv4 addresses for internal usage (so not routing them to the internet) is a perfectly valid use case. Unfortunately in the APNIC and RIPE regions there are no more IPv4 addresses left, so moving to IPv6 is really the only future-proof solution... ULA addresses sound like a good option there.
    – Sander Steffann
    Jan 22, 2014 at 16:38
  • 3
    It is not a valid use case. Not with limited IPv4 address space. This is what private addresses are for. And they wont waste it on companies "not able or willing to follow established conservation procedures".
    – TomTom
    Jan 22, 2014 at 16:40
  • It's certainly not a valid use case today, I don't know if it ever was. Do you have any documentation to back up your assertion, @SanderSteffann?
    – mfinni
    Jan 22, 2014 at 17:10
  • 3
    @proski ah, no. See - TEST-NET-3 addreses are for testing. A customer using them for testing has a valid case. SOmeone shipping appliances is either ignorant OR willfully ignoring the policies around these addresses, which is gross neglect. In both cases.
    – TomTom
    Jan 22, 2014 at 18:22
  • 1
    @SanderSteffann I don't know about APNIC, but RIPE certainly do have IPv4 addresses -- around 14 million of them (0.85 of a /8) according to the latest status update on their web site.
    – Jules
    Jan 23, 2014 at 2:25
4

In theory, any private IP range could be in use by any private network, so I doubt you'll find a best practice, or anything that's going to be universally applicable if you're hard-coding the address. The best practice would be to make it configurable and allow the client network to assign the device a private address (via DHCP, for example).

If that's not an option, I find that hardly anyone uses the upper half of the 172.16.0.0/12, so that's what I use. (I think I'm running on 172.25.0.0/16, to be precise.) I've yet to have an address collision on it, and I VPN into a lot of private networks.

If you have to use an IPv4 private address, I think that's the best you'll be able to do, with the 10.0.0.0/8 block being widely used and the 192.168.0.0/16 block being the default for almost everything, the only one left would be 172.16.0.0/12. Of course, this block is often used for VPNs, to avoid address collisions, because of the widespread use of the other private network blocks, so use the upper addresses, since (in my experience) they're the least utilized subnets in that block.

Improve this answer
3
  • 1
    If you pick a random /24 in the 10.0.0.0/8 range, and assuming a reasonable use of addresses by existing devices (i.e. at most a handful of /24 subnets are in use -- I tend to think of my network setup as quite complex, given that it has 4 such subnets [3 different locations, and a vpn to route between them]), the chances of a conflict are < 0.01%. I'd generally be willing to take this risk in most circumstances.
    – Jules
    Jan 23, 2014 at 2:19
  • 1
    @Jules except for those (unfortunately common) networks that use the entire /8 subnet just because its the default.
    – Grant
    Jan 23, 2014 at 5:08
  • The route to a smaller network has priority, to it should work. I could actually have /29 internally to reduce the risk even further. But not eliminating that risk, no matter how small, would be bad. The customer support would need to know about it and check the customer's network configuration.
    – proski
    Jan 23, 2014 at 19:42
2

We're designing the exact same thing and have decided to go with IPv6 site local addresses with a random fc00:nnnn prefix.

Improve this answer
1
  • 1
    Bad. Get an ULA block.
    – TomTom
    Jan 23, 2014 at 7:13
1

Assuming none of these subdevices need direct connectivity outside of the appliance, you should use the loopback network for this (127.0.0.0/8).

RFC 5735 / Section 3

Loopback on Wikipedia

Improve this answer
6
  • 3
    How would this possibly work? His "subdevices" are individual hosts. Loopback is for a host to communicate with itself.
    – mfinni
    Jan 22, 2014 at 19:26
  • 1
    Good point, I swear I've seen it used like this before.. but I can't recall where. I'll remove my answer shortly.
    – user143703
    Jan 22, 2014 at 19:31
  • But, that document has another suggestion that I like!
    – mfinni
    Jan 22, 2014 at 19:31
  • Actually, I'm thinking of using 127.0.1.0/255 for the internal network. Not sure if it would be better that TEST-NET-3.
    – proski
    Jan 22, 2014 at 22:35
  • 1
    THAT WON"T WORK. That's loopback. A host communicating to a loopback address will ONLY BE TALKING TO ITSELF. The loopback address happens to be the size of a whole subnet; it's still only host-local.
    – mfinni
    Jan 23, 2014 at 1:01
1

Can your "main controller" run a DHCP server/provide DHCP leases on its "internal" interface?

I've done something in the past for one of our company's commercial products that might be of use. The device had two ethernet ports, one of which was meant for "direct" connectivity from a PC. The issue was similiar; we wanted to avoid IP address conflict with a customer's internal LAN (possibly on a private IP network) as well as with the world at large.

The logic on this device was to dynamically configure a DHCP server ("udhcpc", via command line options) on the "direct" LAN port (eth1) based on its own IP configuration on its "public" LAN port (eth0). Whether the device obtained its own IP address through DHCP or via static setting, the module which applied the setting would also change the DHCP server configuration to avoid conflict.

For instance, if the device obtained address 192.168.0.100/netmask 255.255.255.0 (on eth0), it would configure its own DHCP server (on eth1) for the next available network 192.168.1.0/255.255.255.0.

It would pick from one of these networks (in priority order): 192.168.0.0/24 ... 192.168.254.0/24 172.16.0.0/16 ... 172.31.0.0/16 10.0.0.0/8

Hope this helps.

Improve this answer
2
  • What if I'm using 192.168.0.0/16 as my site prefix, but you're only connected to the VLAN using 192.168.0.0/24? You've just hi-jacked 192.168.1.0/24 even though I'm using it on another VLAN at the same site.
    – fukawi2
    Jan 23, 2014 at 8:06
  • That's a good idea in theory. In practice, one of the subdevices uses static IP address and another uses a DHCP client. Neither is configurable in a shipped product. Thus the addresses should be preconfigured, but the link-local addresses won't work.
    – proski
    Jan 23, 2014 at 20:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .