Đó là câu hỏi mình mà cô mình đã hỏi ? Mình đã suy nghĩ như thế này , mong các bạn cho mình nhận xét và lời giải thích hợp lý ..
_Đối với mô hình 7 lớp , khi một client truy cập vào mạng nó gởi một "DHCP Discover có kèm theo MAC của chính nó" theo cơ chế broadcast để hỏi rằng nó muốn truy cập vào mạng , có DHCP server nào cấp IP cho nó không. Khi một server nhận được gói này nó sẽ gởi một "DHCP offer" cho client kèm theo một địa chỉ IP đề nghị , do lúc này client chưa có một địa chỉ IP chính thức nên server sẽ gởi IP theo cơ chế broadcast , vấn đề được đặt ra là tại sao server đã biết được MAC của client nhưng nó không dùng cơ chế unicast để gời MAC mà dùng broadcast.
 

http://blog.360.yahoo.com/blog-fa9ZLv0_fLMGPjLrRaJOfhi8oNIHfsU-?cq=1&l=6&u=10&mx=20&lmt=5

2 – DHCP Server ở một Node mạng nào đó nhận được tín hiệu DHCPDISCOVER thì nó lập tức nó thực hiện việc kiểm tra lại xem có khả năng phục vụ client không. Nếu không có khả năng phục vụ thì tín hiệu DHCPDISCOVER lại tiếp tục được gửi đến các Node mạng khác nơi có thể có một DHCP Server nào đó (tùy theo việc định cấu hình).

Nếu có khả năng phục vụ thì lúc này DHCP Server thực hiện việc gửi tín hiệu DHCPOFFER (thông điệp Unicast – Hình minh họa bên dưới) cho DHCP Client. Nội dung thông điệp này là lời đề nghị phía trình khách định cấu hình Network Connection với những thông số như địa chỉ IP của DNS Server, địa chỉ IP của máy khách, khoảng thời gian Server duy trì phục vụ (sau khoảng thời gian này thì có thể máy tính bạn bị đổi IP trong Network đó) .v.v.

 

Tín hiệu DHCPOFFER từ DHCP Server gửi là dạng Unicast cơ chứ ko phải là Broadcast. 

lúc này mình lại có suy nghĩ là tại sao server không gởi IP theo cơ chế unicast , bởi nó đã biết địa chỉ MAC rồi 

Tất cả các bước xin cấp phát địa chỉ IP đều dùng các message theo dạng broadcast.

Tín hiệu DHCPOFFER từ DHCP Server gửi là dạng Unicast cơ chứ ko phải là Broadcast. 

Lúc này client vẫn chưa có IP mà, làm sao gửi DHCPOFFER theo kiểu unicast được.

lúc này mình lại có suy nghĩ là tại sao server không gởi IP theo cơ chế unicast , bởi nó đã biết địa chỉ MAC rồi 

Tại sao đang đề cập đến IP lại pass sang MAC ? 

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t1/easyip2.htm

Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client
using unicast delivery. The IP destination address (in the IP header) is set
to the DHCP 'yiaddr' address and the link-layer destination address is set
to the DHCP 'chaddr' address. Unfortunately, some client
implementations are unable to receive such unicast IP datagrams until the
implementation has been configured with a valid IP address (leading to a
deadlock in which the client's IP address cannot be delivered until the
client has been configured with an IP address).
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP
clarifications document discusses the ramifications of the use of the
BROADCAST bit.
 

Muốn biết DHCP broadcast hay unicast thì cứ capture mấy cái message là biết liền hà. 

Figure 1 shows the basic steps that occur when a DHCP client requests an IP address from a DHCP server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS DHCP Server. A DHCP server offers configuration parameters (such as an IP address, a MAC address, a domain name, and a lease for the IP address) to the client in a DHSCPOFFER unicast message. 

Khi nói unicast hay broadcast cần nói rõ ở tầng nào: IP datagram ở tầng Network (địa chỉ broadcast là FF:FF:FF:FF) hay frame ở tầng Data-Link (có địa chỉ broadcast là FF:FF:FF:FF:FF:FF).

DHCPOFFER được gửi từ DHCP Server tới DHCP client có:
- IP Datagram:
+ Src IP: IP của DHCP server
+ Dest IP: 255.255.255.255
- Frame Src Addr: MAC của DHCP server
- Frame Dest Addr: MAC của DHCP client (lấy địa chỉ này từ DHCPDISCOVER)

Cho nên nếu nói ở tầng Data-Link, DHCPOFFER gửi đi dưới dạng unicast, còn ở tầng Network, DHCPOFFER vẫn phải gửi đi ở dạng broadcast (vì client lúc này chưa có IP).
 

DHCP Theory of Operation

When a DHCP device attaches itself to the network for the first time, it broadcasts a DHCPDISCOVER packet. A DHCP server on the local segment will see the broadcast and return a DHCPOFFER packet that contains an IP address, along with other information. The servers may also conduct some sort of preliminary testing prior to offering the IP address, such as generating an ARP (Address Resolution Protocol) or an ICMP (Internet Control Message Protocol) echo to see if the address is already in use by another node. (If your network does not have a DHCP server on every segment, you will need to configure your routers to provide BOOTP relay agents that forward the broadcasts to a predefined server on a remote segment.)

The DHCP client may receive multiple DHCPOFFER packets from any number of servers, so the client must choose between them and broadcast a DHCPREQUEST packet that identifies the explicit server and lease offer that it likes the best. This decision may be based on which offer has the longest lease, or which offer provides the most information that the client needs for optimal operation (more on this later). The non-chosen servers would notice the explicit DHCPREQUEST packet from the client and go about their business.

Assuming that the offer is still valid, the chosen server would return a DHCPACK that tells the client the lease is finalized. If the offer is no longer valid for some reason-perhaps due to a time-out or to another client allocating the lease-then the selected server must respond with a DHCPNAK message. This would cause the client to send another DHCPDISCOVER packet, starting the process over again.

Once the DHCP client receives a DHCPACK from the DHCP server, all ownership and maintenance of the lease is the responsibility of the client. For example, a client may refuse an offer that is detailed in the DHCPACK message, and it is the client's responsibility to do so. Clients are supposed to test the addresses that have been offered to them by conducting ARP broadcasts. If another node responds to the ARP, the client would assume that the offered address is in use. At this point, the client would reject the offer by sending a DHCPDECLINE message to the offering DHCP server, and then the client would also send another DHCPDISCOVER packet, thereby starting the process yet again.

Once the DHCP client obtains a lease on an IP address, the lease must be renewed prior to its expiration date through another DHCPREQUEST message. If a client finishes using a lease prior to its expiration date, the client may send a DHCPRELEASE message to the DHCP server so that the address can be made available to other nodes. If the DHCP server doesn't hear from the client by the end of the lease, it marks the lease as expired, and makes the address available for other clients to use. 

When a DHCP client computer is booted, DHCP messages are exchanged between client computer and server as follows:

1. The DHCP client computer broadcasts a DHCPDISCOVER message. In a routed environment, the broadcast is limited to the physical subnet. If there is no DHCP server on the physical subnet, one or more of the routers should be configured to forward the (BOOTP) message to a known DHCP server location.The DHCPDISCOVER message can include options that request specific values for the network address and lease duration.
2. Each DHCP server that is configured to respond to the client computer's subnet should respond with a DHCPOFFER message. The DHCPOFFER message has a (presumably) available IP address as well as other configuration information. According to the IETF standard, the DHCP server should first grope the target subnet with an ICMP ECHO request to confirm that the address is available.
3. The DHCP client computer receives one or more DHCPOFFER messages from the DHCP server(s). The client computer selects one of the DHCPOFFER messages.
4. The DHCP client computer broadcasts a DHCPREQUEST message that includes a server identifier option to indicate which server it has selected. This DHCPREQEST message can include requests for specific configuration information.
5. All DHCP servers that responded to the client computer's original DHCPREQUEST broadcast should receive the second DHCPREQUEST message broadcast. The DHCP server(s) that were not selected by the client computer take no further action.
6. The selected DHCP server commits the IP address for the client computer to its list of client computers, IP addresses, and leases. It then sends a DHCPACK message that includes the (requested) configuration parameters for the DHCP client computer.
7. If the selected DHCP server cannot comply with the DHCPREQUEST message from the client computer (usually because the requested IP address is not available), the server sends a DHCPNAK message to the client computer.
8. The DHCP client computer receives the DHCPACK message from the server. The client computer normally performs a final validation of the configuration information and saves the address lease duration specified in the DHCPACK message. The client computer is configured.
 

DHCP Offer

Once a DHCP Server has received the Discover packet, and determined that it can accommodate the client's request, it responds with a DHCP Offer message.

The details of the base DHCP Offer frame are:
•

Size of 342 bytes.
•

Destination Hardware Address of FFFFFFFFFFFF, indicating an Ethernet broadcast.
•

Type of packet is IP (0x800).

The details of the 20 byte IP portion of the frame are:
•

Source Address is that of the DHCP server.
•

Destination Address of 255.255.255.255, indicating a network broadcast, as the client has not acquired an address yet.
•

Protocol is UDP (User Datagram Protocol).

The details of the eight byte UDP portion of the frame are:
•

Source Port is BOOTP Server (UDP port 67).
•

Destination Port is BOOTP Client (UDP port 68).

The remainder of the frame, 300 bytes, is the DHCP Offer portion. Its details include:
•

Your IP Address lists the IP address the DHCP server is offering to the client.
•

In the DHCP Option Field section, the Subnet Mask lists the proposed subnet mask parameter value.
•

Lease renewal times are listed as Renewal Time Value and Rebinding Time Value.
•

The IP Address Lease Time lists the duration of the lease, which defaults to three days.
•

Server Identifier lists the IP address of the DHCP server that made this offer.
http://www.microsoft.com/technet/archive/winntas/plan/capacityplanning/a04_dhcp.mspx?mfr=true 

light.phoenix wrote:

Khi nói unicast hay broadcast cần nói rõ ở tầng nào: IP datagram ở tầng Network (địa chỉ broadcast là FF:FF:FF:FF) hay frame ở tầng Data-Link (có địa chỉ broadcast là FF:FF:FF:FF:FF:FF).

DHCPOFFER được gửi từ DHCP Server tới DHCP client có:
- IP Datagram:
+ Src IP: IP của DHCP server
+ Dest IP: 255.255.255.255
- Frame Src Addr: MAC của DHCP server
- Frame Dest Addr: MAC của DHCP client (lấy địa chỉ này từ DHCPDISCOVER)

Cho nên nếu nói ở tầng Data-Link, DHCPOFFER gửi đi dưới dạng unicast, còn ở tầng Network, DHCPOFFER vẫn phải gửi đi ở dạng broadcast (vì client lúc này chưa có IP).
 

Cám ơn bạn , nhưng ở tầng Dât-Link DHCPOFFER vẫn gởi đi dạng broadcast bởi vì khi học cô giáo mình đã hỏi DHCPOFFER ở tầng Data-Link gởi unicast hay broadcast bạn mình đã trả lời broadcast (vì bạn mình nghĩ ở Network broadcast thì Datalink cũng phải broadcast), cô mình nói đúng nhưng tại sao thì phải giải thích rõ ?? 

Khi nói unicast hay broadcast cần nói rõ ở tầng nào: IP datagram ở tầng Network (địa chỉ broadcast là FF:FF:FF:FF) hay frame ở tầng Data-Link (có địa chỉ broadcast là FF:FF:FF:FF:FF:FF). 

Cho nên nếu nói ở tầng Data-Link, DHCPOFFER gửi đi dưới dạng unicast, còn ở tầng Network, DHCPOFFER vẫn phải gửi đi ở dạng broadcast (vì client lúc này chưa có IP).
 

. Khi dhcp hoạt động, giai đoạn server gửi về DHCPOFFER cho pc , vẫn cứ là broadcast, chỉ có MAC nói chuyện với MAC thì sao có chuyện unicast được. Nói vui vui vậy không biết có hợp lý không.
Góp vui với bà con bằng google  

Bác tham khảo thêm cái gói dhcpoffer mà microsoft mô tả. xem nó là gói dạng gì. Lúc đó biết nó uni hay broadcast liền. 

light.phoenix wrote:

Khi nói unicast hay broadcast cần nói rõ ở tầng nào: IP datagram ở tầng Network (địa chỉ broadcast là FF:FF:FF:FF) hay frame ở tầng Data-Link (có địa chỉ broadcast là FF:FF:FF:FF:FF:FF). 

Tôi ko nghĩ như bạn. Chả nhẽ việc truyền phát một message dạng Broadcast, Unicast, Anycast, multicast lại còn cần nói rõ thêm ở tầng nào à .
 

light.phoenix wrote:

Cho nên nếu nói ở tầng Data-Link, DHCPOFFER gửi đi dưới dạng unicast, còn ở tầng Network, DHCPOFFER vẫn phải gửi đi ở dạng broadcast (vì client lúc này chưa có IP).
 

một thông điệp dạng Unicast mà qua tầng khác của OSI nó đã biến thành Broadcast sao?. Tài nhẩy ... Cái mô hình phân tầng kia chỉ là lý thuyết, chỉ là mô hình mà thôi

Tại sao lại cần IP trong việc gửi một thông điệp dạng Unicast hả bạn light.phoenix?
 

DHCP Offer

Once a DHCP Server has received the Discover packet, and determined that it can accommodate the client's request, it responds with a DHCP Offer message.

The details of the base DHCP Offer frame are:
• Size of 342 bytes.
• Destination Hardware Address of FFFFFFFFFFFF, indicating an Ethernet broadcast.
• Type of packet is IP (0x800).

The details of the 20 byte IP portion of the frame are:
• Source Address is that of the DHCP server.
• Destination Address of 255.255.255.255, indicating a network broadcast, as the client has not acquired an address yet.
...
 

Công nhận mình đã nhầm lẫn khi nói Frame của DHCPOFFER có DestMAC là DHCPServer's MAC. Thực sự thì như saddream1985 nói, DestMAC của DHCPOFFER là broadcast, nhằm mục đích thông báo cho các DHCP server khác biết rằng client đã chọn một DHCP server cụ thể trong số các DHCP server trả lời client bằng DHCPOFFER  

The client returns a formal request for the offered IP address to the DHCP server in a DHCPREQUEST broadcast message. The DHCP server confirms that the IP address has been allocated to the client by returning a DHCPACK unicast message to the client.
 

Note The formal request for the offered IP address (the DHCPREQUEST message) that is sent by the client is broadcast so that all other DHCP servers that received the DHCPDISCOVER broadcast message from the client can reclaim the IP addresses that they offered to the client.

If the configuration parameters sent to the client in the DHCPOFFER unicast message by the DHCP server are invalid (a misconfiguration error exists), the client returns a DHCPDECLINE broadcast message to the DHCP server.

The DHCP server will send to the client a DHCPNAK denial broadcast message, which means the offered configuration parameters have not been assigned, if an error has occurred during the negotiation of the parameters or the client has been slow in responding to the DHCPOFFER message (the DHCP server assigned the parameters to another client) of the DHCP server. 

HCP Server, thì việc Client chọn DHCP Server nào, không nằm ở DHCPOFFER Message mà nằm ở DHCPREQUEST Message - Tức bước thứ 3 trong "cuộc đối thoại" của DHCP Client với Network đó
 

If the 'giaddr' field in a DHCP message from a client is non-zero,
the server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
field is zero and the 'ciaddr' field is nonzero, then the server
unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client's hardware address and 'yiaddr' address. In
all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
messages to 0xffffffff.
 

Nếu trường 'giaddr' trong thông điệp DHCP từ client gửi tới là non-zero, server sẽ gửi trả các thông điệp cho BOOTP relay agent có địa chỉ ghi trong 'giaddr'. Nếu trường 'giaddr' == 0 && 'ciaddr' != 0, server sẽ gửi DHCPOFFER & DHCPACK dưới dạng unicast tói địa chỉ ghi trong 'ciaddr'. Nếu 'giaddr' == 0 && 'ciaddr' == 0, và broadcast bit được bật, thì các thông điệp DHCPOFFER và DHCPACK được gửi broadcast tới 0xffffffff. Nếu broadcast bit bị tắt và 'giaddr' cũng như 'ciaddr' bằng 0 thì server gửi unicast thông điệp DHCPOFFER và DHCPACK tới địa chỉ phần cứng của client và 'yiaddr'. Trong mọi tình huống, khi 'giaddr' bằng 0, server sẽ broadcast DHCPAK tới 0xffffffff
 

if (giaddr != 0)
{
	unicast
}
else 
	if (ciaddr != 0)
	{
		unicast
	}
	else 
		if (broadcast_bit & 0x1)
		{
			broadcast
		}
		else 
		{
			unicast
		}

Vậy thì sau khi đưa ra đoạn thông tin trích từ RFC 1541, bạn kết luận thông điệp DHCPOFFER được gửi đi là dạng nào, unicast hay broadcast? Bạn khẳng định lại xem nào ... đừng đưa ra một đoạn thế rồi ko đưa ra kết luận của mình nhé (góp ý). 

Tất cả các bước xin cấp phát địa chỉ IP đều dùng các message theo dạng broadcast.  

DHCP server sẽ cố gắng sử dụng unicast để gửi các thông điệp DHCPOFFER, DHCPACK, DHCPNAK trực tiếp đến client. Nhưng nếu như client không thể nhận unicast IP datagram khi chưa được cấu hình IP thì nên gửi bằng broadcast. 

DHCPOFFER được gửi từ DHCP Server tới DHCP client có:
- IP Datagram:
+ Src IP: IP của DHCP server
+ Dest IP: 255.255.255.255
- Frame Src Addr: MAC của DHCP server
- Frame Dest Addr: MAC của DHCP client (lấy địa chỉ này từ DHCPDISCOVER)
 

MicrosoftX wrote:

Vậy thì sau khi đưa ra đoạn thông tin trích từ RFC 1541, bạn kết luận thông điệp DHCPOFFER được gửi đi là dạng nào, unicast hay broadcast? Bạn khẳng định lại xem nào ... đừng đưa ra một đoạn thế rồi ko đưa ra kết luận của mình nhé (góp ý). 

Bạn có đọc bài viết phía trên của tôi không ?
 

Muốn biết DHCP broadcast hay unicast thì cứ capture mấy cái message là biết liền hà.  

DHCP server sẽ cố gắng sử dụng unicast để gửi các thông điệp DHCPOFFER, DHCPACK, DHCPNAK trực tiếp đến client. Nhưng nếu như client không thể nhận unicast IP datagram khi chưa được cấu hình IP thì nên gửi bằng broadcast.  

Đọc xong bài này theo logic hiểu của tớ thì lại mù mờ thông tin, quote một đoạn ra rồi không giải thích gì, không khẳng định lại ý kiến của mình mà bảo người khác thử capture. Há chẳng phải thừa sao?

Còn những điều mà tớ nói đó là "Cisco IOS DHCP Server". 

Theo tôi hiểu thì thế này, chắc chắn client ko thể nhận unicast IP datagram đc, vì client chỉ nhận đc IP datagram khi đã đc cấu hình IP, kiền thức nông cạn của tôi là như thế, vậy DHCP để làm gì khi Client đã đc cấu hình IP ( vì nhận đc IP datagram).  

vậy DHCP để làm gì khi Client đã đc cấu hình IP ( vì nhận đc IP datagram).  

Cơ chế là thế này, client la làng lên, DHCP la làng trở lại, 2 lần như thế là client có IP trong dãy IP định trước, IP này ko trùng với bất cứ IP nào của clients khác đã dc cấp  

"Mỗi DHCP server trả lời bằng bản tin DHCPOFFER bao gồm thông tin về địa chỉ mạng, địa chỉ DHCP server, địa chỉ gateway... Địa chỉ mạng phải được đảm bảo là chưa được sử dụng (server có thể xác nhận điều này bằng cách dùng giao thức ICMP để kiểm tra xem địa chỉ này đã sử dụng chưa). Bản tin này được gửi quảng bá với địa chỉ MAC đích (destination MAC) là địa chỉ vật lý của client (địa chỉ này lấy từ địa chỉ MAC gửi đi trong bản tin DHCPDISCOVER)".