Internet DRAFT - draft-lai-mip4-proxy-nat-traversal
draft-lai-mip4-proxy-nat-traversal
MIP4 Working Group S. Lai
Internet-Draft H. Deng
Expires: December 18, 2006 Hitachi (China)
June 16, 2006
Proxy Mobile IPv4 Traversal of Network Address Translation (NAT) Devices
draft-lai-mip4-proxy-nat-traversal-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a solution to address NAT traversal problem
for proxy Mobile IPv4. By only utilizing network entities, an MIP
UDP Tunnel to achieve NAT Traversal is built up for an Mobile IP
Client which exchanges messages and data with HA on mobile node's
behalf.
Lai & Deng Expires December 18, 2006 [Page 1]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Architecture Model . . . . . . . . . . . . . . . . . . . . 4
3.2. UDP Tunnel Setup . . . . . . . . . . . . . . . . . . . . . 5
3.3. HoA Assignment . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. DHCP Consideration . . . . . . . . . . . . . . . . . . 6
3.3.2. IPCP Consideration . . . . . . . . . . . . . . . . . . 8
3.4. New Message Formats . . . . . . . . . . . . . . . . . . . 9
3.4.1. UDP Tunnel Request Extension . . . . . . . . . . . . . 9
3.4.2. Pre UDP Tunnel Request . . . . . . . . . . . . . . . . 10
3.4.3. Pre UDP Tunnel Reply . . . . . . . . . . . . . . . . . 11
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Mobile Node Operations & Consideration . . . . . . . . . . . . 13
6. Proxy AR Operations & Consideration . . . . . . . . . . . . . 13
7. HA Operations & Consideration . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Lai & Deng Expires December 18, 2006 [Page 2]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
1. Introduction
Proxy Mobile IPv4 is a helpful solution which to provide mobility for
mobile node with no MIP4 function. The main idea of proxy Mobile IP
is that an access router, defined as Proxy AR in this document,
initiates the MIP4 registration procedure on behalf of mobile node.
However, the procedure of NAT Traversal for Proxy Mobile IPv4 is
different from that for base Mobile IPv4 in RFC3519[RFC3519]. The
difference is as follows,
1) Mobile node must first make L2 authentication/authorization before
MIP4 registration in Proxy MIP4. Since there is no MIP4 stack on
host stack of mboile node for Proxy MIP4, the unmodified mobile node
cannot make network layer authentication/authorization with HA or
Proxy AR directly. So we should make L2 layer authentication when
mobile node establishes L2 connection with Proxy AR. And AAA message
must cross NAT to reach AAA server which is outside NAT device.
2) An UDP Tunnel is needed for DHCP transmitting before MN getting
its HoA. In Proxy MIP4, to get the home address(HoA), DHCP message
from MN should be tunneled to HA which acts as DHCP Relay Agent. But
IP-in-IP tunnel cannot cross NAT since it lacks information for IP
adress translation by NAT device. It is necessary to build up an UDP
Tunnel for DHCP message exchanging before MN has HoA and MIP4
registration prcocedure starts.
One of the scenario of proxy AR behind NAT is enterprise deployment.
By placing the Proxy AR behind NAT, it is not necessary to modify NAT
device(a Gateway in most case) in order to provide mobility for
mobile node. Besides, mobile node attaching to such proxy AR can
communicate to other nodes behind NAT directly in case that proxy AR
sending PROXY ARP[RFC1027].
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
The following new terminology and abbreviations are introduced in
this document and all other general mobility related terms as defined
in Mobile IPv4 specification [RFC3543].
Mobile Node (MN)
Lai & Deng Expires December 18, 2006 [Page 3]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
Any IPv4 node that has the ability to physically access or roam
across different networks. The Mobile Node does not necessarily
have the Mobile IPv4 protocol stack.
Proxy Access Router (Proxy AR)
An access router with Mobile IPv4 client which performing MIP4
registration function on the mobile node's behalf.
UDP Tunnel
A Tunnel between two hosts. In one IP session, both hosts send
and receive encapsulated data through unchanged UDP port. UDP
Tunnel can be IP-in-UDP, GRE-in-UDP or Minimal encapsulation in
UDP.
3. Overview
3.1. Architecture Model
The typical model for NAT traversal in proxy Mobile IPv4 is
illustrated in Figure 1, showing a proxy AR behind NAT device.
Generally, the NAT device is the gateway for proxy AR. Proxy AR
should make a registration on HA which is outside NAT device,on
behalf of MN. MN attaches to Proxy AR through different link layer
technology, such as WLAN, CDMA2000 etc,. And once MN attaches to
access point or base station linked with Proxy AR, MN must make a L2
authentication/authorization with AAA server.
| +-----+
| | AAA |
+-----+ +-------+ +-----+ +--+--+ +----+
| MN |-----| Proxy |-------| NAT |----------|-------| HA |
+-----+ | AR | +-----+ +-----+ | |
+------ + | |DHCP | +----+
| +-----+
Figure 1: Typical model for NAT traversal in Proxy MIP4
When MN accesses the network via PPP [RFC1332], LCP CHAP is used to
authenticate the MN. After authentication, the Proxy AR (acting as
NAS here)sends proxy Registration Request message to the Home Agent
which responds with the Home Address in the Registration Reply to MN.
If MN get its HoA through DHCP [RFC2131]procedure, Proxy AR can
tunnel all DHCP message to HA in Figure 1. In this case, HA has the
Lai & Deng Expires December 18, 2006 [Page 4]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
role of DHCP Relay Agent. However, DHCP message in IP-in-IP Tunnel
cannot cross NAT directly. Our solution want to address the problem
by utilizing a UDP Tunnel [RFC3519] between Proxy AR and HA. Proxy
AR can send the DHCP message from MN to HA through the UDP Tunnel.
Then HA relays the DHCP message to corresponding DHCP server.
Proxy AR need to send an MIP4 RRQ message with MIP4 UDP Request
Extension to HA indicating that it want to build a UDP Tunnel for NAT
traversal. And HA should send a Registration Reply message with MIP
UDP Reply Extension to indicate whether the request is accepted or
denied.
3.2. UDP Tunnel Setup
One major difference between base MIP4 and Proxy MIP4 is that there
is no MIP4 stack on host stack of MN for Proxy MIP4. So unmodified
MN cannot make network layer authentication/authorization with HA or
FA/Proxy directly. In Proxy MIP4, it's necessary to make L2
authentication after MN establishing L2 connection with the network.
In authentication process, AAA server may download some information
about the MN, including user's profile, home agent address, NAI MN-HA
SA etc,.
MN can connect to the mobile wireless network via any link technology
e.g. CDMA, GPRS, WLAN etc. After MN's L2 connection establishment
and authentication, Proxy AR would send Proxy MIP4 RRQ message with
UDP Tunnel Request to HA. And HA responds back with Proxy MIP4 RRQ
message with UDP Tunnel Reply. After the registration successful,
there is an UDP Tunnel build up between Proxy AR and HA. for data
sending from MN through the UDP Tunnel, the source port may vary
between new registrations, but remains the same for all tunneled data
and re-registrations, and the destination port is always 434 . UDP
tunneled packets sent by the home agent uses the same ports, but in
reverse turn.
Lai & Deng Expires December 18, 2006 [Page 5]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
+----+ +-------+ +----+ +-----+ +----+
| MN | | Proxy | |NAT | | AAA | | HA |
| | | AR | | | | | | |
+----+ +------ + +----+ +-----+ +----+
| | | | |
| 1. L2 Access | 2. AAA message | |
|<------------->|<--------///--------->| |
| | | | |
| | 4. Proxy MIP4 RRQ| |
| | with UDP Tunnel Request |
| |---------///------------------------>|
| | | | |
| | 5. Proxy MIP4 RRP| |
| | with UDP Tunnel Reply |
| |<--------///-------------------------|
| | | | |
| Data Packet | UDP Tunneled pkg |
|<------------->|<========///========================>|
| | UDP keeplive |
| |---------///------------------------>|
| | | | |
Figure 2: Signal Flow for UDP Tunnel Building up
The Proxy MIP4 RRQ is an base Mobile IPv4 Registration Request
message [RFC3344]. The HoA field is the IP address of MN(ALL-ZERO-
ONES-ADDRESS in case of MN with no IP address), and CoA field is the
private IP address of Proxy AR. As to Authentication Extension,
Proxy AR should have MN-HA secruity association information which is
gotten in the L2 authentication procedure.
The Proxy MIP4 RRP is an base Mobile IPv4 Registration Reply message
[RFC3344]. The HoA field is the IP address of MN.
UDP Tunnel Request and UDP Tunnel Reply is compliant with the
extensions in [RFC3519]. These extensions is to solicit HA to send
MIP UDP packets to Proxy AR.
3.3. HoA Assignment
3.3.1. DHCP Consideration
If MN get its HoA by DHCP procedure, there is one problem as mention
in section 1. MN CANNOT exchange its DHCP message with HA when there
is no UDP Tunnel before MIP4 registration. It is necessary to build
such an UDP Tunnel to transmit DHCP message before MIP4 Registration.
Lai & Deng Expires December 18, 2006 [Page 6]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
+----+ +-------+ +----+ +-----+ +----+ +----+
| MN | | Proxy | |NAT | | AAA | | HA | |DHCP|
| | | AR | | | | | | | | |
+----+ +------ + +----+ +-----+ +----+ +----+
| | | | | |
|1. L2 Access| 2. AAA message | | |
|<---------->|<--------///--------->| | |
|3. DHCP | | | | |
| DISCOVERY | | | | |
|----------->| 4. Pre UDP Tunnel Request | |
| |---------///------------------->| |
| | | | | |
| | 5. Pre UDP Tunnel Reply | |
| |<--------///------------------->| |
| | | | |7. Relayed
| | 6. DHCP message in UDP Tunnel |DHCPDISCOVERY
| |=========///===================>|------->|
| | | | | |
|10.DHCPOFFER| 9. DHCP message in UDP Tunnel | 8.DHCPOFFER
|<-----------|<========///====================|<-------|
| | | | | |
Figure 3: HoA assignment through DHCP
The procedure of HoA assignment before MIP4 Registration is
illustrated in Figure 3. Triggered by DHCPDISCOVERY message, Proxy
AR send a Pre UDP Tunnel Request to HA to solicit building an UDP
Tunnel for DHCP message exchanging. HA responds Pre UDP Tunnel Reply
to Proxy AR indicating whether the UDP Tunnel is built up or failed.
If the UDP Tunnel is built up, Proxy AR can send all DHCP messages
from MN to HA through the UDP Tunnel. Then HA, which acts as DHCP
Relay Agent, send relayed DHCPDISCOVERY to corresponding DHCP server
in the domain of HA.
Then one of DHCP server assigns an IP address as the HoA for MN, and
sends DHCPOFFER containing the address to HA. HA send back the
DHCPOFFER message to Proxy AR through previous built up UDP Tunnel.
And Proxy AR forward the DHCPOFFER message to MN. MN thus gets its
HoA.
After MN getting its HoA address, Proxy AR makes registration with HA
on MN's behalf. The procedure is same as the registration procedure
in RFC3344[RFC3344].
The Pre UDP Tunnel Request is an base MIP4 RRQ with UDP Tunnel
Request extension. In the part of MIP4 RRQ, the field of CoA is set
Lai & Deng Expires December 18, 2006 [Page 7]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
to the private address of Proxy AR . The source port for Pre UDP
Tunnel Request is variable and destination prot is 434.
The Pre UDP Tunnel Reply is an base MIP4 RRP with UDP Tunnel Reply
extension. In the part of MIP4 RRP, the field of CoA is set to the
public address of Proxy AR after NAT traversal. The source port for
Pre UDP Tunnel Reply is 434 and destination port is the port number
of Pre UDP Tunnel Request after NAT Traversal.
The detailed formats for Pre UDP Tunnel Request and Pre UDP Tunnel
Reply are described in section 3.4.
3.3.2. IPCP Consideration
+----+ +-------+ +----+ +-----+ +----+
| MN | | Proxy | |NAT | | AAA | | HA |
| | | AR | | | | | | |
+----+ +------ + +----+ +-----+ +----+
| | | | |
| 1. L2 Access | 2. AAA message | |
|<------------->|<--------///--------->| |
| 3. IPCP Config| | | |
| Request | | | |
|-------------->| 4. MIP4 RRQ |
| | with UDP Tunnel Request |
| |---------///------------------------>|
| | | | |
| | 5. MIP4 RRP |
| | with UDP Tunnel Reply |
| |<--------///-------------------------|
| 6. IPCP | | | |
| Config-NAK | | | |
|<--------------| | | |
| | | | |
Figure 4: Network connection setup using IPCP
When MN attaches to Proxy AR by PPP, its HoA is assigned by IPCP
procedure. The HoA assignment procedure using IPCP when Proxy AR
being behind NAT is depicted in figure 4.
In authentication process(step1 and step2),AAA server may download
some information about the MN, including user's profile, home agent
address, NAI. After the link layer association process is finished,
MN sends IPCP config request for HoA assignment(step3). And then
Proxy AR make registration on HA on behalf of MN.
Lai & Deng Expires December 18, 2006 [Page 8]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
Proxy AR sends MIP4 RRQ with UDP Tunnel Request on behalf of MN to
HA(step4). The HoA field of Proxy MIP4 RRQ is set to ALL-ZERO-ONES-
ADDRESS. HA responses the message with MIP4 RRP with UDP Tunnel
Reply, in which HoA for MN is contained.
After Proxy AR receiving Proxy MIP4 RRP from HA, it responds back to
MN with an IPCP config-NAK to suggest the assigned HoA.
When registration finished, an UDP Tunnel is built up between Proxy
AR and HA. All traffic from or to MN SHOULD be transmitted through
the UDP Tunnel.
3.4. New Message Formats
3.4.1. UDP Tunnel Request Extension
This extension is a skippable extension. It signifies that the
sender is capable of handling MIP UDP tunneling, and optionally that
a particular encapsulation format is requested in the MIP UDP tunnel.
The format of this extension is as shown below. It adheres to the
short extension format described in [RFC3344].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|D| Reserved | Encapsulation | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (TBD)
Length
6. Length in bytes of this extension, not including the Type and
Length bytes.
Sub-Type
0
Reserved
Reserved for future use. MUST be set to 0 on sending, MUST be
ignored on reception.
F
F (Force) flag. Indicates that the Proxy AR wants to force MIP
UDP tunneling to be established.
Lai & Deng Expires December 18, 2006 [Page 9]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
D
D (UDP Tunnel for DHCP message) flag. This flag is used to
indicate that Proxy AR wants to build an MIP UDP Tunnel for DHCP
message, other than for common data traffic.
Encapsulation
Indicates the type of tunnelled data, using the same numbering as
the IP Header Protocol Field.
3.4.2. Pre UDP Tunnel Request
The Pre UDP Tunnel Request is used to solicit an UDP Tunnel built up
before MIP4 Registration. The message is defined as follows:
IP Fields:
Source Address Proxy AR's address.
Destination Address HA's address.
UDP Fields:
Source Port variable.
Destination Port 434
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Type (TBD)
Reserved
Reserved for future use. MUST be set to 0 on sending, MUST be
ignored on reception.
Home Agent Address
Lai & Deng Expires December 18, 2006 [Page 10]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
IP address of Home Agent.
Care-of Address
The private IP address of Proxy AR behind NAT.
Identification
A 64-bit number, constructed by the Mobile Node, used for matching
Pre UDP Tunnel Reply, and for protecting against replay attacks of
the messages. See Sections 5.4 and 5.7 of [RFC3344].
Extensions
The fixed portion of the Pre UDP Tunnel Request Message is
followed by one or more extensions which may be used with this
message, and by one or more authentication extensions (as defined
in Section 3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of
[RFC3344] for information on the relative order in which different
extensions, when present, must be placed in a Pre UDP Tunnel
Request Message.
3.4.3. Pre UDP Tunnel Reply
The Pre UDP Tunnel Reply is used by Home Agent to respond an Pre UDP
Tunnel Request message. The Pre UDP Tunnel Reply message is defined
as follows:
IP Fields:
Source Address HA's address.
Destination Address Proxy AR's address.
UDP Fields:
Source Port variable.
Destination Port 434
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Lai & Deng Expires December 18, 2006 [Page 11]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
Type (TBD)
Reserved
Reserved for future use. MUST be set to 0 on sending, MUST be
ignored on reception.
Status
If the Pre UDP Tunnel Request Message was received without error,
this field is set to zero. However, if there is an error in
reception, the field is nonzero with the following allowable codes
defined in section 3.4 of[RFC3344].
Home Agent Address
IP address of Home Agent.
Identification
A 64-bit number, constructed by the Mobile Node, used for matching
Pre UDP Tunnel Request, and for protecting against replay attacks
of the messages. See Sections 5.4 and 5.7 of [RFC3344].
Extensions
The fixed portion of the Pre UDP Tunnel Reply Message is followed
by one or more extensions which may be used with this message, and
by one or more authentication extensions (as defined in Section
3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344]
for information on the relative order in which different
extensions, when present, must be placed in a Pre UDP Tunnel Reply
Message.
4. Benefits
The benefits for Proxy MIPv4 NAT traversal is as follows,
1). MN-Proxy AR interface is safer and is subjected to less threats.
The interface between MN and Proxy AR faces a number of threats,
such malicious node acting as a proxy AR, or acting as mobile
node. But if Proxy AR is behind NAT, the interface is less likely
to be attacked by such threats.
2). Support mobility for MN in case of NAT Traversal
Even though Proxy AR is located behind NAT, a mobile node with HoA
can communicate with a correspond node outside NAT. At the same
time, MN can communicate directly with fix-node in NAT and share
resource in the NAT, e.g. file sharing, printer sharing. Through
PROXY-ARP sending by proxy AR, MN can find other fix-node/mobile
Lai & Deng Expires December 18, 2006 [Page 12]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
node behind the NAT and know their MAC address and IP address.
3). Less amount of signals.
For MIP4 NAT traversal, a mobile node needs to send keepalives
[RFC3519]at short intervals to properly maintain the NAT states.
This can be performed by the Proxy AR in the network which doesn't
consume any air-link bandwidth. And Proxy AR can aggregate
multiple MNs on the same tunnel. Thus the amount of keepalives
needed to maintain the NAT states can be reduced largely.
5. Mobile Node Operations & Consideration
A mobile node can be a normal IPv4 host without Mobile IPv4 Client
function. The required behavior of the node will be consistent with
the base IPv4 specification, such as IPv4 address maintenance, DHCP
protocol, PPP stack, ARP function. MN also need to have a MN-HA
mobility Security Association, NAI, home agent address for
authentication and HoA assignment.
6. Proxy AR Operations & Consideration
Proxy AR is the assess point to network for MN. It should have the
functions as follows,
1) Acting as a NAS for authentication. When MN performs L2
establishment Proxy AR, it will make access authentication/
authorization with the NAS in Proxy AR. The NAS in Proxy AR also
exchanges AAA messages with the AAA server to perform authentication
and authorization of the MN.
2) Proxy Registration. Proxy AR should have function of Mobile IPv4
Client in order to send registration to HA on MN's behalf.
3) Supporting UDP Tunnel.
When sending MIP4 RRQ to the HA, Proxy AR will set the care-of
address for MN as its own IP address which is private IP address.
Then HA will have a local binding for MN using the public address of
Proxy AR after MIP4 RRQ crossing NAT.
The proxy AR also needs to know such information as, MN's NAI, MN-HA
Security Association, Home Agent IP Address, for sending a
registration. Such information can be downloaded from AAA server
after the authentication process.
Lai & Deng Expires December 18, 2006 [Page 13]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
7. HA Operations & Consideration
The Home Agent has the functionalities described in RFC 3344[RFC3344]
and RFC 3519 [RFC3519].
8. Security Considerations
The functionality in this document is protected by the Authentication
Extensions described in RFC 3344[RFC3344]. Access Authentication and
Authorization MUST be performed prior to Proxy Mobile IP
registration. The Identity (NAI) that is used during the Access
Authentication and Authorization is used to as the NAI in MIP4
Registration Request. In order to protect the Registration message,
each proxy AR needs to have the MN-HA SA.
9. IANA Considerations
The following values must be assigned by IANA:
UDP Tunnel Request Extension:
Type TBD-1.
Pre UDP Tunnel Request:
Type TBD-2.
Pre UDP Tunnel Reply:
Type TBD-3.
10. References
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
implement transparent subnet gateways", RFC 1027,
October 1987.
[RFC1331] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", RFC 1331, May 1992.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
Lai & Deng Expires December 18, 2006 [Page 14]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
May 2003.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
Lai & Deng Expires December 18, 2006 [Page 15]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
Authors' Addresses
Shouwen Lai
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: swlai@hitachi.cn
Hui Deng
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Lai & Deng Expires December 18, 2006 [Page 16]
Internet-Draft Proxy MIP4 NAT Traversal June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lai & Deng Expires December 18, 2006 [Page 17]
