Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by September 13, 2023

[Ted Lemon <[e-mail]>]

BTW, I think that a network might prefer IA_NA to registration, or vice
versa, so it would be good to specify this in a way such that if the
network signals that it prefers registration to IA_NA, the client doesn't
ask for an IA_NA. Whether this is done by doing the registration first and
sending the signal in the response, or whether it's done by having two PIO
flags, I leave an exercise to the working group. My personal opinion is
that two PIO flags is simpler and better, but I'm not attached to that
position. One benefit to using two flags is that they could say "Do SLAAC
and register only if you don't do IA_NA" or "Do IA_NA only if you don't
know how to do SLAAC and register". I guess if both bits are set then that
could mean "Do SLAAC and IA_NA if you want, the network has no preference."

On Tue, Sep 12, 2023 at 11:57 AM Ted Lemon <[e-mail]> wrote:

> FWIW I support this work, and prefer this model to IA_NA. I think using
> address registration plus SLAAC actually gives us what we wanted from DHCP
> without the limitations that DHCP has in terms of database management, so
> if I were deploying in an environment where this kind of tracking was
> required, I think this would be a better technical approach than IA_NA. I'm
> sure there are cases where this would not be true—I'm not trying to suggest
> otherwise—but if this could work, I'd rather use it than IA_NA because I
> think there are fewer failure modes.
>
> That said, I have questions.
>
> First, the term "Client Identifier" is used throughout the document. What
> is meant here?  Do you mean the DUID? Also, I see some normative language
> that is probably unnecessary, e.g.:
>
> DHCPv6 relay agents and switches that relay address registration messages
>> directly from clients SHOULDinclude the client's link-layer address in
>> the relayed message using the Client Link-Layer Address option ([RFC6939
>> <https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-04.html#RFC6939>
>> ]).
>
>
> It doesn't really make sense to say this here, because this is a document
> about clients and servers, not about relay agents. I don't think we can
> assume that relay agents either do or do not support this option, and I
> don't think this document can meaningfully place requirements on relay
> agents. What might make sense to have here would simply be a recommendation
> for operators that they use relay agents that implement this RFC, as
> opposed to normative language recommending that relay agents implement this.
>
> Regarding retransmission and acknowledgment, it's not clear to me that
> this is a good idea. If the server doesn't support this message type, and
> isn't going to respond to it, as seems likely, then what we really want is
> to signal this to the client in the RA rather than having the client send
> useless multicast messages, particularly given that multicast is expensive
> in some settings, and also some clients may be battery-operated and we'd
> prefer they not send useless data. For this reason, I think you really need
> a flag in the PIO that indicates that this service is wanted by the
> network. If that flag isn't present, the client doesn't attempt to register.
>
>
>>    - If the network never changes the lifetime, or stops refreshing the
>>    lifetime, then only one refresh ever occurs. The address expires.
>>
>> Should this say "the client stops refreshing the lifetime?" I think this
> text isn't correct.
>
> The other issue I have with this is that I think it's likely to be a
> common flow that the client wants information from the DHCP server in
> addition to registering its address. In this case, two approaches could
> work: add an option to the "information request" that adds the registration
> functionality, which would also mean that we'd get an affirmative response
> from the server in all cases. Or, have this new "address registration"
> function allow an ORO and have the server return the same information as in
> an information request if the ORO is present. I don't care one way or
> another, but I will say that since we can probably safely assume that an
> Information Request will get a reply when the 'O' bit is set, the reply can
> indicate that the registration was accepted, and this eliminates the need
> for a PIO flag.
>
> On Tue, Sep 12, 2023 at 11:21 AM Bernie Volz <[e-mail]> wrote:
>
>> Nicely put. I’m just not as favorable on the work as you are.
>>
>> And, managed addresses (DHCP) by themselves offer no added “security” as
>> a device could just configure an address it wants to use directly.
>>
>> - Bernie Volz
>>
>> On Sep 12, 2023, at 10:54 AM, Sheng Jiang <[e-mail]> wrote:
>>
>> 
>> Hi, Bernie,
>>
>> First, I would like to express my prefer for managed address model. It
>> gives network management more authorization on network access and certainty
>> on the user of addresses. And it does not reduce the autonomic or user
>> transparant experience giving our feeling on using DHCP(v4). However, no
>> matter the reason what have happened regarding to DHCPv6 deployment, it is
>> the current situation that stateless address model are in dominant. Giving
>> the limitation of reality, the notification mechanism of this document, as
>> least, suppliments the lack of motheds that the network management can
>> obtain the information of in-used addresses. Therefore, I support to move
>> this document forward as a co-auhtor.
>>
>> Regards,
>>
>> Sheng
>>
>>
>> ------------------ Original ------------------
>> *From: * "Bernie Volz"<[e-mail]>;
>> *Date: * Tue, Sep 12, 2023 10:15 PM
>> *To: * "dhcwg"<[e-mail]>;
>> *Subject: * Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification -
>> Respond by September 13, 2023
>>
>> Comments with co-chair hat off:
>>
>> While I think this work has marginal utility as its is optional and can
>> be disabled (as bad actors will soon learn to disable it in devices they
>> may use for nefarious purposes), it may have some utility for help desk and
>> other troubleshooting purposes. Whether the cost to implement (for clients
>> and servers) is worth it is debatable. But we can let the market decide
>> that.
>>
>> I have worked on the draft to improve its clarity on what is expected of
>> clients and servers.
>>
>> I am not, however, a big supporter of this work. If all clients fully
>> supported the “full” DHCPv6 protocol, there would be no need to configure
>> prefixes for both managed and stateless as is now often the case to support
>> “all” clients. And this is the situation that is driving this work -
>> clients that don’t support managed address assignment. I’d prefer we
>> invested the time and energy into getting that support, rather than
>> extending the protocol to cover additional cases.
>>
>> While some argue that a server need just log this information when a
>> notification is received, that probably is too simplistic a view as
>> administrators want to know what addresses are in use “now” (and scanning
>> logs is not very efficient) and may want to use other facilities a server
>> provides (such as historical views, again by not having to search logs).
>> For the server I worked on these and other (failover and lease query)
>> considerations make this much more complex to implement and integrate
>> completely (though likely most of “our” customers will not demand for this
>> work to be supported). Sure, for “check the box” that it is supported one
>> can just log.
>>
>> Comments with co-chair hat on:
>>
>> The chairs need to follow the consensus of the working group, regardless
>> of our personal opinions (we can weigh our position as we would any other
>> “member’s”).
>>
>> This is why it is important to hear from as many people as we can to
>> understand the level of consensus that this work is useful and complete.
>> Volume is just one measure (and sometimes a suspect one), but we are much
>> more interested in detailed reviews of the work and your level of interest
>> in seeing it move forward. Hopefully this message will spur more feedback
>> to make the chairs decisions easier as to WGLC?
>>
>> - Bernie Volz
>>
>> On Sep 11, 2023, at 10:43 AM, Bernie Volz <[e-mail]> wrote:
>>
>> Just a friendly reminder for those that support this work, or those not
>> in favor, to comment on the document. We will wait until Wednesday
>> September 13th as subject had that date for WGLC to conclude. (Monday is
>> September 11th - today.)
>>
>> - Bernie Volz
>>
>> On Aug 31, 2023, at 10:15 AM, Timothy Winters <[e-mail]> wrote:
>>
>> 
>> Hi:
>>
>> The authors believe this document is ready for WGLC. Therefore, the
>> chairs are initiating a WGLC on this document.
>>
>> Please review this document and provide your comments and whether you
>> support this document moving forward or not by end of day on Monday,
>> September 13th, 2023.
>>
>> Please see
>> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-04.
>> This is a Standards Track document.
>>
>> Thank you!
>>   ~ Tim and Bernie
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>