[dhcwg] Fwd: I-D Action: draft-ietf-dhc-addr-notification-05.txt
Li HUANG <bleuoisou@gmail.com> Tue, 24 October 2023 18:49 UTC
Return-Path: <bleuoisou@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 A9B3DC151545 for <dhcwg@ietfa.amsl.com>; Tue, 24 Oct 2023 11:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 KF-Incw46fEG for <dhcwg@ietfa.amsl.com>; Tue, 24 Oct 2023 11:49:07 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 E7CFDC14F74E for <dhcwg@ietf.org>; Tue, 24 Oct 2023 11:49:07 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5a9d8f4388bso2732881a12.3 for <dhcwg@ietf.org>; Tue, 24 Oct 2023 11:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698173347; x=1698778147; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=xo+XNLoi1vVby1d59hpV5Qbv13sWml8xhqjLllwFXjw=; b=JQH9kKtM52Hlit2K8xVHakBKLtL7pZ/1tjFQSFfIZSOpgozvNEyy0b7uDdLY3ZTCt3 ZpKvimEiKG7+Ey9BDhU5WeSjAblBH5WQxFyZeR1fFT527o3K0c/mKeyv/OrCKonfCOz7 qz4rM8JznRh3T59a+U4bxaKxLJdQaj/vgM96kHwjpIOcuqS0xFTGsoJy00RNgaY45EAG bLd3xc0OjPoGLTCVSrWmQ6jl/tjQEOAOrY5RjDx4/zUvkRGeUWJSHP6I4ZdNK2f8CxPh qv1Cdr4hz8j3F0+2ZJoscd1GkwC80OK3IOIELLU/N9jkPslQ+vYfUuz+zX2QuZNNhlmx siGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698173347; x=1698778147; h=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=xo+XNLoi1vVby1d59hpV5Qbv13sWml8xhqjLllwFXjw=; b=Gq6ZxD79vrPckq2U6JIr5WfHP0rr0ZjuVyF69UiOhOr6nsnV1bL7vsYwx1/ORfdAuU bqUeLHXw9IbxYjS8e9HENW0Qrz27TJgMJagvfD6/SagV8fvWbvKp4wI3pABei+rgN7+y wxO+PrLLu+mBgsqQkDkG+r+BmuJ/q7PvFSek+STjrMGVKrdOIl5ZfhyW4YMhd2VYpG7P eUI8M4nR2BFPKDsriGc9kT2Uap/RmgQ8gOIyqt0K3u/LfdSV57r3kXypaFeEArIbNC5X WaK6rXBQZf368wbC4fG4PmOxETVRL6QZEA9Iswki1WY3TTTWi4zBfyAXtvZVu9y6/GSf Z3/A==
X-Gm-Message-State: AOJu0Yw6teX9+fydXcSkh1O5t7bVPn65efS+ha4LW08TVlP3849jsvIy KfuzZVylyUppaqlnVUGGn6PyRom4tvvQBMeFiJUC4Y40Kro=
X-Google-Smtp-Source: AGHT+IEs9ZeXGy4hxzgfStOgRYgLRxxIecuP4eg18pbhkJAQJXxnHHulV9YFOYMKXU62DWoUzDdu5kRLVe+IQV/UrEM=
X-Received: by 2002:a17:90b:1d01:b0:27d:26f1:3b55 with SMTP id on1-20020a17090b1d0100b0027d26f13b55mr10513502pjb.16.1698173346839; Tue, 24 Oct 2023 11:49:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BASxV++n7GB4vOsQaui0No_KrnZxo6GTUqxEfL+sFUapMw@mail.gmail.com> <554CED20-1D2A-4184-A73F-77CE7C06C3BC@gmail.com> <CAFU7BAQQ0YYP6+u5T0NAzfhazxjPM3E2AQGPaJNQ2PD-knuqiQ@mail.gmail.com>
In-Reply-To: <CAFU7BAQQ0YYP6+u5T0NAzfhazxjPM3E2AQGPaJNQ2PD-knuqiQ@mail.gmail.com>
From: Li HUANG <bleuoisou@gmail.com>
Date: Wed, 25 Oct 2023 03:48:54 +0900
Message-ID: <CAGGiuEbod7Vayy2uOgydErn=rBrJWsFRO0EXFbyyKgS15kGJvQ@mail.gmail.com>
To: dhcwg <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001b03a106087acbc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/_Xl4F29yIGKPvFlDKXH8dDY_2Gw>
Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-addr-notification-05.txt
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, 24 Oct 2023 18:49:11 -0000
Oct. 25 2023 03:44.co.jp X30 To a region where in any way, the wan being "managed" ,dhcpv6 for an end user, where to get the *authority* what discussing the minor here please...? Sincerely Li HUANG ---------- Forwarded message --------- From: Jen Linkova <furry13@gmail.com> Date: Tue, Oct 24, 2023, 21:21 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-addr-notification-05.txt To: Bernie Volz <bevolz@gmail.com> Cc: <dhcwg@ietf.org>, <draft-ietf-dhc-addr-notification.authors@ietf.org> On Mon, Oct 23, 2023 at 6:34 PM Bernie Volz <bevolz@gmail.com> wrote: > Ok, thanks for updated draft. Likely you were trying to meet the publication deadline. I was really hoping it's not *so* obvious ;) > There are places were OPTION_ADDR_REG_ENABLE and OPTION_ADDR_REG (& ADDR_REG_ENABLE) are used, you likely want to standardize on one? Oh yes, indeed, sorry. Clearly an oversight, will be fixed. > If there are multiple servers serving clients, it is possible that one supports this new mechanism and another does not, do you want to discuss that? This really isn’t much different than if one server provides DNS information and another does not - depending on which reply a client receives will control whether it has dns resolvers or not, but also in this case the server that doesn’t support address registration may still receive those address registration messages. Obviously the multiple servers should be configured/updated the same. Yes, I wasn't sure if it needs to be explicitly discussed or not. What Section 4.4 ( https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-05.html#name-address-registration-suppor ) is trying to say is "as long as *at least one* of Replies received for the given Information-Request contains OPTION_ADDR_REG_ENABLE, then the client is allowed to send the registration information, If no Replies contain that option, it means that no servers support the mechanism, so shut up until one of the subsequent Replies tells you otherwise". So yes, if only some servers support the mechanism, then those w/o the support would receive some garbage and drop it. It seems harmless enough and could be either a misconfiguration or just a transition period, when the registration mechanism is incrementally enabled on the network. I took a note to add some text about in Section 4.4. Will be added in the next revision. > > On Oct 23, 2023, at 12:23 PM, Jen Linkova <furry13@gmail.com> wrote: > > > > Hello, > > > > First of all, thanks to everyone who reviewed -04 during the WGLC and > > provided comments/suggestions! > > So, as a result of the WGLC we updated the draft suggesting the following: > > - a new Address Registration option (OPTION_ADDR_REG_ENABLE) of zero > > length (https://datatracker.ietf.org/doc/html/rfc7227#section-5.2) is > > created to signal that the server supports the address registration. > > - Information-Request message is sent by the client upon connecting to > > the network and then periodically, and the Option Request Option > > includes that new OPTION_ADDR_REG_ENABLE. > > - servers supporting the registration mechanism would include > > OPTION_ADDR_REG_ENABLE into their Reply messages. > > > > Upon receiving a Reply containing OPTION_ADDR_REG_ENABLE, the client > > starts the registration process using the mechanism described in -04 > > (no changes there). > > > > Another option would be using Information-Request messages as a > > container for all address registration data, as Bernie suggested. > > However the authors would prefer the way currently described in this > > document for the following reasons: > > > > - the proposed mechanism allows the host to detect the server support > > (or lack thereof) by sending just one multicast packet (assuming there > > is no packet loss). If the client uses Information-Request to > > register the address and stops the registration upon receiving some > > signal, it might result in multiple packets being sent (one per > > address) unless the client implements some complex logic to avoid > > that. > > - as per RFC8415 the client MUST include a lot of things into its > > Information-Request message. So the registration messages will be > > inflated unnecessary (especially as most clients have multiple SLAAC > > addresses). > > - registration refresh timers depend on the address lifetime and might > > conflict with INF_MAX_RT. > > - it's unclear if all implementations would be happy with > > Information-Request messages coming from global sources. > > > > Looking forward to comments/suggestions on the list and in-person > > discussion in Prague! > > > > P.S. A disclaimer: it's quite possible that some new "SHOULD" in the > > document should be MUST and vice versa ;) > > > >> On Mon, Oct 23, 2023 at 9:02 AM <internet-drafts@ietf.org> wrote: > >> > >> Internet-Draft draft-ietf-dhc-addr-notification-05.txt is now available. It is > >> a work item of the Dynamic Host Configuration (DHC) WG of the IETF. > >> > >> Title: Registering Self-generated IPv6 Addresses using DHCPv6 > >> Authors: Warren Kumari > >> Suresh Krishnan > >> Rajiv Asati > >> Lorenzo Colitti > >> Jen Linkova > >> Sheng Jiang > >> Name: draft-ietf-dhc-addr-notification-05.txt > >> Pages: 16 > >> Dates: 2023-10-23 > >> > >> Abstract: > >> > >> This document defines a method to inform a DHCPv6 server that a > >> device has a self-generated or statically configured address. > >> > >> The IETF datatracker status page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/ > >> > >> There is also an HTML version available at: > >> https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-05.html > >> > >> A diff from the previous version is available at: > >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dhc-addr-notification-05 > >> > >> Internet-Drafts are also available by rsync at: > >> rsync.ietf.org::internet-drafts > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg -- SY, Jen Linkova aka Furry _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] I-D Action: draft-ietf-dhc-addr-notificat… internet-drafts
- Re: [dhcwg] I-D Action: draft-ietf-dhc-addr-notif… Jen Linkova
- Re: [dhcwg] I-D Action: draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] I-D Action: draft-ietf-dhc-addr-notif… Jen Linkova
- [dhcwg] Fwd: I-D Action: draft-ietf-dhc-addr-noti… Li HUANG
- Re: [dhcwg] I-D Action: draft-ietf-dhc-addr-notif… Bernie Volz