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?

proski
  • 203
  • 1
  • 7
  • 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 '14 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 '14 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 '14 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 '14 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 '14 at 23:36

7 Answers7

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.

Community
  • 1
mfinni
  • 36,144
  • 4
  • 53
  • 86
  • 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: http://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 '14 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 '14 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 '14 at 18:38
  • Read this : http://tools.ietf.org/html/rfc3927 - anything that is using link local needs to implement conflict detection. – mfinni Jan 23 '14 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 '14 at 21:02
  • Well, that probably would have been useful info to include in your question as an important constraint, I suppose. – mfinni Jan 23 '14 at 21:28
  • Edited my answer to account for your new details – mfinni Jan 23 '14 at 21:40
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.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 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 '14 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 '14 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 '14 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 '14 at 19:01
  • "the subdevice connected to both networks would be confused" – proski Jan 23 '14 at 21:04
  • 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 '14 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.

TomTom
  • 51,649
  • 7
  • 54
  • 136
  • 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 '14 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 '14 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 '14 at 17:10
  • @TomTom, thank you for insight about getting routable addresses! Making the address configurable is not an easy option. Some subdevices are not DHCP capable and hard to configure. I'm puzzled by your reference to "gross neglect". For TEST-NET-3 addresses to conflict, the customer should be using them too and thus share the responsibility. – proski Jan 22 '14 at 17:44
  • 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 '14 at 18:22
  • @mfini it never was. Last time I got an AS and my own routable space was about 20 years ago and even then we had to fill out a utilization plan and make a valid case. Moving those to non routed customer internal space would get you a laugh - by the policies 20 years ago. – TomTom Jan 22 '14 at 18:23
  • @TomTom I understand your point. Since the appliance only needs the customer network to reach the cloud service, it doesn't matter if the network has hosts in the TEST-NET-3 subnet. The appliance won't work only if the customer's default gateway is in the TEST-NET-3 range. Not a big deal, not all tests have to be successful. It would be much worse to stop functioning if the customer is _not_ testing anything other than a new valid network addressing scheme. – proski Jan 22 '14 at 22:19
  • 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 '14 at 02:25
  • I can only speak for the RIPE region, but in our region there was never any requirement to publicly route any IPv4 address space. RIR policies don't usually involve themselves in routing, only in allocating addresses to those who need them (so you have to justify the amount of addresses, but for something like this you could easily get a /27 or a /28). I admit that we made mistakes there in IPv6 policy, but those have been fixed. The having multiple upstreams or peers is a requirement for getting an AS number, not for getting address space. – Sander Steffann Jan 23 '14 at 12:26
  • As for APNIC and RIPE still having IPv4 addresses: that is technically true. APNIC still has ±0.81 /8 and RIPE NCC ±0.85. But those are only distributed under special 'final /8' policies which don't allow for end-users getting PI addresses anymore. ISPs can get *one* /22 so e.g. new entrants in the ISP market have *some* routable IPv4 address space for their MAP, DS-Lite, NAT64, NAT444 etc. But that is it, no more than a /22 for the entire lifetime of the whole ISP... And once ARIN runs out later this year it will be really interesting as they have a more restrictive policy for post-runout... – Sander Steffann Jan 23 '14 at 12:33
  • @mfinni: it has always been a valid use-case in the RIPE region, and still is today. There are just no more addresses left to give out for these cases, but if there were it would still be completely valid under current policy. Yes, we're cleaning that up so the policy matches the current situation again :) Take a look at the current [IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region](http://www.ripe.net/ripe/docs/ripe-599). Nothing in there requires you to route the addresses publicly. – Sander Steffann Jan 23 '14 at 12:36
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.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
  • 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 '14 at 02:19
  • 1
    @Jules except for those (unfortunately common) networks that use the entire /8 subnet just because its the default. – Grant Jan 23 '14 at 05: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 '14 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.

Michael
  • 21
  • 1
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

Community
  • 1
  • 3
    How would this possibly work? His "subdevices" are individual hosts. Loopback is for a host to communicate with itself. – mfinni Jan 22 '14 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. –  Jan 22 '14 at 19:31
  • But, that document has another suggestion that I like! – mfinni Jan 22 '14 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 '14 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 '14 at 01:01
  • @yoonix Switches and routers will often use different addresses in the loopback subnet, but again, those are for communicating with itself. I can see an IP address of 127.0.0.50 for the SPF module on one of our switches, (which is where you may have seen this before) but that doesn't mean I'll be able to communicate with it on that address. – HopelessN00b Jan 23 '14 at 14:29
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.

user1722483
  • 11
  • 1
  • 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 '14 at 08: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 '14 at 20:58