IPv4 host behind NAT talking to IPv6 host

Hello,

I have a basic question about IPv6.

Consider a set-top box which has basic networking
functionality, say an Ethernet interface and an
IPv4-only stack. The STB can access the Internet
through an ADSL modem.

The modem has a dual IPv4/IPv6 network stack.

LAN
STB <---> ADSL modem <---> Internet

The modem runs a DHCP server on the LAN to hand
out IPv4 addresses, and performs NAT on packets
to and from the Internet.

Now suppose the STB wants to talk to a distant server
which happens to be IPv6-only, e.g. ipv6.google.com

$ dig ipv6.google.com ANY

; <<>> DiG 9.7.1 <<>> ipv6.google.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31584
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv6.google.com. IN ANY

;; ANSWER SECTION:
ipv6.google.com. 86400 IN CNAME ipv6.l.google.com.
ipv6.l.google.com. 300 IN AAAA 2a00:1450:4001:c01::69

Obviously, the STB is not able to talk directly
to ipv6.google.com since it does not support IPv6.

I see several work-arounds. The server could be dual
stack, and provide ALSO an IPv4 address, but 1) IPv4
address space is running out and 2) the STB might be
confused by the IPv6 addresses in the DNS reply, even
if it should just ignore them.

The modem, which is already performing NAT, could
"rewrite" the DNS packets, and somehow map a few
IPv6 addresses to unused "virtual" IPv4 addresses.

Is this what NAT-PT proposed?

I guess I need to read (and understand!) this article
as a starting point.

http://en.wikipedia.org/wiki/IPv6_transition_mechanisms

I've also stumbled upon

http://ipv6.com/articles/nat/NAT-In-Depth.htm

Are there other good references/pointers?

Regards.

>>>>> Noob <root@127.0.0.1> writes:

[…]

> Obviously, the STB is not able to talk directly to ipv6.google.com
> since it does not support IPv6.

> I see several work-arounds. The server could be dual stack, and
> provide ALSO an IPv4 address, but 1) IPv4 address space is running
> out and 2) the STB might be confused by the IPv6 addresses in the DNS
> reply, even if it should just ignore them.

Let's check it out:

$ dig ipv6.google.com A

; <<>> DiG 9.7.2-P3 <<>> a ipv6.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51576
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv6.google.com. IN A

;; ANSWER SECTION:
ipv6.google.com. 0 IN CNAME ipv6.l.google.com.

;; AUTHORITY SECTION:
l.google.com. 60 IN SOA ns2.google.com. dns-admin.google.com. 1457624 900 900 1800 60

;; Query time: 252 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Jul 28 21:01:10 2011
;; MSG SIZE rcvd: 104

$

As could be seen from the above, no AAAA (IPv6 address) resource
records were returned by the server. So, there's nothing to
confuse the device in question.

(Of course, it's unlikely that an IPv4-only device will ever
request AAAA records from the DNS server. Neither should it
request ANY.)

[…]

--
FSF associate member #7257

Noob <root@127.0.0.1> writes:
> Obviously, the STB is not able to talk directly
> to ipv6.google.com since it does not support IPv6.
>
> I see several work-arounds. The server could be dual
> stack, and provide ALSO an IPv4 address, but 1) IPv4
> address space is running out and 2) the STB might be
> confused by the IPv6 addresses in the DNS reply, even
> if it should just ignore them.
>
> The modem, which is already performing NAT, could
> "rewrite" the DNS packets, and somehow map a few
> IPv6 addresses to unused "virtual" IPv4 addresses.
>
> Is this what NAT-PT proposed?

I think so. There's also an RFC describing some of the problems with
it. Ultimately the only right answer is: the STB must be upgraded to
support IPv6.

In the meantime you may be able to persuade it to use application-level
gateways. For instance, an IPv4-only host accessing the web via a web
proxy on a dual-stack host would be able to see IPv6-only web sites.

--
http://www.greenend.org.uk/rjk/

In article <j0rcqr$nee$(E-Mail Removed)>, Noob <root@127.0.0.1> wrote:

> Now suppose the STB wants to talk to a distant server
> which happens to be IPv6-only, e.g. ipv6.google.com

Why would an IPv4-only device want to talk to ipv6.google.com in the
first place?

--
Barry Margolin, (E-Mail Removed)
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Ivan Shmakov wrote:

> Noob wrote:
>
>> Obviously, the STB is not able to talk directly to ipv6.google.com
>> since it does not support IPv6.
>>
>> I see several work-arounds. The server could be dual stack, and
>> provide ALSO an IPv4 address, but 1) IPv4 address space is running
>> out and 2) the STB might be confused by the IPv6 addresses in the DNS
>> reply, even if it should just ignore them.
>
> Let's check it out:
>
> $ dig ipv6.google.com A

OK, you limited the request to "A" records, while I requested
"ANY" record.

I suppose legacy apps will be using gethostbyname() right?
And it seems gethostbyname will only request A records?

> As could be seen from the above, no AAAA (IPv6 address) resource
> records were returned by the server.

Obviously, since you requested only "A" records.

> So, there's nothing to confuse the device in question.

Thus the IPv4-only device is unable to talk to the
IPv6-only server, right?

> (Of course, it's unlikely that an IPv4-only device will ever
> request AAAA records from the DNS server. Neither should it
> request ANY.)

I mistakenly believed gethostbyname would issue a request
for "ANY" record.

But in the scenario where the modem is trying to provide
"transparent" compatibility with IPv6-only nodes, does
that mean that some DNS-ALG is supposed to rewrite
outgoing DNS requests?

Regards.

Barry Margolin wrote:

> Noob wrote:
>
>> Now suppose the STB wants to talk to a distant server
>> which happens to be IPv6-only, e.g. ipv6.google.com
>
> Why would an IPv4-only device want to talk to ipv6.google.com
> in the first place?

It was only an example to illustrate the existence of
IPv6-only nodes.

foo.greatest-content-since-grilled-cheese.com will
be deployed in 2012 and it will be IPv6-only. And,
as it turns out, every owner of the IPv4-only STB
will want to access that site! :-)

>>>>> Noob <root@127.0.0.1> writes:
>>>>> Ivan Shmakov wrote:

[…]

>> So, there's nothing to confuse the device in question.

> Thus the IPv4-only device is unable to talk to the IPv6-only server,
> right?

Not directly, at the least.

>> (Of course, it's unlikely that an IPv4-only device will ever request
>> AAAA records from the DNS server. Neither should it request ANY.)

> I mistakenly believed gethostbyname would issue a request for "ANY"
> record.

> But in the scenario where the modem is trying to provide
> "transparent" compatibility with IPv6-only nodes, does that mean that
> some DNS-ALG is supposed to rewrite outgoing DNS requests?

I know of NAT64, which is a proposed solution for the inverse
problem. I. e., NAT64 is designed to allow IPv6-only hosts to
connect to IPv4-only ones. Indeed, it requires some DNS
rewriting. So I guess it would also be necessary to allow
IPv4-only hosts to connect to IPv6-only ones.

I should note, however, that while NAT64 relies on a mapping of
the whole IPv4 address space into a part of the IPv6 one, I
cannot imagine a way to map it the other way around.

For the simpler cases, I'd rely on dual stack application-level
gateways (like HTTP proxies), which were already mentioned in
this thread.

--
FSF associate member #7257

["Followup-To:" header set to comp.protocols.tcp-ip.]

On Thu, 2011-07-28, Noob wrote:
....

> I suppose legacy apps will be using gethostbyname() right?
> And it seems gethostbyname will only request A records?

Mine use getaddrinfo(3) even if I haven't tested them with IPv6. It
has been available for a /long/ time -- Stevens wrote about it over a
decade ago -- and is much more convenient than gethostbyname().

There's supposed to be some mechanism for not looking up AAAA on an
incapable host, but I forget the details.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In article <j0s04j$fjk$(E-Mail Removed)>, Noob <root@127.0.0.1> wrote:

> I mistakenly believed gethostbyname would issue a request
> for "ANY" record.

Applications should practically NEVER request ANY records. Unless
you're querying an authoritative server for the domain, ANY != ALL. In
the normal case where you're querying a caching server, it will only
return the records it happens to have cached already, and there's no
reason to assume that this is all the record types for the name (the
only scenario where that's likely to happen is if someone requests ANY
when the server doesn't have anything cached for the name -- it will
then forward the ANY request to an authoritative server and get back
everything).

--
Barry Margolin, (E-Mail Removed)
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***