Internet DRAFT - draft-chen-softwire-4v6-add-format
draft-chen-softwire-4v6-add-format
Internet Engineering Task Force G. Chen
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: April 3, 2012 Oct 2011
Design Principles of a Unified Address Format for 4v6
draft-chen-softwire-4v6-add-format-00
Abstract
There are heated discussion over the unified address format and
mapping algorithm. In order to converge the solutions, it is
desirable to discuss the requirements and principles for the design.
This document tries to propose practical principles for 4v6
deployment. The requirements have been derived from this deployment
consideration. Based on that, a unified address format has been
proposed for easying 4v6 solution implementation .
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 April 3, 2012.
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
include Simplified BSD License text as described in Section 4.e of
Chen & Cao Expires April 3, 2012 [Page 1]
Internet-Draft 4v6-add-format Oct 2011
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
2. The Principles for Address Format Design . . . . . . . . . . . 3
2.1. P1: Traffic Classification . . . . . . . . . . . . . . . . 3
2.2. P2: Prefix Delegation Deployment . . . . . . . . . . . . . 4
2.3. P3: Users Privacy Consideration . . . . . . . . . . . . . . 4
2.4. P4: Stateless Behaviour . . . . . . . . . . . . . . . . . . 4
2.5. P5: Coexisting Cases . . . . . . . . . . . . . . . . . . . 4
2.6. P6: Friendly to Network Management . . . . . . . . . . . . 5
3. Requirements for Address Format Design . . . . . . . . . . . . 5
4. Address Format Proposals . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Chen & Cao Expires April 3, 2012 [Page 2]
Internet-Draft 4v6-add-format Oct 2011
1. Introduction
Currently,4v6 stateless technologies have attracted growing efforts
in the IETF communities. The motivation draft
[I-D.ietf-softwire-stateless-4v6-motivation] has been formally
approved as Softwires WG documents. Several drafts on solution set
have been proposed to fit into the 4v6 stateless designing
objectives. There is a strong desirable voice to seek a unified
address presentation converging the efforts to provide consolidated
mapping baseline for either 4v6 encapsulation or 4v6 translation
solutions.
This draft tries to document some analysises on several principles of
unified address design depending on the practical deployment
consideration, which is helping to deduce rational address format for
4v6 solutions. A proposed address format would not only facilitate
implementation of Encap/Translation, but also meet the demands from
potential deployment cases.
We believe that only by figuring out the requirements can the group
converges on the choice of different solutions.
2. The Principles for Address Format Design
Regarding the solution of 4v6 stateless, the community has granted to
investigate encap/decap and translation for different use cases.
From algorithm perspectives, it could share one common mapping rules
but different data packaging. A new designed solutions should not
impact customary behaviour on existing network nodes, thereby below
principles should be applied for both encapsulation and translation.
2.1. P1: Traffic Classification
Usually, operators adopt traffic classification to ensure service
quality for different classes of customers. This feature is also
helpful for user behavior monitoring and security protection. for
example, DIA (Dedicated Internet Access) has been provided by
operators for corporations to cater for their Internet communications
needs. Service is made possible by means of the edge router features
and key systems, like ACL(Access List Control) to classify different
traffic by identifying IP Source/Destination.
In order to take that fly, five tuples should be identified from IP
header and UDP/TCP header. Currently, it has very well supporting in
IPv4. All vendors are delivering or committed to support that
feature for IPv6. According the situation we have, 4v6 solution
should support this feature on IPv6 plane.
Chen & Cao Expires April 3, 2012 [Page 3]
Internet-Draft 4v6-add-format Oct 2011
As for decrease additional investment and opex required over native
IPv6, it is desirable to identify a user based on the first 64 bits.
2.2. P2: Prefix Delegation Deployment
Prefix delegation is an important feature both for broadband and
mobile network. In mobile network, Prefix delegation is introduced
in 3GPP network in Release 10. A UE (CPE) obtains IPv6 prefix from
the mobile network. It then initiates DHCPv6 for prefix delegation.
Such deployment feature requires flexibilities of 4via6 mapping
algorithm allowing the variable length of IPv6 prefix assigned to CE
for deriving IPv4 information. This also implicitly means 4v6 nodes
only can acquire provisioning parameters from delegated IPv6 prefix.
2.3. P3: Users Privacy Consideration
User privacy should be taken into address format designing.
RFC4941[RFC4941] has already expressed the concern associated with
the embedding of non-changing interface identifiers within IPv6
addresses.Changing the interface identifier over time makes it more
difficult for eavesdroppers and other information collectors to
identify when different addresses used in different transactions
actually correspond to the same node. Considering that, it is
expected that IID should as free as possible to allow this security
improvement taken place.
2.4. P4: Stateless Behaviour
4v6 address format should serve for stateless processing purposes.
Communications inside 4v6 domain could take an advantage of pre-
configured parameters and respective algorithm doing stateless
mapping both for source and destination address. However, there is
no referable parameter for destination addresses when a 4v6 node has
a communication with a node outside 4v6 domain. In this case, there
should be a way to express a destination IPv4 address explicitly in
corresponding translated IPv6 address.
2.5. P5: Coexisting Cases
4v6 solutions(i.e. encapsulation and translation) would not only
coexist with each other, but also can harmonize with other deployment
cases. Here lists some coexisting cases. (Note: more coexisting
cases are expected to be investigated in future.)
o Case 1: Coexisting between 4v6 encapsulation and 4v6 translation
o Case 2: Coexisting between 4v6 translation and NAT64 (Single
Translation)
Chen & Cao Expires April 3, 2012 [Page 4]
Internet-Draft 4v6-add-format Oct 2011
o Case 3: Coexisting between 4v6 solutions and SLAAC
For the case 1, the different data packaging could naturally
distinguish whether received data is encapsulated or translated by
inspecting "Next Header" filed in IP header.
For the case 2, an address in 4v6 translation should consider to
specify a dedicated tag so as to compatible with rfc4941 and
differentiate a data flow, which is undergoing single translation
processing(i.e. normative NAT64 processing).
For the case 3, 4v6 should allow CPE performing SLAAC for connected
dual-stack nodes to synthesize IPv6 address. Afterwards, native IPv6
communications could get along with the 4v6 session. A special tag
should be used for distinguishing 4v6 packets from other IPv6 packet
whose destination start with CPE IPv6 prefixes.
2.6. P6: Friendly to Network Management
Besides the end-2-end communication, the address format should be
designed in a way that is also friendly to the network manangement
plane.
Examples for the management plane requirements include the ability to
identify different users and the compatible with the address
assignment techniques in the domain. In 3GPP network, for example,
only the IPv6 prefix is assigned to the devices, used to identify
different users. And one family address managment plane is better
than two, namly the operating platform does not need to manage both
IPv4 and IPv6. But since only IPv6 prefix is assigned, the
management plane is defaultly conducted only via IPv6.
3. Requirements for Address Format Design
Above principles are trying to provide a guidance to derive the
requirements for address format design. Since there are distinct
data processing regarding encapsulation and translation solutions,
below takes two tables to deduce requirements respectively.
Chen & Cao Expires April 3, 2012 [Page 5]
Internet-Draft 4v6-add-format Oct 2011
+----------------------------------------------------------------+
| | CE--CE | CE--BR |
+----+----------------------------+------------------------------+
| | source | destination | source | destination |
+----+----------------------------+------------------------------+
| P1 |inspecting IPv6 address and port information in IPv6 header|
+----+----------------------------+------------------------------+
| P2 |variable IPv6| N/A |variable IPv6 | N/A |
| | length | | length | |
+----+----------------------------+------------------------------+
| P3 | IID should compatible with rfc4941 | N/A |
+----+-------------------------------------------+---------------+
| P4 | N/A | inserting IPv4|
| | | address in IID|
+----+-------------------------------------------+---------------+
| P5 | inserting a tag to indicate 4v6 translation |
+----+-----------------------------------------------------------+
Table 1: Requirements for Address Format in 4v6 Translation
+----------------------------------------------------------------+
| | CE--CE | CE--BR |
+----+----------------------------+------------------------------+
| | source | destination | source | destination |
+----+----------------------------+------------------------------+
| P1 | padding additional information in lower 64 bits |
+----+----------------------------+------------------------------+
| P2 |variable IPv6| N/A |variable IPv6 | N/A |
| | length | | length | |
+----+----------------------------+------------------------------+
| P3 | Somewhat contradictory with P1 |
+----+-------------------------------------------+---------------+
| P4 | N/A | inserting IPv4|
| | | address in IID|
+----+-------------------------------------------+---------------+
| P5 | inserting a tag to indicate 4v6 session |
+----+-----------------------------------------------------------+
Table 2: Requirements for Address Format in 4v6 Encapsulation
Chen & Cao Expires April 3, 2012 [Page 6]
Internet-Draft 4v6-add-format Oct 2011
4. Address Format Proposals
Considering the requirements for different cases, below table has
categorized proposed address format.
+----------+-----------------+--------------------+
| |source address | destination address|
+----------+-----------------+--------------------+
| CE-CE | t1 | t1 |
+----------+-----------------+--------------------+
| CE-BR | t1 | t2 |
+----------+-----------------+--------------------+
Table 3: Address Format Category for 4v6 Translation
+----------+-----------------+--------------------+
| |source address | destination address|
+----------+-----------------+--------------------+
| CE-CE | t3 | t3 |
+----------+-----------------+--------------------+
| CE-BR | t3 | t2 |
+----------+-----------------+--------------------+
Table 4: Address Format Category for 4v6 Encapsulation
Therein, T1, T2 and T3 represent different type of address formats.
The following would like to show each of them.
<------------64 --------------><8 ><--------56---------->
+------------+------------+---+---+---------------------+
|IPv6 prefix |MAX CE index| 0 | V | |
+------------+------------+---+---+---------------------+
Figure 1: Type 1 Address Format
Chen & Cao Expires April 3, 2012 [Page 7]
Internet-Draft 4v6-add-format Oct 2011
<--------- 64 ------------>< 8 ><---- 32 ----><--- 24 ----->
+--------------------------+----+-------------+------------+
| BR subnet prefix | V |IPv4 address | suffix |
+--------------------------+----+-------------+------------+
Figure 2: Type 2 Address Format
<--------- 64 ----------------><8 ><------ L >= 32 -------><56-L>
+------------+------------+---+---+---------------+------+-----+
|IPv6 prefix |MAX CE index| 0 | V | IPv4 address | PSID | 0 |
+------------+------------+---+---+---------------+------+-----+
Figure 3: Type 3 Address Format
o V is a tag to indicate 4v6 solution.
o MAX CE index is used to identify each user in IPv6 prefix. for
more detailed, see addmapping[I-D.despres-softwire-4rd-addmapping]
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. References
7.1. Normative References
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
Chen & Cao Expires April 3, 2012 [Page 8]
Internet-Draft 4v6-add-format Oct 2011
7.2. Informative References
[I-D.despres-softwire-4rd-addmapping]
Despres, R., Qin, J., Perreault, S., and X. Deng,
"Stateless Address Mapping for IPv4 Residual Deployment
(4rd)", draft-despres-softwire-4rd-addmapping-01 (work in
progress), September 2011.
[I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-ietf-softwire-stateless-4v6-motivation-00 (work in
progress), September 2011.
[I-D.murakami-softwire-4v6-translation]
Murakami, T., Chen, G., Deng, H., Dec, W., and S.
Matsushima, "4via6 Stateless Translation",
draft-murakami-softwire-4v6-translation-00 (work in
progress), July 2011.
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: chengang@chinamobile.com
Zhen Cao
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: caozhen@chinamobile.com
Chen & Cao Expires April 3, 2012 [Page 9]