BFD Support DS-Lite
draft-tsou-softwire-bfd-ds-lite-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tina Tsou | ||
| Last updated | 2012-03-05 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tsou-softwire-bfd-ds-lite-00
Internet Engineering Task Force T. Tsou, Ed.
Internet-Draft Huawei Technologies (USA)
Intended status: Informational March 5, 2012
Expires: September 7, 2012
BFD Support DS-Lite
draft-tsou-softwire-bfd-ds-lite-00
Abstract
In DS-Lite, there is no state information of the tunnel, which make
it difficult to mange and diagnose. BFD can be used in this case to
detect the state of the IPv4-in-IPv6 tunnel by creating BFD session
between CPE and AFTR.
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 September 7, 2012.
Copyright Notice
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.
Tsou Expires September 7, 2012 [Page 1]
Internet-Draft BFD DS-Lite March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BFD for DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. DS-Lite Scenario . . . . . . . . . . . . . . . . . . . . . 4
3.2. Parameters for BFD . . . . . . . . . . . . . . . . . . . . 4
3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Failover . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Implementation Considerations . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Tsou Expires September 7, 2012 [Page 2]
Internet-Draft BFD DS-Lite March 2012
1. Introduction
In DS-Lite [RFC6333], there is no status information about the IPv4-
in-IPv6 tunnel, no keep-alive mechanism available, it is difficult to
know whether the tunnle is up or down, which causes trouble to
operation and maintenance. Although administor can use ping to test
the connectivity, but that is not a commonly used keep-alive
mechanism.
BFD [RFC5880] is a mechanism intended to detect faults in the
bidirectional path. It is uaually used in conjunction with
applications like OSPF, IS-IS, etc, for fast fault recover -- fast
re-route.
BFD [RFC5880] can be used in DS-Lite, creating BFD session between
CPE and AFTR, to provide tunnel status information. If a fault is
detected CPE can try to create DS-Lite tunnel with another AFTR, and
terminate the existing one, so as to continue network service.
[I-D.vinokour-bfd-dhcp] proposes using DHCP option to distribute BFD
parameters to CPE. But in case of DS-Lite, some of the key BFD
parameters are already available, e.g. peer ip address is already
available, and other parameters can be negotiated by BFD signaling,
or statically configured, no extra DHCP option(s) need to be defined.
1.1. 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 [RFC2119].
2. Terminology
BFD: Bidirectional Forwarding Detection.
AFTR: Address Family Transition Router.
CPE: Customer Premise Equipment.
FQDN Fully Qualified Domain Name
3. BFD for DS-Lite
Tsou Expires September 7, 2012 [Page 3]
Internet-Draft BFD DS-Lite March 2012
3.1. DS-Lite Scenario
In DS-Lite [RFC6333], BFD packet SHOULD be sent through IPv6 tunnel,
as shown Figure 1. The IPv4 address of CPE and AFTR SHOULD be the
endpoint of a BFD session.
+--------------+ +--------------+
+-----+ | | +------+ | |
| |-----+--------------+-----| | | |
| CPE | IPv6 Tunnel | AFTR |-----| IPv4 Network |
| |-----+--------------+-----| | | |
+-----+ | IPv6 Network | +------+ | |
192.0.0.2 +--------------+ 192.0.0.1 +--------------+
Figure 1: DS-Lite Scenario
3.2. Parameters for BFD
In order to setup a BFD session, the following parameters are needed,
as shown in session 4.1 of [RFC5880]:
o Peer IP address
o My Discriminator
o Your Discriminator
o Desired Min TX Interval
o Required Min RX Interval
o Required Min Echo RX Interval
In DS-Lite [RFC6334], CPE WAN port IPv4 address is a well known
address 192.0.0.2, and AFTR's IPv4 address is 192.0.0.1, as defined
in section 5.7 of [RFC6333]. Because all the CPEs and AFTRs are
using well known IP address, IPv4 address is not suffient for setting
up a BFD session. From the CPE's point of view, CPE needs to create
an IPv6 tunnel to an AFTR so as to get network connectivity to the
AFTR, and send IPv4 BFD packets through the tunnel. From the AFTR's
point of view, a lot of CPEs with the same IPv4 address will setup
BFD session with itself, in order to distinguish the CPEs, AFTR needs
to combine both the IPv4 address and the IPv6 address of a CPE with a
BFD session.
When a CPE gets online, set up a tunnel with a AFTR, then it should
iniitate a BFD session with the AFTR, generating a local
discriminator, and send the first BFD packet to AFTR with peer
Tsou Expires September 7, 2012 [Page 4]
Internet-Draft BFD DS-Lite March 2012
discriminator set to zero; when receiving the first BFD packet from
CPE, AFTR should get a local discriminator and put it in the response
BFD packet to the CPE.
Other parameters can be negotiated by BFD signaling; and initial
values can be set on CPE and AFTR.
3.3. Procedures
In DS-Lite [RFC6333], When a CPE gets online, it will be assigned an
IPv6 prefix/address, and also the FQDN of the AFTR, as defined in
[RFC6334]. The CPE will create an IPv6 tunnel to the AFTR, With
which, and also the well know CPE IPv4 address 192.168.0.0.2 and AFTR
IPv4 address 192.0.0.1, the CPE can initiate a BFD session to the
AFTR. BFD packets will be sent through DS-Lite tunnel.
When sending out the first BFD packet, the CPE can generate a unique
local discriminator, and set the remote discriminator to zero. When
the AFTR receive the first BFD packet from a CPE, the AFTR will also
generate a corresponding local discriminator, and put it in the
response packet to the CPE. This will finish the discriminator
negotiation, without any manual configuration.
When the AFTR receive the first packet from a CPE, AFTR will get the
IPv6 address and discriminator of the CPE, then AFTR can BFD session
of the other direction.
The procedures of setting up a BFD session is shown below:
Tsou Expires September 7, 2012 [Page 5]
Internet-Draft BFD DS-Lite March 2012
CPE AFTR
| (CPE get online) |
| BFD DOWN |
| -------------------------------------------------------> |
| local discriminator = 1234 |
| remote discriminator = 0 |
| |
| BFD INIT |
| <------------------------------------------------------- |
| local discriminator = 5678 |
| remote discirminator = 1234 |
| |
| BFD UP |
| -------------------------------------------------------> |
| local discriminator = 1234 |
| remote discriminator = 5678 |
| |
| (BFD session in one direction is finished) |
| (Start BFD session in the other direction) |
| |
| BFD DOWN |
| <------------------------------------------------------- |
| local discriminator = 5678 |
| remote discriminator = 1234 |
| |
| BFD INIT |
| -------------------------------------------------------> |
| local discriminator = 1234 |
| remote discriminator = 5678 |
| |
| BFD UP |
| <------------------------------------------------------- |
| local discriminator = 5678 |
| remote discriminator = 1234 |
| |
| (Bidirectional session created!) |
| |
Figure 2: BFD session setup procedures
3.4. Failover
The FQDN of AFTR is sent to CPE via DHCP option, as defined in
[RFC6334]. Multiple IP addresses can be configured for a FQDN on the
DNS server. If BFD detect a fault on the link to an AFTR, CPE can
choose another AFTR address, use a different AFTR to provide network
sevice.
Tsou Expires September 7, 2012 [Page 6]
Internet-Draft BFD DS-Lite March 2012
If anycast is used for loadbalance and failover, there might be a
ICMP error message problem, that is, when a packet is sent from AFTR
to CPE, one of the routers between them may generate a error ICMP
message, e.g. packet too big, and the error message is not sent back
to the source AFTR, but sent to another AFTR.
3.5. Implementation Considerations
BFD is usually used for quick fault detection, at a very small time
scale, e.g. milliseconds. But in DS-Lite, it may not be necessary to
detect fault in such a short time. On the other hand, an AFTR may
need to tens of thousand CPEs, which means the AFTR will need to
support the same number of BFD sessions. In order to performance
requirement to the AFTR, it may be necessary to reduce the time
period between BFD packets transmission to a longer time, e.g. 10s or
30s.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
In DS-Lite [RFC6333], CPE may not be directly connected to AFTR,
there may be other routers between them. Then there are potential
spoofing problem, as described in [RFC5883], cryptographic
authentication should be used.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
Tsou Expires September 7, 2012 [Page 7]
Internet-Draft BFD DS-Lite March 2012
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
6.2. Informative References
[I-D.vinokour-bfd-dhcp]
Vinokour, V., "Configuring BFD with DHCP and Other
Musings", May 2008.
Author's Address
Tina Tsou (editor)
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara CA 95050
USA
Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com
Tsou Expires September 7, 2012 [Page 8]