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]
