Internet DRAFT - draft-shin-dstm-ports
draft-shin-dstm-ports
INTERNET-DRAFT Myung-Ki Shin
Expires: December 2005 ETRI
June 2005
Ports Option Support in DSTM
<draft-shin-dstm-ports-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 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), <draft-
bound-dstm-exp-02.txt>, 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)", <draft-blanchet-v6ops- tunnelbroker-tsp-01.txt>
(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]
