Re: [v6ops] combination of NAT64/DNS64 and NAT44

Simon Perreault <simon.perreault@viagenie.ca> Wed, 17 April 2013 14:43 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0522021E803D for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2013 07:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtORSDRBVuaO for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2013 07:43:25 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D321F8550 for <v6ops@ietf.org>; Wed, 17 Apr 2013 07:43:25 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A9FA040401 for <v6ops@ietf.org>; Wed, 17 Apr 2013 10:42:54 -0400 (EDT)
Message-ID: <516EB4EC.7010102@viagenie.ca>
Date: Wed, 17 Apr 2013 16:42:52 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: v6ops@ietf.org
References: <alpine.DEB.2.00.1304171206080.23668@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.00.1304171206080.23668@uplift.swm.pp.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [v6ops] combination of NAT64/DNS64 and NAT44
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 14:43:26 -0000

Le 2013-04-17 12:23, Mikael Abrahamsson a écrit :
> A device has dual stack access on its WAN access, with IPv4 RFC1918
> addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44
> gateway for sharing these addresses towards the Internet, and GUA IPv6
> addresses. There is also a NAT64 gateway in the network, and a DNS64
> resolver reachable over IPv6. There is a regular resolver reachable over
> IPv4. A dual stack client will get both types of resolvers.
>
> Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and
> dual stack. The single stack cases are pretty obvious (IPv4 single stack
> will use NAT44, IPv6 single stack will use NAT64/DNS64 and require
> 464XLAT for "proper" function), but my question relates to the dual
> stack case. With a DNS64 based resolver, only IPv4 literals will go over
> the NAT44, if the device uses the IPv6 based resolver.

This is not quite true. Happy-eyeballs algorithms will direct some 
traffic over IPv4 even if IPv6 is available. It could even be a lot of 
traffic, or even most traffic, depending on traffic patterns.

> If it uses the
> IPv4 based resolver, it will use the NAT44 device for IPv4 only sites.
>
> So my questions are:
>
> 1. Is there a case where the above setup will cause problems?

It should work, but it will not be fun to operate.

> 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver?
> This would cause AAAA lookups over IPv4 to steer traffic towards the
> NAT64 gateway, in case a client chooses to use the IPv4 based resolver
> for lookups even if it's dual stacked. As far as I understand, a DNS64
> based resolver will forward A quaries unmodified so this shouldn't cause
> any problems for single stacked IPv4 clients?

It makes a lot of sense, especially since some implementations do happy 
eyeballs at the DNS level and cache the first result received. So an 
otherwise perfectly dual stack node might end up not using the NAT64 if 
it happens to obtain results from the IPv4 resolver first and that 
resolver doesn't do DNS64.

> 3. Did I miss anything?

It might not be immediately useful to you, but you should know about 
this draft:
https://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic

Other than that, my main feedback would be: you want to provide NATed 
IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. 
operating an IPv6-only network?

Simon