Results 1 to 7 of 7

Thread: DHCP (UDP ports 67 and 68)

  1. Arrow DHCP (UDP ports 67 and 68)

    In most client-server-applications, the port number of a server is a well-known number, while the client uses a currently available 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.

    Does anybody know the reason why this protocol design was chosen? Why should a DHCP client also listen on a well-known port?

    I will appreciate any kind of responses.

    Thanks for geeking.

  2. #2
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,941
    Blog Entries
    4

    Default Re: DHCP (UDP ports 67 and 68)

    DHCP is a UDP service. So there are no connections and there is no "listening". So you need different source ports to identify whether the packet comes from a server or a client.

    With a TCP service there are also two ports. It's just that one of the ports is usually a random high port selected by the client so you don't normally think about this port.

  3. #3

    Default Re: DHCP (UDP ports 67 and 68)

    server will always have the port number from where it gets the packet so this can not be the right answer,
    this requirement might be put on so that there can be only one dhcp client instance running at a time.

    Thanks
    devesh


    Quote Originally Posted by ken_yap View Post
    DHCP is a UDP service. So there are no connections and there is no "listening". So you need different source ports to identify whether the packet comes from a server or a client.

    With a TCP service there are also two ports. It's just that one of the ports is usually a random high port selected by the client so you don't normally think about this port.

  4. #4
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,210

    Default Re: DHCP (UDP ports 67 and 68)

    If you want to research your question, it's almost certainly in one of the RFC at ietf.org.

    A list of DHCP related RFC in chronological order
    Appendix C: DHCP RFCs

    I hadn't thought much of this, but DHCP is fundamentally a broadcact protocol (cannot be UDP or TCP because the client does not yet have an assigned address) so it would make sense that kind of traffic should be configured so it would only be listened to, depending on whether the Host is a DHCP server, Host without an address (but identifiable by MAC address) or ignored because the Host already has an IP address.


    TSU

  5. #5

    Default Re: DHCP (UDP ports 67 and 68)



    On 03/07/2013 04:26 AM, tsu2 wrote:
    > I hadn't thought much of this, but DHCP is fundamentally a broadcact
    > protocol (cannot be UDP or TCP because the client does not yet have an
    > assigned address) so it would make sense that kind of traffic should be


    No, part of that is not true. While TCP and IP are almost always used
    together (other than when UDP and IP are together) they do not require one
    another and are on different layers of the OSI model (IP is layer three,
    TCP and UDP are layer four). DHCP does use ports, specifically 67 and 68
    as mentioned earlier and as can be seen in /etc/services on any old box.
    Just because something does not have an IP address does not mean there
    cannot be some other protocol at layer three doing the work. Really all
    intra-broadcast-domain (intra-network) traffic "routes" (or gets switched
    or broadcasted) via MAC addresses alone, not IP address, from one host to
    another, so in that case while the IP address was used to "resolve" to the
    MAC address, the most-important part for traffic delivery is just the MAC
    address, or else DHCP/bootp would never work (how could it? no IP
    address, as you mentioned).

    Going up to the post to which you responded by devesh2408, there are some
    errors there too. The first post that I can see (via NNTP.. this thread
    is too old to show the entire thing in my newsreader for some reason) from
    ken_yap has 'So there are no connections and there is no "listening"'
    which is half-true.... there are no "connections" in the TCP sense
    (meaning there will never be a connection showing up in 'ss' or 'netstat'
    but there is, of course, listening, and that does show up in 'ss' or
    'netstat'. `/usr/sbin/ss -au` or `netstat -anu` will show the same stuff.

    With all of that said, I cannot figure out what the original point of this
    thread was, so hopefully those corrections help in some way. The rest
    seems to be in order, and I'll toss out that there is a dhcpcd-test
    command that is pretty useful for troubleshooting DHCP stuff when you box
    already has an address and you just want to test the server:

    Code:
    ----------
    /usr/sbin/dhcpcd-test eth0
    ----------

    Good luck.

  6. #6
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,210

    Default Re: DHCP (UDP ports 67 and 68)

    Quote Originally Posted by ab View Post
    On 03/07/2013 04:26 AM, tsu2 wrote:
    > I hadn't thought much of this, but DHCP is fundamentally a broadcact
    > protocol (cannot be UDP or TCP because the client does not yet have an
    > assigned address) so it would make sense that kind of traffic should be


    No, part of that is not true. While TCP and IP are almost always used
    together (other than when UDP and IP are together) they do not require one
    another and are on different layers of the OSI model (IP is layer three,
    TCP and UDP are layer four). DHCP does use ports, specifically 67 and 68
    as mentioned earlier and as can be seen in /etc/services on any old box.
    Just because something does not have an IP address does not mean there
    cannot be some other protocol at layer three doing the work. Really all
    intra-broadcast-domain (intra-network) traffic "routes" (or gets switched
    or broadcasted) via MAC addresses alone, not IP address, from one host to
    another, so in that case while the IP address was used to "resolve" to the
    MAC address, the most-important part for traffic delivery is just the MAC
    address, or else DHCP/bootp would never work (how could it? no IP
    address, as you mentioned).
    Interesting, trying to parse what you are describing.
    I agree with all you said that I can understand, but am trying to identify exactly what I might have described that was incorrect so I can correct my own understandings about "how things are."

    By default, the DHCP bootp protocol is broadcast only (by default cannot pass routers, in those cases a DHCP Proxy would need to be setup), and should pass through switches (Someone might block, but I can't think why). As you describe, IP can and does exist without TCP (and AFAIK UDP is defined mostly as the absence of TCP but does require source and destination IP addresses unlike broadcasts and so is also routable).

    Now, getting back to the OP my speculation is that because broadcasts are very bad on a network (can eat up machine resources if machines process network info not intended for them), a simple way to minimize machine resource usage is to simply listen to a port or not. Once a machine has an IP address, it can simply ignore anything that arrives on that port, blocking at the lowest levels of the OSI layers.

    As for the role of the MAC address, I might go off-topic a bit in saying that AFAIK all networked devices actually fundamentally identify each other <only> using the MAC address and not just for "intra-domain switching"and not as you might be suggesting when an IP address is not available. IP addressing is a convenient mechanism humans created to better understand and manage the goings-on at the lower MAC level In other words, although we humans use IP addressing, machines will <always> translate IP addresses to the underlying MAC address when actually doing work.

    Still geeking,
    TSU

  7. #7

    Default Re: DHCP (UDP ports 67 and 68)

    While I appreciate this thread is an old one I just wanted to add some insights into DHCP and broadcast.
    DHCP messages are only broadcast during the INIT and REBIND state. If the client is on the same subnet as the server it is only the DHCP DISCOVER and REQUEST messages that are broadcast from the client to the DHCP server.

    While it's true that the Client has no layer 3 address until the DHCP ACK is received the DHCP OFFER and ACK are both sent unicast, the client passes it's MAC (layer 2) address as part of the DHCP DISCOVER message so the server knows which device it is sending the message back to when it sends the offer and it also uses the layer 3 address it is offering as the destination address.

    When the time comes to try and renew the lease at time T1 the client unucasts it's DHCP REQUEST to the server that allocated it's address, it only switches to broadcast if it does not get a response to that at time T2.

    Raven68

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •