Re: [v6ops] draft-ietf-v6ops-nat64-srv

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 13 May 2019 17:04 UTC

Return-Path: <swmike@swm.pp.se>
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 5AA981201A0 for <v6ops@ietfa.amsl.com>; Mon, 13 May 2019 10:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 mlA4i3uveF9R for <v6ops@ietfa.amsl.com>; Mon, 13 May 2019 10:04:10 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 E861912019B for <v6ops@ietf.org>; Mon, 13 May 2019 10:04:09 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B380FB3; Mon, 13 May 2019 19:04:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557767047; bh=CYOQeM7HFq7t/YiOOYNhGxk597VXW6SlWRHquoUJidQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RdqAMG9/Dzr6V1y2x3eUMqnJ/ymZpK9fJIxuokRToyoUgXSbeqRzqYrj3hmiUmwH0 WwjfQ2upryTRocZPk1qPii/hh7dy0wdXpn4CGXg0TuKqgjgEVF7hDX6Kg8p8/TDNob iBgLXbaoeIzB+8xGVkH96fahAng8jOJhf9WHkCnA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B148FB2; Mon, 13 May 2019 19:04:07 +0200 (CEST)
Date: Mon, 13 May 2019 19:04:07 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
cc: "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <BYAPR05MB4245A78BEC3D7E3622A38395AE0F0@BYAPR05MB4245.namprd05.prod.outlook.com>
Message-ID: <alpine.DEB.2.20.1905131848190.1824@uplift.swm.pp.se>
References: <BYAPR05MB4245A78BEC3D7E3622A38395AE0F0@BYAPR05MB4245.namprd05.prod.outlook.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YxPWZBcuMJCQv8emVkxTWc-GVZA>
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
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: Mon, 13 May 2019 17:04:12 -0000

On Mon, 13 May 2019, Ron Bonica wrote:

> This week, please review and comment on draft-ietf-v6ops-nat64-sr .

I'm generally sympathetic to the problem space this draft tries to solve.

I'm struggling a bit with the different states that the device can end up 
in over time, and also if these lookups should only be done at connect 
time, or do they continue frequently in case the operator changes the 
information? Is there a lifetime to them? If not, why?

Think of a device that is connected for months, how are changes performed? 
What triggers a refresh? The word "time" or "life" (as in lifecycle) 
doesn't exist in the draft.

Perhaps the built in TTL in DNS can be used and lookups are done per 
normal DNS procedures and if the information changes then the settings are 
updated accordingly?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se