Skip to main content

BFD Support DS-Lite
draft-tsou-bfd-ds-lite-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Tina Tsou (Ting ZOU)
Last updated 2012-03-05
RFC stream (None)
Formats
Additional resources
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-bfd-ds-lite-00
Internet Engineering Task Force                             T. Tsou, Ed.
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Informational                             March 5, 2012
Expires: September 5, 2012

                          BFD Support DS-Lite
                   draft-tsou-bfd-ds-lite-00

Abstract

   In DS-Lite, the tunnel is not associated with any state information,
   which makes it difficult to manage and diagnose.  Bidirectional
   Forwarding Detection (BFD) can be used in this case to detect the
   state of the IPv4-in-IPv6 tunnel by creating a BFD session between
   the DS-Lite CPE and the Address Family Transitional Router (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 August 30, 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 August 30, 2012                [Page 1]
Internet-Draft                 BFD DS-Lite                 February 2012

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  BFD for DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . 4
     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 August 30, 2012                [Page 2]
Internet-Draft                 BFD DS-Lite                 February 2012

1.  Introduction

   In DS-Lite [RFC6333], there is no status information about the IPv4-
   in-IPv6 tunnel; no keep-alive mechanism is available.  It is
   difficult to know whether the tunnle is up or down, which creates a
   problem for operation and maintenance.  Although administor can use
   ping to test the connectivity, that is not a commonly used keep-alive
   mechanism.

   BFD [RFC5880] is a mechanism intended to detect faults in the
   bidirectional path.  It is usually used in conjunction with
   applications like OSPF, IS-IS, etc, for fast fault recovery/fast re-
   route.

   BFD [RFC5880] can be used in DS-Lite, by creating a BFD session
   between the CPE and the AFTR to provide tunnel status information.
   If a fault is detected the CPE can try to create a DS-Lite tunnel
   with another AFTR and terminate the existing one, so as to continue
   network service.

   [I-D.vinokour-bfd-dhcp] proposes using a DHCP option to distribute
   BFD parameters to the 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, so that 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 (i.e., the DS-Lite B4).

   FQDN      Fully Qualified Domain Name

Tsou                     Expires August 30, 2012                [Page 3]
Internet-Draft                 BFD DS-Lite                 February 2012

3.  BFD for DS-Lite

3.1.  DS-Lite Scenario

   In DS-Lite [RFC6333], the BFD packet SHOULD be sent through an IPv4-
   in-IPv6 tunnel, as shown in Figure 1.  The IPv4 addresses of the CPE
   and AFTR SHOULD be the endpoints 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 set up a BFD session, the following parameters are
   needed, as shown in Section 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], the CPE WAN-side IPv4 address is a well-known
   address 192.0.0.2, and the AFTR's IPv4 address is 192.0.0.1, as
   defined in section 5.7 of [RFC6333].  Because all the CPEs and AFTRs
   use the same well-known IP addresses, IPv4 addresses are not
   sufficient for setting up a BFD session.  From the CPE's point of
   view, the 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 to manage it.  From the AFTR's point of view, a lot of
   CPEs with the same IPv4 address will setup BFD sessions with it, so
   in order to distinguish the CPEs, the AFTR needs to take account of
   both the IPv4 address and the IPv6 address of the CPE that
   establishes a BFD session.  [Editor's note - I think this isn't quite
   consistent with the following from Section 6 of RFC 5881:

Tsou                     Expires August 30, 2012                [Page 4]
Internet-Draft                 BFD DS-Lite                 February 2012

   "On a point-to-point link, the source address of a BFD Control packet
   MUST NOT be used to identify the session.  This means that the
   initial BFD packet MUST be accepted with any source address, and that
   subsequent BFD packets MUST be demultiplexed solely by the Your
   Discriminator field (as is always the case)."]

   [PTT - Should be a reference to RFC 5881 Section 3 here.]  When a CPE
   goes online and sets up a tunnel with an AFTR, then it should
   initiate a BFD session with the AFTR, generating a local
   discriminator, and send the first BFD packet to AFTR with peer
   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.

   The other parameters listed above can be negotiated by BFD signaling,
   and initial values can be configured on the 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, along with the well known CPE IPv4 address 192.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.  [PTT- should
   refer to RFC 5881 Section 4 for source and destination port
   settings.]

   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 in the CPE to AFTR direction, without any manual
   configuration.

   When the AFTR receives the first packet from a CPE, AFTR will get the
   IPv6 address and discriminator of the CPE, so that the AFTR can
   initiate the BFD session in the other direction and a similar
   discriminator negotiation can be carried out.

   The procedure to set up a BFD session is illustrated below:
   [Is this really necessary given that it is covered by RFC
   5880?]

Tsou                     Expires August 30, 2012                [Page 5]
Internet-Draft                 BFD DS-Lite                 February 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 the AFTR is sent to CPE via a DHCP option, as defined in
   [RFC6334].  Multiple IP addresses can be configured for an FQDN on
   the DNS server.  If BFD detects a fault on the link to an AFTR, the
   CPE can choose another AFTR address and use a different AFTR to
   provide network sevice.

Tsou                     Expires August 30, 2012                [Page 6]
Internet-Draft                 BFD DS-Lite                 February 2012

   If anycast is used for load balancing and failover, there might be an
   ICMP error message problem, that is, when a packet is sent from AFTR
   to CPE, one of the routers along the path 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.  [PTT - this has to do
   with DS-Lite, but not with BFD.  Off topic!]

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 faults in such a short time.  On the other hand, an AFTR may
   need to support tens of thousands of CPEs, which means the AFTR will
   need to support the same number of BFD sessions.  In order to meet
   performance requirements on the AFTR, it may be necessary to extend
   the time period between BFD packet transmissions 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], the CPE may not be directly connected to the
   AFTR; there may be other routers between them.  Then there are
   potential spoofing problems, as described in [RFC5883].  Hence
   cryptographic authentication should be used as described in
   [RFC5880].

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.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              June 2010.

   [RFC5882]  Katz, D. and D. Ward, "Generic Application of

Tsou                     Expires August 30, 2012                [Page 7]
Internet-Draft                 BFD DS-Lite                 February 2012

              Bidirectional Forwarding Detection (BFD)", RFC 5882,
              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.

   [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 August 30, 2012                [Page 8]