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

[Li HUANG <[e-mail]>]

Good day,



IANA is keeping domain registration only as if. WGLC needs this non benefit
organization to approve any RFC ?

The once recent contacted to for rfc2119 by a domain publisher , there was
no replied getting, nor agree with to correct it by ASN co., . From the
ALIAS which ASN # assigned to the  domain_publisher remaining talked over
months yet, tell would care rfc2119 intending to?


ISP MAIL srv, lost years msg, downloading msg won't be find where saved due
to dhcpv6 srv or network, talked to ofca.gov..., out of tele managing scope
as before applying to dhcpv6 bt 2015 ...


To RFC wherever not abey-ing the protocols,  since "should, must.." words
put at RFC, them...


Where would force isp, domain publisher ...to follow RFC with monitor from
the clients who knowing rules of RFC ?



Regarding
Li HUANG


---------- Forwarded message ---------
From: Timothy Winters <[e-mail]>
Date: Sat, Sep 23, 2023, 04:22
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by
September 13, 2023
To: Bernie Volz <[e-mail]>
Cc: dhcwg <[e-mail]>, Ted Lemon <[e-mail]>


Hi Everyone,

The working group had some great discussion about this document during the
WGLC.    Based on the discussion it didn't pass WGLC at this time.  It will
mostly need another round of discussion and potentially a revision based on
those discussions.

Additionally, Bernie and I discussed and think it's a good idea to wait to
ask IANA for a early code points until we have passed WGLC.

Regards,
Tim

On Thu, Sep 14, 2023 at 3:16 PM Bernie Volz <[e-mail]> wrote:

> An interesting question may be do we need new messages at all? Using
> Information Request / Reply with new option is perhaps cleanest?
> - existing clients can do what they do today
> - existing servers (and relays or other snoopers) will not know option so
> ignore (hopefully silently)
> - existing servers only see “more” Information-Request for clients not
> supporting this new work when enabling O-bit to request address
> registrations
> - “new” clients that do SLAAC when O-bit set and did support
> Information-Request can do initial registration in first message (or send
> when address assigned) and do periodic updates (perhaps even ask for other
> options via ORO to refresh information) … they may actually have no more
> messages than today (well, except if they have multiple SLAAC addresses as
> need to use a separate Information-Request for each) … they could also
> decouple previous and new behavior at increase in traffic.
> - registration only clients that did not use Information-Request
> previously add new traffic … which is exactly what we want
>
> The only downside is it kind of overloads Information-Request as it is now
> also a client to server communication. Though the client already can send
> information to server in Information-Request (user class, vendor class,
> vendor information, …). And, we could say the client is asking whether the
> server supports registration (by getting new option in Reply).
>
> Note: It may be worth thinking about making use of the new “registration
> address” option’s encapsulated options field if client wants to send other
> information (such as fqdn). This isn’t really bad as this is likely address
> specific and any server that wanted to do something with this data needs
> updating anyway. This keeps all of the registration information hidden from
> those devices that don’t that registration option.
>
> Anyway, this is now a very good reason to hold off on early assignment for
> message types (and likely say WGLC failed).
>
> - Bernie (from iPad)
>
> On Sep 14, 2023, at 2:32 PM, Bernie Volz <[e-mail]> wrote:
>
> Hi:
>
> (Just catching up and responding to this as was asked specifically…there
> could have been more I haven’t yet read.)
>
> 8415bis only prohibits IA options in Information-Request
>
> 16.12.  Information-request Message
>
>    Clients MUST discard any received Information-request messages.
>
>    Servers MUST discard any received Information-request message that
>    meets any of the following conditions:
>
>    *  the message includes a Server Identifier option (see
>       Section 21.3), and the DUID in the option does not match the
>       server's DUID.
>
>    *  the message includes an IA option.
>
>
> I wonder however if having an Address Registration option specifically
> would be better (the Information-Request and new registration request could
> use this instead of IA_Addr option). This might avoid an overly aggressive
> server or relay that checks the Information-Request or its Reply for
> options from doing odd things if it sees the IAAddr. If we’re trying to
> make things safe, this may be best. Note also that it may help other
> devices in the path that may want to snoop for this data. (But it could
> have downside if any “options” are developed as then those specifications
> would need to determine if they are also allowed in this new address
> option).
>
>
> On a separate note, one issue the current draft may need to document and
> is a consideration is that when O-bit (RA) and A-bit (PIO) is set, a
> registration only server should really support Information-Request as it
> will also get lots of those from clients that support DHCPv6 - it may just
> send back a pretty empty Reply.
>
> By using Ted’s suggestion of using Information-Request, it would be
> natural for registration only to be implemented at least sufficiently to
> send a well formed Reply even when not address registration request.
>
> It seems like a clever idea to use Information-Request at least for
> initial determination of support.
> - it avoids extra packets.
> - client could honor server’s INF_MAX_RT to reduce frequency of probing
> (likely periodic probing is not a bad idea).
>
>
> - Bernie (from iPad)
>
> On Sep 14, 2023, at 11:29 AM, Lorenzo Colitti <[e-mail]> wrote:
>
> 
> On Fri, Sep 15, 2023 at 12:22 AM Ted Lemon <[e-mail]> wrote:
>
>> What I think would be most expedient (if we must use DHCP to probe for
>> support of address registration) would be to do the first address
>> registration as an information request with the additional information in
>> the information request, using the source address being registered. If the
>> reply that comes back confirms the address registration, then all
>> subsequent address registrations on this link would be sent as address
>> registrations.
>>
>
> Well, but if we can come up with a reasonable way to represent an address
> registration using an information-request packet, then why not make all
> registrations be information-request packets?
>
> +Bernie Volz <[e-mail]> any thoughts on using information-request
> and reply messages, instead of the new addr-reg-inform and addr-reg-reply
> messages currently defined in the draft?
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg