IETF Logo Mail Archive

Re: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-analysis-00

Matthew Kaufman <matthew@matthew.at> Wed, 10 November 2010 17:40 UTC

Return-Path: <matthew@matthew.at>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2043A6949 for <behave@core3.amsl.com>; Wed, 10 Nov 2010 09:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.429
X-Spam-Level:
X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlW4aTIxIJ0I for <behave@core3.amsl.com>; Wed, 10 Nov 2010 09:40:24 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id 80F883A69AD for <behave@ietf.org>; Wed, 10 Nov 2010 09:40:18 -0800 (PST)
Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 57B2E148088; Wed, 10 Nov 2010 09:40:44 -0800 (PST)
Message-ID: <4CDAD91B.4020205@matthew.at>
Date: Wed, 10 Nov 2010 09:40:43 -0800
From: Matthew Kaufman <matthew@matthew.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: teemu.savolainen@nokia.com
References: <9B57C850BB53634CACEC56EF4853FF6534384E5E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4CDABD7E.8010506@matthew.at> <18034D4D7FE9AE48BF19AB1B0EF2729F5F05D02959@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F5F05D02959@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Type: multipart/alternative; boundary="------------010609080304070801040708"
Cc: draft-korhonen-behave-nat64-learn-analysis@tools.ietf.org, behave@ietf.org, dthaler@microsoft.com
Subject: Re: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-analysis-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: matthew@matthew.at
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 17:40:25 -0000

On 11/10/2010 8:24 AM, teemu.savolainen@nokia.com wrote:
>
> Hi,
>
> Thank you for feedback. Some clarifying questions
>
> 1)Do you mean such applications cannot even do single DNS query just 
> for learning the NSP (DNS-less host?)? Even if after that they could 
> continue their non-DNS using procedures? What could they do then?
>
I'm ok with a single DNS query (in fact, I don't see any other good 
solution that I can use as an app developer who can't change the OS I'm 
running on), but it needs to be sufficient to calculate all future 
mappings... so I need to get prefix and (if necessary) the algorithm by 
which the bottom part is computed this way.
>
> 2)This sounds like a very hard problem, as how can you possibly tell 
> how many NAT64s there are in an access network? Maybe by downloading 
> some kind of a NAT64 table from network (with DHCPv6?) ? For the case 
> access network does not support discovery of NAT64s with any explicit 
> means, what else host can do than maybe query dozen names (with 
> significantly different IPv4-only addresses) and then live with the 
> NSPs obtained with such an attempt? (send more than two hundred A 
> queries for each /8 subnet in existence?-)
>
One would hope that your DNS64 knows about all your NAT64 options. The 
problem of course is when it tries to be smart, and give you different 
NAT64 based on things like where the IPv4 traffic is going.
>
> Suggestions for better than the proposed ones are also welcome. For 
> both cases: network assisted and without network assistance.
>
My present best suggestion is to force the application to make a AAAA 
query for <ipv4-literal>.<magic-suffix> for every single address. Pretty 
easy to tell if your DNS server is answering those, and once it is it 
probably isn't that hard to do a query for every v4 literal you might 
need to use. It solves the algorithm problem as well as the 
multiple-exits problem., but requires nothing additional that the app 
might not be able to change. It changes the title from "Proposal for 
hosts to learn NAT64 prefix" to "Proposal for hosts to learn 
NAT64-mapped address".

In short, instead of asking for the AAAA for 
"what-is-my-NAT64-prefix.arpa" you would ask for the AAAA for 
"192.0.2.1.is-there-a-NAT64-mapping.arpa" for every single literal you 
need translated.

Matthew Kaufman

v2.23.0 | Report a Bug | By Email