what are layer aware devices - http

What are layer-1, layer-2, layer-3, layer-4 aware devices? What is the difference between them and what makes them belong to specific layer? I found very little on the internet
This is from the HTTP book I am reading:
In Ethernet networks, HTTP messages are sent in the form of addressed
data pack- ets. Each packet has a layer-4 address, consisting of the
source and destination IP address and TCP port numbers; this is the
address to which layer 4–aware devices pay attention. Each packet also
has a layer-2 address, the Media Access Control (MAC) address, to which
layer-2 devices (commonly switches and hubs) pay attention.The job of
layer-2 devices is to receive packets with particular incoming MAC
addresses and forward them to particular outgoing MAC addresses.

Related

network sniffer - detect subnet mask in non-DHCP network

I'm writting a simple network sniffer that should be able to reconstruct network structure.
When an interface has set up a DHCP, I can easily read interface settings such as client IP address, subnet mask, DNS server etc. by catching a DHCP packet and analysing it.
When an interface has a static IP, I'm catching ARP Announcement packet to get static IP address and then ARP request from the gateway, to get geteway IP address. I'm also saving MAC addresses.
My problem is: how to get subnet mask from one or more static IPs in the network and the gateway address. Or by caching some packets. I didn't see packets that could have such informations.
I also need DNS address, but it's less important.
The program should work in OpenWRT (C++).
My problem is: how to get subnet mask from one or more static IPs in the network and the gateway address.
Possibly, you can't.
If the sniffed network uses DHCP then you can monitor the DHCP requests (which should be broadcast) for their subnet mask and router fields which mirror the server's offer.
Without DHCP, all you can do is take an educated guess. If your passive sniffer registers broadcasts from addresses 192.168.1.1 through 192.168.1.29, you know that the prefix length is at most /27. It could also be anything shorter, down to /16, with potential addresses being (currently) absent or silent. The prefix could be even short than /16 if the network admin is ignoring RFC 1918. With public addresses you're mostly on your own.
If you can scan actively you could send ARP requests and see which ones get answered - you'd also see nodes that don't originate any traffic/broadcasts.
The gateway is also just a guess. In a network with mostly Internet-bound traffic, the default gateway is most likely the one being ARPed most often. If the network traffic is mostly server-centric, ARP requests for their addresses outnumber the ones for any gateway.
Your sniffer is severely limited when it is just attached to a switch and listening to broadcast packets only. If the sniffer manages to listen to all traffic on the network (via a monitoring/mirroring switch port) then you can easily identify the gateway by its MAC address that packets for arbitrary IP addresses is sent to and vice versa.
As above, if you can actively send probe packets you could test the gateway(s) with packets that they accept (and hopefully forward) and which ones they reject.

Visibility of IP addresses in layer 2?

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.

NAT on TCP connections

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.

Why we are using mac address in data link layer instead of ip address though ip address itself is unique within a network?

Though ip address is unique,what is the need of mac address.I am confused.
Thanks in advance.
Because mac address is physical, known only within the network and thus frames need to be converted into packets which also contain routing info in their headers to connect with different networks like internet.Thus network layer comes in responsible for logical addressing to make the packets transferable across networks.The whole purpose is utilize the tcp/ip protocol and create less overheads on the physical network.
MAC addresses are used by some, not all, layer-2 protocols, and of those that do use MAC addresses, some use 48-bit MAC addresses, and some use 64-bit MAC addresses.
I assume you are referring to ethernet, which uses 48-bit MAC addresses. Ethernet, as a set of layer-1/2 protocols knows nothing about layer-3 protocols (IPv4, IPX, IPv6, AppleTalk, etc.). Ethernet is more than happy to carry any layer-3 protocol, and layer-3 protocols are unaware of which layer-2 protocol (ethernet, token ring FDDI, PPP, Wi-Fi frame relay, HDLC, etc.) carries it, and that can change along the entire path.
You need to understand the differences between the network layers. Locally, your layer-3 packets are encapsulated and carried in layer-2 frames. The layer-2 protocols are responsible for delivering their payloads (layer-3 packets) on the LAN. Layer-3 protocols are responsible for delivering their payloads (layer-4, e.g. TCP segments) between LANs. Layer-4 protocols are responsible for delivering their payloads (application protocols/data) between applications.

hop to hop communication

If we are in the same network, then hop to hop communication takes place by layer-2 devices such as switches, bridges, etc. that work at the MAC layer.
But if we have to send packets to a destination in some other network then hop to hop communication takes place through routers.
Is this correct?
Your statements are conceptually correct, though the details are not quite right.
A layer 3 protocol like IP can route a packet from its source to its destination across the entire Internet, but a layer 2 protocol like ethernet can only route packets for a single hop. When a device transmits a packet on a TCP/IP network, it must know the ethernet (layer 2) address of the next hop and the IP (layer 3) address of the packet's final destination.
Let's look at the two cases you describe, using a scenario where a user on Device A knows the IP address of Device B and wants to send it a packet.
Devices on the same (unswitched) subnet
The user on Device A issues the command ping 10.1.1.23.
Device A broadcasts an ARP (layer 2) request, asking which device on its network can route a packet to IP address 10.1.1.23.
Device B recognizes the IP address as its own and answers the request by returning a packet with its IP and ethernet addresses as the source, and Device A's IP and ethernet addresses as the destination.
Now Device A has everything it needs to communicate with Device B. Every packet it transmits to Device B will have the proper ethernet and IP addresses as the destination.
Devices on the same (switched) subnet
The user on Device A issues the command ping 10.1.1.23.
Device A broadcasts an ARP (layer 2) request, asking which device on its network can route a packet to IP address 10.1.1.23.
A switch receives the packet on one of its ports and retransmits the same packet on whichever port is connected to Device B. This is the only significant difference between switched and unswitched subnets.
Device B recognizes the IP address as its own and answers the request by returning a packet with its IP and ethernet addresses as the source, and Device A's IP and ethernet addresses as the destination.
Now Device A has everything it needs to communicate with Device B. Every packet it transmits to Device B will have the proper ethernet and IP addresses as the destination.
Devices on different subnets
The user on Device A issues the command ping 8.8.8.8.
Device A broadcasts an ARP (layer 2) request, asking which device on its network can route a packet to IP address 8.8.8.8.
The address 8.8.8.8 is on a different network, so no local device recognizes the address as its own. However, a router sees the packet, checks its routing tables, and sees that it knows how to forward packets to the 8.8.8.x network. So the router replies by returning a packet that has its own ethernet address as the source.
Now Device A can communicate with Device B by sending packets that have a destination IP address of 8.8.8.8, but the router's ethernet address as their destination.
The router receives the packets because they are destined for its ethernet (layer 2) address, but it notices that their destination IP (layer 3) addresses are different from its own, and so it forwards them to whatever address is stored in its routing table.
Yes, you are correct. To access other networks (networks on a different subnet) a client will route the traffic to its default gateway, which will encapsulate the traffic and route appropriately. For communicating on the same network only a layer 2 switch is required.

Resources