DHCP, ARP, RARP, PXE, ICMP, OSI, TMA (was: Cheap Gigabit switch ...)

Ben Scott dragonhawk at gmail.com
Sun Dec 30 13:44:30 EST 2007


On Dec 29, 2007 3:15 PM, Paul Lussier <p.lussier at comcast.net> wrote:
> If memory serves (though, often times, sadly, it serves incorrectly :)
> DHCP is heavily dependant upon (r)ARP (specifically when combined with
> PXE), which kinda sorta sits in a no-where land between layers 2 and 3
> (like ICMP).

  I think this is one of those times memory is serving you somewhat
incorrectly.  :)  Which means that it is time for -- you guessed it --
one of my patented long messages on the details of technology!  :-)

== DHCP ==

  DHCP is implemented entirely in broadcast UDP [1].  To find a DHCP
server, the DHCP client sends a DHCPDISCOVER datagram to the universal
broadcast address, 255.255.255.255.  Every node on the local network
is supposed to get that datagram.  Any DHCP server will then respond
with a DHCPOFFER broadcast identifying itself.  The client will pick a
DHCP server, and send a broadcast DHCPREQUEST identifying which server
it picked.  The server sees that, and broadcasts a DHCPACK.

  The IP layer is responsible for translating IP broadcasts into
data-link layer terms.  For Ethernet, it just sends a frame to the
Ethernet broadcast address (FF:FF:FF:FF:FF:FF).  Because it's all done
using broadcasts, ARP never gets involved.

  [1] Exception: If the DHCP client already has an active lease, and
just wants to renew it, the DHCP client and server will use unicast
datagrams in that transaction.  So ARP gets involved there.

== ARP ==

  Now, it is true that just about everything using IP is heavily
dependent on ARP [2], because ARP is responsible for turning unicast
IP addresses into unicast Ethernet addresses.  An ARP failure means no
IP datagrams can be sent to a given IP address, which means no TCP,
UDP, ICMP, or anything else.  ARP is part of the IP suite, but not
layered on top of the actual Internet Protocol.  It exists alongside
IP.

  ARP is easiest to explain by example.  Say we have two nodes, ALPHA
and BRAVO, on an Ethernet.  ALPHA has IP address 192.0.2.10, and BRAVO
has IP address 192.0.2.99.  ALPHA wants to send a packet to BRAVO, and
knows BRAVO's IP address.  But it doesn't know the Ethernet address of
BRAVO.  So ALPHA sends an Ethernet broadcast frame (the ARP request),
saying "I have IP address 192.0.2.10.  Who has IP address 192.0.2.99?"
 Everybody on that Ethernet sees the request.  BRAVO recognizes its
address, and responds with a unicast Ethernet frame saying, "I have
192.0.2.99.".  BRAVO can use unicast because it got the ALPHA's
Ethernet address from the ARP request frame.

[2] Exception: Not every data-link type needs ARP.  It is possible to
have other means of deriving data-link addresses, and point-to-point
links (SLIP, PPP, etc.) don't need to.

== RARP ==

  RARP is a completely a different design vs DHCP/BOOTP.  RARP has the
game goal as DHCP, in that RARP exists to let nodes without an IP
address discover what their IP address should be.  However, RARP does
not use UDP or anything else on top of, or within, the Internet
Protocol itself.  RARP is implemented outside of the IP layer, using
data-link frames, similar to ARP.  RARP is also limited to assigning
an IP address, nothing more; DHCP can assign arbitrary configuration
parameters.

== PXE ==

  PXE doesn't really have anything to do with DHCP directly.  PXE is
just a standard network boot mechanism for the i386 IBM-PC
architecture.  Of course, PXE does use DHCP to discover it's boot
configuration, but the DHCP it uses is no different than another other
DHCP (in terms of DHCP internals).

  I've never seen anything about PXE being able to use RARP, but then,
nobody uses RARP these days, so maybe it's possible and just nobody
cares.  :)

== ICMP ==

  ICMP is implemented on top of the IP layer, along side the TCP and
UDP layers.  All ICMP datagrams are IP datagrams, same as UDP or TCP.
Other than their specific payload, there is nothing different about
ICMP datagrams vs other IP datagrams.

== OSI model ==

  The 7-layer OSI network model does not really equate neatly,
one-to-one, with the IP model.  That's why I called IP and friends
"layer 3 and higher".

  It is accurate to say that everything in the IP suite is implemented
at layer 3 or higher.  Layer 2, the data-link layer, would be things
like Ethernet, FDDI, Token-Ring, ATM, PPP, 802.11 wireless, and so on.
 Everything in the IP suite, including IP itself, along with ARP and
RARP, is implemented on top of the data-link layer, putting them in
layer 3 or higher.

  IP itself does closely fit in the OSI model's idea of a layer 3
(network layer) protocol.  However, ICMP would also be considered a
network layer function in OSI, but it's stacked on top of IP.  ARP
would also be considered a OSI network layer function, but it exists
outside of IP itself.  UDP is strictly a layer 4 (transport) protocol
by OSI terms, but TCP handles both transport and session (layer 5)
functions in the OSI model.  So fitting the IP suite in to the OSI
model is kind of a mess.

  Fortunately, nobody really cares about OSI anymore, either.  :)

  To avoid pedantic discussions like this one, it's best to use terms
like "data-link layer", "IP layer", "TCP layer", and so on, when
dealing with IP and associated networks.  My bad for even mentioning
"layer 3" in the first place.

-- Ben


More information about the gnhlug-discuss mailing list