Overview
If a Mobile Node (MN) supports Mobile IP Network Address Translation (MIP NAT) traversal, it can indicate to the Home Agent (HA) that it is able to use MIP UDP tunneling when the HA sees that the Registration Request (RRQ) has traversed a NAT device.
The HA determines that the RRQ has passed through a NAT device by comparing the care-of-address in the RRQ with the source IP address of the RRQ. If they are different, and the D bit is set in the RRQ, then it indicates that the RRQ has passed through a NAT device.
If NAT is not detected but the Force (F) bit is set in the RRQ along with a UDP Tunnel Request, the HA rejects the call with the code 129 in the Registration Response (RRP). You can configure a parameter to force the HA to accept these types of requests for UDP tunneling in the absence of NAT.
When the D bit is not set and a mismatch occurs between the source address and the care-of-address, this could be a case when a mobile is registering through an FA using different addresses for signaling and data traffic. This registration behavior is allowed by the HA service.
The MN and HA negotiate UDP tunneling support during Mobile IP call setup. The MN includes a UDP Tunnel Request Extension in the RRQ sent to the HA. This extension optionally specifies the encapsulation type to be used as well (IP, GRE, or Minimal IP). The system only supports IP encapsulation at this time. Note also that the D bit must be set when UDP Tunneling is requested.
If the HA supports the requested form of tunneling, and the registration is successful, it responds with a UDP Tunnel Reply Extension in the RRP and specifies the keepalive interval the MN should use.
If HA does not accept the requested type of UDP tunneling, it ignores the UDP Tunnel Request extension and does not include the UDP Tunnel Reply extension in the Registration Reply. Error code 142 is used in the RRP to indicate to the MN that the requested UDP tunnel encapsulation is unavailable.
The UDP Tunnel Request extension is included in all initial, renewal, and handoff RRQ and RRP messages. The UDP Tunnel Request extension is not included in a Deregistration RRQ from the MN and the HA ignores them if they are included in Dereg RRQs received.
When MIP NAT Traversal is used, normally reverse tunneling is also used. However, this is not required by the HA.
Case | RRQ received at the HA | Action at HA |
---|---|---|
1 |
NAT detected, UDP Tunnel Request sent, NAT Traversal enabled |
Accept call with IP-UDP tunneling, UDP Tunnel Reply included in RRP |
2 |
NAT detected, UDP Tunnel Request sent, NAT Traversal disabled at the HA |
Reject with code 129 |
3 |
NAT not detected, UDP Tunnel Request sent, F bit not set |
Accept call with IP-IP tunneling, UDP Tunnel Reply not included |
4 |
NAT not detected, UDP Tunnel Request sent, F bit set, forced UDP tunnel NOT allowed |
Reject with code 129 |
5 |
NAT not detected, UDP Tunnel Request sent, F bit set, forced UDP tunnel allowed |
Accept call with IP-UDP tunneling, UDP Tunnel Reply included in RRP |
6 |
UDP Tunnel Request sent, D bit not set |
Reject with code 134 |
7 |
NAT detected, UDP Tunnel Request not sent |
Reject with code 129 |