Re: [93attendees] IETF Meeting NAT64 network

Tore Anderson <tore@redpill-linpro.com> Fri, 24 July 2015 15:03 UTC

Return-Path: <tore@redpill-linpro.com>
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 35A941ACE4E for <93attendees@ietfa.amsl.com>; Fri, 24 Jul 2015 08:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 OFcfZPeeGp2M for <93attendees@ietfa.amsl.com>; Fri, 24 Jul 2015 08:03:49 -0700 (PDT)
Received: from gallus.zimbra.h.bitbit.net (gallus.zimbra.h.bitbit.net [87.238.49.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E241ACE4D for <93attendees@ietf.org>; Fri, 24 Jul 2015 08:03:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id CA935C12C0; Fri, 24 Jul 2015 17:03:47 +0200 (CEST)
Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ezr1TknkcClu; Fri, 24 Jul 2015 17:03:47 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id 596B6C12BE; Fri, 24 Jul 2015 17:03:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at gallus.zimbra.h.bitbit.net
Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q_S8tYWWMj4H; Fri, 24 Jul 2015 17:03:47 +0200 (CEST)
Received: from envy.fud.no (login-osl1.i.bitbit.net [87.238.42.59]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTPSA id C8986C11F5; Fri, 24 Jul 2015 17:03:46 +0200 (CEST)
Date: Fri, 24 Jul 2015 17:03:44 +0200
From: Tore Anderson <tore@redpill-linpro.com>
To: Diego Garcia del Rio <diego@nuagenetworks.net>
Message-ID: <20150724170344.720c9598@envy.fud.no>
In-Reply-To: <3558295463922940016@unknownmsgid>
References: <CAE501C3-2CA5-4317-AA5D-CBC27A6E3B25@stuartcheshire.org> <3558295463922940016@unknownmsgid>
Organization: Redpill Linpro
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/93attendees/Q6VwgSfYTQgLKymNh_ZiY3FNGKI>
Cc: Stuart Cheshire <ietf15@stuartcheshire.org>, "93attendees@ietf.org" <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 15:03:51 -0000

* Diego Garcia del Rio

> 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.

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