4

I have a server with both IPv6 and IPv4 addresses. Is it possible to connect to another web server (I know only its IPv4 address) over HTTP through the IPv6 interface, so that that server can see only my IPv6 IP as the source address?

Improve this question
1
  • The answers point out that the two addresses are separate networks, but what seems practically more relevant is that hosts commonly configure an interface for both address types with analogous addresses. There are more results for searching for converting from ipv4 to ipv6 than routing from ipv6 to ipv4. I could connect to my host fine using the converter at dnschecker.org/ipv4-to-ipv6.php but apparently there are also tools and libraries to do this conversion. Commented Jun 29, 2022 at 13:15

2 Answers 2

Reset to default
6

Short answer: NO

Long answer: IPv4 and IPv6 are different protocols. In theory you can connect from IPv6 address to IPv4 service, but you need NAT64 for this and this is primary designed for IPv6 only network.

Improve this answer
1
  • 1
    The only information missing from this answer is the detail that when using NAT64 the server will still not see the IPv6 address of the client, rather it will see the IPv4 address of the NAT64. Commented Mar 16, 2017 at 9:32
5

Updated to reflect comments:

My answer below is incorrect, but I suspect (i.e. hope) I am not the only person to have been under similar misconceptions, and that this answer (and more so, its comments) will help clarify things.

The main problem is my misreading what 6to4 does - 6to4 does not (as I had initially understood) provide a means for an IPv6 node to speak to an IPv4 node. What it does allow is for an IPv6 node to speak to another IPv6 node across an IPv4 network.

So (as has been pointed out) it is an incorrect answer, and specifically does not cover the case the asker was interested in.

As regards deprecation of 6to4, it is indeed only a recommendation currently, applying only to a specific subset of 6to4. It seems that 6to4 is no longer recommended for new deployments.

NAT64 (at least as described here: https://en.wikipedia.org/wiki/NAT64) is possibly more suited:

Stateless translation is appropriate when a NAT64 translator is used in front of IPv4-only servers to allow them to be reached by remote IPv6-only clients. Stateful translation is suitable for deployment at the client side or at the service provider, allowing IPv6-only client hosts to reach remote IPv4-only nodes.

Original:

Technically, this is not impossible: https://en.wikipedia.org/wiki/6to4.

Assuming you find a relay to use, that relay will handle the IPv4 connection on your behalf, making their IP(v4) address the source the destination will see.

It might however make sense to see if all this can be avoided, either by finding the IPv6 address for the service (if there is one), or by using IPv4 - since your server has both, it seems a lot easier to just speak IPv4 than it does involving extra hops and complexity to your service.

All the more so as it sounds like you are using the remote end as an upstream of some kind, so that latency/responsiveness is presumably a consideration too.

Updated to reflect Sander Steffann's comments: 6to4 is deprecated as of 2015 (https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6to4-to-historic-11), and that document recommends NAT64 as a replacement (https://www.rfc-editor.org/rfc/rfc6146).

So while it does remain possible to do what the asker was wanting, 6to4 is not the proper way of doing it.

Improve this answer
11
  • 3
    The reference to 6to4 is incorrect, that is a deprecated protocol that has nothing to do with what you describe. What you mean is using a public NAT64 gateway. Commented Mar 15, 2017 at 20:35
  • As far as I undeestood, using either NAT64, or 6to4 will make target host see IPv4 address of a gateway as source address, and it's impossible to make that host see my (or gateway's) IPv6 address as source? Unfortunately, that host doesn't have AAAA record in DNS. Is it possible to discover it's IPv6 address in any other way? Commented Mar 16, 2017 at 7:27
  • I guess you could set an X-Forwarded-For header (or something like that) - but fundamentally, if you speak IPv4 to something, it sees your IPv4 address, and if you speak IPv6 to it, it will see your IPv6. In the case of 'translating' from 6 to 4 (or vice versa), because there is generally a gateway of some form, that gateway's IP would be seen. So while it is possible to have your IPv6 server speak to an IPv4 host, it really sounds like you probably would do best to just stick to using IPv4. Commented Mar 16, 2017 at 7:31
  • @SanderSteffann Which RFC would deprecate 6to4? There is RFC 7526 which deprecates 192.88.99.1 but it explicitly says that 6to4 is not deprecated. Commented Mar 16, 2017 at 9:23
  • This answer is incorrect in so many ways. First of all 6to4 is incapable of solving the problem posed in the question - even if we ignore all the shortcomings of 6to4 deployments and assume all 6to4 deployments have been done in a perfectly reliable fashion. Also suggesting NAT64 as replacement for 6to4 makes no sense at all, since they are aimed at entirely different scenarios. The document you link to (which is by the way a draft document rather than the final version) explicitly says that NAT64 does not eliminate the need for 6to4 relays. And that is all it says about NAT64. Commented Mar 16, 2017 at 9:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.