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?

TRiG
  • 1,181
  • 3
  • 13
  • 30
Andrey Melnik
  • 43
  • 1
  • 1
  • 4
  • 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 https://dnschecker.org/ipv4-to-ipv6.php but apparently there are also tools and libraries to do this conversion. – fuzzyTew Jun 29 '22 at 13:15

2 Answers2

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.

Quantim
  • 1,358
  • 10
  • 15
  • 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. – kasperd Mar 16 '17 at 09:32
4

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.

Community
  • 1
iwaseatenbyagrue
  • 3,688
  • 15
  • 24
  • 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. – Sander Steffann Mar 15 '17 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? – Andrey Melnik Mar 16 '17 at 07: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. – iwaseatenbyagrue Mar 16 '17 at 07: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. – kasperd Mar 16 '17 at 09: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. – kasperd Mar 16 '17 at 09:29
  • @kasperd Without 192.88.99.1 the only thing you can do with 6to4 is to talk to other 6to4 networks, which isn't very much – Sander Steffann Mar 16 '17 at 13:28
  • @SanderSteffann That is not entirely correct. The original 6to4 RFC did not mention `192.88.99.1` at all, that was added later. Before the `192.88.99.1` anycast address was introduced you had to manually configure your 6to4 router with the unicast IPv4 address of a relay. You could go back to such a configuration, and if you could find a reliable relay it would be a slight improvement in reliability over using `192.88.99.1`. – kasperd Mar 16 '17 at 22:40
  • @kasperd No because the return traffic wouldn't have a relay when there are no public 192.88.99.1 relays. Those relays translates in two directions, and manually configuring one side doesn't help for the traffic in the other direction. Without public relays 6to4 can only bee used to communicate with other 6to4 sites, which is almost nothing... – Sander Steffann Mar 17 '17 at 01:06
  • @SanderSteffann There were public 6to4 relays before the introduction of `192.88.99.1`. They would receive encapsulated traffic destined for their unicast IPv4 address and forward it onto the IPv6 network, and they would receive traffic destined for `2002::/16` and encapsulate it in IPv4 towards the intended destination. The only difference really was that the relays were all using different IPv4 addresses rather than the same anycast address. – kasperd Mar 17 '17 at 08:19
  • I just read the RFC again and you are technically correct. However the problems that rfc6343 mentions are related to relays in both directions and while rfc7526 doesn't deprecate the return relay it does suggest that operators consider retiring both forward and return relays. The operator community pushed for much stronger retirement because 6to4 is a horrible protocol that shouldn't be used anymore at all. The only reason 6to4 isn't deprecated entirely is that some people used it for 6to4-to-6to4 communication. Operational consensus is not to use it at all though. – Sander Steffann Mar 17 '17 at 09:09
  • Thanks for updating your answer! One comment: the deprecation draft had not expired, it became RFC 7526 in May 2015. – Sander Steffann Mar 18 '17 at 08:57