Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


Network Address and Port Translation (NAPT)

[Top]


Purpose

NAPT provides Network Address and Port Translation for local equipment connected to the phone/handset allowing them to use the phone as a gateway to share the device's global Internet connection.

E.g. if a laptop is connected to the phone using a local IP address, it can connect to the Internet using the phone's IP address. To any other device on the internet the request comes from the phone's IP address and responses are sent back to the phone which translates the address in the received packet header to the laptop's local IP address and port and forwards the packet on to the laptop.

[Top]


Architectural relationships

The Sockets architecture provides a generic client interface, and a server to which particular protocol modules can be plugged in. In particular the client socket interface is provided by RSocket.

NAPT is defined as an IPHOOK module at boot/load time and loaded on demand. NAPT is an optional component.

[Top]


Description

Local external devices (such as a laptop computer) can connect to this device via IP. The addresses of these locally attached devices may be assigned by DHCP or other method. NAPT does not rely on DHCP being used for the address provisioning.

Network Address and Port Translation works by maintaining a table of request addresses from devices connected locally to the handset and mapping those addresses to dynamically assigned port numbers using the device's NAPT which exists as a plug-in using the existing IP Hook plug-in interface.

NAPT maps connections on a local sub-net range for the IP address and Port translation. Any datagram destined for the Internet has its private local IP address replaced by the global IP address of the handset; any inbound datagram undergoes the reverse process.

Note: if you wish to use NAPT with more than one locally connected device e.g. more than one laptop, then all local devices that want to use NAPT must be in the same local IP range (as defined by the sub-net mask), so with a subnet mask length of 8 and a local IP range of 10.0.0.0 any device with an IP address of 10.0.0.0 to 10.0.0.255 will use NAPT.


Configuration

NAPT is an optional feature and so needs to be included when the device ROM is built. At boot time it will need to be listed in an .esk file to be recognised. The tcpip.ini file needs to have the IP Forwarding option set on. NAPT will then be an available feature which can be loaded by an application by opening a socket on "napt". See How to configure NAPT.

NAPT is implemented as an IP Hook attaching to the existing IP Hook Plug-in Interface. The IP Hook plug-in interface provides a generic mechanism that allows handset developers to extend networking functionality by intercepting and optionally modifying IP packets passing through the TCP/IP stack.

NAPT IP Hook is identified at boot time using an .esk file. An esk file specifies the information regarding how the protocols should be loaded/bound. At hook start time, protocols are bound in a specified order using the definitions contained in the esk file. NAPT is placed between the IP layer and network interface with inbound preprocessing hook and outbound post processing hook which means it can read every packet being sent from the local to the global network and update the sending IP address/port number, and similarly for inbound packets it can read the destination IP address and port, and replace those with the local values from the translation table. Note that NAPT is only loaded on request and so even if the .esk file is scanned at boot time, NAPT will not be active until loaded.

NAPT places an entry in the table when a computer in the private network sends a packet to the global interface. When it receives a reply, NAPT hook finds the entry and translates the destination address and port number. Note that whenever NAPT changes a source or destination address and port number, NAPT will recompute the IP checksum along with TCP/UDP checksum.

NAPT will also look for certain ICMP messages and make changes to addresses contained within them. Many ICMP messages, such as Destination Unreachable and Parameter Problem contain as data the original IP header of the datagram that led to the ICMP message. Since NAPT is translating addresses in IP headers it must watch for these messages and translate addresses in included headers as required. However protocols like telnet, FTP, TFTP and SNMP include their addresses in the packet and/or port numbers within the data of the packet and would require further processing to translate which NAPT does not provide and so those protocols are not supported over NAPT.

The client socket interface allows sockets to be opened, connections made, data read and written, connections listened for and accepted, and address and other options set.

The client socket interface is provided by RSocket.


Connection

An active connection is needed for the TCP/IP protocol before communication can begin. This may be set up either implicitly, via the RSocket or RHostResolver APIs, or explicitly via the RConnection API.

[Top]


See also

ESock Overview

TCP/IP Overview

How to configure NAPT