From nobody Sat Apr  8 17:49:16 2023
Return-Path: <furry13@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id A5D01C152A02
 for <dhcwg@ietfa.amsl.com>; Sat,  8 Apr 2023 17:49:15 -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_DNSWL_NONE=-0.0001, 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 hS0RGFT6620h for <dhcwg@ietfa.amsl.com>;
 Sat,  8 Apr 2023 17:49:15 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [IPv6:2a00:1450:4864:20::235])
 (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 3DB4EC14F726
 for <dhcwg@ietf.org>; Sat,  8 Apr 2023 17:49:15 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id e20so1990107lji.6
 for <dhcwg@ietf.org>; Sat, 08 Apr 2023 17:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1681001353; x=1683593353;
 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=U5qaIZidyESUk2NJUr302lJVb+oOVI9fd8NoJdd2wHE=;
 b=lnUVo8VdJVdegGXcusNtRG5ZBy//bEWcMjjHfFx/h1RLRLOIOTzb5THL20KwLKHTun
 qLkNhT8/ZCh4sESQisNhvY6yOU/wdCaafLb/QRZSU/YQ5s8LWfUhQCNGVMTyoZrKyB+/
 96QHZHnsDt24Y0rXx5KO9qYAObOYBCByJ5mukOCPe89wpWVthOJEhkzr6yl930Uf/sjr
 ZTkZMP+ArTb/oCSgIkBdHxKv7VBDOXheNvbAJmnk4HFO3LvFq5RQrfcMz3qLtmVVBTtp
 CABoOIhkFqxJESflEBuz1Gf7ynOKMZ84mF67QPi0BZjoJ9GMGbSlSWoWYO2WCrw1Auey
 8Y5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1681001353; x=1683593353;
 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=U5qaIZidyESUk2NJUr302lJVb+oOVI9fd8NoJdd2wHE=;
 b=vsqcMrpLECPXnN5FDczwf7GjCg3BBUjitucHTs0gzbf8Vd632jZjhKB4iIxsT+jiTn
 6KoyFGa/M+BEJT9ZNgiAA2lRZqlalDthgiCS7DxB2n5dtt1y5yU4JjlV9AoG/27hBhNz
 SO36h6LZZrbNh3YW/4xLb2LIFdb6GnX0TWg1nTgD0lBg/dls0JJQ7tRNB/7EbZkRq6rm
 4G2aV+RIp5gsN2xRYuTryIBBiInrnxBEz4mt81xawCARGcDhiFvGyKBBHZ6c4Ts7WAdQ
 HMiVsyzzr8zldzSwdTTw4Bui5vENOW1QIQzYintXz2QUvXbou0L7KgYS8qeiqIej8qzv
 Vvag==
X-Gm-Message-State: AAQBX9eGa64NOWBF61WXIknnlvWpiYFmSUVy5STvOKT0+wtmdE45Gy8b
 JdWv3K/kFEvGmOI6u3QMvX7zAv9J/1vdfbJvY9nr6ucdQ5E=
X-Google-Smtp-Source: AKy350b4YqCRIoWjJVu6kFL06yY8Qtu8RqAtupv447b8KDfddRKEXFlH9RttZK1V2WRYQKiyk6U/KJhas1mijKLZ7og=
X-Received: by 2002:a2e:9d04:0:b0:299:ac5e:376e with SMTP id
 t4-20020a2e9d04000000b00299ac5e376emr1642644lji.2.1681001353518; Sat, 08 Apr
 2023 17:49:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAJgLMKsH9ZqXjwDbYo4izUiOM27tuH_gk_rZPW8H52BawQ48mg@mail.gmail.com>
 <5948.1680883536@localhost>
 <CAFU7BARWZSY8ORz-_iXYxgU4JKnzC5NVEUG6DZHXByhqpJiX_w@mail.gmail.com>
 <14663.1680980580@localhost>
In-Reply-To: <14663.1680980580@localhost>
From: Jen Linkova <furry13@gmail.com>
Date: Sun, 9 Apr 2023 10:49:01 +1000
Message-ID: <CAFU7BAQWjch=LdtUf0iJWmpq5D3yavsEXnR5B=1W-NQjq1tG3Q@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: dhcwg <dhcwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/7l2Raaglde__k5wh5ikF7EJuOKI>
Subject: Re: [dhcwg] Adoption Call for
 draft-wkumari-dhc-addr-notification-07- Respond by April, 20 2023
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>,
 <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>,
 <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Apr 2023 00:49:15 -0000

On Sun, Apr 9, 2023 at 5:03=E2=80=AFAM Michael Richardson <mcr+ietf@sandelm=
an.ca> wrote:
> Jen Linkova <furry13@gmail.com> wrote:
>     >> It seems that this will be in conflict with
>     >> draft-collink-v6ops-ent64pd, should it be adopted.
>
>     > I'm not sure it's the case, actually.  Let's say my DHCP server kno=
ws
>     > that clients on the link A should be delegated the prefixes from
>     > 2001:db8:a::/48.  Then if it receives ADDR-REG-INFORM from link A f=
or
>     > an address in 2001:db8:a::/48, it shall be considered "appropriate =
for
>     > the link".  Or am I missing smth?
>
> So 2001:db8:a::/64 is the "LAN" onlink.
> And host 2001:db8:a::1234 has done a DHCP-PD and been delegated 2001:db8:=
a:0001::/64.
> It now sends a registration for 2001:db8:a:0001::babe/128.
> Does it send that from 2001:db8:a:0001::babe or from 2001:db8:a::1234?

Strictly speaking, in the deployment model described in
draft-collink-v6ops-ent64pd, the host SHOULD NOT
have an address from  2001:db8:a::/64 at all.
Even if it does, for some reason, got both  2001:db8:a:0001::babe and
from 2001:db8:a::1234, it would send two
registration messages, one per address.

> I prefer that it sends it from ::babe.
> I prefer that we don't try to associate the delegated /64 with the addres=
s
> that asked for it... because... a) the requesting address might change du=
e to
> reasons (privacy, etc.)   b) OSPF might move the prefix around a bit.

You'd need to associate the PD pool with *the network segment*, not
individual addresses. I'd need to delegate different prefixes to
devices in my Guest network and to corporate workstation, the same way
I assign on-link /64s now.
So the server obviously would need to know  if the registration
message can come from the given *segment* (not host), or not.
You can not tell if the given host on that segment can send it or not
(but that's why the message shall be sent from the address being
registered).

>     >> Does the packet need to originate from the IP address which is bei=
ng
>     >> registered?
>
>     > This is to prevent spoofing: the host would need "own" the address,=
 if
>     > the infrastructure supports SAVI.
>
> So, the answer is yes, it must originate from the IP address which is bei=
ng registered?

Ah sorry, I read your question as "does it *really* need to do this?".
Section 6.1:
"The host MUST send the packet from the address being registered."

--=20
SY, Jen Linkova aka Furry

