Re: [Int-dir] Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07

Jen Linkova <furry13@gmail.com> Thu, 04 April 2024 07:28 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38C0C14F6ED; Thu, 4 Apr 2024 00:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hedVYC9GYr-w; Thu, 4 Apr 2024 00:28:45 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2D1C14F6E2; Thu, 4 Apr 2024 00:28:45 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2d4886a1cb4so7682721fa.0; Thu, 04 Apr 2024 00:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712215723; x=1712820523; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pDvqQpe0UYemp1IDlGa9lyQd1uPE01kL4BaWVlcnipM=; b=kfDi+qNdXsebPB0Pg9KpaNVAah52rsppn0cclxGsSdj19yruAOptYgVlVf38VK8sJy PVaT85jxbvm7xzPLKxNeoJ/VySeqmoq+/w1ZdWgPgqxouGBbgnYM/nH24bkv1gDXbOay K+eZNeZovjM/fU63tkkuSwprCLeSHDTb30rxS3i1D1SbM5Wm7Seb/BhCD1K5lhHJZKXY z0IgRjRm5y6/mU958FtisldSEgRlodc+fZCVdXioFAeoOA0bwdOS64JJPnomF2GyWF9X BbsaazSU7lztPeucSesEi+dr3U6yQ8qJeHL7MPF+0orW9YMCLW1AwXbPEovr5/uFYWw6 /C8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712215723; x=1712820523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pDvqQpe0UYemp1IDlGa9lyQd1uPE01kL4BaWVlcnipM=; b=VTCt3SdHlU8qaKfPrYIQGceR10EevEe1UIdBBMHr6vXdx+Mlu6XzcW+EhiaC4CBywa Ccqmx0QXOHuOEHmTMwl5Nvee/Sosw2QmqJ9dzKMTYheBhi5t+sLsuO9j7yOnR7qenInA 3BIHfy2nRousejFUFJx4uOS4ZAm4KooXk4RjSbVAQZCpL/eC4+7vngL7gE/pWIYcwwGK yepWzUg1oYJX1gP5wUy+G79hFNarV9V8IkYKuxUQiw+/RIl9eCdTLcnct76bkepjehi3 TS7RCcXAB23d82DW+sokAhv2am2O7SGqJpaWRRVFeRNsX8n4G6M9uJJZKjqtRLeOXwLS 13Vg==
X-Forwarded-Encrypted: i=1; AJvYcCUNl8VDqPa9JZC4Lg0pogI47cvJhhygHBlEH2cAHentWkFSvAGTshV6XRe4njuDOGC2DO3jtK6O50n3cb+nEh6EaIksD/BceOUZSHv3TRkS3OkcjjJpLyw8nb4dyfvD+JDl/ywmoj6BHjgLcIG4Tk2U2loxik51L6VR+/oKu+ZC+iWnjys=
X-Gm-Message-State: AOJu0YxHMJMQqjtGpJzqWgx2NBI2wuyeXd1Vji6g+xFDMzepFkZokmlm 4I6AIohjx0tOUVzDqOMgjp2X0gidI669z9Io6t89Nziq/axnRSmTQkQtUvqCR+rrWhXMWcn/eEO pqKB0RkScPwm/uxaVAQ9vVAMekMlcbycR6IE=
X-Google-Smtp-Source: AGHT+IHxCmbOOIoE18pTtHxooCEZR3jCe7BPyaEgikTLGR91vDqt91q73AC+xZ7cJZkoB6yhKe9HsYR56EFLI7ADzm4=
X-Received: by 2002:a2e:960e:0:b0:2d6:ba96:b9a8 with SMTP id v14-20020a2e960e000000b002d6ba96b9a8mr1321346ljh.27.1712215723118; Thu, 04 Apr 2024 00:28:43 -0700 (PDT)
MIME-Version: 1.0
References: <171154963813.35677.17023374898062077455@ietfa.amsl.com> <CAFU7BAQ6XSo46G72EkF6ieg_N5bg7RRKZ8c_OAQ7=CUsPj5t0A@mail.gmail.com> <2CCBBADB-EEB1-46F7-A043-EF50935D5ED6@jisc.ac.uk>
In-Reply-To: <2CCBBADB-EEB1-46F7-A043-EF50935D5ED6@jisc.ac.uk>
From: Jen Linkova <furry13@gmail.com>
Date: Thu, 04 Apr 2024 18:28:31 +1100
Message-ID: <CAFU7BAR-7Ayw+fKuLH_wHoX2+pD3sZ1xC0LoOPjwubBCfwWydA@mail.gmail.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-v6ops-dhcp-pd-per-device.all@ietf.org" <draft-ietf-v6ops-dhcp-pd-per-device.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/HOH0Wfi3YlWb5F1mApJwxjDwrrM>
Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 07:28:46 -0000

Hi Tim,

> >> It may be useful to explicitly describe how a client using this approach
> >> configures an address through which it can be reached from off the link it is
> >> attached to, e.g, to ssh to it, use an HTTP method, etc.  This is implied in
> >> section 6.4 I think, but could be clearer.
> >
> > Strictly speaking it's the same approach as SLAAC.
> > Would the following text address your concern:
> >
> > DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
> > infrastructure to automatically populate reverse DNS, similarly to
> > what is described in section 2.5.2 of RFC [RFC8501]. Networks that
> > also wish to populate forward DNS cannot do so automatically based
> > only on DHCPv6 prefix delegation transactions, but they can do so in
> > other ways, such as by supporting DHCPv6 address registration as
> > described in [I-D.ietf-dhc-addr-notification].
> >
> > ?
>
> Hmm, there’s the how the node configures an address on that interface,

Ah ;)
The thing is that the host behaviour is explicitly (and intentionally)
out of scope. For me, as a network administrator, it doesn't matter
how exactly the client configures that address: my network
design/topology would be the same. The client can be a RFC7084-type
router (that's what happens when someone plugs a CPE to an access
port), or use smth like rfc7278 - or smth else. Up to the client, the
network routes thet whole prefix to that device, do whatever you want
with it.

>and then also the how that might be added to the DNS. I’m not sure either is stated explicitly at the moment.
>
> I recall ietf-dhc-addr-notification originally included DNS registration, but the current version removed that?

Yes, the dhc-addr-notification doesn't say anything about DNS. What we
are saying in this draft is that the administrator may use DHCP server
logs to populate DNS, if they chose so. Or it could be a dynamic DNS
software run on the device.


-- 
Cheers, Jen Linkova