Network Working Group
Request for Comments: 4000
Category: Informational
Obsoletes RFCs:
H. Law
Y. Ng
HK Polyu.
March 2016
IP Mobility Support of Network Address Translator
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
Overview
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
1. Introduction
With the widespread use of laptop computers and palm PCs in
recent years, the importance of PC mobility has become larger
and larger. The mature broadband networking services provided
by ISPs, as well as the decline of PC hardware prices, has also
made more and more home users involved in connecting to the
Internet. Consequently, people start to concern with the
connectivity of their PCs with the global network “at any time,
in any place”, and this has lead to the development of mobile
IP protocol.
On the other hand, the IP address space has been shrinking at a
very fast rate due to the huge demand of Internet connectivity.
This shortage of IP addresses not only limits the current
growth of the Internet community, but also prohibits the future
expansion and development of new networking techniques.
Although IPv6 is currently under researched and tested to
address this problem, short-term solutions, such as NAT, are
nevertheless required to satisfy the huge demands in the near
future. Specifically, Network Address Translator (NAT)
provides an efficient mechanism for mapping private and public
address spaces.
With NAT, hosts within the netork may
communicate with the outside world through private-public
address bindings provided by the NAT server. Since the
Law & Ng
Informational
1
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
bindings are transparent to internal/external hosts, this
requires minimal changes to the original IP/routing protocols,
and the result is an efficient reuse of public IP addresses
through dynamic mapping of a wide set of private network
addresses to a small set of globally unique public network
addresses.
Incorporating the NAT solution into the Mobile IP protocol,
then, becomes an obvious and effective solution for resolving
the mobility problem, as well as its huge IP addresses
consumption. Nevertheless, mobile IP with NAT also poses many
new challenging problems that still have to be resolved. For
instance, mobile IP protocol does not provide a standard method
for resolving NAT’s private/public address translation problem;
the mobile IP protocol must also provide additional mechanisms
to discover the existence of NAT servers; worst of all,
different NAT implementations may be available, and the mobile
IP protocol alone is not able to take care of all possible
implementations.
The purpose of this report, as a result, is to propose a new
mechanism/ standard protocol for solving the “mobile IP with
NAT” problems. Before working out the solution, the following
assumptions are made:
(1) The new protocol should not modify the original Mobile IP
protocol as much as possible (i.e. changes on Mobile IP should
be minimal);
(2) The new protocol may modify the NAT implementation to
accommodate any new changes (i.e. NAT should accommodate any
new changes/features as mush as possible);
(3) The new protocol should be simple enough, and should not
contain redundant features besides resolving those NAT and
mobile IP problems;
(4) The original mobile IP protocol should work as usual, even
without the existence of NAT servers;
Section 2 provides NAT constraints on mobile IP. Section 3
contains our proposed solution for the mobile IP with NAT
implementation. Section 4 describes various terminologies for
use by the following descriptions. The detailed mechanism, as
well as any new implementations added to the original protocol,
will be described and pointed out step-by-step where necessary
in Section 5. With any new messages proposed in our new
protocol, their message formats are given in Section 6 and 7.
Details of individual fields are given to clarify our new
implementation. Finally, additional considerations are
discussed in Section 9.
Law & Ng
Informational
2
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
2. NAT constraints on IP Mobility
NAT translates between private IP address and public IP address
(and possibly the TCP port numbers) when messages traverse
it. This causes problem on messages that require
authentication and within which IP address information is
embedded. Apart from that, the IP address collision may occur
when mobile nodes with private address going into a foreign
network which also uses the same private address space.
Furthermore, having private addresses in mobile agents results
in messages being unable to be routed to them.
2.1 Private IP address problems
There are two problems from private IP addresses on Mobile IP:
- Home Agent advertises its private address but Mobile Node
needs its public address.
- Private address of Mobile Node may crash with other host
using the same private in foreign network.
2.2 Mobile IP Registration Request problem
If care-of-address in registration request is private, Home
Agent cannot tunnel message to Foreign Agent or Mobile Node.
2.3 Home Agent - Mobile Node Authentication problem
Registration requests and replies must be authenticated by Home
Agent and Mobile Node. However, NAT will translate the UDP
header which is authenticated by the Home Agent and the
Mobile Node. Moreover, key exchange is required for the
keyed MAC (MD5 prefix + suffix mode) [6, 8]. Translating the
IP header will prevent the key exchange procedures, which use
IP address as security association identifier.
3. Current Proposed Solution
Many of the current NAT solutions, such as VPN IP tunneling
[9, 10], RSIP [5], and SKIP [7] use IP tunneling. Messages are
encapsulated with an outer IP address header the original IP
addresses remain unchanged when the messages are passed through
the NAT. The tunnel solution only solves the authentication
problem but it cannot solve the private address problem.
3.1 Solution Overview
Law & Ng
Informational
3
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
The idea of the solution is to allow mobile agents and mobile
nodes to obtain public IP address before they perform Mobile IP
operations. It solves both authentication problem, routing
problem and the private IP address collision problem that NAT
imposes on Mobile IP.
3.2 Goals
The proposed NAT solution for Mobile IP tries to address to the
following problems:
- It resolves the crash of IP address between Mobile Node and
host or routers in foreign network.
- How to put public care-of-address into Mobile IP registration
request message without the need of NAT in foreign network to
translate the private care-of-address.
- How Mobile Node obtains public IP address of the Home Agent
and possibly that of Mobile Node itself.
3.3 Protocol Requirements
The protocols aim at solving the NAT problems imposed on Mobile
protocols while maintaining the following requirements:
- The solution does not affect current operation of the Mobile
IP. That is, when the solution is removed, the Mobile IP
works as usual in the Home and Foreign networks without NAT.
- The impacts on the existing architecture of Mobile IP are
kept minimal. No existing Mobile IP protocol is changed.
The workload is on the NAT side, not the Mobile IP side. The
Mobile IP entities are kept as transparent as possible.
- The binding of private IP address to public IP address in NAT
is dynamic and each binding may expire upon timeout.
- The solution works not only with both Home network and
Foreign network having NAT installed. It also works if only
one side of the Home network and Foreign network has NAT
installed.
4. Terminology
NAT-Aware Mobile Node (NMN)
A mobile node, which is aware of the possibility of the
presence of an NAT in its network.
NAT-Aware Home Agent (NHA)
Law & Ng
Informational
4
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
A Home Agent, which is aware of the possible presence of an NAT
in its network.
NAT-Aware Foreign Agent (NFA)
A Foreign Agent, which is aware of the possible presence of an
NAT in its network.
Home Network NAT (HNAT)
The NAT installed at home network, which can serve the new
protocols.
Foreign Network NAT (FNAT)
The NAT installed at foreign network, which can serve the new
protocols.
5. Protocol Overviews
5.1 The following additional support protocols are required in the
solution:
5.1.1 NAT Discovery
NAT may advertise their availability on the network. From the
NAT the mobile agents and mobile nodes may obtain their public
IP addresses. On the other hand, any NAT-aware mobile agents
or mobile nodes may send solicitation to the network to learn
if any NAT is present.
5.1.2 NAT Registration
Mobile agents and mobile nodes may request for a public IP
address by sending registration to NAT with private IP address.
he NAT replies with an allocated public IP address
corresponding to the registered private address.
5.2 The following steps outline the work flow explaining how the
additional protocols help Mobile IP messages traverse NAT
unchanged:
----(1)
-----|
| -----> |
|
|NHA|
|HNAT|
|
| <----- |
|
----- (2)
/ -----(2)/ /|
|/ /
----- / (1)
|
|
Law & Ng
-----|
|
|FNAT|
|
|
------
(1)
----->
<----(2)
----|
|
|NFA|
|
|
-----
(1) NAT Advertisement
(2) NAT Solicitation
Informational
5
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
|NMN|
|
|
----||
||
\||/
\/
----(3)
----------(3)
--------|
| <----- |
|
|
| <----- |
|
(5)
|
|
|NHA|
|HNAT|
|FNAT|
|NFA| -----> |NMN|
|
| -----> |
|
|
| -----> |
|
|
|
----(4)
----------(4)
--------\
^
(5) \
|
\|
(3) NAT Registration Request by Mobile Agent
|
----- (4) NAT Registration Reply to Mobile Agent
|
|
| (5) Mobile Agent Advertisement
|
|NMN|
|
|
| --------------------------------------------------------Migrate to foreign network
||
||
\||/
\/
----|
|
|NHA|
|
|
-----
--------------(6)
----|
| <---------|----|----------|---|----------|
|
|HNAT|
|FNAT|
|NFA|
|NMN|
|
| ----------|----|----------|---|--------->|
|
-----(7)
-------------(6) NAT Registration Request by Mobile Agent
(7) NAT Registration Reply to Mobile Agent
||
||
\||/
\/
------------------(8)
----|
| <--------|----|-----------|----|----------|---|----------|
|
Law & Ng
Informational
6
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
|NHA|
|HNAT|
|FNAT|
`
|NFA|
|NMN|
|
| ---------|----|-----------|----|----------|---|--------->|
|
----(9)
------------------(8) Home Agent Registration Request
(9) Home Agent Registration Reply
||
||
\||/
\/
----|
|
|NHA|
|
|
-----
-----|
|
| CN |
|
| (10) Message sent to Mobile Node
_------ (11) Message tunneled to Foreign Agent
| ^ (12) Message sent from Mobile Node
(10)| |
| |
-----| |
---------(12)
----<--------|----|---- -----|----|---------|---|--------- |
|
|HNAT|
|FNAT|
|NFA|
|NMN|
---------|----|-----------|----|-------> |
| -------> |
|
(11)
-------------------
(1) NAT Advertisement
HNAT and FNAT, if exist periodically advertise their
existence to the local network by sending NAT Advertisement
message using net-directed broadcast. Each NAT-aware node
(NMN, NHA, NFA) keeps the public IP address of the NAT. If
there is no such advertisement on the network, mobile agents
may communicate using normal Mobile IP protocols
(2) NAT Solicitation
Each NAT-aware node may detect the existence of an NAT by
sending NAT solicitation message. If no reply is returned
upon timeout, normal Mobile IP operations may be carried out.
(3) NAT Registration Request by Mobile Agents
After receiving NAT Advertisement message, Home Agent, Foreign
Agent and the Mobile Node keep the IP address of the NAT in
the message. Home Agent and Foreign Agent will send NAT
Law & Ng
Informational
7
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
registration request to HNAT and FNAT respectively to acquire
a public IP address. The NAT registration request contains
the private IP address and a lifetime value.
-------------|Mobile Agent|
--------------
private address
-----------------> ----|NAT|
-----
Figure 5.1 Home agent or foreign send registration
request to their NAT on their own network.
(4) NAT Registration Reply to Mobile Agents
When the HNAT or FNAT receives an NAT registration request,
it allocates a public IP address for the requesting agent and
keeps a binding between the private IP address and the
corresponding public IP address. The NAT then sends an NAT
registration reply containing the private IP address, the
corresponding public IP address and a lifetime value. The
requesting node needs to re-register to the NAT again before
the public IP address expires. This will keep the address
binding dynamic and allow feasibility for NAT to allocate its
public IP address resource.
private address
-------------- -----------------> ----|Mobile Agent| public address
|NAT|
-------------- <----------------- -----
binding:
private address <->
public address
Figure 5.2 NAT replies with public address and keeps a binding
(5) Mobile Agent Advertisement
Upon receiving the NAT registration reply, the Foreign Agent
(NFA) advertises it public IP address through normal mobile
agent advertisement. However the Home Agent (NHA) still
advertises its private IP address to the Mobile Node. Since
the public IP address of the Home Agent may expire, it is not
feasible for Mobile Node to keep this IP address when it is
away from home. Instead, the Mobile Node may use the Home
Agent's private IP address to ask HNAT for the public IP
address of the Home Agent.
(6) NAT Registration Request by Mobile Agent
A Mobile Node does not need to perform NAT registration request
when it is at home. It only keeps the private IP address of
the Home Agent from its Mobile Agent advertisement and the
public IP address of the HNAT from the NAT advertisement. When
Law & Ng
Informational
8
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
the Mobile Node is away from home, it receives the public careof-address from the Foreign Agent. Before it registers with
its Home Agent, the Mobile Node sends NAT registration request
to the HNAT through the Foreign Agent. The registration
request contains the private IP address of the Mobile Node and
that of the Home Agent.
private addresses of
mobile node and
home agent
------ <------------------- ----- <--- ----|HNAT|
|NFA|
|NMN|
-------------Figure 5.3 Mobile Node's reqistration request
(7) NAT Registration Reply to Mobile Node
Upon receiving a registration request from the Mobile Node, the
HNAT searches the corresponding public IP address of the Home
Agent, and allocates a dynamic public IP address to the Mobile
Node. The HNAT then sends NAT registration reply to the
Mobile Node. The registration reply contains the public IP
address of the Mobile Node, that of the Home Agent and a
lifetime value.
private addresses of
mobile node and
home agent
------ <------------------- ----- <--- ----|HNAT|
|NFA|
|NMN|
------ -------------------> --------public addresses of
mobile node and
home agent
Figure 5.4 HNAT replies with mobile node and home agent's
public IP addresses
(8) Mobile IP Registration Request
After receiving the NAT registration reply, the Mobile Node
sends the Mobile IP registration request to the Home Agent
through its public IP address. The registration request
contains, Foreign Agent's public IP address, Home Agent's
public IP address and the Mobile Node's private IP address.
Note that the private IP address of Mobile Node is needed, as
all external messages sending to the Mobile Node will have
destination address translated to its private IP address by the
NAT.
(9) Mobile IP Registration Reply
Law & Ng
Informational
9
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
As usual, after the Home Agent receives the Mobile IP
registration request. It sends a Mobile IP registration reply
to the Mobile Node through the Foreign Agent.
After all the registration requests and replies are done, the
Mobile IP operations are performed as normal.
(10) Messages sending to the Mobile Node
When a corresponding node sends a message to the Mobile Node,
it is intercepted by Home Agent. However, the destination IP
address is translated to the Mobile Node's private address.
-------------------|Corresponding Node|
-------------------Dest
|
= NMN
V
NFA's public
NFA's private
------------ IP address
------ IP address --------|Home Agent| ------------->|FNAT|----------->|NFA|--->|NMN|
------------------------Figure 5.5 Message forwarded to mobile node through NAT
(11) Home Agent tunnels message to Foreign Agents
When the message is tunneled by Home Agent to the Foreign
Agent, the IP address of the Foreign Agent is translated by the
FNAT. The Foreign Agent receives the tunneled message, detunnels it and forwards the message to the Mobile Node.
(12) Message sent from the Mobile Node
When the Mobile Node wants to send
corresponding node in the external
IP address and through the Foreign
translation is made in the message
messages to the
network, it uses its public
Agent. No address
routing.
-------------------|Corresponding Node|
-------------------^
| D = CN's public address
D = CN's public address
| S = NMN's public address
S = NMN's public address
|
----------------------------------_|FNAT|<-----------|NFA|<---|NMN|
-------------Figure 5.6 Message sent from mobile node.
No change in IP addresses
Law & Ng
Informational
10
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
(13) Mobile Node returns home
A Mobile Node may detect that it actually returns to home
network by the following:
- It receives the Home Agent advertisement again.
- It also receives the HNAT advertisement, if it exists.
If the Mobile Node decides that it is at home, it de-registers
with its Home Agent and HNAT by sending Mobile IP registration
request and NAT registration request respectively by setting
the registration lifetime to zero.
6. NAT Discovery Protocol
In fact, the new NAT Discovery Protocol is very similar to the
mobile IP Discovery Protocol; message format is kept to be the
same, and many important features are re-used, except that
unneeded fields are eliminated to simplify the design. As a
result, implementation would become easy because the new
protocol is just built on top of the original Mobile IP
protocol; no new features are introduced, and only extra logic
needs to be added from existing Mobile IP mechanisms for
handling the existence of NAT server.
6.1 NAT Advertisement
Similar to the mobile IP’s Advertisement message, NAT
advertisement also relies on the Router Discovery ICMP message
to perform data-link broadcast (i.e. through the extension
field). Specifically, the proposed format for the NAT
advertisement message is shown in Figure 5.1 below:
0
31
-----------------------------------------------------------------------|
TYPE
| LENGTH |
Sequence Number
|
-----------------------------------------------------------------------|
Registration Lifetime | | B | | | | | | |
|
-----------------------------------------------------------------------|
NAT Private Address
|
-----------------------------------------------------------------------|
NAT Public Address
|
------------------------------------------------------------------------
Law & Ng
Informational
11
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
From our proposal, the TYPE field is given as 23 for NAT
Advertisement, in order to distinguish it from other mobile IP
Discovery messages. The LENGTH field, as usual, indicates the
total length of the extension. The SEQUENCE NUMBER field
provides the same functionality as the one in the mobile IP
Advertisement message, and is used to represent the count of
NAT advertisement messages sent since the NAT server was
initialized.
However, most of the flag bits in the Mobile Agent
Advertisement Message are not reused in the case of NAT
Advertisement. The only bit that is for use by the NAT and
mobile agents is the B bit, which indicates that the NAT server
is currently busy, and cannot process any new NAT registration.
The NAT server’s public address, along with its private IP
address used within the network, is provided to the mobile
agents for references. This information is necessary because
mobile agents need the private address for registration, and
the public address for authentication.
6.2 NAT Solicitation
In addition to NAT Advertisement, the proposed solution also
supports solicitations from the mobile agents, and its format
is also similar to the router solicitation ICMP message used by
mobile IP.
-----------------------------------------------------------------------|
TYPE
| CODE
|
Checksum
|
-----------------------------------------------------------------------|
Reserved
|
------------------------------------------------------------------------
As in normal cases, the TYPE field is set to 9 to indicate
router solicitation; however, a new CODE number of 1 is given
for the NAT solicitation in this case.
7. NAT Registration Protocol
The NAT Registration Protocol resembles similar message formats
as the mobile IP registration protocol. In particular, the
registration mechanism between mobile agents/hosts and the NAT
server is also divided into two main parts: the registration
request and registration reply.
Law & Ng
Informational
12
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
7.1 Registration Request
The NAT Registration Request Message Format is shown in Figure
below:
0
31
-----------------------------------------------------------------------| TYPE
|S|A|N| |
Lifetime
|
-----------------------------------------------------------------------|
Home Private Address
|
-----------------------------------------------------------------------|
Home Agent Private Address (optional)
|
-----------------------------------------------------------------------|
|
|
Identification
|
|
|
------------------------------------------------------------------------
Here, the TYPE field is set to 7 for registration request, in
order to distinguish it from mobile IP’s registration number
(1). The S bit is kept to indicate simultaneous binding
request. However, two new flag bits are introduced: the A bit
for representing registration request sent from the mobile
agents (0 for home agent; 1 for foreign agent), and the N bit
for representing registration request from mobile nodes (0 for
mobile agents; 1 for mobile nodes). The HOME PRIVATE ADDRESS
field is the private IP address set in the mobile nodes/agents.
The HOME AGENT PRIVATE ADDRESS field, in contrast, is only
required when the request is from mobile node (not used when
request is from mobile agent). The IDENTIFICATION field, as in
the case of mobile IP registration, is a 64-bit number used for
matching registration requests and replies, as well as for
protecting against replay attacks of registration messages.
7.2 Registration Reply
The format of the Registration Reply message is given in Figure
below:
Law & Ng
Informational
13
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
-----------------------------------------------------------------------| TYPE
| CODE
|
Lifetime
|
-----------------------------------------------------------------------|
Replied Private Home Address
|
-----------------------------------------------------------------------|
Replied Public Home Address
|
-----------------------------------------------------------------------|
Replied Private Home Agent (optional)
|
-----------------------------------------------------------------------|
Replied Public Home Agent (optional)
|
-----------------------------------------------------------------------|
|
|
Identification
|
|
|
------------------------------------------------------------------------
Here, the TYPE field is set to 15 for NAT Registration Reply,
in order to distinguish it from mobile IP’s Registration Reply
message. The CODE number, which is used to indicate various
RETURN code numbers, is also similar to the values for the
mobile IP:
Registration Successful:
0
Registration accepted
1
Registration accepted, but simultaneous mobility bindings unsupported
Registration denied by the NAT Server
64
Reason unspecified
65
Administratively prohibited
66
Insufficient resources
67
Mobile node failed authentication
68
69
Requested Lifetime too long
70
Poorly formed request
71
Poorly formed reply
72
73
80
81
NAT Server unreachable (ICMP error received)
82
NAT Server port unreachable (ICMP error received)
88
NAT unreachable (other ICMP error received)
The LIFETIME field is used to represent the duration (in
seconds, as in the case of mobile IP) for which the binding is
valid. The PUBLIC HOME ADDRESS field, which is returned from
the NAT server for the given PRIVATE HOME ADDRESS binding, is
then kept by the mobile node/agent whenever a public identity
is required for normal IP traffic outside the private network.
Specifically, the PRIVATE ADDRESS field is duplicated from the
Law & Ng
Informational
14
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
Registration Request message to indicate a particular address
binding for the given private address. As in the case of NAT
Registration request, the PRIVATE and PUBLIC HOME AGENT
addresses are optional, and are not required for returning
message to mobile nodes. And as usual, the IDENTIFICATION
field is used for matching the registration request with an
registration reply, and for detecting future replay attacks of
the registration message.
8. Additional Issues
8.1 Mobile IP with other NAT Configurations
8.2 Private IP Address Resolution
8.3 Authentication between Mobile Node and Home Agent
In normal Mobile IP, the Mobile Node and the Home Agent must
support security association (SA) identified by the security
parameter index (SPI) and the IP address. The Mobile Node must
use its home address as IP address. In case of having NAT at
home network, Home Agent and Mobile Node may choose its private
address or its public address as the SA identifier. However,
it is suggested that the Home Agent should use its private
address while the Mobile Node should use its public address.
There are two reasons for this.
- Firstly, when the message from Mobile Node arrives, the
destination address is changed to Home Agent's private
address by HNAT, while the Mobile Node's public address is
not changed.
- Secondly, the Home Agent may not know the private address of
the Mobile Node but the Mobile Node knows both the Home
Agent's public address and private address.
8.4 Messages sent to Mobile Node using co-located care-of-address
In case that the Mobile Node uses co-located care-of-address,
it must be a public address. If the Mobile Node obtains the
co-located care-of-address from other means such as DHCP, the
address may be private and the Mobile Node will need to
register with FNAT to obtain a corresponding public address.
It is similar to those done by the Foreign Agent. In this
case, the Mobile Node may hold the public care-of-address for
Home Agent to tunnel message to itself and the private colocated care-of-address for messages routed within foreign
network.
8.5 Scalability
In Mobile IP, there may be more than one Home Agent and Foreign
Agent in the same network. The proposed solution for Mobile IP
Law & Ng
Informational
15
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
to traverse NAT can be scaled up to as many mobile agents as
possible. It is only limited by the resource available in the
NAT. The dynamic IP address binding properties indeed helps
save the public address resource. When the Mobile Node returns
home, it de-registers to the HNAT. The public IP address
originally assigned to the Mobile Node can be freed for our
use. The Mobile Node is a normal host in its home network.
9. Acknowledgements
Ideas in this document have benefited from comments from many
experts. However, the authors are solely responsible for any dumb
ideas in this work.
10. References
1
RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
2 S. Shieh, F. Ho, Y. Huang, and J. Luo, "Network Address
Translator: Effects on Security Protocols and Applications in the
TCP/IP Stack", IEEE Internet Computing, pp. 42-49, Nov/Dec 2000.
3 RFC 1631, E. Egevang and P. Francis. "The IP Network Address
Translator(NAT)", May 1994
4. RFC 2663, P. Srisuresh. and M. Holdrege, "IP Network Address
Translator(NAT) Terminology and Considerations", Aug.1999.
5 D. Grabelsky and G. Montenegro, "Realm specific IP: Protocol
Specification", Internet-Draft draft-ietf-nat-rsip-protocol-07.txt,
July 2000.
6 C. Perkins, "IP Mobility Support for IPv4 revised", InternetDraft draft-ietf-mobileip-rfc2002-bis-03.txt, Sept. 2000
7 RFC 2356, G. Montengro and V. Gupta, "Sun's SKIP Firewall
Traversal for Mobile IP", June 1998.
8 C. Perkins, "Mobile IP, Design Principles and Practises",
Addison-Wesley Wireless Communications Series, 1997
9
RFC 1853, W. Simpson. "IP in IP Tunneling", October 1995.
10 RFC 2547 E. Rosen, Y. Rekhter, "BGP/MPLS VPN", March 1999
Law & Ng
Informational
16
RFC 4000
IP Mobility Support of
Network Address Translator
March 2016
Author's Addresses
Eddie Law
Dept. of Computing,
HK PolyU, Hung Hom,
Kowloon, Hong Kong
Phone:
Email:
852-27667295
99602558g@polyu.edu.hk
Andrew Ng
Dept. of Computing,
HK PolyU, Hung Hom,
Kowloon, Hong Kong
Phone:
Email:
852-27667295
00425524g@polyu.edu.hk
Law & Ng
Informational
17