Re: recommendation on DHCP6 source port numbers
Bernie Volz <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
No. I think that will mean folks will expect it and that is not the intent. I think the revised text is sufficient. - Bernie (from iPad) On Feb 29, 2024, at 1:05 PM, Ole Trøan <[email protected]> wrote: Should we also make it recommended to use the designated port as the source port? With the may to send arbitrary port and a must to accept an arbitrary port? O. On 29 Feb 2024, at 18:51, David Farmer <[email protected]> wrote: Ok, it's a little less wordy this time. Clients receive DHCP messages on UDP (destination) port 546. Servers and relay agents receive DHCP messages on UDP (destination) port 547. Clients, servers, and relay agents MAY send DHCP messages from any UDP (source) port they are allowed to use, including their designated destination ports. Nevertheless, regardless of the source port used, DHCP messages MUST be sent to their designated destination ports. Thanks On Thu, Feb 29, 2024 at 10:24 AM David Farmer <[email protected] > wrote: Would this text clarify things? Clients receive DHCP messages on UDP (destination) port 546. Servers and relay agents receive DHCP messages on UDP (destination) port 547. Clients, servers, and relay agents MAY send DHCP messages from any UDP (source) port they are allowed to use, including their designated destination ports. Nevertheless, regardless of the source port the client uses, the server or relay agent MUST send traffic to the designated destination port of the client. And vice versa, regardless of the source port used by the server or relay agent, the client MUST send traffic to the designated destination port of the server or relay agent. Thanks On Thu, Feb 29, 2024 at 10:03 AM Ole Troan <[email protected] > wrote: Bernie, > DHCPv6 has been successfully deployed and this is the first I recall of this kind of discussion/issue. > You would likely also invalidate a lot of implementations with such a change, which is not really in line with advancing this to Full Standard. It’s a lot more important to have the specification clear and unambiguous. I think it has been shown that it isn’t. Happy with whatever solution there is consensus for, but the ambiguity has to be resolved I think. O. _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg