A crash-course guide to TCP/IP networking, although it's obviously not as simple or as cleanly implemented as this may suggest -
UDP packets only exist within one's own computer, notionally travelling from port to port as per the numbers specified in the UDP packet ... until they are dropped into a TCP packet wrapper with IP addresses, and can thus pass further up the network.
Someone receiving a TCP packet would normally filter anything which wasn't sent to their IP address and throw it away. Everything else gets the TCP wrapper stripped away and then it's thrown into their PC without the IP Addresses and the Port Numbers do the rest.
As UDP is wrapped in TCP to pass between IP addresses, IP is wrapped in Ethernet packets to pass between Network Interface Cards ( NIC's ) on the network where they use the MAC address to decide where they should be going. A NIC throws away any Ethernet packet not addressed to its NIC. There are a set of protocols ( ARP, RARP ) which allow a sending PC to determine the MAC of a PC which has a particular IP address and vice-versa so the sending NIC knows where to send a packet.
When it comes to sending UDP via your ISP to somewhere, it still needs wrapping in a TCP wrapper but if going via modem there is no MAC address for a modem so it simply sends it as a packet of serial data to the ISP. The ISP's modem gets the serial data, extracts the TCP packet, works out the MAC address of where it's to go from the IP adress provided, adds that on and pushes it off. It fakes a MAC address for the modem so response packets can be directed back and when they appear they are routed back up the modem to the sending PC.
For a PC talking to the NIC hardware ( bypassing the OS ) or a PICAXE talking to an ENC28J60, what gets written to the NIC is an Ethernet packet, so the PC/PICAXE has to build a UDP packet, add the IP addresses to create a TCP packet, add the MAC addresses to create an Ethernet packet and then send it to the NIC as a chunk, which gets buffered and then sent out.
On receipt, a NIC indicates it has received a packet, and then allows the PC/PICAXE to take one from its buffer. An entire Ethernet packet received is handed over. The TCP packet has to be extracted from that, and then the UDP packet, and then whatever the UDP data signifies can be dealt with.
To prevent the NIC shouting "got one" on every packet, it can be told to accept only packets to its MAC address and to Broadcast addresses, and some are now clever enough to take a peek into every packet to see if the IP address is correct or not. Conversely, a NIC can be told to act in "promiscuous mode" where it will catch every packet going by regardless of who it's really for, which is what Packet Sniffers do.
Creation of a packet to pass to a NIC to be sent somewhere is easy if the IP addresses and MAC addresses of the destination are known, but if not then it's necessary to use ARP and RARP mechanisms to discover those things. It's also necessary to ensure all sent packets have the right checksums and that's not always an easy task.
The IP of TCP/IP is a layer on top of TCP just as UDP, ARP and RARP are, but considerably more complex, with error checking, requests for re-transmission and handling data arriving in the wrong order. From the networking point of view it's just the same as the rest though, an IP packet gets wrapped in a TCP packet and so on.
The basic entity of the modern familiar network is TCP, carrying other packet types within it. As long as TCP packets can be packaged up and unpackaged at the other end, no matter what means is used ( NIC, modem, wireless etc ), everyone is happy and has not a care in the world over how packets got into the pool of those waiting to be dealt with; in that pool, all packets look just the same, envelopes waiting to be opened.
It's quite an elegant and simple system, but quite complex to implement and get right.