Understanding DHCP server client conversation

Discussion in 'MCSA' started by XeDigital, Mar 1, 2008.

  1. XeDigital

    XeDigital Guest

    Dear Friends,

    Through my researches and my studies I tried to understand the DHCP Server
    client conversation in Windows Server 2003 environment and I'm little bit
    lost here.

    Now, According to this table that is listed on Microsoft web page
    http://support.microsoft.com/kb/169289

    Source Dest Source Dest Packet
    MAC addr MAC addr IP addr IP addr Description
    ------------------------------------------------------------------------------------------------------
    Client Broadcast 0.0.0.0 255.255.255.255 DHCP
    Discover
    * DHCPsrvr Broadcast DHCPsrvr 255.255.255.255 DHCP Offer
    Client Broadcast 0.0.0.0 255.255.255.255 DHCP
    Request
    ** DHCPsrvr Broadcast DHCPsrvr 255.255.255.255 DHCP ACK


    I have some questions regarding the DHCP conversation manner.
    The DHCP server sends a Broadcast MSG offering the IP address to the client
    (*) and at the end it sends AGAIN a Broadcast MSG to acknowledge the IP
    address that's been offered (**).

    Now, my questions are :-

    1) I understand that the Client is sending a broadcast message because it
    doesn't know any concrete DHCP server in order to request an IP address, but
    why the DHCP sends also a broadcast message to the client (*) (**)?

    2) Let's agree that the DHCP server is broadcasting its offer, what happen
    if there is more than one client (lets say 50 or more) is getting same IP
    address that's suppose to be offered to a concrete client at the same time?
    Doesn't this make a high traffic in the network making all the clients go
    back and forth with the DHCPNACK, DHCPDECLINE and the DHCPACK?????
    NOTE: I understand that the client sends an ARP request with the offered
    IP address if it gets a reply that means that this IP address is in use and
    the client sends DHCPDECLINE, this is from the CLIENT side but what about
    the server side and the whole network?? :-s

    3) Why don't the DHCP server cuts the crap and use the client MAC address to
    send the DHCPOFFER and the DHCPACK instate of broadcasting to all clients?
    PLEASE NOTE : That the MAC address is in the second layer (Data Link layer)
    in the OSI model while the IP address is in the third layer (Network layer)
    which make it more reasonable for the DHCP server to use the the MAC address
    of the client that is requesting the service to send him the IP address
    instate of BROADCASTING the DHCPOFFER and the DHCPACK and making high
    traffic.

    I'm sorry for make it long but I think that the subject is worth it....

    Yours,
    Weamfox
    XeDigital, Mar 1, 2008
    #1
    1. Advertising

  2. XeDigital

    John R Guest

    See comments in line.

    "XeDigital" <> wrote in message
    news:...
    > Dear Friends,
    >


    ...snip..

    > Now, my questions are :-
    >
    > 1) I understand that the Client is sending a broadcast message because it
    > doesn't know any concrete DHCP server in order to request an IP address,
    > but
    > why the DHCP sends also a broadcast message to the client (*) (**)?
    >


    Because the client does not yet have a TCP/IP address assigned to it and can
    only receive broadcast traffic.

    > 2) Let's agree that the DHCP server is broadcasting its offer, what happen
    > if there is more than one client (lets say 50 or more) is getting same IP
    > address that's suppose to be offered to a concrete client at the same
    > time?
    > Doesn't this make a high traffic in the network making all the clients go
    > back and forth with the DHCPNACK, DHCPDECLINE and the DHCPACK?????
    > NOTE: I understand that the client sends an ARP request with the offered
    > IP address if it gets a reply that means that this IP address is in use
    > and
    > the client sends DHCPDECLINE, this is from the CLIENT side but what about
    > the server side and the whole network?? :-s
    >


    The DHCP packet contains the hardware (MAC) address of the client. This
    prevents other requesting clients from assuming someone else's offer.

    > 3) Why don't the DHCP server cuts the crap and use the client MAC address
    > to
    > send the DHCPOFFER and the DHCPACK instate of broadcasting to all clients?
    > PLEASE NOTE : That the MAC address is in the second layer (Data Link
    > layer)
    > in the OSI model while the IP address is in the third layer (Network
    > layer)
    > which make it more reasonable for the DHCP server to use the the MAC
    > address
    > of the client that is requesting the service to send him the IP address
    > instate of BROADCASTING the DHCPOFFER and the DHCPACK and making high
    > traffic.
    >


    You have to remember that the client cannot assume the IP address in the
    offer until it receives the DHCP ACK. Further, the client may have accepted
    an offer from another DHCP server on the lan. When a server sees a client
    issue a DHCP Request packet to a different DHCP server, it automatically
    assumes that the offer it made is not accepted. Since all of this traffic
    is broadcast based, all DHCP servers (and relay agents) on the lan know what
    is going on. See RARP for a configuration protocol based on ARP.

    Once the client does assume the IP address, maintenance of the lease is the
    clients responsibility. Typically, after receiving a DHCP offer, the client
    will issue an ARP request to see if another node responds. If so, the
    client will assume the address is in use and will issue a DHCP decline, and
    then another DHCP discover to start all over.

    So, in general...

    1. Client issues DHCP discover
    2. Server responds with DHCP offer
    3. Client officially asks for IP from the offer
    4. Server responds with DHCP ACK and updates it's lease table

    At this point, and this point only, can the client begin to use the IP
    address. Up to this point, the traffic must be broadcast based so that the
    client can see it, and other DHCP servers on the LAN (or remotely through
    DHCP relay agents) can see it. Lease times of as little as 15 minutes can
    prevent a lan with thousands of clients from becomming overburdened with
    DHCP traffic.

    For a better understanding, google or find a diagram of a DHCP packet.
    You'll see it includes fields for the client IP, Your IP (which is used
    separately from client IP, Server IP, router IP, client MAC, server host
    name, boot file name, and in some cases, vendor specific info.

    John R
    John R, Mar 1, 2008
    #2
    1. Advertising

  3. XeDigital

    XeDigital Guest

    Thankx John,

    I understand all what you said
    But why the DHCP server (BROADCAST) the DHCPOFFER and the DHCPACK???
    why not the DHCP server just sends its offer to the client that is
    requesting the service according to its MAC address????



    ---------------------------------------------
    "John R" <jsr^^^813@zoom^^^internet.net> wrote in message
    news:emNmD2#...
    > See comments in line.
    >
    > "XeDigital" <> wrote in message
    > news:...
    >> Dear Friends,
    >>

    >
    > ..snip..
    >
    >> Now, my questions are :-
    >>
    >> 1) I understand that the Client is sending a broadcast message because it
    >> doesn't know any concrete DHCP server in order to request an IP address,
    >> but
    >> why the DHCP sends also a broadcast message to the client (*) (**)?
    >>

    >
    > Because the client does not yet have a TCP/IP address assigned to it and
    > can only receive broadcast traffic.
    >
    >> 2) Let's agree that the DHCP server is broadcasting its offer, what
    >> happen
    >> if there is more than one client (lets say 50 or more) is getting same IP
    >> address that's suppose to be offered to a concrete client at the same
    >> time?
    >> Doesn't this make a high traffic in the network making all the clients go
    >> back and forth with the DHCPNACK, DHCPDECLINE and the DHCPACK?????
    >> NOTE: I understand that the client sends an ARP request with the
    >> offered
    >> IP address if it gets a reply that means that this IP address is in use
    >> and
    >> the client sends DHCPDECLINE, this is from the CLIENT side but what about
    >> the server side and the whole network?? :-s
    >>

    >
    > The DHCP packet contains the hardware (MAC) address of the client. This
    > prevents other requesting clients from assuming someone else's offer.
    >
    >> 3) Why don't the DHCP server cuts the crap and use the client MAC address
    >> to
    >> send the DHCPOFFER and the DHCPACK instate of broadcasting to all
    >> clients?
    >> PLEASE NOTE : That the MAC address is in the second layer (Data Link
    >> layer)
    >> in the OSI model while the IP address is in the third layer (Network
    >> layer)
    >> which make it more reasonable for the DHCP server to use the the MAC
    >> address
    >> of the client that is requesting the service to send him the IP address
    >> instate of BROADCASTING the DHCPOFFER and the DHCPACK and making high
    >> traffic.
    >>

    >
    > You have to remember that the client cannot assume the IP address in the
    > offer until it receives the DHCP ACK. Further, the client may have
    > accepted an offer from another DHCP server on the lan. When a server sees
    > a client issue a DHCP Request packet to a different DHCP server, it
    > automatically assumes that the offer it made is not accepted. Since all
    > of this traffic is broadcast based, all DHCP servers (and relay agents) on
    > the lan know what is going on. See RARP for a configuration protocol
    > based on ARP.
    >
    > Once the client does assume the IP address, maintenance of the lease is
    > the clients responsibility. Typically, after receiving a DHCP offer, the
    > client will issue an ARP request to see if another node responds. If so,
    > the client will assume the address is in use and will issue a DHCP
    > decline, and then another DHCP discover to start all over.
    >
    > So, in general...
    >
    > 1. Client issues DHCP discover
    > 2. Server responds with DHCP offer
    > 3. Client officially asks for IP from the offer
    > 4. Server responds with DHCP ACK and updates it's lease table
    >
    > At this point, and this point only, can the client begin to use the IP
    > address. Up to this point, the traffic must be broadcast based so that
    > the client can see it, and other DHCP servers on the LAN (or remotely
    > through DHCP relay agents) can see it. Lease times of as little as 15
    > minutes can prevent a lan with thousands of clients from becomming
    > overburdened with DHCP traffic.
    >
    > For a better understanding, google or find a diagram of a DHCP packet.
    > You'll see it includes fields for the client IP, Your IP (which is used
    > separately from client IP, Server IP, router IP, client MAC, server host
    > name, boot file name, and in some cases, vendor specific info.
    >
    > John R
    >
    >
    XeDigital, Mar 2, 2008
    #3
  4. XeDigital

    John R Guest

    "XeDigital" <> wrote in message
    news:...
    > Thankx John,
    >
    > I understand all what you said
    > But why the DHCP server (BROADCAST) the DHCPOFFER and the DHCPACK???
    > why not the DHCP server just sends its offer to the client that is
    > requesting the service according to its MAC address????
    >
    >
    >


    What transmission protocol would you suggest that it use?

    John R
    John R, Mar 2, 2008
    #4
  5. XeDigital

    XeDigital Guest

    "John R" <jsr^^^813@zoom^^^internet.net> wrote in message
    news:#...
    >
    > "XeDigital" <> wrote in message
    > news:...
    >> Thankx John,
    >>
    >> I understand all what you said
    >> But why the DHCP server (BROADCAST) the DHCPOFFER and the DHCPACK???
    >> why not the DHCP server just sends its offer to the client that is
    >> requesting the service according to its MAC address????
    >>
    >>
    >>

    >
    > What transmission protocol would you suggest that it use?
    >
    > John R



    hmmmm.....I think I understand now..

    Any transport protocol must has the IP address of the source and
    destination.
    and since we don't have any IP for the client (which is the destination IP
    address) so the DHCP server must broadcast the DHCPOFFER/ DHCPACK to every
    client.
    and since the MAC address of the client that is requesting the service is
    already known, the DHCPOFFER / DHCPACK will be received by all clients but
    will be only accepted by the client that is holding the match MAC
    address....

    Is that what you want to say?

    Weamfox
    XeDigital, Mar 2, 2008
    #5
  6. XeDigital

    John R Guest

    "XeDigital" <> wrote in message
    news:...
    > "John R" <jsr^^^813@zoom^^^internet.net> wrote in message
    > news:#...
    >>
    >> "XeDigital" <> wrote in message
    >> news:...
    >>> Thankx John,
    >>>
    >>> I understand all what you said
    >>> But why the DHCP server (BROADCAST) the DHCPOFFER and the DHCPACK???
    >>> why not the DHCP server just sends its offer to the client that is
    >>> requesting the service according to its MAC address????
    >>>
    >>>
    >>>

    >>
    >> What transmission protocol would you suggest that it use?
    >>
    >> John R

    >
    >
    > hmmmm.....I think I understand now..
    >
    > Any transport protocol must has the IP address of the source and
    > destination.
    > and since we don't have any IP for the client (which is the destination IP
    > address) so the DHCP server must broadcast the DHCPOFFER/ DHCPACK to every
    > client.
    > and since the MAC address of the client that is requesting the service is
    > already known, the DHCPOFFER / DHCPACK will be received by all clients but
    > will be only accepted by the client that is holding the match MAC
    > address....
    >
    > Is that what you want to say?
    >
    > Weamfox


    By George, I think he's got it!!

    John R
    John R, Mar 2, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. POL
    Replies:
    0
    Views:
    613
  2. Richard Simmons

    VPN 3002 Hardware client DHCP Server

    Richard Simmons, Mar 15, 2006, in forum: Cisco
    Replies:
    0
    Views:
    546
    Richard Simmons
    Mar 15, 2006
  3. Replies:
    5
    Views:
    472
    Whiskers
    Aug 19, 2006
  4. Crash
    Replies:
    6
    Views:
    429
    phstpok
    May 14, 2005
  5. Weamfox
    Replies:
    13
    Views:
    694
    Juergen Kluth
    Mar 5, 2008
Loading...

Share This Page