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

Versions: 00

INTERNET-DRAFT                                                 Z. Xiaoyu
Intended Status: Informational                            France Telecom
Expires: November 27, 2010                                  May 26, 2010


             Aplusp Lite - A light weight aplusp approach
                    draft-xiaoyu-aplusp-lite-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2010 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.






Z. Xiaoyu              Expires November 27, 2010                [Page 1]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


Abstract

   This document proposes a solution aimed at providing IPv4 continuity
   in IPv6 environment. The proposed solution is expected to alleviate
   the public IPv4 depletion problem while maximize the benefits from
   IPv6 deployment, and meet the desired service availability and
   reliability with affordable cost.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
      1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Addressing  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IGF Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 7
      5.1. Outgoing traffic process  . . . . . . . . . . . . . . . . . 7
      5.2. Incoming traffic process  . . . . . . . . . . . . . . . . . 7
      5.3. Fragmentation process . . . . . . . . . . . . . . . . . . . 7
      5.4. Load balance and failover . . . . . . . . . . . . . . . . . 7
   6.  HGF Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 8
      6.1. Outgoing traffic processing . . . . . . . . . . . . . . . . 8
      6.2. Incoming traffic processing . . . . . . . . . . . . . . . . 8
      6.3. Fragmentation processing  . . . . . . . . . . . . . . . . . 9
      6.4. Traffic optimization  . . . . . . . . . . . . . . . . . . . 9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
      10.1.  Normative References  . . . . . . . . . . . . . . . . .  10
      10.2.  Informative References  . . . . . . . . . . . . . . . .  10
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11


















Z. Xiaoyu              Expires November 27, 2010                [Page 2]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


1.  Introduction

   It is commonly agreed that the public IPv4 address depletion is
   inevitable, and the daily updated current consumption of public IPv4
   address is available at http://www.potaroo.net/tools/ipv4/index.html.
   Although IPv6 is regarded as the ultimate solution for this problem,
   the current Internet is far from IPv6 dominant. To support the huge
   amount of IPv4 legacies, many solutions, typically aplusp [I-
   D.boucadair-port-range][I-D.ymbk-aplusp] and ds-lite [I-D.ietf-
   softwire-dual-stack-lite]are proposed to provide IPv4 continuity over
   IPv6 network. However, both kinds of solutions are facing challenges
   in terms of complexity, reliability, functionality, routing
   optimization and expense in large scale deployment.

   By keeping the port range based public IPv4 sharing principle in
   aplusp and employing a ds-lite flavor mapping table which records
   specific relationship between shared IPv4 address block and delegated
   IPv6 prefix, this document proposes a light weight solution called
   aplusp-lite, to meet operational requirements for network operators,
   particularly the broadband network service providers.

1.1.  Terminology

   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 RFC 2119 [RFC2119].

2.  Overview

   There are 2 elements in the aplusp-lite solution: HGF and IGF, as
   depicted in Figure 1:




















Z. Xiaoyu              Expires November 27, 2010                [Page 3]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


            +----------------------------------------------+
            |        +-------+            +---------+      |
            |        | host  |            |  host   |      |
            |        +---+---+            | +-----+ |      |
            |            |                | | HGF | |      |
            |            V                | +-----+ |      |
            |     +--------------+        +----+----+      |
            |     | home gateway |             |           |
            |     |   +-----+    |             |           |
            |     |   | HGF |    |             |           |
            |     |   +-----+    |             |           |
            |     +------+-------+             |           |
            |            |                     |           |
            |            ->IPv4-in-IPv6 Tunnel<-           |
            |            |                     |           |
            |            V                     V           |
            |         -----------------------------        |
            |        /      ISP IPv6 network       \       |
            |       |            +-----+            |      |
            |       |            | IGF |            |      |
            |        \           +-----+           /       |
            |         --------------+--------------        |
            |                       |                      |
            |                       V                      |
            |           +------------------------+         |
            |           |   IPv4/IPv6 Internet   |         |
            |           +------------------------+         |
            +----------------------------------------------+

                   Figure 1 Aplusp-lite architecture

      - Home Gateway Function (HGF): This function resident in the
        customer's home gateway or in any other networked node in case
        no home gateway is present.
      - Interconnection Gateway Function (IGF): This function is the
        interconnection point of the ISP IPv6 network and IPv4 Internet.

   The principle behinds aplusp-lite is very simple:

      - A public IPv4 address is shared by multiple customers with
        different allocated TLIs.
      - Network Address Translation (NAT) and Application Layer Gateway
        (ALG) functions may be performed by the HGF, for IPv4 to IPv4
        communications.
      - IPv4 traffic is encapsulated in IPv6 and exchanged between HGF
        and IGF through IPv4-in-IPv6 encapsulation, with the 'Next
        Header' field of the basic IPv6 header set to 4.
      - IGF forwards IPv4 traffic destined to the shared public IPv4



Z. Xiaoyu              Expires November 27, 2010                [Page 4]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


        address to appropriate HGF by consulting transport layer
        information.

3.  Tunneling

   IPv4-in-IPv6 tunneling MUST be done in accordance to [RFC2473] and
   [RFC4213]. Traffic classes ([RFC2474]) from the IPv4 headers SHOULD
   be carried over to the IPv6 headers and vice versa.

4.  Addressing

   All IPv6 addresses mentioned in this document MUST conform to
   [RFC4787].

   The network service provider MUST correlate its public IPv4 sharing
   plan with IPv6 allocation policy for aplusp-lite customers, as
   depicted in Figure 2.

           +---------------+----------+---------------------+
           |   IPV4-POOL   | TLI-MASK |       PREFIX        |
           +---------------+----------+---------------------+
           |   192.0.2.0/24|         6|        2001:DB8::/42|
           +---------------+----------+---------------------+
           |               |          |                     |
           +---------------+----------+---------------------+

             Figure 2 IPv4/IPv6 address allocation mapping

      - IPV4-POOL is the public IPv4 address pool to be shared by
        aplusp-lite customers. In this document the first address of
        this pool is the network address.
      - TLI-MASK is the mask used for dividing the transport layer
        identifiers associated with each public IPv4 address in the
        IPV4-POOL into equal sized none-overlapping sets. These sets are
        then assigned to different customers to share the same public
        IPv4 address. In this document the first TLI set is the set
        started with 0.
      - PREFIX is the IPv6 address space taken from the one allocated to
        a given Service Provider, and is to be delegated to customers
        with aplusp-lite device.

   The rationale behind Figure 2 is: If the M'th TLI set of the N'th
   IPv4 address in IPV4-POOL is allocated to a customer, the IPv6 prefix
   [PREFIX][N][M], represented as DG-PREFIX hereafter, must be assigned
   to that customer accordingly, and vice versa.

   In the DG-PREFIX, both N and M start counting from 0, N occupies the
   same number of bits as the variable bits of the IPv4 address in the



Z. Xiaoyu              Expires November 27, 2010                [Page 5]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


   pool, and M occupies the same number of bits as the value of TLI-
   MASK. DG-PREFIX is then able to be deduced from IPv4 address and TLI
   information, which is essential for the IGF to determine the IPv6
   address of the appropriate customer where the IPv4 packet under
   processing should be forwarded to.

   The DG-PREFIX should be shorter than or equal to 64. In the former
   case, all 1s are appended to the DG-PREFIX to form a 64 bits prefix.
   The 64 bits prefix is dedicated used for aplusp-lite IPv4-in-IPv6
   encapsulation, represented as AL-PREFIX.

   The IPv6 address of the tunnel endpoints used for IPv4-in-IPv6
   encapsulation, represented as ENC-ADDR hereafter, is formed through
   appending any valid IPv6 interface identifier to the calculated AL-
   PREFIX. It is recommended to use a randomized identifier generated
   through the algorithm defined in [RFC4941], represented as RAND-IID
   hereafter. The final ENC-ADDR format is depicted in Figure 3.

           0                         63                   127
           +--------+---+---+- - - - -+---------------------+
           | PREFIX | N | M | All 1s  |      RAND-IID       |
           +--------+---+---+- - - - -+---------------------+
           |   DG-PREFIX    |                               |
           +----------------+---------+                     |
           |         AL-PREFIX        |                     |
           +--------------------------+---------------------+
           |                      ENC-ADDR                  |
           +------------------------------------------------+

              Figure 3 IPv6 address used for encapsulation

   Take the entry provided in Figure 2 as example, if the TLI set [1024-
   2047] along with the IPv4 address 192.0.2.2 is allocated to an
   aplusp-lite customer, the IPv6 address used for IPv4-in-IPv6
   encapsulation can be calculated as following:

      - 192.0.2.2 is the 3rd address of the IPV4-POOL, so N=2 and
        occupies 8 bits (the least significant 8 bits of the IPv4
        address in this pool are variable).
      - TLI set [1024-2047] is the 2nd set associated with the address,
        so M=1 and occupies 6 bits (TLI-MASK is 6 bits).
      - Append 8 bits with value 2 and 6 bits with value 1 to the PREFIX
        (2001:DB8::/42), the final prefix DG-PREFIX is
        2001:DB8:0000:8100::/56 (56=42+8+6).
      - Add 8 bits 1s padding to DG-PREFIX, the final AL-PREFIX is
        2001:DB8:0000:81FF::/64.
      - Add the randomized interface identifier to AL-PREFIX, the ENC-
        ADDR is calculated as 2001:DB8:0000:81FF:[RAND-IID].



Z. Xiaoyu              Expires November 27, 2010                [Page 6]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


5.  IGF Behavior

   IGF is the interconnection point of ISP IPv6 network and the IPv4
   Internet, and is responsible for delivering the IPv4 traffic
   originated from the HGF to the IPv4 Internet (outgoing) through IPv4
   connectivity, and for delivering the IPv4 traffic destined to the
   shared public IPv4 address pool to appropriate HGF (incoming) through
   IPv4-in-IPv6 tunnel.

   A dedicated IPv6 prefix, represented as IGF-PREFIX hereafter, should
   be associated with an IGF. IPv6 traffic destined to this prefix
   should be routed to the associated IGF through IPv6 routing.

   The IPv6 address used to identify the IGF as IPv4-in-IPv6 tunnel end
   points, represented as IGF-ADDR hereafter, should be formed by
   appending any valid interface identifier to the IGF-PREFIX, and a
   randomized one as described in [RFC4941] is recommended.

   The IGF-ADDR can be provisioned to HGF through Point-to-Point
   Protocol (PPP) extensions or specific Dynamic Host Configuration
   Protocol (DHCP) options, in the similar way as [I-D.ietf-softwire-ds-
   lite-tunnel-option] and [I-D.boucadair-pppext-portrange-option].

5.1. Outgoing traffic process

   IPv4 traffic originated from HGF is encapsulated using IPv4-in-IPv6
   scheme and forwarded to IGF through IPv6 transfer capabilities. The
   IGF de-capsulates the encapsulated packet and forward it through
   IPv4.

5.2. Incoming traffic process

   Upon receipt of an IPv4 packet destined to a shared IPv4 address pool
   and for which the IGF is responsible, the IGF will encapsulate it
   into IPv6 and deliver it through IPv6 connectivity. The source IPv6
   address used for encapsulation is set to IGF-ADDR, and the
   destination is set to the ENC-ADDR that had been calculated by using
   the destination address and TLI contained in the IPv4 packet and
   through the algorithm described in Section 5.

5.3. Fragmentation process

   It should be noted that the TLI information is only contained in the
   first fragment of fragmented packets, and the IGF must record this
   information for processing subsequent fragments, like what a
   traditional NAT [RFC3022] will do.

5.4. Load balance and failover



Z. Xiaoyu              Expires November 27, 2010                [Page 7]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


   Since the mapping table provided in Figure 2 is statically defined
   and can be provisioned to all IGFs, a session can be handed over from
   one IGF to another without disruption.

   Each IGF can use its own IGF-PREFIX and announce itself as on the
   forwarding path of that prefix in IPv6 routing. The IGF can also
   announce itself as on the forwarding path of other IGF-PREFIX(es),
   but with higher routing metrics. The IPv6 routing is then able to
   forward the IPv4-in-IPv6 encapsulated packets to the appropriate IGF
   base on the destination IPv6 address and the routing metrics, thus
   load balancing can be achieved in a pre-defined manner.

   In case the IGF with lower metrics for an IGF-PREFIX is failed, the
   IPv6 routing will choose another one automatically, thus failover can
   be achieved also.

   All the IGFs can use the same IGF-PREFIX even with the same metrics,
   and let the IPv6 routing to choose appropriate one at per packet
   basis, thus to achieve pure routing based load balance and failover.
   It should be noted that in this case all the fragments of a
   fragmented packet should be processed by the same IGF, to avoid
   undesired retransmission. A function node dedicated for fragment
   processing can be employed to simplify the implementation.

6.  HGF Behavior

   In all aplusp based solutions including the one proposed in this
   document, both the shared public IPv4 address and available TLI set
   are provisioned to HGF, through Point-to-Point Protocol (PPP)
   extensions defined in [I-D.boucadair-pppext-portrange-option], or
   specific DHCP options. The HGF is responsible for performing NAT
   and/or ALG functions, as well as supporting NAT Traversal mechanisms
   such as [UPnP-IGD]. The HGF MAY also discover the IGF-PREFIX through
   DNS queries, as defined in [I-D.wing-behave-learn-prefix], and the
   IGF-ADDR is calculated from the discovered IGF-PREFIX through the
   same algorithm as IGF.

6.1. Outgoing traffic processing

   For IPv4-to-IPv4 outgoing communications, the HGF performs NAT using
   the IPv4 address and TLI set assigned to it, encapsulates the
   resulting IPv4 packet into an IPv6 one, and delivers it through IPv6
   connectivity. The destination IPv6 address used for encapsulation
   should be set to IGF-ADDR.

6.2. Incoming traffic processing

   Upon receipt of IPv4-in-IPv6 packet destined to the ENC-ADDR of this



Z. Xiaoyu              Expires November 27, 2010                [Page 8]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


   HGF, the HGF de-capsulates the packet and processes the resulting
   IPv4 packet as a traditional NAT [RFC3022], and finally delivers it
   using IPv4 to the appropriate internal host.

6.3. Fragmentation processing

   It should be noted that the IPv4-in-IPv6 encapsulation normally add
   40 bytes overload (basic IPv6 header) to the original packet, thus
   the result IPv6 packet may exceed the Maximum Transmission Unit (MTU)
   of the transmission path. To avoid unnecessary fragmentation, the HGF
   should adjust the application perceived MTU through participating
   Path MTU Discovery (PMTUD) [RFC1191] or modifying MSS parameter in
   TCP session setup stage.

6.4. Traffic optimization

   The IPv4/IPv6 address allocation mapping table as provided in TABLE I
   may also be provisioned to HGF. In this case the ENC-ADDR should be
   used as destination IPv6 address in encapsulation, and the IGF-ADDR
   is used only if the destination IPv4 address does not fall in any
   pool of the table. By employing this mechanism the IPv4-to-IPv4
   communications between aplusp-lite customers can be processed without
   the intervention of a IGF in the path.

7.  Security Considerations

   This document has the same security consideration as [I-D.ymbk-
   aplusp].

8.  IANA Considerations

   This document makes no request to IANA.

9.  Conclusions

   Based on the aplusp concept, this document proposed a new approach of
   delivering traffic destined to a shared public IPv4 address to the
   appropriate customer. The proposed approach only maintains few static
   states in the operator network, and is able to rely on IPv6 routing
   to achieve load balancing, failover and traffic path optimization.
   This approach allows for a high performance and reliable network
   service at low cost compared to NAT-based solutions. Furthermore, by
   keeping the NAT and ALG in customer premises, the end-to-end nature
   of Internet is preserved at customer basis, which can provide better
   compatibility to existing applications.

   It should be noted that the proposed approach brings some links
   between IPv4 and IPv6 addressing, which is somehow inflexible, and



Z. Xiaoyu              Expires November 27, 2010                [Page 9]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


   special cautions should be taken to avoid operational problems when
   designing the public IPv4 sharing plan and IPv6 allocation policy.

10.  References

10.1.  Normative References

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
   [I-D.boucadair-port-range]   Boucadair, M., Levis, P., Bajko, G., and
               T. Savolainen, "IPv4 Connectivity Access in the Context
               of IPv4 Address Exhaustion: Port Range based IP
               Architecture", draft-boucadair-port-range-02 (work in
               progress), July 2009.
   [I-D.ymbk-aplusp]   Maennel, O., Bush, R., Cittadini, L., and S.
               Bellovin, "The A+P Approach to the Broadband Provider
               IPv4 Address Shortage", draft-ymbk-aplusp-00 (work in
               progress), October 2008.
   [I-D.ietf-softwire-dual-stack-lite]   Durand, A., Droms, R.,
               Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual-
               stack lite broadband deployments post IPv4 exhaustion",
               draft-ietf-softwire-dual-stack-lite-01 (work in
               progress), July 2009.


10.2.  Informative References

   [RFC1191]   J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191,
               November 1990.
   [RFC2131]   Droms, R., "Dynamic Host Configuration Protocol",
               RFC 2131, March 1997.
   [RFC2473]   Conta, A. and Derring, S., "Generic Packet Tunneling in
               IPv6 Specification", RFC 2473, December 1998.
   [RFC2474]   Nichols, K., Blake, S., et, al., "Definition of the
               Differentiated Services Field (DS Field) in the IPv4 and
               IPv6 Headers", RFC 2474, December 1998.
   [RFC2663]   Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations",
               RFC 2663, August 1999.
   [RFC2993]   Hain, T., "Architectural Implications of NAT", RFC 2993,
               November 2000.
   [RFC3022]   P. Srisuresh and K. Egevang: "Traditional IP Network
               Address Translator (Traditional NAT)", RFC3022, January
               2001.
   [RFC4213]   Nordmark, E. and Gilligan, R., "Basic Transition
               Mechanisms for IPv6 Hosts and Routers", RFC4213, October
               2005.
   [RFC4787]   Jennings, C. and Audet, F. (Editors), "Network Address



Z. Xiaoyu              Expires November 27, 2010               [Page 10]


INTERNET DRAFT                aplusp-lite                   May 26, 2010


               Translation (NAT) Behavioral Requirements for Unicast
               UDP", RFC4787, January 2007.
   [RFC4941]   Narten, T., Draves, R., and S. Krishnan, "Privacy
               Extensions for Stateless Address Autoconfiguration in
               IPv6", RFC 4941, September 2007.
   [I-D.boucadair-dhcpv6-shared-address-option]   Boucadair, M., Levis,
               P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic
               Host Configuration Protocol(DHCPv6) Options for Shared IP
               Addresses Solutions", draft-boucadair-dhcpv6-shared-
               address-option-00 (work in progress), May 2009.
   [I-D.ietf-softwire-ds-lite-tunnel-option]   D. Hankins and T.
               Mrugalski: "Dynamic Host Configuration Protocol for IPv6
               (DHCPv6) Options for Dual-Stack Lite",
               http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-
               tunnel-option-02, March 2, 2010.
   [I-D.boucadair-pppext-portrange-option]   Boucadair, M., Levis, P.,
               Grimault, J., and A. Villefranque, "Port Range
               Configuration Options for PPP IPCP", draft-boucadair-
               pppext-portrange-option-01 (work in progress), July 2009.
   [I-D.dhankins-softwire-tunnel-option]   Hankins, D., "Dynamic Host
               Configuration Protocol Option for Softwires", draft-
               dhankins-softwire-tunnel-option-01 (work in progress),
               August 2008.
   [I-D.bajko-v6ops-port-restricted-ipaddr-assign]   Bajko, G. and T.
               Savolainen, "Port Restricted IP Address Assignment",
               draft-bajko-v6ops-port-restricted-ipaddr-assign-01 (work
               in progress), October 2008.
   [I-D.wing-behave-learn-prefix]   D. Wing: "Learn the IPv6 Prefix of a
               Network's IPv6/IPv4 Translator",
               http://tools.ietf.org/html/draft-wing-behave-learn-
               prefix-04, October 26, 2009.
   [UPnP-IGD]   UPnP Forum, "Universal Plug and Play Internet Gateway
               Device Standardized Gateway Device Protocol", September
               2006, <http://www.upnp.org/standardizeddcps/igd.asp>.



Author's Addresses


   Xiaoyu ZHAO
   France Telecom
   2 Science Institute South Rd., Haidian District,
   Beijing, 100190
   China

   Email: Xiaoyu.zhao@orange-ftgroup.com




Z. Xiaoyu              Expires November 27, 2010               [Page 11]


INTERNET DRAFT                aplusp-lite                   May 26, 2010





















































Z. Xiaoyu              Expires November 27, 2010               [Page 12]


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