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]