Impact of Network Address Translation


Network Address Translation (NAT) is another technology commonly deployed at the edge of private autonomous systems that can conflict with the delivery of encapsulated traffic. Network Address Translation, which comes in two basic flavorsNAT and Network Address and Port Translation (NAPT)is designed to allow networks with private addressing schemes to exchange traffic with public networks. NAT works by translating the address used by the node in the private autonomous system to an address that is valid in the global network. NAT typically relies on statistical multiplexing to allow a large pool of private addresses to share a smaller pool of public addresses. NAPT goes one step further and allows many nodes to use a single public address by translating the IP address and the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port.

In Mobile IP, usually IP-in-IP tunneling or generic routing encapsulation (GRE) tunneling sends data traffic between the Home Agent and Mobile Nodes, either directly or through a FA. When the CoA tunnel endpoint is behind an NAT gateway, the IP-in-IP tunneling cannot pass through the NAT gateway. Specifically, the IP layer encapsulations do not carry transport layer (TCP/UDP port numbers) to permit unique translation of the private CoA into the public address. For NAPT gateways, the problem is worse because IP-in-IP and GRE tunneling do not use ports to identify sessions and, thus, the tunnel cannot traverse an NAPT gateway.

Note that NAT and NAPT traversal is not an issue with Mobile IP RRQs and RRPs because they are UDP datagrams that originate from behind the NAT. Hence, when these Mobile IP messages pass through the NAT or NAPT gateway on their way to the Home Agent, they are translated into a public address and UDP port mapping that the RRP can pass back through.

NAT Traversal UDP Tunneling

To solve the problems that occur when the tunnel needs to terminate behind NAT and NAPT gateways, the Internet Engineering Task Force (IETF) Mobile IP working group standardized RFC 3519, which defines a UDP tunneling protocol to be used for both the forward and reverse Mobile IP tunnels. The new protocol defines extensions to the registration and agent advertisement portions of the Mobile IP protocol. A key feature of this NATMobile IP solution is that data packets are now also sent to the UDP ports that set up the Mobile IP registration, that is, UDP port 434 on the Home Agent and the UDP source port used for the RRQ on the Mobile Nodes. To this end, a new format for encapsulating data packets is also defined. A basic assumption in the solution is that the NAT gateway allows UDP datagrams from the Mobile Nodes destined to UDP port 434 on the Home Agent to pass through.

The fundamental design of the NATMobile IP solution follows the standard Mobile IP implementation with the following specifics:

  • The FA advertises support for UDP tunneling. This is accomplished by setting a newly defined U bit in the Mobile IP agent advertisement. (The U bit in agent advertisements is backward compatible; if a Mobile Nodes does not understand the U bit, it simply ignores the bit.)

  • A UDP tunnel is requested in the RRQ. To accomplish this, either the FA or the Mobile Nodes appends the UDP Tunnel Request Extension, defined in RFC 3519, to the RRQ. (Although the Mobile Nodes or FA might not know whether the RRQ will traverse an NAT or NAPT gateway, by appending the extension, they are conveying support for UDP tunneling if in fact it is needed.)

  • The Home Agent sends a RRP, either accepting the registration with UDP tunneling or denying the registration if it cannot establish a UDP tunnel. To accomplish this, the Home Agent appends the UDP Tunnel Reply Extension, as defined in RFC 3519, to the RRP.

So, how does the Home Agent know whether the Mobile Nodes's RRQ did, in fact, pass through an NAT or NAPT gateway? It doesn't know for sure, but rather it infers as sucha bit of detective work! The Home Agent evaluates the RRQ and compares the source IP address of the packet to the CoA inside the request. If the two addresses differ, the Home Agent deduces that an NAT gateway exists in the middle and enables the use of UDP tunneling. The UDP Tunnel Request Extension has an F bit to allow the Mobile Nodes to forcefully request UDP tunneling for cases in which the NAT detection algorithm does not work. For example, this can be used to traverse firewalls and other filter devices that allow only TCP and UDP traffic, but do not necessarily perform address translation.

After the UDP tunnel is established between the CoA and Home Agent, all the data traffic is encapsulated within a new format as defined in RFC 3519. Basically, a new Mobile IP Tunnel Data Message header is defined. This header differentiates data traffic that is sent in the tunnel to port 434 on the Home Agent from other Mobile IP messages, for example, RRQs and RRPs.

Although the Mobile IP tunnel has been established for the lifetime granted in the RRQ, the actual life of the tunnel depends on the NAT state information being current on the tunnel. To this end, keepalive messages are sent to ensure that the UDP tunnel through the NAT gateway retains the NAT translation state information if traffic has not been sent down the tunnel in a specified amount of time. Essentially, the keepalive serves as a message saying, "Although traffic hasn't been sent down this tunnel in a while, it is still valid. Please keep it up." The keepalive message is a properly UDP-encapsulated ICMP echo request sent by the Mobile Nodes or FA and directed to the Home Agent. The frequency of the keepalive messages is configurable.

NAT on the Home Agent

In the metro mobility model in which the Mobile Nodes roams outside its autonomous system, the Home Agent must have a global IP address. Usually, the Mobile Nodes is configured with its Home Agent address, and if that address is from a private address space, when the Mobile Nodes leaves its home autonomous system, it cannot reach the private Home Agent address. (A good analogy is using your boss's internal extension when calling him from within the company. As soon as you go outside your company, that extension has no meaning and your boss's full "global" phone number must be known and dialed.)

In these metro mobility models, the Home Agent can reside on the edge of the private network and act as an NAT gateway for its Mobile Nodess. By straddling the public and private networks, the Home Agent address can be global, and the Mobile Nodess can use private addresses. For the most part, configuration of NAT on the Home Agent is similar to standard NAT configuration in IOS. The main difference is the additional configuration needed to address the fact that the egress interface is dynamic.

Remember that the Home Agent uses standard IOS tunnel interfaces and adds a route to the Mobile Nodes through the tunnel interface. Thus, every time the Mobile Nodes changes its CoA, the egress interface changes on the Home Agent. However, the standard IOS NAT protocol requires that inside and outside interface pairs be defined for address translation to take place.

Mobile IP NAT Configuration

Configuration for the Mobile IP NAT feature is needed on both the Home Agent and FA in Cisco IOS.

Configuration on the Home Agent

The first configuration task is to enable the NAT traversal feature on the Home Agent, as follows:

 (i) ip mobile home-agent nat traversal  [keepalive time] [forced {accept | reject}] 

This command enables Network Address Translation-User Datagram Protocol (NAT-UDP) encapsulation support on the Home Agent. The keepalive option allows the Home Agent to configure the frequency of keepalive messages. The forced accept option configures the Home Agent to allow forced UDP tunneling. Conversely, the forced reject option configures the Home Agent to reject forced UDP tunneling. Forced UDP tunneling occurs when the Mobile Nodes requests UDP tunneling, even when the Home Agent does not detect an NAT in the path. Forced tunneling can be useful for firewall traversal as well.

The next step is to configure NAT traversal on the tunnel interface as follows:

 (ii) ip mobile tunnel nat {inside | outside} 

The inside option sets the dynamic tunnel as the inside interface for NAT. Conversely, the outside option sets the dynamic tunnel as the outside interface for NAT.

Configuration on the FA

The FA must be configured to support the NAT traversal feature as follows:

 ip mobile foreign-agent nat traversal  [keepalive  time]  [force] 

This command enables NAT-UDP encapsulation on the FA. The keepalive option allows the FA to use this keepalive time for the messages when the Home Agent does not provide a specific value. The force option allows the FA to force the Home Agent to allocate an NAT UDP tunnel without performing detection presence of NAT along the Foreign Agent-Home Agent (FA-HA) path.



    Mobile IP Technology and Applications
    Mobile IP Technology and Applications
    ISBN: 158705132X
    EAN: 2147483647
    Year: 2005
    Pages: 124

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net