Re: [dhcwg] AD review of draft-ietf-dhc-addr-notification-10
Jen Linkova <furry13@gmail.com> Tue, 09 April 2024 23:15 UTC
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 C4E4DC14F6BB for <dhcwg@ietfa.amsl.com>; Tue, 9 Apr 2024 16:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.848
X-Spam-Level:
X-Spam-Status: No, score=-6.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_HI=-5, 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 ItgPpDqiTEwF for <dhcwg@ietfa.amsl.com>; Tue, 9 Apr 2024 16:15:11 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 41225C14F6AE for <dhcwg@ietf.org>; Tue, 9 Apr 2024 16:15:11 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-5171a529224so3303718e87.0 for <dhcwg@ietf.org>; Tue, 09 Apr 2024 16:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712704509; x=1713309309; 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=J2KjY/I4ss8XIvk5YhOvSzDTxRyKUoGjxc1Z7FA/Xl8=; b=WQjGGtytdWF1z5xjrKoUw8T6hehdK9ED0Q+DfLd+RwiVctwAKP8FOe/mYtWxk311Mt cyDOfNUcR6qaz0CH6VFVUb0SyNjqJf/JP76RSpffOgpJW57AVNolp+KT88Mlx1M7hXgn WApbdbsZXI6iHCpn+ruevCdAXmoYsCju4rRJebtdmx99OAhuWxzNUEg5g1F1/xpFrvPN 6ar8B9ZrEAO/nkXTM/e47mZ4eLGCspqcZh8xOrRTgeUJE8HF+6xsEt70+b/4Ef/fmY7Q Z4t1j6h5qmjpbPT7aCEbZctFJRS96sopQUceiA2+PVHRSmRnaAgy2VoKgzNagoC+Xb50 +M9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712704509; x=1713309309; 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=J2KjY/I4ss8XIvk5YhOvSzDTxRyKUoGjxc1Z7FA/Xl8=; b=chQWu2YTY4X/mMA+zTJq8DTmz2cEITwEAlC90bgm//0oL63K/fX3Xu2izZPDPgWUMM Fdcjw3kp26NpliA2FDtPL0jtfC+MA8zRKm+l3hIvX/Nmxjc+Tm2mFNQz6gTmj2mPGllI Wy6rlb5Tzy3n6SCt1WCObA+k6MxuepH3Mo8OE9iVVdUeY2wWEUx67dK/X0x1CYKaqkhd wedqar1f8C53eeK6VxCbQVPCfltzpvBpm1VRIJNsR9l3AkSMSozq8VcD7I1zDdJFDlRC L4ueKuG9POpFmx2rwIWbK2Q6BcR72zqmnj6m73whIYCbdiiIh//AdRw6l39OXP9WpKTj EzTw==
X-Gm-Message-State: AOJu0YwTZDbSdH6bktEN2BHnXIPSw1pJz79VR9B7sPR8YXUZj5glCvLM riI5HkoGg+xVmCVdc8RIEhtQuXMdmtJEGtl5AWWKBA1udI0NRwy/aDnlwFI6r0avWO84Lc+V1LU Jf79zKoXj05W8qW3WRyXyRL7Vk/o=
X-Google-Smtp-Source: AGHT+IG1L3cieacqN4hEl2NxMOsCRMN9NkrSRKOCNDgjeW1Mvbj9Dp4UWJsIlEVgYjdk1ng81rj3Lb5a74K3bh2q944=
X-Received: by 2002:a2e:9b43:0:b0:2d8:ac90:165c with SMTP id o3-20020a2e9b43000000b002d8ac90165cmr712811ljj.27.1712704508574; Tue, 09 Apr 2024 16:15:08 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR11MB49661E586240C0F620E04783A9032@PH0PR11MB4966.namprd11.prod.outlook.com>
In-Reply-To: <PH0PR11MB49661E586240C0F620E04783A9032@PH0PR11MB4966.namprd11.prod.outlook.com>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 10 Apr 2024 09:14:56 +1000
Message-ID: <CAFU7BAS2bhayYmyNya0pDDGDd4XwaqRF579H4WoGhGv6y_bXgw@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "rajiv.asati@gmail.com" <rajiv.asati@gmail.com>, Warren Kumari <warren@kumari.net>, "suresh.krishnan@gmail.com" <suresh.krishnan@gmail.com>, Lorenzo Colitti <lorenzo@google.com>, "shengjiang@bupt.edu.cn" <shengjiang@bupt.edu.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/VVThyxr_Zt6FPVjSFIyZQNM1QHI>
Subject: Re: [dhcwg] AD review of draft-ietf-dhc-addr-notification-10
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: Tue, 09 Apr 2024 23:15:11 -0000
Hi Eric, Thank you very much for your review and comments. Sorry for the delayed response, the authors have been discussing the remaining open items, our comments are below. On Sat, Apr 6, 2024 at 1:38 AM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote: > Figure 1, suggest to also add the dst address. We'd prefer not to. The diagram focuses on elements which are either new (different from existing mechanisms) or important for understanding the proposed concept. That’s why Fig1 shows the source address: unlike all other DHCPv6 communications, ADDR-REG-INFORM MESSAGE is sent from the global address, not the link-local one. That difference is important to emphasize. The dst address is the standard multicast, so nothing new here. Adding it overloads the diagram with information and makes it harder to understand IMHO. > ` The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6.` what about the very special and rare case where not all multiple DHCPv6 servers have received the confirmation of address lease ? Well...This sounds like a problem DHCPv6 protocol should address with or without this proposal. Improving DHCPv6 reliability is out of scope for this draft (and sending ADDR-REG-INFORM for addresses received via IA_NA is a very high price to pay: it would be *very* noisy if we allow the client to register DHCPv6 addresses - and this group has spent a lot of time discussing how to optimize the registration algorithm to minimize the amount of multicast noise... So while nothing would be broken if we replace 'MUST NOT' with 'SHOULD NOT', it looks very much undesirable. > # Section 4.2.1 > In the case of multiple DHCPv6 servers, how can ` within a prefix delegated to the client`be checked ? There is not much difference between knowing which prefix is “appropriate for the link” and knowing which pool is used on the given link: both require some knowledge of the topology. If the administrator runs multiple DHCPv6 servers which share the same pool - some mechanism to keep the data in sync would be required anyway, even w.o this proposal - and defining such a mechanism sounds like out of scope of this draft. In case of a multi-homing scenario (or multiple administrative domains, each operating its own DHCPv6 infrastructure), then each DHCPv6 server would only register addresses belonging to its address space. Would adding the following text to the end of Section 4.2.1 address your concern?: “If a client is multihomed (connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate for the link or belongs to a delegated prefix ensures that each DHCPv6 server only registers bindings for addresses from the given administrative domain.” > ` SHOULD log the address registration information` should probably be more explicit about which information... I.e., DUID not always have MAC addresses. We’d like the behavior to be consistent with what the server does for assigned addresses and delegated prefixes, hence the text is saying “as is done normally for clients to which it has assigned an address” - we shall probably update it with “...or delegated a prefix” though. The proposed text: “the server SHOULD log the client DUID and the link-layer address, if available. The server MAY log any other information” > ` SHOULD mark the address as unavailable for use and not include it in future ADVERTISE messages` when can this SHOULD be bypassed ? I would assume that a MUST would be safer. If the DHCPV6 pool configuration permits a collision between DHCPv6-assigned and SLAAC addresses, then that problem exists even w/o this proposal. This draft provides an additional signal to prevent the collision but it should be up to the server administrator to use it. Making this SHOULD a MUST would be safer but wouldn't guarantee that there is no collision. MUST would prevent a server from assigning an address that another host has registered. But it wouldn't prevent a host forming an address with SLAAC that the server has assigned to another host. That has to rely on DAD or on the laws of probability. Given that MUST can't guarantee that collisions don't occur, SHOULD seems appropriate. Additionally, a very simple implementation of this draft could simply just log and do nothing else. Unless the hosts are malicious or the network is extremely large, this will work very well in practice, because a collision is extremely unlikely (even with 100k clients it's less than one in a billion). If we said MUST, such an implementation would be non-compliant. > ` SHOULD include the client's link-layer address in the relayed message` when can this SHOULD be bypassed ? I.e., without the client MAC, there is little use of this I-D. Good point, thank you! The proposed text: “DHCPv6 relay agents and switches that relay address registration messages directly from clients MUST include the client's link-layer address in the relayed message using the Client Link-Layer Address option ([RFC6939]) if they would do so for other DHCPv6 client messages such as SOLICIT, REQUEST, and REBIND” > Should the client periodically try to register ? I fear that some statically addressed nodes will never register as they could stay for years without reboot or move. Warren's comment summarizes the WG decision. Anyway, statically assigned addresses are not the primary use case for this proposal... -- Cheers, Jen Linkova
- [dhcwg] AD review of draft-ietf-dhc-addr-notifica… Eric Vyncke (evyncke)
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Warren Kumari
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Jen Linkova
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Eric Vyncke (evyncke)
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Warren Kumari
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Lorenzo Colitti
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Eric Vyncke (evyncke)
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Warren Kumari
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Rajiv Asati