Page 40 / 141
DTUS065 rev A.7 – June 27, 2014
V.6.2.1
Masquerading (ARPNAT)
In this solution to the bridging problem, the client bridge keeps a table to
convert devices MAC addresses to and from their IP addresses.
In frames sent to the AP, the bridge replaces the devices source MAC
address with its own and remembers the MAC/IP correspondence of the
frame.
When a frame comes back from the AP its destination MAC address is the
one of the bridge. The bridge finds the IP address in the frame, finds out the
corresponding device MAC address, pokes it in the destination MAC of the
frame, and sends it to the wired LAN side.
This solution is compatible with any third-party AP since all processing is
done on the client side. However there are special behaviors to keep in mind:
1)
The conversion table handles MAC/IP conversions only. This means that
only the TCP/IP protocols suite
(TCP, UDP, IP, ICMP, ARP, DHCP
and so on) can be bridged.
2)
The conversion table is updated only by frames from the LAN to the Wi-
Fi. This is usually not a problem because prior to any data transfer, an
ARP request/reply exchange must take place. But if the client bridge is
powered down, when it comes up again, the ARP exchange is not
necessarily restarted by the devices on the backbone side. Then, when
the bridge receives a data frame from the AP, its conversion table is
empty and the frame is not forwarded. In this case, the bridge itself
initiates an ARP for the destination IP address mentioned in the frame,
triggering from the LAN device a response that will update the table, so
that the next frame can be forwarded.
3)
Equipment on
the backbone cannot use an IP gateway (a router or a
NAT) located on the client LAN side
. The reason is that the destination
IP address in the frames received from the AP are not the one of the
gateway, but the address of an equipment farther beyond the gateway;
but the MAC address needed is that of the gateway. So the address
conversion is not possible.
4)
DHCP is a protocol used to set up IP addresses. The wired device MAC
address is conveyed not only in the DHCP frame header, but also in the
data payload. The address conversion causes an address mismatch at the
DHCP server. To satisfy the DHCP server requirements, the bridge
advertises itself as a DHCP relay agent, resolving the mismatch. For this
to work,
a DHCP server located on the AP side must be able to send
unicast IP packets to the bridge
. This means that the bridge must have
an IP address reachable from the DHCP server prior to serving IP
addresses to the devices behind the bridge.
5)
ARP is a protocol used to discover MAC addresses. The ARP frames
contain MAC addresses both in their headers and in their data. Special
processing is done in the bridge to convert these frames.
CISCO and others can set up a “proxy ARP server” in their APs. This
means that the AP itself converts IP to MAC addresses on behalf of the
backbone equipment. The proxy ARP server can get confused because