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

[Li HUANG <[e-mail]>]

Sept 23 2023 19:03.hk X30


Good day every,


Hop 1st may be robust that never configured it, perhaps once set up, the
multiple prefixes AAAA won't be configurable ?   In case one of isp only
dhcpv6 sometimes unfunctioning . One of domain issuers front of.


Switch *Cisco 1 item* met its exp. End of life , contract#, GUI # all
different  from local .hk when accepting case supporting  from else region
globally. Asking Cisco near 2 years , no clearly replied on allowance / or
not in such case?!



RFC8174, 2119 since 1996~ reported to ISP  , yet clearly replied their
server billing caring in case sensitive to user account name ...



Sincerely
Li HUANG





On Sat, Sep 23, 2023, 16:08 Ole Trøan <otroan=[e-mail]>
wrote:

> Thanks Tim,
>
> I do wonder if it’s not worth doing a complete retake of this proposal.
>
> If the operator requirement is to know which address has been in use in
> the network by which device at any point in time, then that cannot be
> guaranteed with this mechanism. Existing first-hop security mechanisms in
> switches and routers would be much more robust.
>
> O.
>
> On 22 Sep 2023, at 22:22, Timothy Winters <[e-mail]> wrote:
>
> 
> 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
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>