Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Tue, 12 March 2019 15:19 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
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 CDFFB1310B7 for <v6ops@ietfa.amsl.com>; Tue, 12 Mar 2019 08:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 ZmneMKY31I4H for <v6ops@ietfa.amsl.com>; Tue, 12 Mar 2019 08:19:10 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C19713108E for <v6ops@ietf.org>; Tue, 12 Mar 2019 08:19:09 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1h3jBL-0000ImC; Tue, 12 Mar 2019 16:19:07 +0100
Message-Id: <m1h3jBL-0000ImC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <155229467244.16964.2716057971582201801@ietfa.amsl.com> <D2858BBF-D465-4A7C-BAF1-DB71A6241EDD@consulintel.es> <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com>
In-reply-to: Your message of "Tue, 12 Mar 2019 08:58:22 +0900 ." <60747B6D-C9CB-4DDA-89D3-7519DCA07AB5@gmail.com>
Date: Tue, 12 Mar 2019 16:19:07 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XL7aqvyebiQDjGmq1R1bdjVXurw>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 12 Mar 2019 15:19:12 -0000

>I would invite commentary on the substance of the draft, which has to do 
>with how one determines the prefix one should use in a CLAT, and 
>proposes a solution in an SRV record. 

Let me summerize this proposal as: take the search list you get in an RA
option (or from DHCPv6), prepend some strings and use that to look up the
NAT64 translation prefix and other information in DNS.

At first glance it seems clever. And certainly RA/DHCPv6 agnostic.

What I'm worried about is overloading the DNS search list with network 
configuration.

Suppose an organisation or ISP has the same search list everywhere but
some networks have NAT64 and others don't (or different networks have different
prefixes).

You can add a dummy name to the search list, but that name will then attract
DNS lookups.

Another question, how robust is the search list. Do CPEs obtain the search list
from the upstream ISP and then announce them downstream?