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]