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

Martin Huněk <martin.hunek@tul.cz> Mon, 13 May 2019 22:14 UTC

Return-Path: <martin.hunek@tul.cz>
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 7A0DA12009E for <v6ops@ietfa.amsl.com>; Mon, 13 May 2019 15:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level:
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no 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 iV9QaVyCwVJb for <v6ops@ietfa.amsl.com>; Mon, 13 May 2019 15:14:46 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (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 5F87D12000E for <v6ops@ietf.org>; Mon, 13 May 2019 15:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from hunator-ntb.local (unknown [IPv6:2001:718:1c01:173:e70b:2ede:d5b4:1f70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 4D045180651E5 for <v6ops@ietf.org>; Tue, 14 May 2019 00:14:43 +0200 (CEST)
From: Martin Huněk <martin.hunek@tul.cz>
To: v6ops@ietf.org
Date: Tue, 14 May 2019 00:14:36 +0200
Message-ID: <129843806.b7yKE7hP11@hunator-ntb.local>
In-Reply-To: <alpine.DEB.2.20.1905131848190.1824@uplift.swm.pp.se>
References: <BYAPR05MB4245A78BEC3D7E3622A38395AE0F0@BYAPR05MB4245.namprd05.prod.outlook.com> <alpine.DEB.2.20.1905131848190.1824@uplift.swm.pp.se>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2388614.rnq1y3LAIg"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/eE1B0YgwSDVa9WhBK6XZd4Dz0K8>
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 22:14:49 -0000

Hi thank you for a review.

Dne pondělí 13. května 2019 19:04:07 CEST, Mikael Abrahamsson napsal(a):
> 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?

Sure, the SRV record does have the TTL value after which would had to be 
renewed. This way it would keep in line with updated settings. It is not 
explicitly written there, I guess it should be.

Question is if the "local domain" should be renewed as well. I think not due 
to security precaution (domain could be received for example from unsecured RA 
so it might be good to wait for expiration), but I would probably let this 
open as the draft doesn't specify domain detection mechanisms.

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

As above, I would mention it in new version, something like: SRV record in use 
must be valid and kept updated according to its TTL value.
> 
> 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?

Yes, that is the idea.

Thanks again for review, I would appreciate any other thoughts.

Regards,
Martin