Internet DRAFT - draft-bcx-address-fmt-extension
draft-bcx-address-fmt-extension
behave C. Bao, Ed.
Internet-Draft X. Li
Intended status: Standards Track CERNET Center/Tsinghua
Expires: April 25, 2012 University
October 23, 2011
Extended IPv6 Addressing for Encoding Port Range
draft-bcx-address-fmt-extension-02
Abstract
This document discusses an extension of the algorithmic translation
between IPv4 and IPv4-translatable IPv6 addresses. The extended
address format contains transport-layer port range information which
allows several IPv6 nodes to share a single IPv4 address with each
node managing a different range of ports. This address format
extension can be used for IPv4/IPv6 translation, as well as IPv4 over
IPv6 tunneling.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 14, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Bao & Li Expires October 14, 2011 [Page 1]
Internet-Draft Extended IPv6 Addressing April 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extended IPv4-tranlatable IPv6 Address . . . . . . . . . . . . 3
2.1. Port-range Coding Algorithm . . . . . . . . . . . . . . . . 4
2.2. Extended Address Format . . . . . . . . . . . . . . . . . . 5
2.3. Suffix for Port Range Encoding . . . . . . . . . . . . . . 6
2.4. Stateless Suffix Translation Algorithm . . . . . . . . . . 7
2.5. Partial-state Suffix Translation Algorithm . . . . . . . . 8
2.6. ICMP Packet Handling . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Bao & Li Expires October 14, 2011 [Page 2]
Internet-Draft Extended IPv6 Addressing April 2011
1. Introduction
This document discusses an extension of the address format defined in
[I-D.ietf-behave-address-format]. The original address format
document specifies how an individual IPv6 address is translated to a
corresponding IPv4 address, and vice versa, in cases where an
algorithmic mapping is used. To face the IPv4 public address
exhaustion, it is desirable to assign fractional IPv4 addresses to
IPv6 nodes which can share a single IPv4 address with each node
managing a different range of ports.
In [I-D.ietf-behave-address-format] Section 3.5, it states:
"There have been proposals to complement stateless translation
with a port-range feature. Instead of mapping an IPv4 address to
exactly one IPv6 prefix, the options would allow several IPv6
nodes to share an IPv4 address, with each node managing a
different range of ports. If a port range extension is needed, it
could be defined later, using bits currently reserved as null in
the suffix."
This document defines one of such a suffix encoding scheme and the
corresponding port-range algorithm.
1.1. Applicability Scope
The address format extension can be used for both IPv4/IPv6
translation and IPv4 over IPv6 tunneling. However, in this document
we will use IPv4-translatable addresses in the stateless translation
to discuss this specific address format extension. The descriptions
of the other algorithms for their specific use case can be defined
later.
1.2. Conventions
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 [RFC2119].
2. Extended IPv4-tranlatable IPv6 Address
In Section 2.2 of [I-D.ietf-behave-address-format], IPv4-embedded
IPv6 address format is defined which composed of a variable length
prefix, the embedded IPv4 address, and a variable length suffix, as
presented in the following diagram, in which PL designates the prefix
length:
Bao & Li Expires October 14, 2011 [Page 3]
Internet-Draft Extended IPv6 Addressing April 2011
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: Address Format
It is clear that only Prefix lengths (PL) with 32, 40, 48, 56 and 64
have suffix portions, with maximum suffix lengths of 56, 48, 40, 32,
24, respectively. In order to use different Prefix length and unify
the port range encoding method, the suffix should be 24 bits or less.
Furthermore, we choose the port-range coding suffix which is directly
following the embedded IPv4 address and padding zeros after the
suffix.
2.1. Port-range Coding Algorithm
The address-sharing scheme is shown in the following figure.
---------------------------------
-----|IPv4-translatable-0|port-range-0 |
/ ---------------------------------
/ ---------------------------------
|--------|IPv4-translatable-1|port-range-1 |
| ---------------------------------
-------------------- | ---------------------------------
| IPv4-addr|any ports|-----------|IPv4-translatable-2|port-range-2 |
-------------------- | ---------------------------------
| ---------------------------------
|--------|IPv4-translatable-3|port-range-3 |
| ---------------------------------
\ ...
\ ---------------------------------
-----|IPv4-translatable-K|port-range-K |
---------------------------------
...
Bao & Li Expires October 14, 2011 [Page 4]
Internet-Draft Extended IPv6 Addressing April 2011
Figure 2: Address Sharing Scheme
In the above figure, the IPv4-translatable-0, IPv4-translatable-1,
IPv4-translatable-2, ..., IPv4-translatable-K are sharing the same
IPv4 address IPv4-addr, but port number range for different IPv4-
translatable addresses (i.e. port-range-0, port-range-1, port-range-2
, port-range-K) are not overlapped. When an IPv6 node using IPv4-
translatable addresses communicates with the IPv4 Internet via a
translator, it looks like a single host using IPv4 address (IPv4-
addr) communicating with the IPv4 Internet.
There exist many port-range coding schemes and each one may have its
advantages and disadvantages, as well as has its best application
scenario. In this document, we will introduce a simple one, which we
believe is suitable for the IPv4/IPv6 stateless translation. This
encoding scheme uses the modulus operator to define the port number
range.
If the sharing ratio is N, then:
o Given K (K=0, 1, ..., N-1), the allowed port number (P) are
P=j*N + K-1, where j=0, 1, ..., (65536-N)/N.
o Given P, the IPv6 node index (K) is
K=(P%N) (% is the Modulus Operator).
For example, If N=128, then IPv6 node K=5 is only allowed to use port
numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the
source port, while the packets with these port numbers as the
destination port number will be send to IPv6 node K=5.
The modulus operator has several features:
1. The port ranges are not overlapped for different IPv6 nodes.
2. The individual ports for each IPv6 node are not continues and the
whole 65536 port range is equally shared by IPv6 nodes.
3. The port number range can be uniquely determined by given sharing
ratio (N) and the IPv6 node index (K).
Based on the modulus operator, We need to encode N and K in the
suffix as an extended IPv4-translatable IPv6 address.
2.2. Extended Address Format
Since the transport port number is a 16 bit integer, the sharing
ratio (N) and the IPv6 node index (K) can both have the value from 0
Bao & Li Expires October 14, 2011 [Page 5]
Internet-Draft Extended IPv6 Addressing April 2011
to 65535. In theory, 32 bits (16 bits for sharing ratio and 16 bits
for IPv6 node index) are required for encoding the port range based
on the modulus operation. In order to fit into 24 bit or less suffix
range, we need to do compression.
First, we can use number of bits to represent the sharing ratio when
the sharing ratio is bit-wise, hence 4 bits is enough for N.
Secondly, if sharing ratio N is very high, each IPv6 node can only
use a small number of concurrent sessions. For example, if N=4096,
each IPv6 node will have 16 concurrent sessions, which may be too
small for most of the applications. Therefore, if we set the maximum
sharing ratio N=4096, then 12 bits are enough for the IPv6 node
index. In this case, we can design suffix which consists of 16 bits
for encoding the port range.
Based on the above discussion, the extended address format is shown
in the following figure.
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix| zero |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix| zero |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix| zero |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix| zero |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix|zer|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: Extended Address Format
Since different suffixes are more specifics in the original address
format defined in [I-D.ietf-behave-address-format], the routing
considerations in that document are also applied here. Furthermore,
the port range is embedded in the extended IPv4-translatable IPv6
addresses and bound to the IPv6 node index (K), therefore the packets
containing extended IPv4-translatable IPv6 addresses as the
destination can be routed to different IPv6 nodes.
2.3. Suffix for Port Range Encoding
The most significant 4 bits define the multiplexing ratio and the
least significant 12 bits define the IPv6 node index. The
multiplexing ratio, the suffix range and the number of corresponding
Bao & Li Expires October 14, 2011 [Page 6]
Internet-Draft Extended IPv6 Addressing April 2011
concurrent ports are as shown in the following figure.
ratio | suffix range | # of Ports
--------------------------------------
1 0000 - 0000 65,536
2 1000 - 1001 32,768
4 2000 - 2003 16,384
8 3000 - 3007 8,192
16 4000 - 400f 4,096
32 5000 - 501f 2,048
64 6000 - 603f 1,024
128 7000 - 707f 512
256 8000 - 80ff 256
512 9000 - 91ff 128
1,024 a000 - a3ff 64
2,048 b000 - b7ff 32
4,096 c000 - cfff 16
--------------------------------------
Figure 4: Suffix for Port Range Encoding
2.4. Stateless Suffix Translation Algorithm
For the stateless translation, the IPv6 nodes are required to follow
the port number range defined by the extended IPv4- translatable
address format when communicating with the IPv4 Internet. The port
number handling algorithm is:
o If the packets are from IPv4 to IPv6, the IPv4 source addresses
are translated to the IPv4-converted addresses and the source port
numbers are unchanged before and after translation; the IPv4
destination addresses are translated to the extended IPv4-
translatable addresses based on the destination port number and
the destination port numbers are unchanged before and after
translation. Note that this means that only a specific IPv6 node
can receive the packets for a specific port number. When it is
port 80, that specific IPv6 node can setup http redirect service
for other IPv6 nodes which also provide web services with non-
standard port numbers (e.g. 81, 82, etc.).
o If the packets are from IPv6 to IPv4, the IPv6 source addresses
and the source port numbers are checked, if the source port number
matches the port number range defined by the extended IPv4-
translatable address format, the IPv6 source addresses (which are
the IPv4-translatable addresses) are translated to the IPv4
addresses and the source port numbers are unchanged before and
after translation; the destination IPv6 addresses (which are the
IPv4-converted addresses) are translated to the IPv4 destination
Bao & Li Expires October 14, 2011 [Page 7]
Internet-Draft Extended IPv6 Addressing April 2011
addresses and the destination port numbers are unchanged before
and after translation. However, if the source port number does
not match the port number range defined by the extended IPv4-
translatable address format, the packets will be dropped.
2.5. Partial-state Suffix Translation Algorithm
Stateless translation requires that IPv6 nodes generate source port
number in the range defined by the extended IPv4-translatable
address. If this condition does not hold, the partial-state suffix
translation algorithm can be used.
The reason we call this partial-state is that:
o The address mapping is fully algorithm based, as defined in
section 3.4. The states are used for port number mapping only.
o There will be no port mapping table created if the the source port
number from IPv6 to IPv4 is in the range defined by the extended
IPv4-translatable address.
o For the destination port number of the packet from the IPv4 to
IPv6, there will be no port mapping table created.
The partial-state suffix translation algorithm can be defined later.
2.6. ICMP Packet Handling
The ICMP errors should be translatable using the same algorithm (that
is, an error such as Destination Unreachable includes the original
TCP (or UDP) header in the ICMP payload, and the that TCP (or UDP)
port number can be used to translate the ICMP packet into an IPv6-
encoded packet and back again.
Since ICMP echo-request/echo-reply packets only contain
identification field, not the transport port numbers, similar to NAT,
special actions can be taken for translating the ICMP echo-request/
echo-reply packets, which can be defined later.
3. IANA Considerations
This memo adds no new IANA considerations.
4. Security Considerations
There is no special security consideration.
Bao & Li Expires October 14, 2011 [Page 8]
Internet-Draft Extended IPv6 Addressing April 2011
5. Acknowledgements
6. References
6.1. Normative References
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-10 (work in progress),
August 2010.
Authors' Addresses
Congxiao Bao (editor)
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
Email: xing@cernet.edu.cn
Bao & Li Expires October 14, 2011 [Page 9]
