| Network Working Group | I. Farrer |
| Internet-Draft | Deutsche Telekom AG |
| Intended status: Informational | A. Durand |
| Expires: April 23, 2013 | Juniper Networks |
| October 22, 2012 |
lw4over6 Deterministic Architecture
draft-farrer-softwire-lw4o6-deterministic-arch-01
This memo describes an architecture for implementing Lightweight 4over6 (lw4o6) in a scalable and resilient manner. This is achieved using characteristics which are inherent to lw4o6 and dynamic IP routing protocols.
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 [RFC2119].
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 23, 2013.
Copyright (c) 2012 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.
DS-Lite [RFC6333] is a solution to deal with the IPv4 exhaustion problem once an IPv6 access network is deployed. It enables unmodified IPv4 applications to access the IPv4 Internet over the IPv6 access network. In the DS-Lite architecture, global IPv4 addresses are shared amongst subscribers as the concentrator (AFTR) performs a Carrier-Grade NAT (CGN) function.
[I-D.cui-softwire-b4-translated-ds-lite] describes Lightweight 4over6, which extends the original DS-Lite model so that NAT is performed by the CPE and IPv4 address sharing is possible through the use of source port-restrictions. AFTRs which only implement the functionality required for lw4o6 (i.e. tunnel concentration without a CGN function) are referred to as lwAFTRs.
This memo provides an operational architecture for the deployment of Lightweight 4over6, offering scalability and high-availability whilst preserving the per-flow stateless nature of the solution.
The approach presented here is stateless and deterministic. It leverages the stateless properties of Lightweight 4over6 to offer a completely deterministic solution. The bindings between IPv4 addresses, ports and IPv6 addresses are pre-computed and stored identically in the lwAFTRs and DHCP servers. This allows for a very simple fail-over mechanism within a cluster of identically provisioned lwAFTRs.
The deterministic architecture is unsuited to per-flow stateful approaches such as DS-Lite, as by their nature, states are dynamically created / deleted and would need to be syncronised in real time between all of the AFTRs in a single cluster to function correctly. This syncronisation greatly increases the complexity of the AFTR and is not required by lwAFTRs.
In a large deployment, it makes sense to distribute the subscriber population into subscriber groups, managed by a single lwAFTR, or by many lwAFTRs grouped in a cluster. Topological considerations and geographical proximity may also be factors in the grouping of subscribers. The exact size of those groups depend on the capacity characteristics of the lwAFTRs and is out of scope for this memo.
Each subscriber group is assigned an IPv6 anycast address and a pool of IPv4 addresses which are common to all lwAFTRs in a cluster. The IPv4 pool must be sized to handle the subscriber population. No constraints are placed upon the addresses that are used for this pool, in that they can be taken from a single, contiguous block, multiple non-contiguous blocks or single IPv4 addresses as required by the operator.
The exact ratio subscribers to IPv4 addresses, (e.g. the average number of ports assigned per subscriber) is out of scope for this memo.
All lwAFTRs within a cluster are configured with identical lw4o6 parameters. In particular, they are configured with the same:
The DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6] server will provide each IPv6 CPE an IPv4 address and port range to use within its local NAT binding table. The DHCPv4 server uses the IPv6 address of the CPE as its identifier. As such, the DHCPv4 server contains a table for assigning a specific IPv4 address and ports based on the IPv6 address of the requesting CPE. To maintain the stateless nature of the architecture, DHCPv4 reservation based address assignment is recommended. The lease time for the IPv4 address is unimportant, although a long lease time (or even infinity) is recommended to reduce the number of DHCPv4 requests.
A similar table (containing the same address/port binding information) is also present on all lwAFTRs in the cluster.
The following table shows sample CPE configuration data for a subscriber group. In order for the system to function coherently, this data needs to be kept synchronised between all of the functional elements (lwAFTRs and DHCPv4o6 servers) serving the subscriber group.
+--------------+------------+----------+
| IPv6 address |IPv4 address|port-range|
+--------------+------------+----------+
|2001:db8::1 | 1.2.3.4 | 1000-1999|
|2001:0:1::2 | 1.2.3.4 | 2000-2999|
|2001:0:5::1 | 2.3.4.5 | 1500-3999|
+--------------+------------+----------+
Figure 1 DHCP4o6/lwAFTR Per-subscriber configuration table data example
This memo proposes a simple architecture to guarantee the synchronization of those mapping tables and rely on anycast IPv4 and IPv6 technologies to provide failover within the lwAFTRs in the same cluster.
The following diagram shows the architecture for the Lightweight 4over6 cluster deployment.
^
| To public Internet
Public IPv4 Address | (IPv4)
pool advertised into |
upstream routing |
by all lwAFTRs +-------+-------+
in cluster | |
| Upstream |
+- - - - - - - - - - >| IPv4 Anycast |
| +--+----+----+--+
| | |
| | | |
+---------------------+ | +---------------------+
| | | |
+----+--+-------+ +-------+ ------+ +-------+-------+
| | | | | |
| lw4o6 | | lw4o6 | | lw4o6 |
| lwAFTR1 | | lwAFTR2 | . . . . | lwAFTRn |
| | | | | |
+----+--+-------+ +-------+-------+ +-------+-------+
| | | |
+---------------------+ | +---------------------+
| | | |
| | |
| +--+----+----+--+
+- - - - - - - - - - >| |
| Downstream |
IPv6 tunnel end-point | IPv6 Anycast |
Anycast Address +-------+-------+
advertized into |
downstream routing |
by all lwAFTRS | To Initiator
in cluster | Access network
| (IPv6 only)
v
Figure 2 Lightweight 4over6 Cluster
To increase service availability, A simple way to achieve fail-over is to configure both the IPv6 tunnel end point address and the IPv4 address pool as anycast addresses on the lwAFTRs and announce these routes into the IGP run by the ISP, such as OSPF or IS-IS.
The number of lwAFTRs in a cluster provides the degree of redundancy of the solution. In practice, two lwAFTRs are expected to be sufficient in most cases.
lwAFTR functionality can be scaled by load balancing the encapsulation/decapsulation across multiple lwAFTRs in a cluster. Due to the commonality of configuration and stateless nature of the solution, any tunneled packet from any Initiator served by the cluster can arrive at any cluster member and will be processed in the same way. Likewise, for inbound packets originating in the IPv4 realm, a packet that arrives at any of the cluster member will be encapsulated and sent to the correct initiator.
Load balancing could be achieved using specific load balancing infrastructure to distribute the tunnels and inbound v4 traffic across the cluster. It is also possible to use the Equal Cost Multipath inherent in some routing protocols to achieve this.
In order to prevent out-of-sequence packets in the tunnelled traffic, a mechanism for forwarding all packets belonging to a single tunnel through the same cluster member should be used. An example of this would be a source/destination hashing algorithm such as [RFC2992] describes.
All CPEs belonging to the same group of subscribers need to receive the same tunnel end-point option (via DHCPv6). This will be set to the IPv6 anycast address of the lwAFTR cluster.
The DHCPv4 server uses the IPv6 address of the CPE as its index. In order to keep the overall service architecture flexible and adaptable, it is preferable that the CPE is configured using DHCPv6 out of a specific pool reserved by the ISP.
It is proposed that binding tables be pre-computed and stored statically on the lwAFTRs and the DHCPv4 servers. The method of creating the binding tables is out of the scope of this memo.
These tables are not expected to change regularly. Typical reasons for an update include adding or removing an IPv4 address block, or changing the size of IPv4 ports ranges available to each CPE.
To ensure continuous operation, binding tables have to be updated simultaneously across all lwAFTRs in a cluster by a mechanism such as netconf. It may also be necessary to reconfigure CPEs during this process (e.g. via a DHCPv6 reconifgure message). The details are out of scope for this memo.
It is recommended that the ISP predefines all IPv6 addresses and corresponding IPv4 addresses and port ranges for any given subscriber group.
If the ISP runs out of space within a subscriber group, another group is then defined. Cutomer CPEs can be migrated between different subscriber groups by alterning the CPE configuration over DHCP.
In some deployments, regulations require that IP addresses allocated to customers can be changed periodically or on demand to protect users privacy.
This can be achieve by rolling over the IPv6 addresses in the DHCPv6 server allocating IPv6 addresses to the CPE. If all subscribers within the subscriber group are allocated the same number of ports in IPv4, then the IPv6 to IPv4 address and port binding may remain the same, the IPv4 address and ports will then roll over automatically at the same time as the IPv6 addresses do.
[I-D.cui-softwire-b4-translated-ds-lite] states that when the IPv6 address of the lwB4 is changed, then DHCPv4over6 configuration process must be re-initiated.
None.
None.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2992] | Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000. |
| [RFC6333] | Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. |
| [I-D.cui-softwire-b4-translated-ds-lite] | Cui, Y, Wu, J, Wu, P, Sun, Q, Xie, C and C Zhou, "Lightweight 4over6 in access network", Internet-Draft draft-cui-softwire-b4-translated-ds-lite-01, July 2011. |
| [I-D.ietf-dhc-dhcpv4-over-ipv6] | Cui, Y, Wu, P, Wu, J and T Lemon, "DHCPv4 over IPv6 Transport", Internet-Draft draft-ietf-dhc-dhcpv4-over-ipv6-01, March 2012. |