Simple Failover Mechanism for Lightweight 4over6
Author(s): Qiong Sun, Cong Liu, Yiu Lee
This memo specifies a simple mechanism for Lightweight AFTR (lwAFTR) to notify Lightweight B4 (lwB4) to initiate the recreation of the binding when lwAFTR does not have the subscriber mapping in the mapping table. This often happens at...
Softwire Working Group Y. Lee Internet-Draft Comcast Intended status: Informational Q. Sun Expires: January 16, 2014 China Telecom C. Liu Tsinghua University July 15, 2013 Simple Failover Mechanism for Lightweight 4over6 draft-lee-softwire-lw4over6-failover-01 Abstract This memo specifies a simple mechanism for Lightweight AFTR (lwAFTR) to notify Lightweight B4 (lwB4) to initiate the recreation of the binding when lwAFTR does not have the subscriber mapping in the mapping table. This often happens at failover the backup lwAFTR does not have the subscriber mapping information to process the packets between lwB4 and external IPv4 host. Requirements Language 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]. 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 January 16, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Lee, et al. Expires January 16, 2014 [Page 1] Internet-Draft lw4over6 Failover July 2013 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. Failover Use Case . . . . . . . . . . . . . . . . . . . . . . 3 3. Failover Setup Considerations . . . . . . . . . . . . . . . . 4 3.1. Backup lwAFTR Discovery Consideration . . . . . . . . . . 4 3.2. lwB4 IPv4 Prefix Management Consideration . . . . . . . . 5 3.3. lwB4 IPv4 Address Provisioning . . . . . . . . . . . . . . 6 3.3.1. DHCPv4-over-DHCPv6 . . . . . . . . . . . . . . . . . . 6 3.3.2. Port Control Protocol . . . . . . . . . . . . . . . . 6 4. Failover Trigger Mechanisms . . . . . . . . . . . . . . . . . 7 5. Control Message Trigger Failover . . . . . . . . . . . . . . . 7 5.1. Tunnel Concentrator Behavior . . . . . . . . . . . . . . . 7 5.2. Tunnel Initiator Behavior . . . . . . . . . . . . . . . . 8 6. Data Packet Trigger Failover . . . . . . . . . . . . . . . . . 8 6.1. Tunnel Concentrator Behavior . . . . . . . . . . . . . . . 8 6.2. Tunnel Initiator Behavior . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Lee, et al. Expires January 16, 2014 [Page 2] Internet-Draft lw4over6 Failover July 2013 1. Background Lightweight 4over6 [I-D.ietf-softwire-lw4over6] defines that Lightweight AFTR (lwAFTR) stores per subscriber binding. The subscriber binding entry is usually created when the Lightweight B4 (lwB4) successfully requested IPv4 resource from the provisioning system. lwAFTR could be in the provisioning path between lwB4 and the provisioning system. This allows lwAFTR to listen to the provisioning messages and create the binding on demand. The exact mechanism is out of scope. The AFTR's subscriber binding table is used to map the subscriber's IPv6 address to the IPv4 resource (i.e., full IPv4 address or restricted IPv4 address). Due to security reason, entries in the table are usually created after a successful lwB4 provisioning. This means the network knows the lwB4 and authorizes the lwAFTR to provide lightweight 4over6 services. Consider when the primary lwAFTR failed, the Backup lwAFTR might not have the binding entry in the table because the Backup lwAFTR was not in the original provisioning path. This requires the Backup lwAFTR to notify lwB4 to trigger provisioning request so that the Backup lwAFTR can create the binding entry. This memo defines two simple mechanisms to let the Backup lwAFTR to create the subscriber binding after failover. 2. Failover Use Case Consider a typical deployment model that a set of lwAFTRs were all provisioned with the same IPv6 anycast address. When lwB4 booted up, it sent a dhcpv4 request over dhcpv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] to the primary lwAFTR (e.g., lwAFTR1). lwAFTR1 created the subscriber binding and started providing lightweight 4over6 service. At some point lwAFTR1 failed. Network converged and the Backup lwAFTR (e.g., lwAFTR2) became the active lwAFTR serving the lwB4s previously served by lwAFTR1. However, when lwAFTR2 received an IPv6 packet sourced from the lwB4, lwAFTR2 would fail to perform decapsulation and forward the IPv4 packet because lwAFTR2 didn't have the subscriber binding in the table. In this use case there are four assumptions: 1. lwAFTR in the same failover group use the same IPv6 anycast address for the Softwire interface 2. The subscriber binding entry is created on-demand upon successfully lwB4 provisioning Lee, et al. Expires January 16, 2014 [Page 3] Internet-Draft lw4over6 Failover July 2013 3. IPv4 provisioning mechanism is dynamically required by the lwB4 4. IPv4 address used by the lwB4 is either static or dynamic In this memo, we only consider the failover scenario in deployments with these assumptions. Other deployments such as using static provisioning are out of scope. 3. Failover Setup Considerations To provide minimal impact to users during failover, there are some considerations: o Backup lwAFTR Discovery o lwB4 IPv4 Prefix Management o lwB4 IPv4 Address Provisioning 3.1. Backup lwAFTR Discovery Consideration During failover, fast service recovery relies on how fast the lwB4 to detect and discover the Backup lwAFTR. In this memo, we suppose lwAFTR serving a failover group will all use the same IPv6 anycast address for the softwire interface. When the Primary lwAFTR fails, lwB4 will rely on IP routing to discover the closest Backup lwAFTR. This mechanism does not require any pre-configuration in the lwB4. The time lwB4 to discover the Backup lwAFTR relies on how fast the routing protocol converges. When mulitple Primary (or Backup) lwAFTRs using the same anycast address, the intermediate routers can using Equal Cost Multi-Path (ECMP) to load-balancing session among the lwAFTR. [RFC6437] proposes to use IPV6 flow label for the load-balancing entropy, but this requires the lwB4 to generate the flow label. Since most existing routers support load-balancing by hashing of the three-tuple of IP header, we recommend to use this as entropy field for the load- balancing. Somebody may argue 3-tuple may not seem unique enough to randomize session in IPv4. But IPv6 address is 4 times longer than IPv4 address, it guarantees way better uniqueness for the hash. lwAFTR must stop announcing the anycast address when it no longer provides lightweight 4over6 service. This is critical to prevent lwB4's packets from reaching the failed lwAFTR. Lee, et al. Expires January 16, 2014 [Page 4] Internet-Draft lw4over6 Failover July 2013 3.2. lwB4 IPv4 Prefix Management Consideration Given service agreement, some users may expect their IPv4 addresses will not change due to failover. This is particular important for server applications which require to accept external connections using a given static IPv4 address. Others may accept dynamic IPv4 address which may change after failover. In reality, an operator may have a mixed scheme for both static and dynamic IPv4 prefixes. The business decision of IPv4 prefix management is out of scope of this memo. However, the decision will have impact in failover design. For the same failover group, operators usually have two choices to manage the IPv4 prefix for lwAFTR: Case 1: Each lwAFTR is given different IPv4 prefixes Case 2: All lwAFTR are given identical IPv4 prefixes Case 1 supports dynamic IPv4 scenario. lwB4 does not require to use the same IPv4 address after failover. Hence, both Primary and Backup lwAFTRs are advertising their own IPv4 prefixes. When Backup lwAFTR receives a packet sourcing from an unknown IPv6 address (i.e., fail to find a match in the subscriber binding table), it will silently drop the packet. Backup lwAFTR is not required to know the status of Primary lwAFTRs. In fact, both Primary and Backup lwAFTRs are running autonomously. Case 2 supports the static IPv4 scenario. lwB4 expects the IPv4 will stay unchanged during failover. When the Primary lwAFTR fails, the Backup lwAFTR will take over the IPv4 prefix and start accepting packets designated to that IPv4 prefix. This requirement implies the following steps: 1. Primary and Backup lwAFTRs are running dynamic routing protocol 2. Primary lwAFTR set the routing matrix higher than the Backup lwAFTR does for the serving IPv4 prefix 3. When Primary detects problem, it stops advertising the IPv4 prefix 4. Routing protocol converges and the Backup lwAFTR is the router announcing the IPv4 prefix The above steps requires the Primary and Backup lwAFTR must run dynamic routing protocol. At any given time, only the serving lwAFTR is the next-hop router of the IPv4 prefix. This implies the operator must manually configure the routing matrix of the IPv4 prefix so that Lee, et al. Expires January 16, 2014 [Page 5] Internet-Draft lw4over6 Failover July 2013 the Backup lwAFTR will be the next-hop only if the Primary lwAFTR withdraws announcing the prefix. In both cases, when the Backup lwAFTR receives the IPv4 packet, the Backup lwAFTR must identify the lw4over6 B4 and send the packet to the lwB4. This requires the Backup lwAFTR to know the subscriber binding. Section 4 will discuss more in details. 3.3. lwB4 IPv4 Address Provisioning When lwB4 starts up, it will need to acquire IPv4 resources. There are multiple ways to acquire IPv4 address and restricted port-set. In this memo, we make no assumption how to obtain the IPv4 resources. Given a provisioning method, there are implications when failover occurs. In this memo, we discuss failover impacts to DHCPv4-over- DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and PCP Port-Set [I-D.ietf-pcp-port-set]. 3.3.1. DHCPv4-over-DHCPv6 Operator may use DHCPv4 to provision IPv4 address to the lwB4. Since the access network is IPv6, the DHCPv4 messages must be encapsulated into DHCPv6 message to deliver between DHCP server and lwB4. In a typical deployment, the DHCP server is a centralized DHCP server and lwAFTR is the DHCP relay agent to relay the dhcp messages to the server over unicast. Rarely DHCP server will collocate with the lwAFTR to provision IPv4 resources to the lwB4. We consider the collocated DHCP server is out of scope. DHCPv6 client uses a link-scoped multicast [RFC3315] to communicate with neighboring relay agents and servers. If the Primary and Backup lwAFTRs are the lwB4's next-hop IPv6 routers, they must act as a dhcpv6 relay agent and listen to the DHCP multicast request. If they are not the next-hop IPv6 router, the next-hop router must relay the dhcp packet over unicast to the lwAFTR's anycast address. This will allow the Backup lwAFTR to receive the dhcp message and create the subscriber binding at failover. 3.3.2. Port Control Protocol Operator may also use PCP Port-set Option [I-D.ietf-pcp-port-set] to provision IPv4 address and port-set to the lwB4. In a typical deployment, PCP server [RFC6887] will collocate with lwAFTR, and the subscriber binding can be determined by the lwAFTR. The PCP request should be sent to the lwAFTR's anycast address. It is uncommon that PCP server will be centralized deployed in which the lwAFTR is the PCP proxy to relay PCP requests. We consider the centralized PCP server is out of scope in this document. Lee, et al. Expires January 16, 2014 [Page 6] Internet-Draft lw4over6 Failover July 2013 If the Primary and Backup lwAFTR are the lwB4's next-hop IPv6 routers, the PCP requests can be sent in the plain mode. However, if the lwAFTRs are not the lwB4's next-hop IPv6 routers and multiple Primary lwAFTRs are using anycast address to achieve ECMP load- balancing. When using EMCP load-balancing, it is possible that intermediate routers will perform 3-tuple hash on the plain PCP packets while doing 5-tuple hash for subsequent softwire traffic. This may result inconsistent path selection (e.g., PCP request may arrive in one Primary lwAFTR while softwire packets may arrive in a different Primary lwAFTR). Therefore, the PCP request SHOULD also been encapsulated into IPv6 tunnel and apply the same 3-tuple hash on the outer IPv6 header. This guarantees the same hash will be used for both PCP and Softwire packets. 4. Failover Trigger Mechanisms For Control Message Trigger Failover, when a lwAFTR receives an IPv6 packet from an unknown lwB4 from its tunnel interface, it sends an ICMP error message to the lwB4. When lwB4 receives the ICMP error message, it must send the provisioning request to the network to trigger the subscriber entry creation in the lwAFTR. For Data Packet Trigger Failover, when a lwAFTR receives a packet which contains an unknown lwB4 from its tunnel interface, it must validate the source IPv4 address whether it is assigned by the provisioning system to the user. The validation mechanism is deployment specific. If the lwAFTR is next-hop of the lwB4, DHCP Lease Query may be used to validate the IPv4 address. Other methods such as proprietary out-of-band verification may be used. After successfully validation, lwAFTR will create the binding entry. 5. Control Message Trigger Failover 5.1. Tunnel Concentrator Behavior When lwAFTR receives a packet in its tunnel interface: 1. It must check its subscriber binding table against the IPv6 source address of the encapsulated packet. 2. If an entry is found, forward the packet. 3. If an entry is not found, send an ICMPv6 Error Message (Type 1 Code 0) Lee, et al. Expires January 16, 2014 [Page 7] Internet-Draft lw4over6 Failover July 2013 5.2. Tunnel Initiator Behavior When lwB4 receives an ICMPv6 Error Message (Type 1 Code 0), it must start the provisioning mechanism to request IPv4 resource. lwB4 may be setup to receive external initiated sessions. This is important for the lwB4 to periodically verify the binding entry in the lwAFTR. Therefore, lwB4 must send packets (e.g. PING) periodically to the lwAFTR. 6. Data Packet Trigger Failover 6.1. Tunnel Concentrator Behavior When lwAFTR receives a packet in its tunnel interface: 1. It must check its subscriber binding table against the IPv6 source address of the encapsulated packet. 2. If an entry is found, forward the packet. 3. If an entry is not found, extract the IPv4 source address from the encapsulated packet. 4. Validate the IPv4 address is the IPv4 address provisioned to the user. The validation mechanism is out of scope. 5. Upon successful validation, create an entry in the subscriber binding table. 6.2. Tunnel Initiator Behavior lwB4 is transparent to the failover. lwB4 will continue to send packets to the backup lwAFTR. lwB4 may be setup to receive external initiated sessions. This is important for the lwB4 to periodically verify the binding entry in the lwAFTR. Therefore, lwB4 must send packets (e.g. PING) periodically to the lwAFTR. 7. IANA Considerations Lee, et al. Expires January 16, 2014 [Page 8] Internet-Draft lw4over6 Failover July 2013 8. Security Considerations TBD 9. Acknowledgements TBD 10. References 10.1. Normative References [I-D.ietf-softwire-lw4over6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", draft-ietf-softwire-lw4over6-00 (work in progress), April 2013. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-dhc-dhcpv4-over-dhcpv6] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-dhcpv4-over-dhcpv6-00 (work in progress), April 2013. [I-D.ietf-pcp-port-set] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", draft-ietf-pcp-port-set-02 (work in progress), July 2013. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC3315, July 2003. [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC6437, November 2011. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC6887, April 2013. Lee, et al. Expires January 16, 2014 [Page 9] Internet-Draft lw4over6 Failover July 2013 Authors' Addresses Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA Email: firstname.lastname@example.org Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100084 P.R. China Email: email@example.com Cong Liu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5822 Email: firstname.lastname@example.org Lee, et al. Expires January 16, 2014 [Page 10]