[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

    Network Working Group                                      Xiaohong Deng
    Internet Draft                                              M. Boucadair
    Intended status: Standards Track                          France Telecom
    Expires: May 2012                                                C. Zhou
                                                         Huawei Technologies
                                                            October 31, 2011
                     NAT offload extension to Dual-Stack lite
       Dual-Stack Lite, combining IPv4-in-IPv6 tunnel and Carrier Grade NAT
       technologies, provides an approach that offers IPv4 service via IPv6
       network by sharing IPv4 addresses among customers during IPv6
       transition period. Dual-stack lite, however, requires CGN to maintain
       active NAT sessions, which means processing performance, memory size
       and log abilities for NAT sessions should scale with number of
       sessions of subscribers; Hence increasing in CAPEX for operators
       would be resulted in when traffic increase.
       This document propose the NAT offload extensions to DS-Lite, which
       allows offloading NAT translation function from centralized network
       side (AFTR) to distributed customer equipments (B4), thereby offering
       a trade-off between CAPEX (e.g. less performance requirements on AFTR
       device) and OPEX (e.g., easy and fast deployment of Dual-Stack Lite)
       for operators. The ability of easily co-deploying with basic Dual-
       Stack Lite is essential to NAT offload extension to DS-Lite.
    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."
    DBC                     Expires May 31, 2012                  [Page 1]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
       This Internet-Draft will expire on April 26, 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
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.
    Table of Contents
       1. Background........................................................3
       2. NAT offload extended DS-Lite Overview and terminologies...........3
       3. NATed B4 Behavior.................................................5
          3.1. Plain IPv4 Address...........................................5
          3.2. Restricted IPv4 Address and port set provisioning............5
             3.2.1. Restricted port allocation strategies and requirements..5
             3.2.2. Restricted IPv4 Address and port set provisioning method
          3.3. Outgoing Packets Processing..................................6
          3.4. Incoming Packets Processing..................................6
             3.4.1. Incoming Ports considerations on a given restricted IPv4
       4. NAT offload AFTR Behaviour........................................7
          4.1. Outgoing Packets Processing..................................7
          4.2. Incoming Packets Processing..................................7
       5. Fragmentation and Reassembly and DNS..............................7
       6. Security Considerations...........................................8
       7. IANA Considerations..............................................10
       8. References.......................................................10
          8.1. Normative References........................................10
          8.2. Informative References......................................10
       9. Acknowledgments..................................................12
    DBC                     Expires May 31, 2012                  [Page 2]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
    1. Background
       The basic idea of NAT offload extension to DS-lite, is to reuse the
       basic DS-Lite infrastructure, including tunneling transport and
       provisioning method, and ICMP and fragmentation processing as well.
       The NAT offload extension makes the AFTR table scales with customer
       number other than traffic sessions. Based on this NAT offload
       extension, log entries for per subscriber instead of per session is
       achievable. IPv4 address utilization efficiency depends on port
       allocation strategies, e.g., per port on demand, or a buck of ports
       pre-allocation, which would be elaborated in Section 5.
       Besides, this method allows unique IPv6 address for delivery both
       IPv4 over IPv6 traffic and native IPv6 traffic without introduce any
       IPv4 addressing/rouging into IPv6 address/routing, as it reuses Dual
       Stack Lite tunneling transport infrastructure, unlike stateless
       solutions with port set allocation such as aplusp and 4rd, that
       either requires two IPv6 addresses separately for either IPv4 traffic
       over IPv6 or native IPv6 traffic, or require carefully design to
       avoid introduce IPv4 routing to IPv6 routing when using unique IPv6
       address to transport both IPv4 over IPv6 traffic and native IPv6
    2. NAT offload extended DS-Lite Overview and terminologies
       Figure 1 provides an overview of the NAT offload extended DS-Lite.
    DBC                     Expires May 31, 2012                  [Page 3]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
                          |    IPv6 ISP Network     |
                          |                         |
                          |                         |
                            |                   +-----------+   +----------+
                            |                   |NAT offload|   |   IPv4   |
          +--------+        |     IPv4-in-IPv6  |AFTR       |---| Internet |
          |        |  +---------+               |           |   |          |
          |IPv4 LAN|--|NATed    |===============+-----------+   +----------+
          |        |  |B4       |CPE/HOST           |
          +--------+  +---------+                   |
                          |                         |
                          |                         |
                 Figure 1 : NAT offload extended DS-Lite Overview
       NATed B4:  A NAT offload extended B4 which is called NATed B4 in this
       document can be either an IPv6 hosts or a CPE. NATed B4 performs IP
       address and port translation function, besides establishment of IPv4
       in IPv6 tunnel with AFTR.
       NAT offload AFTR: A NAT offload extended AFTR which is called NAT
       offload AFTR is responsible for establishing IPv4 in IPv6 tunneling
       with NATed B4 to transport IPv4 over IPv6 while the NAT translation
       function is offloaded to NATed B4.
       A NATed B4 uses IPv4 address with a restricted port set for this IPv4
       connectivity, which may be provisioned via either DHCPv4 with the
       AFTR, or via PCP with the PCP server. The AFTR keeps the mapping
       between B4's IPv6 address, allocated IPv4 address, and a restricted
       port set ID on a per customer basis.
       For host NATed B4 case, the host gets public address directly. It is
       also suggested that the host run a local NAT to map randomly
       generated ports into the restricted port set. Private to public
       address translation would not be needed in this NAT.  Another
    DBC                     Expires May 31, 2012                  [Page 4]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
       solution is to have the IP stack to only assign ports within the
       restricted port set to applications.  Either way the host guarantees
       that every port number in the packets sent out by itself  falls into
       the allocated port set.
    3. NATed B4 Behavior
       The NATed B4 is responsible for performing NAT and/ALG functions,
       basic B4 functions, as well as supporting NAT Traversal mechanisms
       (e.g., UPnP or NAT-PMP).
       The tunneling provisioning of the B4 element should reuse what has
       defined in [I-D.ietf-softwire-dual-stack-lite].
    3.1. Plain IPv4 Address
       A NATed B4 MAY be assigned with a plain IPv4 address.
       When a plain, IPv4 address is assigned, the NAT operations are
       enforced as per current legacy CPEs.  The NAT in the AFTR is disabled
       for that user.IPv4 datagrams are encapsulated in IPv6 as specified in
    3.2. Restricted IPv4 Address and port set provisioning
    3.2.1. Restricted port allocation strategies and requirements
       Restricted port allocation strategies for this approach could either
       be allocating per port on demand, or be pre-allocating a port set (no
       matter a continuous port range, or multiple non-continuous sub port
       sets),which leads to trade-off between provisioning  efficiency and
       IPv4 utilization efficiency.
       Note that efficiency on log is reported by operators as a practical
       requirement for AFTR, hence port set decoding should take this
       requirement into account, no matter which port allocation strategy is
    DBC                     Expires May 31, 2012                  [Page 5]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
       Unlike stateless 4over6 solutions such as  [I-D.murakami-softwire-
       4rd], the restricted port sets allocation for NAT offload extended
       DS-Lite has no requires on careful planning of the IPv6 and IPv4
       addressing together. It therefore offers more flexibility for ISPs,
       when it comes to managing the IPv6 access network, and introduces no
       impact on IPv6 routing.
    3.2.2. Restricted IPv4 Address and port set provisioning method
       Either DHCP for example, [I-D.bajko-pripaddrassign] or PCP would be
       candidate for delivery Restricted IPv4 and port set.
       With PCP, The basic PCP protocol allows per port on demand allocation,
       while an extension to PCP [I-D.tsou-pcp-natcoord] supports pre-
       allocate bulk of ports.
    3.3. Outgoing Packets Processing
       Upon receiving an IPv4 packet, the B4 performs NAT using the public
       IPv4 address and port set assigned to it.  Then B4 encapsulates the
       resulting IPv4 packet into an IPv6 packet, and delivers it through
       IPv6 connectivity to AFTR which will then decapsulate the
       encapsulated packet and forward it through IPv4.  The destination
       IPv6 address used for encapsulation should be the AFTR's address.
    3.4. Incoming Packets Processing
       Upon receipt of IPv4-in-IPv6 packet from AFTR, B4 will decapsulate
       the packet and translate the public IPv4 address to the private IPv4
       address.  Finally, it delivers the packet to the host using the
       translated IPv4 address.  The source IPv6 address used for
       encapsulation at AFTR is the AFTR's address, and the destination
       address is set to the external address of B4.
    3.4.1. Incoming Ports considerations on a given restricted IPv4 address
       As described in [I-D.ietf-intarea-shared-addressing-issues], a bulk
       of incoming ports can be reserved as a centralized resource shared by
       all subscribers using a given restricted IPv4 address.  In order to
    DBC                     Expires May 31, 2012                  [Page 6]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
       distribute incoming ports as fair as possible among subscribers
       sharing a given restricted IPv4 address, other than allocating a
       continuous range of ports to each, a solution to distribute bulks of
       non-continuous ports among subscribers, which also takes port
       randomization into account, is elaborated in Section 3.1.
    4. NAT offload AFTR Behaviour
       The NAT offload AFTR may be co-located with IP and /or restricted
       port set allocation server (e.g., a DHCP server, or a PCP server).
       The AFTR only maintains a static mapping entry per customer consist
       of IPv6 address, IPv4 address and port set ID, other than maintains
       NAT entries per session.
    4.1. Outgoing Packets Processing
       For outgoing packets, the NAT offload AFTR simply decapsulates it and
       forwards it to IPv4 Internet.
    4.2. Incoming Packets Processing
       For inbound traffic, NAT offload AFTR would use the IPv4 destination
       address and port as the index to retrieve mapping table in order to
       find a destination IPv6 address, and then encapsulates it into IPv6,
       so that native IPv6 routing could be used to forward the IPv4 in IPv6
    5. Fragmentation and Reassembly and DNS
       No change to Section 5.3 of [I-D.ietf-softwire-dual-stack-lite. The
       DNS behavior is the same as described in [I-D.ietf-softwire-dual-
    DBC                     Expires May 31, 2012                  [Page 7]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
    6.  Security Considerations
       As port randomization is one protection among others against blind
       attacks, a simple non-contiguous port sets distribution mechanism is
       therefore proposed to distribute bulks of non-continuous ports among
       subscribers, and to enable subscribers operating port randomized NAT.
       In this section, a non-continuous restricted port set
       encoding/decoding and an algorithm of random ephemeral port selection
       within the allocated restricted port set example proves that port
       randomization is applicable this approach.
       On every external IPv4 address, according to port set size N, log2(N)
       bits are randomly choosing by NAT offload AFTR as subscribers
       identification bits(s bit) among 1st and 16th bits. Take a sharing
       ration 1:32 for example, Figure 1 shows an example of 5 random
       selected bits of s bits.
                        |1st |2nd |3rd |4th |5th |6th |7th | 8th|
                        | 0  |  s | 0  | 0  | s  | 0  | s  |  0 |
                        |9th |10th|11th|12th|13th|14th|15th|16th|
                        | s  | 0  |  s | 0  | 0  | 0  | 0  | 0  |
           Figure 2 : A s bit selection example (on a sharing ration 1:32
       Subscriber ID pattern is formed by setting all the s bits to 1 and
       other trivial bits to 0.  Figure 2 illustrates an example of
       subscriber ID pattern on a sharing ration 1:32 address.  Note that
       the subscriber ID pattern will be different, guaranteed by the random
       s bit selection, on every restricted IP address no matter whether the
       sharing ratio varies.The NAT offload AFTR can use subscriber ID
       pattern as port set ID on a per restricted IPv4 address basis, which
       allows log entries scale on a subscriber basis, hence meets the log
       efficiency requirements described in Section 3.1.2.
    DBC                     Expires May 31, 2012                  [Page 8]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
                        |1st |2nd |3rd |4th |5th |6th |7th | 8th|
                        | 0  | 1  | 0  | 0  | 1  | 0  | 1  |  0 |
                        |9th |10th|11th|12th|13th|14th|15th|16th|
                        | 1  | 0  | 1  | 0  | 0  | 0  | 0  | 0  |
        Figure 3 : A subscriber ID pattern example (on a sharing ration 1:32
       Subscribers ID value is then assigned by setting subscriber ID
       pattern bits (s bits shown in the following example) according to a
       customer value and setting other trivial bits to 1.
                        |1st |2nd |3rd |4th |5th |6th |7th | 8th|
                        | 1  | s  | 1  | 1  | s  | 1  | s  | 1  |
                        |9th |10th|11th|12th|13th|14th|15th|16th|
                        | s  | 1  |  s | 1  | 1  | 1  | 1  | 1  |
          Figure 4 : A subscriber ID value example (0# subscriber on this
                               restricted address).
       Subscriber ID pattern and subscriber ID value together uniquely
       defines a non-overlapping port set on a restricted IP address.
       Pseudo-code shown in the Figure 4 describe how to use subscriber ID
       pattern and subscriber ID value to implement a random ephemeral port
       selection function in a restricted port set.
    DBC                     Expires May 31, 2012                  [Page 9]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
                 restricted_next_ephemeral = (random()| customer_ID_pattern)
                                             & customer_ID_value;
                 if(five-tuple is unique)
                 return restricted_next_ephemeral;
        Figure 5    : Random ephemeral port selection of restricted port set
    7. IANA Considerations
    8. References
    8.1. Normative References
                    Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.
    8.2. Informative References
                     Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
                     "Port Restricted IP Address Assignment",
                     draft-bajko-pripaddrassign-03 (work in progress),
                     September 2010.
    DBC                     Expires May 31, 2012                 [Page 10]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
                     Boucadair, M., Skoberne, N., and W. Dec, "Analysis of
                     Port Indexing Algorithms",
                     (work in progress), September 2011.
                     Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP
                     tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work
                     in progress), July 2011.
                     Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
                     Lee, "Public IPv4 over Access IPv6 Network",
                     draft-cui-softwire-host-4over6-06 (work in progress),
                     July 2011.
                     Murakami, T., Troan, O., and S. Matsushima, "IPv4
                     Residual Deployment on IPv6 infrastructure - protocol
                     specification", draft-murakami-softwire-4rd-01 (work in
                     progress), September 2011.
    DBC                     Expires May 31, 2012                 [Page 11]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
                     Sun, Q. and C. Xie, "LAFT6: NAT offload address family
                     transition for IPv6", draft-sun-v6ops-laft6-01 (work in
                     progress), March 2011.
    9. Acknowledgments
       Thank Alain Durand, Ole Troan and Ralph Dorm for their valuable
       feedback and discussion to this appraoch, and thanks to Qiong Sun for
       a discussion from operators needs' perspective.
    Appendix A. Variants of this approach
       A.1. Introduction
       This section defines variants of deployment for this NAT offload DS-
       Lite approach. A.2 describes its combination with stateless
       A.2 Stateless Encapsulation
       B4 may implement the stateless encapsulation specified in Section 4.4
       of [I-D.ymbk-aplusp].
    DBC                     Expires May 31, 2012                 [Page 12]

    Internet-Draft    Lightweight extension to DS-Lite        October 2011
    Authors' Addresses
          Xiaohong Deng
          France Telecom
          Email: xiaohong.deng@orange.com
          Mohamed Boucadair
          France Telecom
          Rennes,   35000
          Email: mohamed.boucadair@orange.com
          Cathy Zhou
          Huawei Technologies
          Bantian, Longgang District
          Shenzhen  518129
          P.R. China
          Email: cathyzhou@huawei.com
          Tina Tsou
          Huawei Technologies (USA)
          2330 Central Expressway
          Santa Clara, CA  95050
          Phone: +1 408 330 4424
          Email: tena@huawei.com
          Gabor Bajko
          Email: gabor.bajko@nokia.com
    DBC                     Expires May 31, 2012                 [Page 13]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/