When a host needs to resend a packet (whatever the payload), is there any field in the header that gets modified, so that you can tell that it is a duplicate packet?
No. IP packet are not resent, that's a function of the higher protocol layers.
Some transport protocols, e.g. TCP or SCTP have retransmission built into them that re-sends packets at that protocol layer, some application protocols, e.g. DNS, applies retransmission at the application protocol layer.
The IP layer does not know or care about this, there is no protocol fields that identifies a retransmission from a higher layer.
Related
A packet reached the server of UDP type at Transport layer. When the source IP address is extracted from the received packet by the server (at Transport Layer), where does the server stores this address, as it will be required in future, since the connection between server and client is connection-less? Or what mechanism does server use to identify source (during a connection-less environment) in order to reply?
Why do you think the address is required in the future? It may not be.
Also, there is no such thing as client/server for the first four network layers of the OSI model. The client/server model is an application concept, not a network concept. Layer-2 (e.g. ethernet), layer-3 (e.g. IP), and layer-4 (e.g. TCP) are peer-to-peer protocols, not client/server protocols.
If an application on one host needs a reply from a host to which it sends data using UDP, it can include its host address as part of the UDP data in the application-layer protocol, and the receiving application can store the source IP and UDP addresses wherever it wants.
As you wrote, UDP is connectionless (and unreliable), and an application using UDP must assume that the UDP datagram will not arrive. The application either adds reliability as part of the application-layer protocol used, or it just doesn't care that some data will be lost. For instance:
Real-time applications use UDP, and some, like video applications are unidirectional. Others like VoIP use a signalling protocol to set up bidirectional traffic. Almost all real-time protocols don't want missing data to be resent because that would cause more problems. Having missing video or voice data resent, arriving out of order, would be chaos.
Are datagrams a protocol or not?
Is "Ping" (protocol ICMP) used in an IP DATAGRAM? Or is it using other protocols, such as TCP or UDP?
How do you know the message "Reply" the way back?
Why the Tel number stays the same?
https://en.wikipedia.org/wiki/IPv4#Protocol
Datagrams are basically the packets that go back an forth over the network at IP level. Each of these packets can specify a protocol. You can have TCP, UDP, ICMP, etc. (see https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers)
So to answer your question, yes the protocol for datagrams is basically IP.
You can have higher level protocols that run over IP such the one above.
See https://en.wikipedia.org/wiki/Internet_protocol_suite
Ping uses the ICMP protocol.
Are datagrams a protocol or no?
'Datagram' is the name of the unit of transmission in the UDP protocol.
Is "Ping" ( protocol ICMP ) used in a IP DATAGRAM?
The question doesn't make sense. It would make more sense to say that the ICMP protocol is transmitted via IP packets.
Or is it using other protocols, such as TCP or UDP ?
ICMP is a protocol: you said so yourself; and it is layered over the IP protocol.
IP protocol datagram header contains a Protocol field to define the protocol used in the data portion of the IP datagram.
How does a TCP packet identify the its application level protocols? I don't see similar fields in the TCP header format. So it all depends on the port number?
If so, does it mean I can silently switch the application protocol on the same port, just like what happens when WebSocket uses a handshake request in the format of HTTP to tell the server to switch from HTTP to WebSocket protocol?
TCP itself does not care about the application layer protocol used. The closest thing is the port number. Port numbers are used to distinguish different connections on the same host. When a packet is received, the operating system uses the port number to determine which program it belongs to. Although many protocols have standard port numbers, you are not required to use them.
So yes, you can switch protocols on the same port.
I started to learn Linux Networking and packets filtering. In the iptables documentation it is stated that:
If a packet is destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.
So, suppose there're 3 server apps on a host. Servers A and B are TCP servers, and C is UDP server.
Is it true, that if we receive an UDP packet, at IP level this packet is to be delivered for apps A, B, C? Or sockets of apps A & B wouldn't receive this packet at all?
TCP servers and UDP servers operate in very different ways.
At most one TCP server will listen on a given TCP port (corner cases ignored for the sake of simplicity). Connection requests (encapsulated in IP packets) destined for that port are "accepted" by exactly one process (more accurately, accepted by a process that has a file descriptor corresponding to exactly one listening endpoint). The combination of [remote_address,remote_port] and [local_address,local_port] is unique. A TCP server doesn't really receive "packets", it receives a stream of data that doesn't have any specific relationship to the underlying packets that carry the data (packet "boundaries" are not directly visible to the receiving process). And a TCP packet that is neither a connection request nor associated with any existing connection would simply be discarded.
With UDP, each UDP datagram is logically independent and may be received by multiple listening processes. That is, more than one process can bind to the same UDP endpoint and receive datagrams sent to it. Typically, each datagram corresponds to a single IP packet though it is possible for a datagram to be broken into multiple packets for transmission.
So, in your example: no, a server that is listening for TCP requests (a "TCP server") will never receive a UDP packet. The port namespaces for TCP and UDP are completely separate.
The delivery of the packet will depend on its destination port.
Lets assume that the servers A, B and C are listening on port 1111, 2222 and 3333 respectively, so when a packet with destination port 2222 is arrived, it will be delivered to server B.
My question wasn't well formulated, unfortunatelly. I understood it when I had seen the answers. Here is an explanation which I was looking for, it's from http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html#tth_chAp6: > When the process scheduler sees that there are networking tasks to do it runs the network bottom-half. This function pops packets off of the backlog queue, matches them to a known protocol (typically IP), and passes them to that protocol's receive function. The IP layer examines the packet for errors and routes it; the packet will go into an outgoing queue (if it is for another host) or up to the transport layer (such as TCP or UDP). This layer again checks for errors, looks up the socket associated with the port specified in the packet, and puts the packet at the end of that socket's receive queue.
What is TCP response packets?
How to meet this requirement in access-list on a router?
You probably want to look up stateful firewalling for whatever router you're using.
TCP response packets are basically any related TCP packets that come back after an initial SYN has been sent. Typically this would be either a packet with SYN+ACK set, or one with RST if the connection was refused.
Stateful firewalls keep track of not just the source and destination of individual packets, but what connection the packets belong to. By doing this they are able to distinguish between expected, legitimate replies to SYN packets (and others) and random or malicious unrequested "replies".