Internet Engineering Task Force G. Bajko Internet Draft T. Savolainen Intended Status: Proposed Standard Nokia Expires: May 2, 2009 November 2, 2008 Port Restricted IP Address Assignment draft-bajko-v6ops-port-restricted-ipaddr-assign-02 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 May 2, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract With the foreseen scarcity of public IPv4 addresses and the hesitation and technical difficulties to deploy IPv6, the transition scenarios which assumed that migration to IPv6 happens before the run-out of IPv4 addresses, need to be revisited. This document defines a method to allocate the same IPv4 address to multiple hosts, thus prolonging the availability of public IPv4 addresses for as long as it takes for IPv6 to take over the demand for IPv4. The document also describes the deployment scenarios where this method is applicable. Bajko & Savolainen Expires May 2, 2009 [Page 1] Port restricted IP address assignment November 2008 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. Terminology and abbreviations used in this document Port restricted IPv4 address: an IP address which can only be used in conjunction with the specified ports. Port restriction refers to all transport addresses. ASN GW Access Service Network Gateway CGN Carrier Grade Network Address Translator CPE Consumer Premises Equipment, a device that resides between internet service provider's network and consumers' home network. GGSN Gateway GPRS Support Node GPRS General Packet Radio Service OPR Offered Port Restricted IP Address PDN GW Packet Data Network Gateway PDSN Packet Data Serving Node RPR Requested Port Restricted IP Address Table of Content 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Usage of port-restricted IPv4 addresses in various scenarios . .3 2.1 Point-to-point links with L2 IPv4 support . . . . . . . . . 4 2.2 Point-to-point tunneled links . . . . . . . . . . . . . . . 4 2.3 NAT in a host . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Distributed Network Address Translation function . . . . . .6 2.5 Relationship to other proposals . . . . . . . . . . . . . . 7 2.5.1 Dual-Stack Lite . . . . . . . . . . . . . . . . . . . 7 2.5.2 Address and Port Borrowing Protocol . . . . . . . . . 7 2.6 Efficiency issues in dynamic and static port allocation methods . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. DHCPv4 Option for allocating port restricted public IPv4 addr. .8 3.1 Option for offering port restricted IPv4 address . . . . . .8 3.2 Option for requesting port restricted IPv4 address . . . . .9 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . .9 4.1 Client Behaviour . . . . . . . . . . . . . . . . . . . . . .9 4.2 Server Behaviour . . . . . . . . . . . . . . . . . . . . . 10 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .11 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . .11 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . .12 8. Security considerations . . . . . . . . . . . . . . . . . . . .12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . . .12 11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . .14 Bajko & Savolainen Expires May 2, 2009 [Page 2] Port restricted IP address assignment November 2008 1. Introduction There are a number of possible solutions to deal with the problem of transitioning from IPv4 to IPv6; however none of them is a one fits all solution. Different solutions fit different deployment scenarios (see also [ARKK2008]). See [WING2008] for comparison. As a possible alternative solution for the IPv4-IPv6 coexistence period, this document describes a method, using newly defined DHCPv4 [RFC2131] options, that allows servers to assign port restricted IPv4 addresses to clients. By assigning the same IPv4 address to multiple clients, the availability of IPv4 addresses can be prolonged for as long as it takes for IPv6 to take over the demand for IPv4. The solution described in this document is intended to be used by large ISPs, who as of the date of writing this document, have a large enough IPv4 address pool to be able to allocate one public IPv4 address for each and every client. They expect though that the situation is unsustainable and they will soon not be able to provide every client with a public IPv4 address. Such ISPs have two possibilities to choose from: - deploy Network Address Translators (NAT), which can be a significant investment for ISPs not having NATs yet. The address space limitations of [RFC1918] may even force these large ISPs to deploy double NATs, which come with all the harmful behaviour of Carrier Grade NATs (CGN), as described in [MAEN2008]; or - allocate fragments of the same public IPv4 address directly to multiple clients (which can be CPEs or end hosts), thus avoid the cost of deploying multiple layers of, or carrier grade NATs. It is however assumed, that the demand for IPv4 addresses will decrease in the not so distant future, being taken over by IPv6, as the proposal in this draft is not by any means a permanent solution for the IPv4 address exhaustion problem. In fact, some presented deployment scenarios require existence of IPv6 access network. For ISPs not having NATs yet, a solution not requiring NATs would probably be preferred. For some other ISPs, who already have NATs in place, increasing the capacity of their NATs might be the preferred solution. 2. Usage of port-restricted IPv4 addresses in various scenarios This chapter depicts the scenarios where port restricted IPv4 addresses can be used, and what kind of assumptions have to be made. Relationships to various IPv4-IPv6 transition proposals being currently discussed in IETF are also considered. Bajko & Savolainen Expires May 2, 2009 [Page 3] Port restricted IP address assignment November 2008 2.1 Point-to-point links with L2 IPv4 support In point-to-point links it can be assumed that there are only two communicating parties on the link, and thus IP address collisions are easy to avoid. In wireless cellular networks host attaches to an access router, such as 3GPP PDN GW [3GP23401] or WiMAX ASN GW [WMFS21.2], over a point-to-point link providing layer 2 IPv4 transport capability. In order to be able to allocate a port-restricted IP addresses to a host, the access router needs to implement DHCPv4 server [3GP23401] or at least act as a DHCPv4 relay or DHCPv4 proxy [WMFS31.2], while a DHCPv4 server exists in the backend. These setups are illustrated in figure 1. +--------+ | 3GPP ---Point to Point link--| 3GPP |------| host <-IPv4 EPS bearer--> | PDN GW | | +--------+ | | IPv4 Internet +--------+ | WiMAX ---Point to Point link--| WiMAX |------| host <-----IPv4 CS------> | ASN GW | | +--------+ | Figure 1 Point-to-point physical links As each host is attaching to the access router with an individual link, both modified and unmodified hosts can be supported simultaneously. This enables incremental deployment of modified hosts that are supporting public IPv4 address conservation by using DHCP port restricted IPv4 address assignment, while continuing to support the legacy hosts using DHCP as currently specified. In this scenario IPv6 addresses can be used in parallel with any IPv4 address, therefore no tunneling is necessary. 2.2 Point-to-point tunneled links From DHCPv4 point of view tunneled link scenario does not differ very much from L2 point-to-point links as described in 2.1, although there are general concerns regarding tunnels (e.g. decreased MTU). It is expected by authors that the tunneling would be done over IPv6, but other mechanisms can also be thought of. Tunnel is established between a host (or a CPE) and a tunnel endpoint in the host operator's network. In different scenarios the tunnel endpoint may be placed at different locations. The tunnel endpoint can be at the first hop router such as 3GPP2 PDSN [3G2X0011] or 3GPP PDN-GW, or farther off in the network such as at Bajko & Savolainen Expires May 2, 2009 [Page 4] Port restricted IP address assignment November 2008 Dual-Stack Lite Carrier Grade NAT (see 2.5.1). These example setups are illustrated in figure 2. Having the tunnel endpoint at the first hop router can be beneficial in setups where arrangement of native dual-stack transport for the last mile is not feasible or cost-effective approach. This can be the case e.g. in current 3GPP networks where a PDP context [3GP23060] is capable of transporting only IPv4 or IPv6 packets, and for dual-stack access two parallel PDP contexts are required. Tunnel endpoints, implementing DHCPv4 server/relay/proxy +-------------+ Host ====IPv4 over IPv6==== | 3GPP2 | | <---PPP & IPv6CP ----> | PDSN |------| (point-to-point) +-------------+ | | +-------------+ | Host ====IPv4 over IPv6==== | 3GPP |------| IPv4 Internet <--IPv6 PDP context--> | GGSN | | (point-to-point) +-------------+ | | +-------------+ | Host ====IPv4 over IPv6==== | IETF |------| <---- IPv6-only -----> | DS-Lite CGN | | network +-------------+ Figure 2 Point-to-point links as IPv4 over IPv6 tunnels over three different accesses For networks which use IP(v6)CP to configure an IPv4 and IPv6 address to the host, allocating a port-restricted IPv4 address to the host to prevent running out of available IPv4 addresses, can also be a feasible solution. In these deployment scenarios IPv6CP would be used to configure an IPv6 address to the host. The host would then set up the tunnel and use the DHCPv4 extensions defined in this document to request a port-restricted IPv4 address. Examples of such networks include 3GPP2 and BRAS. 2.3 NAT in a host When a host which is capable of handling a port-restricted IP address, but some of the applications on the host may have trouble using those addresses (e.g. they require a specific port to operate), as an implementation choice, the host may hide the port restricted nature of the allocated address by implementing an internal NAT as illustrated in figure 3 below: Bajko & Savolainen Expires May 2, 2009 [Page 5] Port restricted IP address assignment November 2008 Host +---------------------+ + Applic + + | + + | IPv4p +-----+ + Port Restricted IPv4 address + |-------| NAT | +--------------------------------- + +-----+ + + + +---------------------+ Figure 3 Internal NAT in a host 2.4 Distributed Network Address Translation function One deployment model for port restricted IPv4 addresses is the distributed Network Address Translation, as shown in figure 4. This deployment scenario is preferred for the cases when: 1 the port-restricted IPv4 address is not supported by all hosts connected to the CPE 2 Applications may have trouble understanding port restricted public IPv4 addresses, but are familiar with RFC1918 addresses 3 Centralized NAT (Carrier Grade NAT) function may be expensive to deploy IPv6-only network +----+ +------+ |home| + AR+ + +-------------+ IPv4 host--------+CPE +=====tunnel======+DHCP +--+IPv4 Internet| +----+ +Server+ +-------------+ +------+ <---private v4---> <--- v4 over v6 --> <---public v4----> Figure 4 Distributed NAT scenario illustrated With distributed NAT model, the home CPE is assigned a port restricted public IPv4 address and it provides NATed addresses to the legacy devices attached to it. This setup allows avoidance of Carrier Grade NAT and enables customers' control on NAT with e.g. protocols such as UPnP and NAT-PMP, and also makes it easier to optimize sending of keep-alive messages. The distributed NAT model can be used in both physical and tunneled point-to-links. Alternatively, a CPE may choose to subdivide the port-restricted IPv4 address, in cases when all hosts connected to the CPE support port-restricted IPv4 address assignment. Bajko & Savolainen Expires May 2, 2009 [Page 6] Port restricted IP address assignment November 2008 2.5 Relationship to other proposals This chapter describes how the new DHCPv4 options for port restricted IPv4 address assignment can be seen to relate to some recent IETF proposals on this subject. 2.5.1 Dual-Stack Lite Dual-Stack Lite [DURA2008] describes a setup where a Dual-Stack Lite enabled device tunnels IPv4 over IPv6 to a Carrier Grade NAT. For the address mapping purposes, the CGN uses Dual-Stack Lite device's unique IPv6 address as an identifier in addition to any private IPv4 address device may be using. Dual-Stack Lite client side functionality can be implemented into a home router or a host. The DHCPv4 port-restricted addresses can be used in combination with Dual-Stack Lite environment, as defined in [DURA2008], by simply incorporating the port-restricted IPv4 address allocation mechanism into the CGN entity. The benefit of doing so is to both enable distribution of the NAT function and to allow updated devices and applications to make good use of public, but port-restricted, IPv4 addresses. The setup is illustrated in figure 5. Alternatively, the Carrier Grade NAT can just act as a tunnel endpoint and DHCP relay, while the DHCPv4 server is a separate entity. Collocating DHCPv4 server and tunnel endpoint is preferred approach to avoid introduction of control interfaces between DHCPv4 server and tunnel endpoint. +------------------+ +---------------+ |Dual-Stack Lite | +---+ +------+ |host |==IPv4 over IPv6===|NAT|----| | +------------------+ +---+ | | |+----+ |Multi | ||IPv4| |plexer|--- IPv4 ||pool| | | Internet |+----+ +------+ +------------------+ +------+ | | | Host with port |==IPv4 over IPv6===|DHCPv4|----+ | |restricted IP addr| +------+ | | (&internal NAT) | +---------------| +------------------+ Carrier Grade NAT Figure 5 Using port-restricted IPv4 addresses in Dual-Stack Lite environment 2.5.2 Address and Port Borrowing Protocol The architecture of address and port borrowing protocol (APBP) is described in [DESP2008]. The new DHCPv4 options can be used by APBP enabled CPE, or host, to request public IPv4 address with port range Bajko & Savolainen Expires May 2, 2009 [Page 7] Port restricted IP address assignment November 2008 from APBP server. The APBP server can also act as a IPv4-over-IPv6 tunnel endpoint. This is illustrated in figure 1 of [DESP2008]. Again the DHCPv4 client can be either CPE implementing the distributed NAT, or a host having internal NAT. 2.6 Efficiency issues in dynamic and static port allocation methods With the port-restricted IPv4 address allocation method, ports are allocated statically providing benefits as described, while carrier grade NAT based proposals, such as DS-Lite [DURA2008], have a dynamic port mapping, but require NATs. The obvious result is that DS-Lite is more efficient in sharing single public IPv4 address for multiple hosts, but with related downsides. Thus there is a trade- off that has to be taken into account when making deployment decisions. The seriousness of efficiency difference is decreased when more services become available in IPv6 and thus will cease to consume IPv4 address and port space. In this regard it is important to have very port consuming services directly IPv6-accessible. 3. DHCPv4 Options for allocating port restricted public IPv4 address This section defines new dhcpv4 options, which would allow allocation of port restricted IPv4 addresses. 3.1 Option for offering port restricted IPv4 address The option layout is depicted below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | length | IPv4 address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... IPv4 address | beginning port range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ending port range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv4-OPR (TBD) - 1 byte Length 1 byte, value=8 IP address Public IPv4 address Bajko & Savolainen Expires May 2, 2009 [Page 8] Port restricted IP address assignment November 2008 Beginning port range beginning source port number, which can be used in conjunction with the IP address Ending port range last source port number, which can be used in conjunction with the IP address 3.2 Option for requesting port restricted IPv4 address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | length | IPv4 address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... IPv4 address | beginning port range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ending port range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv4-RPR (TBD) - 1 byte Length 1 byte, value=8 IP address Public IPv4 address Beginning port range beginning source port number, which can be used in conjunction with the IP address Ending port range last source port number, which can be used in conjunction with the IP address 4. Option Usage 4.1 Client Behaviour A client which supports the extensions defined in this document, SHOULD insert the option OPTION-IPv4-RPR, by setting the IPv4 address field to 0.0.0.0, the beginning and ending port numbers to Bajko & Savolainen Expires May 2, 2009 [Page 9] Port restricted IP address assignment November 2008 zero, into a DHCPDISCOVER message, to explicitly let the server know that it supports port restricted IPv4 addresses. When a client, which supports the options defined in this document, receives a DHCPOFFER with the 'yiaddr' (client IP address) field set to 0.0.0.0, it SHOULD check for the presence of OPTION-IPv4-OPR option field. If such an option is present, the client MAY send a DHCPREQUEST message and insert the option OPTION-IPv4-RPR with the IP address and port ranges received in the OPTION-IPv4-OPR option of the previous DHCPOFFER. The client MUST NOT include a 'Requested IP Address' DHCP option (code 50) into this DHCPOFFER. The client MUST NOT insert the IP address received in OPTION-IPv4- OPR into the 'Requested IP Address' DHCP option (code 50). When the client receives a DHCPACK message with an OPTION-IPv4-OPR option, it MAY start using the specified IP address in conjunction with the source ports specified. The client MUST NOT use the IP address with different source port numbers, as that may result in a conflict, since the same IP address with a different source port range may be assigned to a different client. Furthermore, the client MUST notice the situation where an outgoing IP packet has the same IP address as destination address than the client itself has, but the port number is not belonging to the allocated range. In this case the client MUST detect that the packet is not destined for itself, and it MUST send it forward. In case the initial port range received by the client from the server is exhausted and the client needs additional ports, it MAY request so by sending a new DHCPDISCOVER message. A client MUST NOT include an OPTION-IPv4-OPR option field into any DHCP message it generates. 4.2 Server Behaviour When a server, which supports the options defined in this document, receives a DHCPDISCOVER message, it SHOULD check the presence of the OPTION-IPv4-RPR option. If that option is present, the server SHOULD allocate port restricted IPv4 address to the client, and save the unrestricted addresses for clients which do not support the extensions defined in this document. If OPTION-IPv4-RPR is not present in DHCPDISCOVER, the server SHOULD allocate full unrestricted public or private [RFC1918] IPv4 address to the client, whenever available, by generating a DHCPOFFER as described in [RFC2131]. When a server, which supports the options defined in this document, receives a DHCPDISCOVER message and can only offer port restricted IP address to the client, it MUST set the 'yiaddr' (client IP address) field of the DHCPOFFER message to 0.0.0.0 and SHOULD insert Bajko & Savolainen Expires May 2, 2009 [Page 10] Port restricted IP address assignment November 2008 the OPTION-IPv4-OPR option field by specifying the IP address and allowed port range. When a server, which supports the options defined in this document, receives a DHCPDISCOVER message from a client without the OPTION- IPv4-RRP, and knows by means outside the scope of this document, that the client supports the usage of port-restricted IPv4 addresses (or it is only entitled to be provisioned with such addresses), MUST set the 'yiaddr' (client IP address) field of the DHCPOFFER message to 0.0.0.0 and SHOULD insert the OPTION-IPv4-OPR option field by specifying the IP address and allowed port range. When the server receives a DHCPREQUEST message from the client with an OPTION-IPv4-RPR option field containing the IP address and port range it has previously offered to the client, the server MUST send a DHCPACK, where the 'yiaddr' (client IP address) field is set to 0.0.0.0 and the server MUST include the OPTION-IPv4-OPR option including the IP address and port range the client requested. When the server receives a DHCPREQUEST message from the client with an OPTION-IPv4-RPR option field containing an IP address and port range it has previously not offered to the client, the server MUST send a DHCPNAK to the client. When the server detects that a client with a specific hardware address, having already been allocated with a port restricted IP address, sent another DHCPDISCOVER, it MAY, based on local policy, offer the client with additional port restricted IP address. A server MUST NOT include an OPTION-IPv4-RPR option field into any DHCP message it generates. A server MUST ignore any OPTION-IPv4-OPR options in DHCP messages generated by clients. A server SHOULD ensure the client is residing on an access link where usage of port-restricted addresses are not causing problems, before allocating it a port restricted IPv4 address. 5. Applicability The immediate applicability of such a solution is in 3GPP [3GP23401] or WiMAX [WMFS21.2] compliant mobile networks, where cellular hosts can directly utilize the option without separate gateway or consumer premises gateway being present. The new options can be utilized both in point-to-point links and/or IPv4-over-IPv6 tunnels. This document does not address the issue of how clients configured with port restricted IP addresses would handle protocols that run directly over IP (e.g. ICMP). That problem needs further consideration. The server leasing the port restricted IP address, or a gateway in the network, (e.g. the first hop router of a point-to-point link) Bajko & Savolainen Expires May 2, 2009 [Page 11] Port restricted IP address assignment November 2008 MUST enforce the restricted port range policy by filtering out packets sent using out of range source ports. 6. IANA considerations This document defines two new DHCPv4 options as described in section 2. Offered Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4- OPR) TBD Requested Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4- RPR) TBD 7. Open issues Handling ICMP and other protocols running natively on top of IP is a challenge when multiple hosts share the same IP address. As the new DHCP options are designed only for point-to-point links, usage of these options on shared mediums such as Ethernet is not recommended, as there would be possible problems with ARP. If port- restricted IP addresses are going to be taken into use, it MUST be ensured that they are only used in environments where their usage does not interfere with standard IP communication. 8. Security considerations The solution is vulnerable to DoS when used in shared medium or when access network authentication is not a prerequisite to IP address assignment. The solution SHOULD only be used on point-to-point links, tunnels, and/or in environments where authentication at link layer is performed before IP address assignment, and not shared medium. 9. Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March 1997 10. Informative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, G., Lear, E., "Address Allocation for Private Internets", RFC1918, February 1996 [WING2008] Wing, D., Ward, D., Durand, A. "A Comparison of Proposals to Replace NAT-PT", September 2008, draft- wing-nat-pt-replacement-comparison-00 [DESP2008] Despres, R., "A Scalable IPv4-IPv6 Transition Architecture Need for an address-port-borrowing- Bajko & Savolainen Expires May 2, 2009 [Page 12] Port restricted IP address assignment November 2008 protocol (APBP) ", July 2008, draft-despres-v6ops-apbp- 01 [ARKK2008] Arkko, J., Townsley, M., "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", September 2008, draft-arkko- townsley-coexistence-00 [DURA2008] Durand, A., Droms, R., Haberman, B., Woodyatt, J. "Dual-stack lite broadband deployments post IPv4 exhaustion", September 2008, draft-durand-softwire- dual-stack-lite-00 [MAEN2008] Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "A Better Approach than Carrier-Grade-NAT", 2008, Technical Report CUCS-041-08 [WMFS21.2] WiMAX Forum, "WiMAX Forum Network Architecture, (Stage 2: Architecture Tenets, Reference Model and Reference Points)", January 2008, Release 1, Version 1.2 [WMFS31.2] WiMAX Forum, "WiMAX Forum Network Architecture, (Stage 3: Detailed Protocols and Procedures)", January 2008, Release 1, Version 1.2 [3GP23401] 3rd Generation Partnership Project (3GPP), Technical Specification Group Services and System Aspects, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E- UTRAN) access (Release 8)", September 2008, 3GPP TS 23.401 V8.3.0 [3GP23060] 3rd Generation Partnership Project (3GPP), Technical Specification Group Services and System Aspects, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 8)", September 2008, 3GPP TS 23.060 V8.2 [3G2X0011] 3rd Generation Partnership Project 2 (3GPP2), "cdma2000 Wireless IP Network Standard: Introduction", August 2003, 3GPP2 X.S0011-001-C version 1.0.0 11. Author's Addresses Gabor Bajko Email: gabor(dot)bajko(at)nokia(dot)com Teemu Savolainen Hermiankatu 12 D FI-33720 TAMPERE FINLAND Bajko & Savolainen Expires May 2, 2009 [Page 13] Port restricted IP address assignment November 2008 Email: teemu.savolainen@nokia.com Bajko & Savolainen Expires May 2, 2009 [Page 14] Port restricted IP address assignment November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bajko & Savolainen Expires May 2, 2009 [Page 15]