2

I have an application that requires users who share a 3G or 4G network access point (same public IP address) to communicate directly through their local IP addresses rather than trying to traverse their global IP addresses, but the local network addresses on my T-mobile 3G and 4G network are not like normal local IP addresses on most routers - they never start with 192, 172, or 10. Instead, they start with other numbers - for example, my phone now says that my private IP address is 21.48.25.107. How do you tell if an IP address is a local address when the IP address originates from a cellular network?

Clarification:

I am implementing a peer to peer NAT traversal solution for cellular applications. I avoid using the public IP address when the devices share a common public IP address because most routers do not support hairpin translation.

Hairpin is a behavior where a NAT device forwards packets from a host in an internal network (lets call it host A) back to some other host (host B) in the same internal network when it detects that the (public IP address) destination of the packet is actually a mapped IP address that was created for the internal host (host B). This is a desirable behavior of a NAT, but, unfortunately, not all NAT devices support this. Lacking this behavior, two (internal) hosts behind the same NAT will not be able to communicate with each other if they exchange their public addresses.

That is why they must exchange and use their local IP addresses if they share a public IP address.

  • 1
    Unfortunately, it is rather standard practice for mobile networks to "illegally" use public address space as if it were private. They all do this. – Ricky Beam Jul 23 '15 at 8:03
  • It is difficult to know by looking at the address (outside RFC1918) if it really is public or private. Further, knowing what nat domain systems are within is nearly impossible. – Ricky Beam Jul 23 '15 at 8:06
  • 1
    I sat through a T-Mobile demonstration a while back. T-Mobile is interesting in that it is starting to put everything on IPv6. The IPv4 addresses for those devices are not real. T-Mobile came up with a home-grown solution to let IPv6 devices communicate with the IPv4 Internet. I think that something like 60% of the T-Mobile phones are actually IPv6-only, but use the proprietary solution to communicate with IPv4. Your application may need to be re-engineered for that carrier. – Ron Maupin Jul 23 '15 at 15:03
  • @RickyBeam - do you know if most cellular internet network access points support hairpin translation? Because if they all did I wouldn't have to bother with using local addresses for mobile devices. – Fakey Anonymous Jul 23 '15 at 15:43
  • I mean that the IPv4 addresses don't actually exist until you get deeper into the T-Mobile network, well beyond the cell tower. The only real IP addresses that the devices have are IPv6 addresses. You could certainly use the link-local IPv6 addresses to communicate locally. My understanding is that T-Mobile is on a direct path to eliminating real IPv4 on the mobile phone. – Ron Maupin Jul 23 '15 at 15:52
2

It doesn't answer your question, but may answer your need: I fear the only option would be to have all peers register their local IP addresses on a server directly connected to the Internet (without NAT). Each peer could then query the server for the local and translated IP addresses of others. If their translated public IP addresses are in the same range (allocated in the same AS), they could then try a direct connection through their local IP addresses.

Of course, with end-to-end IPv6 connectivity, there would be no issue...

  • "fear the only option would be to have all peers register their local IP address on a server". I am already doing this. Every peer provides a server with its local ip and upon contact with the server, the server stores its public ip. The problem is that when I ask a device (often a laptop) for its local ip address, I sometimes don't get it. Instead I sometimes get a loopback address or I get unnecessary or extraneous addresses for virtual machines on the same device or things of that nature. I need a way to know that the address I requested is actually local. – Fakey Anonymous Jul 23 '15 at 15:38
  • Maybe the peers should just provide the server with ALL the addresses for all the network interfaces that are not loopback addresses and the other peer should receive ALL of these addresses and if the public ip's match, and in that case it should try ALL the local addresses just in case the other peer disconnected one of their network interfaces or was using a virtual machine. – Fakey Anonymous Jul 23 '15 at 15:41
  • " I need a way to know that the address I requested is actually local": what about looking at the routing table of the device, and take the address associated with the default route ? – CuriousFab Jul 24 '15 at 16:40
  • I'm programming in Java for the most part, and java's way of doing it that doesn't work in all cases on all OS's is here: stackoverflow.com/questions/9481865/… . Your idea might work, but it would require native code. I'm afraid I don't know how to get the default route. – Fakey Anonymous Jul 25 '15 at 2:46
0

You can't figure out what local address ranges will be used, but you can use the link-local IPv6 addresses to communicate locally in case hairpin translation is unavailable.

0

Proper private addresses are well-known. Occasionally addresses are added to the list but it's rare.

Unfortunately it seems like T-Mobile is using hijacked address space. 21.0.0.0/8 is allocated to "DoD Network Information Center (DNIC)"

Detecting whether a machine is behind a NAT is easy enough, just compare the local IP the client reports for the connection (use the getsockname api call) to the remote IP the server reports for the connection. This will work regardless of whether the local IP addresses used behind the NAT are well-known private IP addresses, hijacked IP addresses or even IP addresses legitimately assigned to the network in question (sometimes it makes sense to use NAT even when your clients have legitimate public IP addresses)

However even if two machines are behind the same public IP there is no guarantee that communicating using their local addresses will work. Equally there is no guarantee that communicating with NAT traversal techniques will work.

So sadly if you want reliable operation you will have to implement a fallback to communicating via your servers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.