Subject: [93attendees] IETF Meeting NAT64 network

From: Stuart Cheshire <[email-masked]>
Date: Fri, 24 Jul 2015 02:07:47 -0700

I’ve spent the entire week of this IETF meeting on the “ietf-nat64” network, on both my iPhone and my laptop. With just one exception, everything has worked fine and I have not had any problems (from what I’ve heard, the NAT64 network has actually been working *better* than the IPv4 network).

The exception mentioned above was trying to pay my Amazon credit card bill on-line, which involves accessing www.onlinecreditcenter6.com. That domain name appears to have a broken DNS server, which doesn’t answer AAAA queries, and the failure to respond to AAAA queries results in the DNS64 engine returning a SERVFAIL error instead of synthesizing a AAAA record from the IPv4 address record that it does have:

% host www.onlinecreditcenter6.com
www.onlinecreditcenter6.com has address 216.74.188.135
Host www.onlinecreditcenter6.com not found: 2(SERVFAIL)

This seems like a fixable bug in the DNS64 engine. If a server has no IPv6 support, and a broken DNS server that also doesn’t know that IPv6 exists, that should not stand in the way of DNS64/NAT64 creating a communication path to the server’s IPv4 address.

This is reminiscent of my 2008 talk at IETF 72 about the perils of blocking forever waiting for an IPv6 response that will never be coming: <http://www.stuartcheshire.org/IETF72/>

Stuart Cheshire

---

From: Diego Garcia del Rio <[email-masked]>
Date: Fri, 24 Jul 2015 11:39:05 +0200

I tried to revert to ietf-nat64 when the wifi went doesn't and
unfortunately encountered two issues. One was that for whatever
reason, the DNS resolution for one of our company's vpn endpoint was
being answered as an IPv4 record. Couldn't figure out the logo why to
be honest. The second was that even after configuring a manual host
entry, my ssl Vpn client would fail to finish the connection (has some
issues with routes it needed to install locally). That I blame on the
client. My other IPSec client refused to work over v6 but was at least
very clear. "IPv6 not supported". Oh well :(

> On Jul 24, 2015, at 11:08, Stuart Cheshire <[email-masked]> wrote:
>
> _______________________________________________
> 93attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/93attendees

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 24 Jul 2015 11:29:12 +0200

Hello Stuart,

Interestingly enough, I had the exact same bug this morning on ietf-nat64, with a payment system as well.

DNS was returning a A address but no AAAA.

- Pierre

> Le 24 juil. 2015 à 11:07, Stuart Cheshire <[email-masked]> a écrit :
>

---

From: Tore Anderson <[email-masked]>
Date: Fri, 24 Jul 2015 17:03:44 +0200

* Diego Garcia del Rio

> be honest.

Hi Diego,

DNS64 does not filter out IPv4 addresses; IN A records are returned
normally. The synthetic IPv6 IN AAAA responses are returned *in
addition* to the upstream IN A records (assuming the application
queries for both). So what you describe is actually expected behaviour.

FWIW I spent most of my time on ietf-nat64 as well, using Linux with
464XLAT. It was working very nicely, and I think better than plain
"ietf", except for some connectivity issues I had on Tuesday
(periodically losing the ability to communicate with the default router
and beyond with unicast frames). That was not a NAT64 problem though,
but an IPv6-only problem that applied to ietf-v6only as well -
as I understand it, the wireless infrastructure assumed that clients
without a (non-169.254.0.0/16) IPv4 address weren't at all interested in
having network connectivity...

Tore

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jul 2015 17:36:32 -0400

Openvpn requires some tweaks to work on nat64, but it can be made to work.