Practical issues at the network and link layers
===============================================

Outline
- VLANs
- NAT traversal


=========================================================

* We have seen that switched LANs have to broadcast packets over the
  entire domain ocassionally, leading to scalability issues. One
  solution: virtual LANs. When a switch is configured with VLANs,
  broadcast packets are exchanged only between hosts of a particular
  VLAN, and not across the entire domain. VLANs can be configured as
  port-based (certain ports of a switch are designated to certain
  VLANs), or MAC address-based (certain MAC addresses are mapped to
  certain VLANs).

* Suppose switches S1 and S2 have two VLANs 101 and 102 on their ports
  1--4 and 5--8 respectively. Now, suppose S1 gets a broadcast frame
  on VLAN 101, and must send it to switch S2 in order to connect the
  VLAN 101 hosts on both switches. How is this accomplished? That is,
  when S2 receives a frame from S1, how does it know which ports to
  send it on? One naive way is to connect VLAN 101 ports on both
  switches, VLAN 102 ports on both switches etc. However, this
  requires N ports used up on each switch to connect N VLANs. Instead,
  the switches can be connected using only one port on each switch,
  and this link can carry traffic of all VLANs. In this case, we need
  to tag frames with the VLAN ID, so that the other switch knows what
  to do with this frame. This is called VLAN trunking. With VLAN
  trunking, two switches are only connected using one port at each
  switch, and traffic on this link is tagged with VLAN ID between the
  switches using a special frame header.

* Another network layer issue of practical concern - NAT traversal. We
  have seen so far that hosts behind NATs can initiate TCP connections
  to public hosts, but are not reachable from outside. Usually, a NAT
  also has a firewall that stops incoming packets to any internal host
  that it believes do not belong to any existing flow. Suppose two
  hosts A and B are both behind such NATs (+ firewalls), and they want
  to communicate with each other, say, as part of a P2P
  application. Without any external mechanism, such communication
  cannot happen.

* First let us consider NAT traversal for UDP traffic. One method
  followed is to have special servers called STUN (Session Traversal
  Utilities for NATs) servers. Hosts A and B communicate with the STUN
  server initially. This way, the server will know the external IP
  address and port of the hosts. It will then send this information to
  A and B. Now A and B will try to send a packet to the external
  addresses of each other. Suppose A sends a packet first. Now when
  B's packet reaches A, the firewall believes this is reply to A's
  packet and allows this packet through. (Even if A hasn't already
  sent the packet, B can retry periodically, and succeed within a few
  attempts.) This technique is also called NAT hole punching. Such
  elaborate techniques are used by P2P software like Skype to help
  hosts behind NATs to connect with each other.

* Basic premise of the above STUN-based method: the NAT uses the same
  external IP address and port for a given internal IP address and
  port of host A, irrespective of whether it is communicating with the
  STUN server or host B. That is, the NAT only rewrites the source IP
  but not the source port. Only then can the address conveyed by the
  STUN server be used by the other host B to send a packet to host
  A. That is, we require that the external IP and port assigned the
  NAT be the same for a given source IP and port, irrespective of what
  the destination IP and port is. However, some type of NATs called
  symmetric NATs pick a random port number for different connections
  to different destinations from the same internal source IP and
  port. NAT traversal is very hard with such NATs. In such cases,
  users must program the NAT (if allowed by the network administrator)
  to allow traffic on certain ports or allow certain traffic to pass
  through using special protocols that communicate with NATs. For
  example, with the UPnP (universal plug n play) protocol, hosts can
  request a specific public IP and port for their connections and
  convey it to the other end points, so that connections can be
  initiated. However, not all NATs and networks support such
  functionality.

* What about NAT traversal for TCP flows? TCP is a much harder problem
  even with non-symmetric NATs. With TCP, host A generates a SYN
  packet to B, but the reply (SYN ACK) cannot be generated by the
  application layer at B (it is in the control of the OS). So, if both
  end points start a TCP flow, both sides will send SYN and not get
  SYN ACK as a reply because the SYN will be dropped by the other
  NAT. So NAT traversal is a much harder problem. Several techniques
  have been proposed. 

* Further reading

- "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Guha and Francis.