In most client-server applications, the port number of a server is a well-known number (e.g., an FTP server uses port number 21, the Telnet server uses port number 23, etc.), while the client uses a currently available (ephemeral) port number. DHCP is different. Here, both the client and the server use a well-known port: UDP port 67 for the DHCP server and UDP port 68 for the DHCP client. Refer to RFC 2131 and provide an explanation for this protocol design choice.

What will be an ideal response?

RFC951 “Bootstrap Protocol” has this explanation. The reason is the DHCP server may broadcast a reply. If clients pick their ports independent of each other, the server cannot determine which destination port the broadcast should use. The reason for broadcasting a DHCP reply is related to the problem how to send an IP message to a client which is not configured with a valid IP address. (The Chick/Egg problem in RFC951.) At this time, the client doesn’t reply to ARP query because it doesn’t have a valid IP address. In this case, the DHCP server has to call some APIs to insert this ARP entry into ARP cache (The server has client’s MAC address from client’s request.) However, if there’s no such ARP APIs, the server has to broadcast the reply. Because each broadcast message can only be sent to one port, all clients have to use the same UDP port. Also DHCP and BOOTP should interoperate with each other as recommended by the RFC 1534. Originally, BOOTP was designed to use the client port number 68 and the server port number to be 67. And the reason behind this design choice is to avoid waking up and scheduling the BOOTP server daemons, when a bootreply must be broadcast to a client. Since the server and other hosts won't be listening on the 'BOOTP client' port, any such incoming broadcasts will be
filtered out at the kernel level. We could not simply allow the client to pick a "random" port number for the UDP source port field; since the server reply may be broadcast, a randomly chosen port number could confuse other hosts that happened to be listening on that port. The concept behind using it in DHCP is the same as its just an extension of the BOOTP protocol. Hence the client is not allowed to chose an ephemeral port number.