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.
An example of successful
MIP UDP Tunneling negotiation is shown below.
Figure 1. MIP UDP Tunneling
negotiation between MN and HA
The following table
lists the various cases possible in UDP Tunneling negotiation during Mobile
IP call establishment.
Table 1. MIP UDP Tunneling
Negotiation Cases
| 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
|