I understand that UDP resides on the transport layer and IP on the internet layer. I also get that they're both connectionless and unreliable. Then what is the point of UDP when we already have IP? The distinction is not very clear. Any help on this is greatly appreciated. Thanks!
Then what is the point of UDP when we already have IP?
To multiplex services. The UDP port number can differentiate between multiple services on the same host, using the same L3 identification. Using IP only it wouldn't be possible to host multiple services on the same station and easily differentiate between them.
Also, consider the case of UDP over IPv6. Since IPv6 doesn't have error-checking somebody has to perform it: the Checksum field of UDP is not optional.
Once a packet reaches a host using its IP address, the packet needs to be given to one of the applications on this machine. To determine which application should get the packet, it needs demultiplexing logic, which is based on ports. UDP has port information which is used by IP to deliver the packet to appropriate application.
Related
I know that when two machine communicate they may use the TCP/IP protocol.. But after the IP packet is routed to my router and it is converted to physical signal , how does my computer again decapsulate it and send it to proper application....I know that transport layer header is used for identifying port numbers to send it to proper process,but which device will do all these inside a host..am new to network and apologize if something was wrong or silly here
A packet comprises of information in the form of [header[body]] which will be looked up and processed across all the layers in the TCP/IP stack.
The information related to the all layers are encapsulated into a single packet.
Packet being a general term here, can be of many types based on the protocol with which two nodes are communicating (TCP Packet, UDP Packet, IP Packet etc). The information from a TCP/IP packet for example, are processed by different devices or services working at specific layers.
Switches or Bridges operate at the Ethernet layer. These devices switch packets inside LAN by looking up the MAC address information.
Routers operate at the Internet Layer and utilizes the IP protocol (i.e., IP address) to route traffic between networks.
Stateful firewalls, Proxies, Load Balancers etc. are at the transport layer. They work based on the TCP or UDP information to allow/deny/direct traffic.
Application layer facilities effective communication between application programs in a network. The application layer is not the application itself that is doing the communication. It has protocols such as DNS, FTP, SMTP, SNMP to help and serve the purpose.
References:
https://docstore.mik.ua/orelly/networking/firewall/ch06_03.htm
https://technet.microsoft.com/en-in/library/cc786128(v=ws.10).aspx
We all say that IP is connection less protocol but network layer provides us with switching facility wherein we have packet switching under which, we have virtual packet switching which is connection oriented i.e resources are reserved on the way. Then why do we say IP is connection less as every packet travels in IP datagram?
Well I think that network layer has many other protocols which might use virtual ckt concept. IP uses datagram service, so it is connectionless. Because in datagram service packets go independently without any reservation of resources.
From what I've read, TCP sits on the layer between the application and IP, and handles setting up the packets, checking for errors, ordering etc so the application itself doesn't have to do it.
However, when I looked at the TCP header I became confused. From the way I understand it, some data is handed to TCP from the application, and is given a destination address to which to send the data. The TCP layer packages it up, and sends it on to the IP layer, who in turn hands it off, all the way on down to the physical layer.
But looking at the TCP header on Wikipedia, there is no mention of a destination address! There is only a destination port number which I am pretty sure is not an address.
So my question is, how does TCP get the addresses? And/or, how does IP get the address if TCP isn't passing them to it?
It's the Application that's running on top of Transport Layer that chooses everything.
If the Application is designed with reliability in mind, it chooses the connection oriented protocol like TCP.
The same applications tells TCP what the Source and Destination port should be, TCP alone cannot decide this.
Example: If you're accessing a website, your Application would be the browser, since accessing websites normally happens over HTTP/HTTPS and HTTP/HTTPS is designed to be reliable, it chooses TCP. Port 80(HTTP) or 443(HTTPS) are the standard ports used for accessing websites, so either of these ports are used in the Destination Port field while the Source Port can be any random higher number port.
This combination is used to identify something called Transport Layer VC(Virtual Circuit).
Coming to IP, the same application tells what the Destination IP address is, while the Source IP is the machine from where you are running the browser.
IP in Network Layer and TCP in Transport Layer cannot choose anything, it's the Application that tells them what to choose, considering they are the chosen ones.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
I am familiar using IPv4 broadcast of UDP packets as a technique for probing the network looking for servers running a given service. I.E. the broadcast packet is sent out on a given port and the listening servers can reply to this packet and the reply will allow the client to know the ip addresses of the available servers.
I am wondering what the recommended accepted technique is for doing the same type of network probing for IPv6. I have not done much with IPv6 but would like to make my new application compatible with it (for future proofing). I know I cannot use broadcast packets in the same way as IPv4 allow because this feature is taken out of IPv6. I would expect there must be another way to achieve the same thing.
You can use the link local all nodes multicast address ff02::1 to achieve the same result