We have a function that takes in a request from an authenticated end user, and then makes another, secure connection to a third party service with api secrets etc, including the user's IP address, IPv4 IP, which is required by them.
For nearly every user, this hasn't been an issue, because I've been able the request header X-Forwarded-For, but for 2 users, only an IPv6 address was present there, and no IPv4 details was present in the headers for them.
When I contacted one of the users, and asked them what came up from visiting whatismyip.com, they got a public IP of 107.140.xxx.xxx and the IPv6 address I'd been seeing, 26xx:17xx:2dx:a7xx:e8xx:36xx:xxxx:xxxx. When I tried to drop that v6 address into a few of the online services, I got messages similar to
Only addresses in 6to4 notation or IPv4 mapped notation can be converted back to IPv4 address
Do I have any options at all? I understand the real issue here is that we all SHOULD be using IPv6 at this point, any way, but we're not in control of the third party, and they require a IPv4 address.
The short answer is "you don't". There is no general cross-over between the two addressing schemes; you cannot convert an address from one version to the other.
Any "address conversion" methods you might've seen were specific to transition mechanisms – tunnels that carry IPv6 traffic over IPv4 (for the specific purpose of allowing v4-only clients to have some IPv6 access through relays) and therefore necessarily involve mapping the overlay IPv6 addresses to underlay IPv4 addresses, such as the "6to4"
2002:xxyy:zztt::addresses. But none of that can be applied to native IPv6 traffic as it doesn't involve IPv4 in any way.That being said, if the user reached you via IPv6 but you absolutely need to forward an IPv4 address to somewhere else, there are a few options depending on what kind of user it might be and how the IPv4 address will be used.
In theory, one way to get the client's IPv4 address would be to set up an IPv4-only endpoint which the client is forced to connect to (e.g. through a redirect or an iframe). But you don't know whether an address obtained this way will actually remain valid for a week or even just 5 minutes. (For that matter, even without IPv6 being involved, you probably have many IPv4 users that access you through CGNAT and have no IPv4 address of their own!)
Keep in mind that the user might not have a single IPv4 address – one client might have a full dual-stack connection with static IPv4, but another client might be behind the ISP's CGNAT gateways sharing an IPv4 pool with a bunch of other customers, and a third client might actually have no IPv4 whatsoever (with the ISP's NAT64 gateways again having a shared pool of IPv4 addresses). This is to say that it's becoming increasingly unwise to rely on the "observed" address of your visitors for anything long-term.
So if the address is required for an API that the client will use in their own software, then your best option is to explicitly ask the client what IPv4 address they want to allow, so that they could make an informed decision (and possibly arrange a static IPv4 address with their ISP).This is also nice to do when the client has more than one address; e.g. the PC that they're signing up from may not necessarily be the server they're planning to use the API from.The other option is to proxy the requests on the client's behalf: set up an authenticated HTTP reverse proxy of some sort, and instead of requiring each client's IPv4 address, you would always specify your proxy server's address. (An advantage here is that you don't have to send the client's personal information to a third party – it's not clear whether they're currently even aware that you're doing so.)