The Destination of packet No.17, 22, 200, 390, 531, 535 should be broadcast message, but why are they my ip address?
Note that I have released my IP.
There are only specific circumstances where the DHCPOFFER and DHCPACK should be broadcast. In most cases, those should be unicast back to the requesting host.
The server knows the MAC address of the requesting host, so the frame is unicast back to the requesting host unless the requesting host has set the broadcast bit in the DHCPREQUEST.
See RFC 2131, Dynamic Host Configuration Protocol:
Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
unicast delivery. The IP destination address (in the IP header) is
set to the DHCP 'yiaddr' address and the link-layer destination
address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP datagrams
until the implementation has been configured with a valid IP address
(leading to a deadlock in which the client's IP address cannot be
delivered until the client has been configured with an IP address).
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP
clarifications document discusses the ramifications of the use of the
BROADCAST bit [21].
-and-
In the case of a client using DHCP for initial configuration (before
the client's TCP/IP software has been completely configured), DHCP
requires creative use of the client's TCP/IP software and liberal
interpretation of RFC 1122. The TCP/IP software SHOULD accept and
forward to the IP layer any IP packets delivered to the client's
hardware address before the IP address is configured; DHCP servers and
BOOTP relay agents may not be able to deliver DHCP messages to clients
that cannot accept hardware unicast datagrams before the TCP/IP
software is configured.
To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
defined as the BROADCAST (B) flag. The semantics of this flag are
discussed in section 4.1 of this document. The remaining bits of the
flags field are reserved for future use. They MUST be set to zero by
clients and ignored by servers and relay agents. Figure 2 gives the
format of the 'flags' field.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
MBZ: MUST BE ZERO (reserved for future use)
Figure 2: Format of the 'flags' field
Related
Whether IP addresses will be visible to layer 2 (data link layer) devices. If not, then how come those layers use ARP protocols to convert IP address to MAC address without knowing IP address.
Thank You.
From thread here
ARP has always been a Layer 2 protocol. The reason: The highest layer addresses carried within ARP are Layer2 MAC addresses for typical ARP operation. The IP addresses in the ARP packets are protocol payload, no addressing information of the ARP packet itself.
ARP is a protocol that does not fit too well into the 7 layer OSI model or the ancient DoD layer model. These models were defined for end user applications like HTTP or FTP and they still define, how traffic is sent from application to application through a network stack (L3+L4) and a network interface (L2 + L1) down on the wire.
ARP is a service protocol that glues together layer 2 and layer 3 protocols. It solves the problem that you need to add a layer 2 (MAC) destination address over a shared media like Ethernet or Wireless LAN using IP packets. But ARP is a separate process with separate packets. You will find no ARP protocol information within an IP packet. This is the reason, why ARP is definitely not a layer 2.5 protocol.
Whether IP addresses will be visible to layer 2 (data link layer) devices.
generally speaking no. Ethernet header has ethertype field, which speficies next header format after the current ethernet header. There are a couple of values that are still at layer 2, like VLAN tags, spanning tree BPDUs, and similar. If Ethertype is anything else, layer 2 device is not supposed to look into it. (And a device that does should not really be called layer 2 device)
On end-hosts, ethertype will determine how packet is processes, after layer 2 processing is done. But this is no longer layer 2 processing.
If not, then how come those layers use ARP protocols to convert IP address to MAC address without knowing IP address.
I think you think of it backwards. ARP protocol is used by IP layer to find MAC address of a device with a given IP address on a local network. It is not used by layer 2 to map IPs.
For example, let's say your home network has two devices, your laptop which has IP 192.168.0.10 and your phone, which has IP 192.168.0.20. The network mask is /24. Now you want to send a packet from your laptop to your phone, for example ping 192.168.0.20.
First, an ICMP packet is created. Next, layer 3 determines where to send the packet. It has determined that the other host is connected to the same local network (based on first 24 bits of both addresses).
Next, this packet needs to be sent to local network. However, local network is layer 2, and layer 2 can only forward MAC addresses. Thus layer 3 signals layer 2 to do "MAC address lookup" for the IP address. Approximatelly, your laptop will send a broadcast packet to all connected devices saying that it looks for MAC address of a device that has IP address 192.168.0.20. Since your phone currently has this address, it replies, with its own MAC address. When the laptop receives the reply, it can send a frame with destination MAC to your phone. Note: laptop will usually also save an entry in its APR cache.
When we establish a TCP connection from PC1 to Server and send data through this connection, how does the Router know to which of the two PCs (PC1 and PC2) should it communicate on the way back from Server to PC1?
And
How does ping (ICMP) know to which internal node it should send the answer?
NAT (Network Address Translation) is stateful. It creates a translation table that has the layer-3 and layer-4 protocols and addresses. By looking up the return traffic addresses in the translation table, the NAT process can determine which inside addresses should be placed in the packet.
Edit:
Per the edit to your question, asking about ICMP (it is very bad form to change the question in order to ask a different question because it can invalidate the perfectly acceptable answers already given):
It is all the same as TCP or UDP. NAT creates a state table that is dynamically built as traffic passes from inside to outside. NAPT will allow you to overload a single IP address with traffic from multiple inside addresses, and it will translate the return traffic by looking up where to send it in its state table.
With NAPT, besides looking at and translating the IP address, NAPT looks at the layer-4 protocol (TCP, UDP, ICMP) and translates the layer-4 addresses (TCP or UDP port numbers or ICMP identifies), too, storing the translations in its translation table. When return traffic is destined to a particular layer-3 and layer-4 address combination, from a particular layer-3 and layer-4 address combination, the NAPT process finds that in its translation table, and it can see where to send the traffic on the inside.
NAT is very resource intensive, and it breaks the IP paradigm of end-to-end connectivity, where every host is uniquely identified by its own IP address, which is why it is called a kludge (or worse). NAT was developed to extend the life of IPv4 until IPv6, with its nearly unlimited addressing, can become ubiquitous.
RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations:
4.1.2. Network Address Port Translation (NAPT)
NAPT extends the notion of translation one step further by also
translating transport identifier (e.g., TCP and UDP port numbers, ICMP
query identifiers). This allows the transport identifiers of a number
of private hosts to be multiplexed into the transport identifiers of a
single external address. NAPT allows a set of hosts to share a single
external address. Note that NAPT can be combined with Basic NAT so
that a pool of external addresses are used in conjunction with port
translation.
For packets outbound from the private network, NAPT would translate
the source IP address, source transport identifier and related fields
such as IP, TCP, UDP and ICMP header checksums. Transport identifier
can be one of TCP/UDP port or ICMP query ID. For inbound packets, the
destination IP address, destination transport identifier and the IP
and transport header checksums are translated.
A NAPT router in figure 2 may be configured to translate sessions
originated from N-Pri into a single external address, say Addr-i.
Very often, the external interface address Addr-Nx of NAPT router is
used as the address to map N-Pri to.
There is a large pool of resources describing NAT (Network Address Translation), which is available if you search "nat explained". A great resource is What is NAT and how it work tutorial.
The most important detail is that commonly we use NAPT (commonly used as PAT - Port Address Translation) (Network Address and Port Translation), alongside NAT.
When a device needs to use the Internet, it must open a local (source port) and send the IP request to the other end. For example, a notepad with source IP address 192.168.1.2 needs to communicate with a web server at 216.58.212.35.
It fires up random source port 1234 and requests information from target port 80 (HTTP - Web page).
This goes through the networks NAT device, which stores the information 192.168.1.2/1234 with the next information that it computes, and sends the request as 46.103.93.105 (its own IP public IP) and a new source port, for example 2345.
The web server responds to the NAT device, which in turn finds the correlated information (source port 2345 targets 192.168.1.2/1234). The notepad receives the information and displays it to the user.
The router adds information to the request header sent to the server that allows it to look up the sender when the reply is received. This is usually accomplished by using a table stored in the router's memory that maps the PC's address to the token added to the header.
I'm trying to understand what sort of structural changes happens to the IP packet during the Hop.
Allow me to please explain my question with example.
traceroute -w 1 google.com
traceroute to google.com (216.58.199.174), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 1.055 ms 0.857 ms 0.822 ms
2 10.0.0.1 (10.0.0.1) 2.038 ms 1.477 ms 1.540 ms
3 * * *
4 114.79.130.1.dvois.com (114.79.130.1) 3.091 ms 2.076 ms 2.329 ms
5 10.241.1.6 (10.241.1.6) 3.245 ms 3.102 ms 3.358 ms
6 10.240.254.140 (10.240.254.140) 4.388 ms 2.149 ms 2.319 ms
7 10.240.254.1 (10.240.254.1) 3.067 ms 3.336 ms 2.852 ms
8 10.241.1.1 (10.241.1.1) 2.542 ms 2.339 ms 3.231 ms
9 1.186.191.10.dvois.com (1.186.191.10) 3.046 ms 3.076 ms 3.382 ms
10 216.239.62.212 (216.239.62.212) 3.290 ms 3.559 ms 3.466 ms
11 209.85.143.5 (209.85.143.5) 3.699 ms 3.250 ms 4.062 ms
12 bom05s08-in-f174.1e100.net (216.58.199.174) 3.739 ms 4.038 ms 3.803 ms
Assuming that I'm making a request to google.com
The first thing the IP packet originated from my machine would do add this bit inside packet.
(My machine) source IP i.e assuming it is 192.168.0.100
also a port number is assigned from where the request was originated for simplicity let assume it is 6000
destination IP i.e google.com IP 216.58.199.174 (also the destination port is assigned for simplicity let assume it is 80)
my mac address
There other detail as well that an IP packet contain but let just focus on these 3 part
Now I know IP packet are transferred from source to destination with help of other devices / routers in hops (as can be seen in the traceroute output)
But what I'm not clear of whether the source IP & port inside the IP packet are update in Hop.
I'm assuming it does because that way it response coming from the server (google server over here) can be relayed back to the intended originator of the request (that is my laptop browser window).
So If what I'm assuming is correct. Here how things work then
On 1st Hop to my router my router update the source IP to 192.168.0.1 and source port to 6001(lets assume)
Internally it maintain a reverse entry table telling that If I ever happen to receive a response on 192.168.0.1 at port 6001 then I have to route it to 192.168.0.100 to port 6000.
Like wise in each Hop(hop to 114.79.130.1.dvois.com , 1.186.191.10.dvois.com and others) a entry is update i.e source IP and source port(in IP packet) and reverse mapping is maintain to relay the response back.
Is my understanding correct?. Also a what happen to MAC in hop.
You need to look at the network layers. An application will send data to the Transport Layer, e.g. TCP.
TCP has addresses called ports, and the application is assigned to one of the addresses, port 6000 in your example. TCP will segment these data and put TCP headers on the data segment. The TCP headers include the source and destination port number.
TCP will send the segments to layer-3 (IPv4 or IPv6). IP will encapsulate the TCP segments into IP packets. The IP packet headers will contain the source and destination IP addresses.
IP will send the IP packets to layer-2, e.g. ethernet. Not all layer-2 protocols use MAC addresses. MAC addresses are used by IEEE LAN protocols. Other layer-2 protocols use something else, or nothing at all for addressing. Ethernet will encapsulate the layer-3 IP packets in layer-2 ethernet frames. The ethernet frames will have the source and destination MAC addresses. The host (your computer) will mask both the source and destination layer-3 IP addresses to determine if the destination address is on the same LAN. If the destination is on the same LAN, the frames will be addressed with the MAC address of the destination host, otherwise they are addressed with the MAC address of the configured gateway as the destination host. This will require resolving the layer-3 addresses to the layer-2 addresses. ARP (Address Resolution Protocol) will look to see if the destination host MAC address is in its ARP cache. If not, it will send an ARP request to get the destination MAC address.
Layer-2 will then send the frames to layer-1 (physical interface) to be encoded and placed on the wire.
When the frame is received by the router, the layer-2 frame, including the MAC addresses, is stripped off the packet and discarded, losing the original MAC addresses. The router will decrement the TTL and create a new header checksum, and inspect the layer-3 IP packet for the destination address. The router will then look up how to get to the destination IP address in its routing table. If it doesn't find a route to the destination IP address in its routing table, the packet is discarded, otherwise the router will switch the packet to the next interface toward the destination and create a new layer-2 frame for the new interface. If the next interface is a WAN interface, it may use something like PPP that doesn't use MAC addresses.
The next router in the path will get the new frame, and it will repeat the routing process. This happens until the packet gets to the last router, and the last router will put on a frame for the destination LAN. The destination host will process in reverse order from the sending host. The destination host will have the source layer-3 and layer-4 addresses from the packet and segment, and it can send back to the source using those addresses in the same manner that the original host was the sender.
Routers are layer-3 devices, and they only look at the layer-3 packet, not into the layer-4 segment. A router will only change the TTL and Header Checksum fields of the packet.
Hmm.
Look. Every router has a default gateway for a network range, so if it handles your packet going from your IP A to some remote IP C it does not need to rewrite anything. It just knows, that it has to forward this packet to the interface, say, 3.
Of course it may have route cost and many other settings, but generally it is like that.
It does not need to remember and store your table. It has only route table to intercommunicate with neighbour routers.
Look here: https://en.wikipedia.org/wiki/Time_to_live
Every hop TTL value decreases. At 0 value the packet will be killed.
L2 devices change nothing.
L3 (routers) devices rewrite L2 info (MACs)
IP address is changed by NATs, FWs, Proxy and so on. Generic router does not change neither IP nor port (souce and destination) values. It changes TTL. It may rewrite ToS.
When a computer, with IP address IPs and default gateway IPg, is sending a datagram to destination with IP address IPd on a different subnet, it will perform:
a)- ARP(IPg)
b)- ARP( IPd)
c)- ARP(IPs)
d)- ARP(0)
Sending packet to another subnet actually means sending packet to gateway, since gateway is responsible for proper routing between subnets. Thus computer will perform discovery of gateway MAC address unless it's cached.
By searching on internet I got information that Address Resolution Protocol (ARP) is Link Layer (L2) protocol. As per ARP functionality it broadcasts to entire network to check to whom this specific IP belongs to get its MAC address.. but as ARP is L2 protocol, how does it knows destination IP address as IP's are encapsulated in L3 and L2 protocol can't read it
Layer 3 and above are located in the "Payload" part of an ethernet header.
As you can see here the ARP packet also contains IP addresses from its sender and receiver:
ARP packet contain source HW address and src IP address as well as destination HW address and destination IP also .
when ARP resolution happens, means when ARP send request and get response from same destination,ARP update the destination IP in arp_entry .
I would like to elaborate on the previous questions.
first, here it is the case where you can't really apply the model. ARP is sometimes layer 2 and sometimes layer 3 (the similar functionality in IPv6 is done with neighbor discovery protocol, which is carried in ICMP packets)
ARP packets do not carry IP payload. They only carry ARP packets. See other answers for the format
ARP is executed by two end-hosts, which both have to implement both layer 2 and layer 3
ARP is initiated by layer 3, when layer 3 tries to send packet to an IP address on the local network.
ARP is processed by a host, which implements both layer 2 and layer 3. A host without layer 3 cannot have an IP address.
Intermediate layer 2 systems generally cannot process ARP requests, past forwarding ethernet packets with broadcast destination MAC