If the TTL of a IP packet becomes 0, then who will discard the IP packet i.e., either router or host.
The router.
If the TTL is 0, the packet is discarded, and never reaches the host.
More information in wikipedia
It's the router that discards it. From this post on CiscoPress:
Time To Live (TTL) is a well-known mechanism thanks to IP. In the IP header is a field of 8 bits that signifies the time that a packet still has before its life ends and is dropped. When an IP packet is sent, its TTL is usually 255 and is then decremented by 1 at each hop. If the TTL reaches 0, the packet is dropped. In such a case, the router that dropped the IP packet for which the TTL reached 0 sends an Internet Control Message Protocol (ICMP) message type 11 and code 0 (time exceeded) to the originator of the IP packet.
Related
I know that control bits in tcp define the flags of TCP connection like SYN, FIN, ACK. But from my network traffic sometimes for some packets control bits are 0 (not-set).
What does this behaviour mean?
Those are flags of a TCP segment, not connection.
When a flag bit isn't set that indicates the absence of the meaning and behavior defined for the corresponding flag.
It means ACK and only ACK flag is set. RFC says ACK is 16, however it's only 16 when used in combination with another flag e.g. SYN/ACK (18), FIN/ACK (17). Flags value 0 could also indicate a 'null' scan.
If you see a flow record with value 2 and there are 8 packets in it, that means there are both SYN packet(s) and ACK packets.
If you see 18 and there are more than 1 packet in the flow that means there is at least one SYN/ACK and the rest are ACK.
I'm really confused on how traceroute works, I read online that Traceroute uses ICMP messages and TTL fields in the IP header for its operation and transmits packets with small TTL values.
I did
test 1: traceroute <"domain">
traceroute was never able to map the final destination
test 2: traceroute -I -IP icmp <"domain">
the final destination was mapped but the confusion in all this is WHY ?, I thought Traceroute already uses ICMP.
Different tracroute implementations use different packets. Typically, either UDP or ICMP, although TCP traceroute exists as well.
You were probably using some UDP implementation.
Traceroute works by taking advantage of a feature called time-to-live (TTL), which is the number of hops a packet can take before it stops being retransmitted. The TTL is decremented by 1 for each hop the packet traverses. When the TTL reaches zero, the router on which it reached zero will send back an ICMP Time Exceeded packet to the source, rather than retransmitting the packet. The source (i.e. you) will then receive this packet from the router at which the original packet's TTL reached zero, and thus you'll know the IP address at which the packet failed. Traceroute works by sending out packets towards the destination with successively larger TTLs. This way, you'll get ICMP Time Exceeded packets for each hop on the path between you and the destination, because you'll have a packet reaching a TTL of 0 at each hop.
Now notice that nowhere here do we mention the protocol you're using to send your packets. TTL is in the IP header, which encapsulates the packet for the protocol you're using. Thus, you can use whatever protocol you want when tracerouting.
As for why traceroute hops resolve for some protocols and don't for others, its likely firewalls as well as policies on the routers you're traversing. Some routers either de-prioritize responding to ICMP, or have ICMP disabled. There's all sorts of reasons why some protocols happen to work better than others in a given case.
Exam question (with no additional info):
When an bunch of IP datagram fragments are being sent over the network and only one of them does not get to it's destination, what will happen then?
I'm not sure if ICMP is involved here or not. Does ICMP send an error report reporting to the source that it needs to resend that same fragment (only this one fragment)?
The problem is here that I don't know if the IP fragments use UDP or TCP therefore I don't know the answer to the question.
(I've posted on the networkengineering.stackexchange but my question was rejected)
Points to cover:
After a timer triggered by the receipt of the first fragment has expired, the reassembling host will discard all the of fragments.
The reassembling host may generate an ICMP Time Exceeded (Fragment reassembly time exceeded).
The first fragment will need to have been received for the ICMP to include the first 8 bytes of the triggering payload. IPv6 will not generate the ICMP Time Exceeded unless the first fragment was received.
With IPv6 if the reassembled datagram would be larger than 1500 bytes then it may be silently discarded.
If a higher level protocol with reliable delivery was used (e.g. TCP), then the originating host should retransmit datagrams for which no acknowledgement has been received.
I use raw socket to create TCP packets, with focus on the sequence number and TCP flags(SYN, ACK)
I used one machine S to send a tcp ACK packet (flag ACK is set to 1) and another machine R to receive it these two machines are in different subnets, all in my school
meanwhile, I used tcpdump to capture the packets.
Strange things happens! On machine S, the captured packet is as expected, it is an ACK packet however, on the receiving machine R, the packet becomes a SYN packet, and the sequence number is changed, the seq no is 1 smaller the expected and the ack_seq become 0!
what are potential problems?
my guess is that the router/firewall modified the ACK packet to a SYN packet because it never sees a SYN SYN/ACK exchange ahead of the ACK?
is it possible or not?
the two captured packets are:
https://docs.google.com/file/d/0B09y_TWqTtwlVnpuUlNwUmM1YUE/edit?usp=sharing
https://docs.google.com/file/d/0B09y_TWqTtwlTXhjUms4ZnlkMVE/edit?usp=sharing
The biggest problem you will encounter will be that the receiving TCP stack in each case will receive the packet and possibly reply to it. What you are attempting is really not possible.
I have a question on how TCP_ACK works when the original packet are fragmented.
For example, original packet size is 1,500*N bytes and MTU is 1,500. Then, the packet will be frgmented into (approximately) N packets.
In this case, how does the receiver sends TCP_ACK to the sender?
I checked with wireshark, it seems that the receiver sends TCP_ACK for every two fragmented packet. Is it right?
Could you give me some refereces for this or explanation?
Thanks.
IP layer on the receiver stack reassembles all the IP fragments into a single TCP segment before handing the packet over to TCP. Under normal conditions, TCP should send only one ACK for the entire TCP segment. The ACK # would be the next expected SEQ # as usual.