[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