Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-notification
Lorenzo Colitti <lorenzo@google.com> Tue, 16 January 2024 15:07 UTC
Return-Path: <lorenzo@google.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 934F6C14F6FF for <dhcwg@ietfa.amsl.com>; Tue, 16 Jan 2024 07:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Level:
X-Spam-Status: No, score=-17.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 x9-Ux29_gudr for <dhcwg@ietfa.amsl.com>; Tue, 16 Jan 2024 07:07:19 -0800 (PST)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 A0422C1519A0 for <dhcwg@ietf.org>; Tue, 16 Jan 2024 07:06:24 -0800 (PST)
Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-68163449a36so8534706d6.2 for <dhcwg@ietf.org>; Tue, 16 Jan 2024 07:06:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705417583; x=1706022383; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kUou5F+KFx4lk5Nz5rQ+n71EAHM6T3gP9dT+oGdthd8=; b=odfswWmr5/fnwzFaeTEDsidavyqXVyItrbH1fyded9q5WnzvK+1hN4ZAl//t8bWTT7 JL+XD+Nx3nOY/IDtYBk61QaRG3P7HQ4FEqJl67W6m75AuSEe3bBchbP/TTEj7QPZZ0y0 RP/6WfxZqv4DJNKzNiqyMQ2wUV2PKMkghm4vmbRDPqMOHLS0gs4pXwzc1FV268HRHLBs hmSFgy4LrjDhHpQqAUZVUlTICsJd2dS9+ygnQ7GNFUC2Raxu3+q70cc4fKg7fV11lXin hj2Hsat25Y0sCeIs7R1voKYr4e43lTRQOcVjOxD0mKWwUXsnmSbK2EiTzcp319BrDETw CEtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705417583; x=1706022383; h=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=kUou5F+KFx4lk5Nz5rQ+n71EAHM6T3gP9dT+oGdthd8=; b=F4fIpooNkpDvDwG5912eyWm6XP8PXHTbmgy6F+4mnUs4+DCEOuGsBPP33bQLy6piYc mczDa6oBYhUcQ86gSMY8mjKIosy1Sx8MTUJ5sqCW3gNsNmZWH3ljoFEXSGQr+pCDRdAs a+aqh75kbf7nb8CyYh3KmUl1yZwGSXTlpATReJ0kYyFIOgwb5pUt0QRFKt5yZUfd4x2z lxdB5iKTdGg0isLCThqYpKGtrjwOE8G3Bftiob77E25b9h/hpIiQIkMBTWZpQOgxNox4 E7EILOpZDZhhfLVOYA6COhLqF5FvIG331O4zQ1VuyJDkennLgPpbW0CpdKX8axSuGHSt zXOw==
X-Gm-Message-State: AOJu0Yydoa64Nkg7991XPznOQn1bsIcKYD+U9elNipi4N85aZlOAWg3F gFwYxs2m9PcL5aKKgdj0Ne1layYqcnXDrN2HMYUTs8S2AWCFeIl3TwpyVNGVjjuO
X-Google-Smtp-Source: AGHT+IH68WW+NrHvKL4mE4FUZm8d8l+XFXRO6JcrrvJDtF8KLLSIex6ePFagmPglqtX4yfBusgqXQwI6uRvpc498WC8=
X-Received: by 2002:a05:6214:2265:b0:680:caa6:9612 with SMTP id gs5-20020a056214226500b00680caa69612mr8631741qvb.111.1705417583463; Tue, 16 Jan 2024 07:06:23 -0800 (PST)
MIME-Version: 1.0
References: <MN0PR21MB3240FBA9937882A154298231F6662@MN0PR21MB3240.namprd21.prod.outlook.com>
In-Reply-To: <MN0PR21MB3240FBA9937882A154298231F6662@MN0PR21MB3240.namprd21.prod.outlook.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 17 Jan 2024 00:06:06 +0900
Message-ID: <CAKD1Yr0rsGLgrBj-9OWSQkxHFUAQDES4LZRkRdBMJ50tLSr+-w@mail.gmail.com>
To: Aditi Patange <Aditi.Patange=40microsoft.com@dmarc.ietf.org>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-addr-notification@ietf.org" <IMCEAUNDEFINED-draft-ietf-dhc-addr-notification+40ietf+2Eorg@namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="00000000000041fec0060f1179a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/3NTzOMqA5bUp3UA8qJVb3KYG-cI>
Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-notification
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, 16 Jan 2024 15:07:23 -0000
Aditi, Good to hear feedback from a DHCPv6 implementer on the algorithm. Wanted to reply on this specific point: On Fri, Jan 5, 2024 at 11:31 AM Aditi Patange <Aditi.Patange= 40microsoft.com@dmarc.ietf.org> wrote: > > > - Section 4.6 “Whenever the client creates an address or receives a > PIO which changes the Valid Lifetime of an existing address by more than 1%” > > The Prefix Information Option aspect of the above statement requires the > client to listen to the state of every address on every adapter, and store > significant additional state. The client needs to track every address on > every adapter, lifetime of each address, and has to store both the existing > time as well as the newly-received time. Needless to say, this could lead > to race conditions. Also, as the draft briefly acknowledged, this refresh > logic would have significant power implications especially for devices > running in low power mode. Can we please simplify the renewal logic to > reduce computation required by the client? > The intent of this text was to ensure that the server always knows about what addresses are in use. The reason it's written this way is that RAs can extend, or reduce, the lifetime of existing addresses to arbitrary values at arbitrary times. So static refresh intervals wouldn't work. Some common examples in the real world are: 1. Constant: periodic RAs which refresh the address lifetime to the *original* value. 2. Sawtooth: periodic RAs which refresh the address lifetime to the *current* value for a while, then jump back to a higher value (e.g., RA at t=0 with lifetime 3600, RA at t=300 with lifetime 3300, RA at t=600 with lifetime 3000, RA at t=900 with lifetime 2700, RA at t=1200 with lifetime 3600). This happens on routers that sync RA lifetimes with DHCPv6 PD timers - the RA reflects the remaining lease time of the PD, and then when the PD renew happens, it 3. Configuration changes RAs which lower the lifetime to 0 for renumbering, or raise the lifetime for config changes, or... and so on. That said, I don't think it's that expensive to implement. Yes, the stack needs to know the current lifetime (aka expiry time) of every address, and it needs to detect changes in address lifetime. I don't think it's possible to write any correct algorithm that doesn't require the client to know this though. And also, the stack needs this information because otherwise it can't delete the addresses when their lifetime expires. Even in a situation where you have a mixed kernel/userspace stack (like Android) this information isn't difficult to track. As for CPU and power - the algorithm looks complicated, but in practice, in most cases, the client only needs to send a bit more than one refresh per lifetime. Consider case #1 above: if the RA always announces a lifetime of 3600, no matter how many RAs are received, the first refresh happens after around 2880s, and after that, after another 2880s, and so on. Case #2 is similar - even though the lifetime in the RA goes down every time, it goes down linearly, and the 1% text prevents any refreshes until 2880s. At that point, the next refresh is scheduled for whatever 80% of the remaining lifetime is. In the example I gave, the next refresh would happen 80% of 2700 and 80% of 3600, or between 2160 and 2880 seconds in the future. The 10% jitter also helps because the client can try to align the refresh with other wakeups. The number of packets that need to be sent is similar to (but a bit lower than) the number of packets that need to be sent for stateful DHCPv6 - by default, in DHCPv6 T1 is 0.5, so refreshes occur at 50% of lifetime, whereas here they occur at 80%. If the client has multiple addresses with the same lifetimes (which is typical for privacy addresses), then it can refresh all of them at once; sending packets back-to-back makes this relatively cheap. Would definitely be interested in any thoughts you have on how to improve this further. Or maybe some of this should be written down in the draft, since perhaps not very obvious? Cheers, Lorenzo
- [dhcwg] Mail regarding draft-ietf-dhc-addr-notifi… Aditi Patange
- Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-no… Lorenzo Colitti
- Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-no… Jen Linkova
- Re: [dhcwg] Mail regarding draft-ietf-dhc-addr-no… Jen Linkova