Internet DRAFT - draft-lee-softwire-lw4over6-failover

draft-lee-softwire-lw4over6-failover






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

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.

   [RFC2119]  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)", RFC 3315, July 2003.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437, November 2011.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              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: yiu_lee@cable.comcast.com


   Qiong Sun
   China Telecom
   Room 708, No.118, Xizhimennei Street
   Beijing  100084
   P.R. China

   Email: sunqiong@ctbri.com.cn


   Cong Liu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6278-5822
   Email: gnocuil@gmail.com























Lee, et al.             Expires January 16, 2014               [Page 10]