IETF Logo Mail Archive

Re: [93attendees] IETF Meeting NAT64 network

Pierre Pfister <pierre@darou.fr> Fri, 24 July 2015 09:29 UTC

Return-Path: <pierre@darou.fr>
X-Original-To: 93attendees@ietfa.amsl.com
Delivered-To: 93attendees@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FDF1A8894 for <93attendees@ietfa.amsl.com>; Fri, 24 Jul 2015 02:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.357
X-Spam-Level:
X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_CiOxGDgOxU for <93attendees@ietfa.amsl.com>; Fri, 24 Jul 2015 02:29:05 -0700 (PDT)
Received: from ks395963.kimsufi.com (darou.fr [176.31.121.140]) by ietfa.amsl.com (Postfix) with ESMTP id 185C21A8925 for <93attendees@ietf.org>; Fri, 24 Jul 2015 02:29:05 -0700 (PDT)
Received: by ks395963.kimsufi.com (Postfix, from userid 112) id 502B66034A; Fri, 24 Jul 2015 11:29:04 +0200 (CEST)
Received: from [IPv6:2001:67c:1231:998:49d3:72a5:e2b4:642e] (unknown [IPv6:2001:67c:1231:998:49d3:72a5:e2b4:642e]) (Authenticated sender: pierre@darou.fr) by ks395963.kimsufi.com (Postfix) with ESMTPSA id 026CF601D2; Fri, 24 Jul 2015 11:29:02 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Pierre Pfister <pierre@darou.fr>
In-Reply-To: <CAE501C3-2CA5-4317-AA5D-CBC27A6E3B25@stuartcheshire.org>
Date: Fri, 24 Jul 2015 11:29:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A728501C-1BD3-48A1-A4EF-1F40E2829655@darou.fr>
References: <CAE501C3-2CA5-4317-AA5D-CBC27A6E3B25@stuartcheshire.org>
To: Stuart Cheshire <ietf15@stuartcheshire.org>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/93attendees/qRBG5voUXwwZaHMaOjdies2IMKA>
X-Mailman-Approved-At: Fri, 24 Jul 2015 06:59:56 -0700
Cc: 93attendees@ietf.org
Subject: Re: [93attendees] IETF Meeting NAT64 network
X-BeenThere: 93attendees@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list of IETF 93 attendees that have opted in on this list. " <93attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/93attendees>, <mailto:93attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/93attendees/>
List-Post: <mailto:93attendees@ietf.org>
List-Help: <mailto:93attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/93attendees>, <mailto:93attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2015 09:29:07 -0000

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 <ietf15@stuartcheshire.org> a écrit :
> 
> 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
> 
> _______________________________________________
> 93attendees mailing list
> 93attendees@ietf.org
> https://www.ietf.org/mailman/listinfo/93attendees

v2.8.7 | Report a Bug | By Email