As a UDP segment traverses down the stack, each layer adds a header.

What occurs for this to happen? Does the kernel do a bunch stuff then add the header?

I am particularly interested in the transition from the network to data-link layer on an Ethernet system.

Is ARP performed and then the cache searched in order to provide the next hope information?

  • 1
    Every operating system does it a little differently. If you're looking for programming assistance, you might try asking on Stack Overflow. – Ron Trunk Jan 31 '17 at 16:23
  • Alright. I'm not looking for programming assistance, was just trying to understand the idea in general. – user_ABCD Jan 31 '17 at 16:24
  • You might want to take a look at the MAC and LLC Sublayers to better understand the encapsulation process. The LLC Sublayer communicates with the Network Layer and is implemented in software (in the NIC's driver which is OS-dependant). The MAC Sublayer interacts with the Physical layer, provides access to the physical medium and is responsible for data encapsulation, it is implemented in hardware (in the NIC itself). – chomba Feb 2 '17 at 1:38
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it. – Ron Maupin Aug 7 '17 at 16:29

Each OS can do this differently. It is up to the OS designers how this specifically happens in an OS.

RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware gives you a general outline of what is supposed to happen, but an OS could skip the whole table creation and use ARP requests for every packet.

Packet Generation:

As a packet is sent down through the network layers, routing determines the protocol address of the next hop for the packet and on which piece of hardware it expects to find the station with the immediate target protocol address. In the case of the 10Mbit Ethernet, address resolution is needed and some lower layer (probably the hardware driver) must consult the Address Resolution module (perhaps implemented in the Ethernet support module) to convert the pair to a 48.bit Ethernet address. The Address Resolution module tries to find this pair in a table. If it finds the pair, it gives the corresponding 48.bit Ethernet address back to the caller (hardware driver) which then transmits the packet. If it does not, it probably informs the caller that it is throwing the packet away (on the assumption the packet will be retransmitted by a higher network layer), and generates an Ethernet packet with a type field of ether_type$ADDRESS_RESOLUTION. The Address Resolution module then sets the ar$hrd field to ares_hrd$Ethernet, ar$pro to the protocol type that is being resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet address), ar$pln to the length of an address in that protocol, ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address of itself, ar$spa with the protocol address of itself, and ar$tpa with the protocol address of the machine that is trying to be accessed. It does not set ar$tha to anything in particular, because it is this value that it is trying to determine. It could set ar$tha to the broadcast address for the hardware (all ones in the case of the 10Mbit Ethernet) if that makes it convenient for some aspect of the implementation. It then causes this packet to be broadcast to all stations on the Ethernet cable originally determined by the routing mechanism.


It is handled by a protocol stack, namely, an Internet Protocol Stack. For example, there is the Lightweight Internet Protocol Stack. Once you get to the link layer, e.g. Ethernet or WiFi, you are then talking about firmware functionality.

  • My question is how does it happen in the stack. Not just where. The other answer here states it is OS dependent. – user_ABCD Jan 31 '17 at 22:18
  • But more specifically, It's protocol stack dependent. The protocol stack is a component of the OS. But, whatever works for you... Windows is known to have messaged "Windows couldn't automatically bind the IP protocol stack to the network adapter". – Ronnie Royston Jan 31 '17 at 22:22
  • Ahh I think I follow you. You are saying it is specifically dependent on the protocol stack packaged in the middle-ware of a given OS. – user_ABCD Jan 31 '17 at 22:24
  • @user_ABCD, but if you look how Linux does it, much of the network stack is actually built into the kernel. At one time, the network stack for Windows was a complete add-on from a third party, and Windows shows its roots in that. Other OSes do it differently. – Ron Maupin Jan 31 '17 at 22:37
  • @RonMaupin POSIX / BSD sockets constructs / IPC but it does boild down to monolithic vs micro or hybrid kernel I suppose. MAC/PHY "hooked into Linux kernel" IEEE 802.15.4 – Ronnie Royston Jan 31 '17 at 23:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.