Re: [dhcwg] Fwd: New Version Notification for draft-wkumari-dhc-addr-notification-07.txt

On Fri, Mar 31, 2023 at 2:42 AM Bernie Volz <bevolz@gmail.com> wrote:
>
> Reason to tell client if registration done or not is to have it reduce or eliminate future communication with server. I’m not suggesting forever, but to reduce frequency as otherwise could result in heavy traffic on large networks.

I think we are in agreement here: it's highly desirable to tell the
client that its packets reached the server (and were either registered
or dropped - it doesn't really matter for the client).
I'm still inclined to say 'SHOULD' as it's an optimization to achieve
scalability - a rather useful one, but nothing would be broken as the
server doesn't do this.
 When the client joins the network, it would send up to 4 packets per
address, while if it uses DHCPv6 w/o rapid commit it would be 2.

> It is not a good idea to have server directly communicate with client as you don’t know if communication is possible. Please do not that. 8815bis is removing server unicast.

Oh yes, my bad, indeed. Don't know what I've been thinking.
OK, we'll rephrase the destination address as either the address being
registered or the relay address.

> The server could extract peer-address, but not sure that is best as it could be link-local address?

The host MUST send the packet from the address being registered, so
peer-address can not be link-local.

>Not sure if you are requiring server to validate that registered address (ip source if not relayed or peer-address in innermost relay-forw must be registered address or not … and that likely begs question if address needs to be sent by client in first place inside packet … but likely safer to require to send and require check).

The server must discard the message if the address is not appropriate
for the link. I believe that shall address your concern, rigth?

> I still am not in favor of this work. Use DHCPv6 or not for address assignment (and if not, why register).

Besides use cases we already discussed in our previous presentations,
there is another one: if a node is getting a prefix via PD and assigns
some addresses to its interfaces, the administrator might use the
registration data (e.g. populating DNS or monitoring systems).

> > On Mar 30, 2023, at 10:43 AM, Jen Linkova <furry13@gmail.com> wrote:
> >
> > On Thu, Mar 30, 2023 at 11:28 PM Bernie Volz <bevolz@gmail.com> wrote:
> >> In section 5, the following sentence makes no sense:
> >>
> >> The IPv6 destination address of the packet is the address being registered.
> >>
> >> If a registration request is relayed, how could this be true?
> >
> > Ah, I think I meant the destination address when it reaches the client
> > (so after relaying). However, now I'm thinking about it: is there
> > anything preventing the server from responding directly to the client?
> > The server does know the destination address (one being registered).
> >
> >> I’m still concerned that you are not making it a MUST for a server to respond to a registration request (obviously only if it implements the standard) and that a status code (excepting the sucess case) can be included to indicate to the client the results.
> >
> > I usually treat 'MUST' as "if you don't do this, smth gets badly
> > broken". I'm not sure what exactly would get badly broken if the
> > server does not respond.
> > Also, I'm concerned that "the server MUST respond" can be read as "the
> > client can always expect the server to respond" which is definitely
> > not the case.
> > (Though I do not have any strong opinion...just a thought).
> >
> >> One option might be for a new status code that indicates that the server does not support the feature … as it would be much less implementation work for a server to simple return this “not supported” status to any registration request to hopefully quiet the client.
> >
> > I'm not an implementer indeed, but is it really much easier to
> > implement a new status code than just insert an IA Address option?
> >
> >> Note that depending on how successfully this is implemented in the future in clients, the traffic might be very heavy from these retransmissions for clients trying to register. Think of a conference network where there could be thousands or tens of thousands of clients.  Thus, having a low cost way for a server to shut up these clients (by returning a not supported or similar status) would be useful. A server could always lie and just return success, but that is likely less desirable?
> >
> > The client doesn't care *what* the server returns, right? Whether the
> > server successfully registered the address or said "I don't know how
> > to register" - the client reaction is the same...
> > Or am I missing smth?
> >
> >> I likely will have some other comments but need to listen to the discussion at the WG session first.
> >
> > Thank you for the comments, highly appreciated!
> >
> >> On Mar 30, 2023, at 5:19 AM, Jen Linkova <furry13@gmail.com> wrote:
> >>
> >> Dear DHC WG,
> >>
> >> -07 version of draft-wkumari-dhc-addr-notification has been submitted
> >> to address comments received during today's presentation.
> >>
> >> ---------- Forwarded message ---------
> >> From: <internet-drafts@ietf.org>
> >> Date: Thu, Mar 30, 2023 at 8:17 PM
> >> Subject: New Version Notification for draft-wkumari-dhc-addr-notification-07.txt
> >> To: Jen Linkova <furry@google.com>, Lorenzo Colitti
> >> <lorenzo@google.com>, Rajiv Asati <rajiva@cisco.com>, Suresh Krishnan
> >> <suresh.krishnan@gmail.com>, Warren Kumari <warren@kumari.net>
> >>
> >>
> >>
> >> A new version of I-D, draft-wkumari-dhc-addr-notification-07.txt
> >> has been successfully submitted by Jen Linkova and posted to the
> >> IETF repository.
> >>
> >> Name:           draft-wkumari-dhc-addr-notification
> >> Revision:       07
> >> Title:          Registering Self-generated IPv6 Addresses using DHCPv6
> >> Document date:  2023-03-30
> >> Group:          Individual Submission
> >> Pages:          11
> >> URL:
> >> https://www.ietf.org/archive/id/draft-wkumari-dhc-addr-notification-07.txt
> >> Status:
> >> https://datatracker.ietf.org/doc/draft-wkumari-dhc-addr-notification/
> >> Html:
> >> https://www.ietf.org/archive/id/draft-wkumari-dhc-addr-notification-07.html
> >> Htmlized:
> >> https://datatracker.ietf.org/doc/html/draft-wkumari-dhc-addr-notification
> >> Diff:
> >> https://author-tools.ietf.org/iddiff?url2=draft-wkumari-dhc-addr-notification-07
> >>
> >> Abstract:
> >>  This document defines a method to inform a DHCPv6 server that a
> >>  device has a self-generated or statically configured address.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >> --
> >> SY, Jen Linkova aka Furry
> >>
> >> _______________________________________________
> >> dhcwg mailing list
> >> dhcwg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dhcwg
> >
> >
> >
> > --
> > SY, Jen Linkova aka Furry

--
SY, Jen Linkova aka Furry