One document matched: draft-tsou-softwire-port-set-algorithms-analysis-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC6056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY RFC6431 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6431.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-softwire-port-set-algorithms-analysis-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->
<title abbrev="Port Set Algorithms Analysis">Port Set Definition Algorithms Analysis</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Tina Tsou" initials="T." role="editor"
surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>CA 95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author fullname="Tetsuya Murakami" initials="T." surname="Murakami">
<organization>IP Infusion</organization>
<address>
<postal>
<street>1188 East Arques Avenue</street>
<city>Sunnyval</city>
<country>USA</country>
</postal>
<email>tetsuya@ipinfusion.com</email>
</address>
</author>
<author fullname="Simon Perreault" initials="S." surname="Perreault">
<organization>Viagenie</organization>
<address>
<postal>
<street>246 Aberdeen</street>
<city>Quebec</city>
<region>QC</region>
<code>G1R 2E1</code>
<country>Canada</country>
</postal>
<phone>+1 418 656 9254</phone>
<email>simon.perreault@viagenie.ca</email>
<uri>http://viagenie.ca</uri>
</address>
</author>
<date year="2012" />
<!-- Meta-data Declarations -->
<area>INT</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>This memo analyses the some port set definition algorithms which encodes port
set infomation into IPv6 address so as to support stateless IPv4 to
IPv6 transition technologies, e.g. 4rd-U and MAP.</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>Some stateless IPv4 to IPv6 stransition technologies are invented by
the industrial to provide IPv4 network service through IPv6 network,
which also support IPv4 address sharing via port sets. These technologies
can significantly simplify the implementation of the border router and
reduce resource requirement. </t>
<t>In these solutions, a port set is assigned to each CPE, and can be
calculated by a port set ID in conjunction with some other parameters;
for any port number, the corresponding port set ID can also be derived,
that means, the mapping algorithm must be reversible. When the CPE needs
to send an IPv4 packet, it can map an IPv4 packet into an IPv6 packet,
either by translation or encapsulation, the IPv4 address and port set ID
will be embedded into an IPv6 address; when the BR receive the IPv6 packet,
it will decapsulate it. When the BR need to forward an IPv4 packet to the
CPE, it will first derive the port set ID from the port, and then map the
IPv4 packet into an IPv6 packet.</t>
<t>In order to support these technologies, some port set definition
algorithms are worked out. It may be useful to analyse the characteristics
of these algorithms for better understanding and to choose a proper
algorithm for different needs.</t>
<t>A good port set definition algorithm must be reversible, easy to implement,
and should be able to define non-continuous or random port sets for better
security, be able to exclude the well known ports, 0 ~ 1023 or 0 ~ 4095, etc.</t>
<t>This memo will analyse the following characterics:
<list style="symbols">
<t>Port set type: continuous, non-continuous, random</t>
<t>Stateless: yes or no</t>
<t>Security: security level, continuous port set provides common security,
random port set provides good security.</t>
<t>Implementation: implementation complexity, performance, etc.</t>
<t>Friendliness for NAT44: comply with NAT44 or not</t>
<t>Sharing ratio: maximum, minimum sharing ratio</t>
<t>Revert calculation from port number to PSID at BR.</t>
<t>Exclude well known ports</t>
</list>
</t>
</section>
<section title="Terminology">
<t><list hangIndent="10" style="hanging">
<t hangText="BR:">Border Router.</t>
<t hangText="CPE:">Customer Premise Equipment.</t>
<t hangText="GMA:">Generalized Modulus Algorithm.</t>
<t hangText="MAP:">Map Address and Port.</t>
<t hangText="PSID:">Port Set ID, one of the key parameters used to derived
a set of ports.</t>
</list></t>
</section>
<section anchor="algorithms" title="Various types of algorithms">
<t>Currently, the port set definition algorithms can be classified
into three categories: GMA style, Mask/Value style and cryptographical style.</t>
<section title="GMA style algorithms">
<t>Currently there are three sets of draft support GMA style algorithm:
<xref target="I-D.ietf-softwire-map-01">MAP</xref>,
<xref target="I-D.ietf-softwire-4rd-02">4rd-U</xref> and, but they are
not exactly all the same.
</t>
<section title="MAP">
<t>In <xref target="I-D.ietf-softwire-map-01">MAP</xref>,
a port set can be defined by the following parameters:</t>
<t>
<list>
<t>R: sharing ratio;</t>
<t>P: PSID;</t>
<t>M: maximum number of contiguous ports.</t>
</list>
</t>
<t>To derive a port from the port set, the following equation can be used:</t>
<t>Port = R * M * j + M * P + i </t>
<t>j is port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1,
if the port numbers (0 - 4095) are excluded.</t>
<t>i is the port index in a sub port set, i = 0 to M-1;</t>
<t>To derive the PSID from a given port: </t>
<t>PSID = (floor(Port/M)) % R, where % is the modulus operator.</t>
<t>Parameter M is to generate non-continuous ports sets, rather than a single
continuous port set, which brings better sercurity. If M=1, a single
continuous port set is defined.</t>
<t>PSID will be encoded in the IPv6 address, as shown in
<xref target="Bit representation"></xref> and
<xref target="Deriving of MAP IPv6 address"></xref>.</t>
<figure anchor="Bit representation"
title="Bit representation"
align="center">
<artwork>
0 8 15
+---------------+----------+------+-------------------+
| P |
----------------+-----------------+-------------------+
| A (j) | PSID (K) | M (i) |
+---------------+----------+------+-------------------+
|<----a bits--->|<-----k bits---->|<------m bits----->|
</artwork>
</figure>
<figure anchor="Deriving of MAP IPv6 address"
title="Deriving of MAP IPv6 address"
align="center">
<artwork>
| 32 bits | | 16 bits |
+--------------------------+ +-------------------+
| IPv4 destination address | | IPv4 dest port |
+--------------------------+ +-------------------+
: : ___/ :
| p bits | / q bits :
+----------+ +------------+
|IPv4 sufx| |Port-Set ID |
+----------+ +------------+
\ / ____/ ________/
\ : __/ _____/
\ : / /
| n bits | o bits | m bits | 128-n-o-m bits |
+--------------------+-----------+---------+------------+----------+
| Rule IPv6 prefix | EA bits |subnet ID| interface ID |
+--------------------+-----------+---------+-----------------------+
|<--- End-user IPv6 prefix --->|
</artwork>
</figure>
</section>
<section title="4rd-U">
<t>In <xref target="I-D.ietf-softwire-4rd-02">4rd-U</xref>, PSID
itself is sufficient for defining a port set, as shown in
<xref target="From CE IPv6 prefix to 4rd IPv4 address and Port set"></xref>. </t>
<t>To derive the PSID from a given port, it only needs to take out
the PSID bits from the 16bit port number.</t>
<figure anchor="From CE IPv6 prefix to 4rd IPv4 address and Port set"
title="From CE IPv6 prefix to 4rd IPv4 address and Port set"
align="center">
<artwork>
+--------------------------------------------+
| CE IPv6 prefix |
+--------------------------+-----------------+
: Longest match : :
: with a Rule IPv6 prefix : :
: || : :
: \/ : EA-bits length :
+--------------------------+ | :
| Rule IPv6 prefix |<----'---->:<-.->:
+--------------------------+ : \
|| : : Length of the
\/ : : Rule IPv6 suffix
+-----------------+-----------+(if the rule has one)
|Rule IPv4 prefix | EA bits |
+-----------------+-----------+
: :
+-----------------------------+
| CE 4rd IPv4 prefix |
+-----------------------------+
________/ \_________ :
/ \ :
: ____:________________/ \__
: / : \
: =< 32 : : > 32 :
+----------------+ +-----------------+----+
|IPv4 prfx or add| OR | IPv4 address |PSID|
+----------------+ +-----------------+----+
: 32 : || :
\/
(by default) (If WKPs authorized)
: : : :
+---+----+---------+ +----+-------------+
Ports in |> 0|PSID|any value| OR |PSID| any value |
the CE port set +---+----+---------+ +----+-------------+
: 4 : 12 : : 16 :
</artwork>
</figure>
</section>
<section title="Summary">
<figure align="center">
<artwork>
-------------------------------+-------------------------
Port set type | no-continuous
-------------------------------+-------------------------
Stateless | yes
-------------------------------+-------------------------
Security | good
-------------------------------+-------------------------
Implementation | easy
-------------------------------+-------------------------
Friendliness for NAT44 | yes
-------------------------------+-------------------------
Sharing ratio | up to 2^12
-------------------------------+-------------------------
Revert calculation from |
port number to PSID at BR | yes
-------------------------------+-------------------------
Exclude well known ports | yes, 0~1023 or 0~4095
-------------------------------+-------------------------
</artwork>
</figure>
<t>1. 4rd-U is a parameter-free algorithm, which is different MAP;
while MAP can provide more variation due to the extra parameter(s).
From the port set definition point of view, MAP and 4rd-U provide the
same level of security. </t>
<t>2. MAP support sharing ratio up to 2^16, although it may not be
necessary.</t>
</section>
</section>
<section title="Mask/Value style algorithms">
<t><xref target="RFC6431"></xref> defines an IPCP option to
allocate port set to CPEs, as shown in <xref target="IPCP option format"></xref>.</t>
<figure anchor="IPCP option format"
title="IPCP option format"
align="center">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Port Range Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Range Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The Port Range Value can be encoded in IPv6 address, similar
as parameter PSID in other technologies, e.g.
<xref target="I-D.ietf-softwire-map-01">MAP</xref>.</t>
<t>To derive the Port Range Value from a given port, the port number
should porform bit-and operation with the Port Range Mask.</t>
<figure anchor="Example of Port Range Mask and Port Range Value"
title="Example of Port Range Mask and Port Range Value"
align="center">
<artwork>
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| | (two significant bits)
v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x 0 x 1 x x x x x x x x x x| Usable ports
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (x may be set to 0 or 1)
</artwork>
</figure>
<t>This alogrithm can have some kind of randomization effect by setting different
number of bits and bits at different location in the Port Range Mask.</t>
<t>This algorithm may have a problem if the well known ports(0~1023 or 0~4096)
need to be excluded, it is a bit difficult to achieve that. But if the operator
do not have a specific usage for the well known ports, then it is OK to allocate
those port to end users, just like other common ports. Some tests have done and
prove that is OK.</t>
<figure align="center">
<artwork>
-------------------------------+----------------------------
Port set type | continuous, no-continuous
-------------------------------+----------------------------
Stateless | yes
-------------------------------+----------------------------
Security | good
-------------------------------+----------------------------
Implementation | easy
-------------------------------+----------------------------
Friendliness for NAT44 | yes
-------------------------------+----------------------------
Sharing ratio | up to 2^16
-------------------------------+----------------------------
Revert calculation from |
port number to PSID at BR | yes
-------------------------------+----------------------------
Exclude well known ports | difficult
-------------------------------+----------------------------
</artwork>
</figure>
</section>
<section title="Cryptographical style algorithms">
<t>The cryptographical port set definition algorithm introduced in
<xref target="RFC6431"></xref> can provide very good security, but it is very
difficult to derive the port set infomation, e.g. the starting point, from a
given port. This algorithm can only be used in stateful scenarios, the BR must
be operated in stateful mode.</t>
<t>In order to use this kind of algorithm in a stateless scenario, the algorithm
must be reversible, that is, with some given information, it should be able
to derive the port set information from a given port number.</t>
<figure anchor="Format of the Cryptographically Random Port Range Option"
title="Format of the Cryptographically Random Port Range Option"
align="center">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| starting point | number of delegated ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key K ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure align="center">
<artwork>
-------------------------------+----------------------------
Port set type | continuous, no-continuous
-------------------------------+----------------------------
Stateless | No *
-------------------------------+----------------------------
Security | Very good
-------------------------------+----------------------------
Implementation | difficult
-------------------------------+----------------------------
Friendliness for NAT44 | yes
-------------------------------+----------------------------
Sharing ratio | up to 2^16
-------------------------------+----------------------------
Revert calculation from |
port number to PSID at BR | No *
-------------------------------+----------------------------
Exclude well known ports | difficult
-------------------------------+----------------------------
</artwork>
</figure>
<t>* It may be possible to find a cryptographic algorithm which
can be reversed, e.g. define a reversible one-to-one mapping algorithm.
But that is out the scope of this memo. If strong security is required,
it may be worth giving this topic further study.</t>
</section>
</section>
<section title="Conclusion">
<t>TBD.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The port set should be as random as possible, in order to make it difficult
to predict what the next port will be used, to avoid some potential TCP attack
<xref target="RFC6056"></xref>. </t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC6056;
&RFC6431;
<reference anchor="I-D.ietf-softwire-4rd-02">
<front>
<title>IPv4 Residual Deployment via IPv6 - a unified Stateless
Solution (4rd) (Work in progress)</title>
<author initials="R." surname="Despres" fullname="Remi Despres">
<organization>RD-IPtech</organization>
</author>
<author initials="R." surname="Penno" fullname="Reinaldo Penno">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="Y." surname="Lee" fullname="Yiu Lee">
<organization>Comcast</organization>
</author>
<author initials="G." surname="Chen" fullname="Gang Chen">
<organization>China Mobile</organization>
</author>
<author initials="S." surname="Jiang" fullname="Sheng Jiang">
<organization>China Mobile</organization>
</author>
<date month="Jan" year="2012" />
</front>
</reference>
<reference anchor="I-D.ietf-softwire-map-01">
<front>
<title>Mapping of Address and Port (MAP) (Work in progress)</title>
<author initials="O." surname="Troan" fullname="Ole Troan">
<organization>Cisco Systems</organization>
</author>
<author initials="W." surname="Dec" fullname="Wojciech Dec">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li" fullname="Xing Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="C." surname="Bao" fullname="Congxiao Bao">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="Y." surname="Zhai" fullname="Yu Zhai">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
<organization>SoftBank Telecom</organization>
</author>
<author initials="T." surname="Murakami" fullname="Tetsuya Murakami">
<organization>IP Infusion</organization>
</author>
<date month="Jun" year="2012" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.bsd-softwire-stateless-port-index-analysis">
<front>
<title>Analysis of Port Indexing Algorithms</title>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="N." surname="Skoberne" fullname="Nejc Skoberne">
<organization>Viris</organization>
</author>
<author initials="W." surname="Dec" fullname="Wojciech Dec">
<organization>Cisco Systems</organization>
</author>
<date month="Sept" year="2011" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:17 |