INTERNET-DRAFT Myung-Ki Shin Expires: December 2005 ETRI June 2005 Ports Option Support in DSTM 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 docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in pro- gress." 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, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract As an extension to the address allocation process for DSTM, this document defines the ports option for DSTM. A DSTM server may also provide a range of port numbers to be used by the client. This would allow the use of the same IPv4 address by several DSTM nodes at the same time, reducing the size of the required IPv4 address pool. Shin Expires December 2005 [Page 1] INTERNET-DRAFT Ports Option Support in DSTM June 2005 Table of Contents: 1. Introduction .............................................. 2 2. Terminology ............................................... 2 3. DSTM Ports Option Overview ................................ 2 4. DSTM Host Requirements .................................... 3 4.1 Configuration of the IPv4 stack .......................... 3 5. DSTM Server Requirements .................................. 3 6. TEP Requirements .......................................... 3 7. Implementation Considerations ............................. 3 8. Applicability Statement ................................... 4 9. Security Considerations ................................... 4 Normative References ........................................ 5 Informative References ...................................... 5 Authors' Address ............................................ 5 1. Introduction The Dual Stack Transition Mechanism (DSTM)[1] is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only network and provides a method to allocate a temporary IPv4 Address to IPv6/IPv4 nodes. When a DSTM node wants to talk to IPv4 only nodes, a temporary IPv4 Address is required, so that if the number of the DSTM nodes which want to get IPv4 addresses increases at the same time, a lot of IPv4 address will be needed. As an extension to the address allocation process for DSTM, this document defines the ports option for DSTM. A DSTM server may also provide a range of port numbers to be used by the client. This would allow the use of the same IPv4 address by several DSTM nodes at the same time, reducing the size of the required IPv4 address pool. 2. Terminology 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 [2]. This document uses terminology specific to DSTM as defined in section "Terminology" of the DSTM specification [1]. 3. DSTM Ports Option Overview As an extension to the address allocation process, when a DSTM node wants to talk to IPv4 only nodes, a DSTM server MAY also provide a Shin Expires December 2005 [Page 2] INTERNET-DRAFT Ports Option Support in DSTM June 2005 range of port numbers to be used by the client. This would allow the use of the same IPv4 address by several DSTM nodes at the same time. The DSTM nodes dynamically configure their IPv4 stack (with the same IPv4 address shared by several DSTM nodes and newly assigned ports) and establish 4over6 tunnels towards a TEP. In order to identify the returning path of packets with the same IPv4 address, the TEP SHOULD cache the port number as well as the association between IPv4 and IPv6 source addresses. 4. DSTM Host Requirements 4.1 Configuration of the IPv4 stack When a DSTM node wants to talk to IPv4 only nodes, the DSTM node can detects the need of an IPv4 address. When the first IPv4 packet needs to be sent, the DSTM client MAY contact the DSTM server to obtain a range of ports to be used as well as a temporary IPv4 address and the IPv6 address of a TEP. This information is used to configure the 4over6 interface. It is at this point that the IPv4 stack is configured. 5. DSTM Server Requirements The DSTM server MAY provide the port range to be used as well as a temporary IPv4 address and the IPv6 address of a TEP. The DSTM server has just to guaranty the uniqueness of the range of ports on an IPv4 address for a period of time. This would allow the use of the same IPv4 address by several nodes simultaneously. The DTSM server MUST memorize the mapping between the IPv6 address of the node requesting an address and the allocated IPv4 address and port range. The range of ports is allocated by the server for a fixed amount of time. This duration MUST be included in the response. If the client needs the range of ports for a longer period of time, the client MUST renew the lease. 6. TEP Requirements When a tunnelled packet arrives to the IPv6 destination, the IPv6 header is removed and the packet is processed by the IPv4 layer. The IPv4 packet will then be forwarded by the TEP using the IPv4 infrastructure. The TEP SHOULD cache the source port number as well as the association between the IPv4 and IPv6 source addresses, in order to identify the returning path of packets with the same IPv4 address. Shin Expires December 2005 [Page 3] INTERNET-DRAFT Ports Option Support in DSTM June 2005 7. Implementation Considerations The DSTM node MUST assign the port range provided by the DSTM server to an interface, instead of existing port range, supporting the client's IPv4 stack implementation. Once the IPv4 Address valid lifetime expires the port range MUST be deleted as well as the IPv4 address from the respective interface. When the DSTM server, or DSTM node, provides a range of ports, if the ports are not availabe in a remote node, or the proposed range are exhausted in a DSTM node, implementation MAY allow re- allocation of another range of ports. It may well be implementation dependent. If the port range option is provided in a DSTM doamin, IPv4 ARP on the DSTM nodes SHOULD be disabled. 8. Applicability Statement The motivation of ports option in DSTM is to allow the use of the same IPv4 address by several DSTM nodes at the same time, reducing the size of the required IPv4 address pool. Even if the IPv4 address pool is exhausted in the DSTM server, the ports option may help to establesh new sessions for IPv4 communications on DSTM nodes. It will allow for a maximum of 63K TCP and 63K UDP sessions per IPv4 address. Basically, the ports option is limited to only TCP and UDP applications. ICMP messages may not work. In order to solve this problem, the ports option can adopt an idea on using the query identifier in ICMP message [5]. ICMP messages packets (i.e., ICMP query messages), with the exception of REDIRECT message type, may be tunneled similar to that of TCP/UDP packets, in that the range of identifiers used in ICMP message header will be uniquely assigned to the DSTM nodes. The identifier field in ICMP query messages is set by Query sender and returned unchanged in response message from the Query responder. So, as the TEP caches the tuple of {IPv6 source address, IPv4 source address, source port number, ICMP query identifier}, ICMP queries of all types from the DSTM nodes are uniquely identified for bi-directional forwarding on the TEP. In order to do so, the DSTM server SHOULD provide the range of query identifiers to be used as well as the range of ports. As well, there are operational concerns with that about path MTU discovery in the case tunnels are used. At this time, one way to look at it is to make recommendation on MTU, for example limit MTU to 512 on the DSTM link. The ports option is limited to client applications that do not insist on choosing their own source port number. With the ports Shin Expires December 2005 [Page 4] INTERNET-DRAFT Ports Option Support in DSTM June 2005 option, inbound traffic (from IPv4 only nodes outside the IPv6 domain) is restricted to one server per service. This document does not address yet the case that two nodes sharing the same IPv4 address communicate together. 9. Security Considerations The ports option can meet all of the security considerations mentioned in DSTM specification [1]. Normative References [1] J. Bound et al., Dual Stack Transition Mechanism (DSTM), , January 2005, (work in progress). [2] S. Bradner, Key words for use in RFCs to indicate Requirement Levels. RFC 2119, March 1997. Informative References [3] R. Droms (ed) et. al. Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3315, July 2003. [4] M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", (work in progress), June 2004. [5] P. Srisuresh el al., Traditional IP Network Address Translator (Traditional NAT), RFC 3022, January 2001. Authors' Addresses Myung-Ki Shin ETRI PEC 161 Gajeong-dong Yuseong-gu, 305-350 Korea Tel : +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Shin Expires December 2005 [Page 5] INTERNET-DRAFT Ports Option Support in DSTM June 2005 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 (2005). 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. Shin Expires December 2005 [Page 6]