Unified IPv4-in-IPv6 Softwire CPE
draft-ietf-softwire-unified-cpe-02

Softwire WG                                                 M. Boucadair
Internet-Draft                                            France Telecom
Intended status: Standards Track                               I. Farrer
Expires: April 21, 2016                                 Deutsche Telekom
                                                        October 19, 2015

                   Unified IPv4-in-IPv6 Softwire CPE
                   draft-ietf-softwire-unified-cpe-02

Abstract

   In IPv6-only provider networks, transporting IPv4 packets
   encapsulated in IPv6 is a common solution to the problem of IPv4
   service continuity.  A number of differing functional approaches have
   been developed for this, each having their own specific
   characteristics.  As these approaches share a similar functional
   architecture and use the same data plane mechanisms, this memo
   describes a specification whereby a single CPE can interwork with all
   of the standardized and proposed approaches to providing encapsulated
   IPv4 in IPv6 services.

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

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 April 21, 2016.

Boucadair & Farrer       Expires April 21, 2016                 [Page 1]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  S46 Priority Option . . . . . . . . . . . . . . . . . . .   4
     1.3.  Client Behavior . . . . . . . . . . . . . . . . . . . . .   5
     1.4.  Server Behavior . . . . . . . . . . . . . . . . . . . . .   6
     1.5.  S46 Mechanisms and their Identifying Option Codes . . . .   6
   2.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   IPv4 service continuity is one of the major technical challenges
   which must be considered during IPv6 migration.  Over the past few
   years, a number of different approaches have been developed to assist
   with this problem.  These approaches, referred to as 'S46 mechanisms'
   in this document, exist in order to meet the particular deployment,
   scaling, addressing and other requirements of different service
   provider's networks.

   A common feature shared between all of the differing modes is the
   integration of softwire tunnel end-point functionality into the CPE
   router.  Due to this inherent data plane similarity, a single CPE may
   be capable of supporting several different approaches.  Users may
   also wish to configure a specific mode of operation.

Boucadair & Farrer       Expires April 21, 2016                 [Page 2]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   A service provider's network may also have more than one S46
   mechanism enabled in order to support a diverse CPE population with
   differing client functionality, such as during a migration between
   mechanisms or where services require specific supporting softwire
   architectures.

   For softwire based services to be successfully established, it is
   essential that the customer end-node, the service provider end-node
   and provisioning systems are able to indicate their capabilities and
   preferred mode of operation.

   A number of DHCPv6 options for the provisioning of softwires have
   been standardized:

   RFC6333  Defines DHCPv6 option 64 for configuring B4 elements with
      the IPv6 address of the AFTR.
   RFC7341  Defines DHCPv6 option 88 for configuring the address of a
      DHCPv4 over DHCPv6 server, which can then be used by a softwire
      client for obtaining further configuration.
   RFC7598  Defines DHCPv6 options 94, 95 and 96 for provisioning MAP-E,
      MAP-T and lw4o6 respectively.

   This document describes a DHCPv6 based prioritisation method whereby
   a CPE which supports several S46 mechanisms and receives
   configuration for more than one can prioritise which mechanism to
   use.  The method requires no server side logic to be implemented and
   only uses a simple S46 mechanism prioritization to be implemented in
   the CPE.

   The prioritisation method as described here does not provide
   redundancy between S46 mechanisms for the client.  I.e.  If the
   highest priority S46 mechanism which has been provisioned to the
   client is not available for any reason, the means for identifying
   this and falling back to the S46 mechanism with the next highest
   priority is not in the scope of this document.

1.1.  Rationale

   The following rationale has been adopted for this document:

   (1)  Simplify solution migration paths: Define unified CPE behavior,
        allowing for smooth migration between the different s46
        mechanisms.
   (2)  Deterministic CPE co-existence behavior: Specify the behavior
        when several S46 mechanisms co-exist in the CPE.
   (3)  Deterministic service provider co-existence behavior: Specify
        the behavior when several modes co-exist in the service
        providers network.

Boucadair & Farrer       Expires April 21, 2016                 [Page 3]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   (4)  Re-usability: Maximize the re-use of existing functional blocks
        including tunnel end-points, port restricted NAPT44, forwarding
        behavior, etc.
   (5)  Solution agnostic: Adopt neutral terminology and avoid (as far
        as possible) overloading the document with solution-specific
        terms.
   (6)  Flexibility: Allow operators to compile CPE software only for
        the mode(s) necessary for their chosen deployment context(s).
   (7)  Simplicity: Provide a model that allows operators to only
        implement the specific mode(s) that they require without the
        additional complexity of unneeded modes.

1.2.  S46 Priority Option

   The S46 Priority Option is used to convey a priority order of IPv4
   service continuity mechanisms.  Figure 1 shows the format of the S46
   Priority option.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   OPTION_V6_S46_PRIORITY      |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        s46-option-code        |  s46-priority   |      option-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |code |        s46-option-code        |  s46-priority   |       .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: S46 Priority Option

   o  option-code: OPTION_V6_S46_PRIORITY (TBD)
   o  option-length: variable-length
   o  s46-option-code: 16-bits long IANA registered option code of the
      DHCPv6 option which is used to identify the softwire mechanism.
   o  priority: 8-bit integer indicating the priority of the mechanism.

   The fields s46_option_code and s46_priority are a key-value pair.
   Both fields MUST appear together sequentially.

   Each defined s46_option_code, and its associated s46_priority field
   MAY appear exactly once within the list of S46 option codes.  The
   option MUST contain at least two s46_option_code/s46_priority pairs,
   and MAY contain more as necessary.

   DISCUSSION: The prioritisation field is included to offer additional
   flexibility, making it possible to give the same weight to two or

Boucadair & Farrer       Expires April 21, 2016                 [Page 4]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   more mechanisms to instruct the client to configure them
   simultaneously.  If this is not seen to be a requirement (i.e. only
   one active mechanism is needed), then the prioritisation field could
   be removed.  The prioritization would then be done as an ordered list
   of option codes as described in section 17 of RFC7227.

   The s46_priority field associated with each s46_option_code is an
   8-bit integer, which tells the recipient the priority of the
   associated S46 mechanism.  A higher s46_priority is taken by the
   client to be a higher priority.  If two or more s46_option_codes with
   the same s46_priority value are received, then the client should
   attempt to configure these mechanisms simultaneously.  As this
   document is solely concerned with provisioning, issues related to the
   client's usage of multiple active softwires are out of scope.

1.3.  Client Behavior

   Clients MAY request option OPTION_V6_S46_PRIORITY, as defined in
   [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7.
   As a convenience to the reader, we mention here that the client
   includes requested option codes in the Option Request Option.

   Upon receipt of a DHCPv6 Offer message from the server containing
   OPTION_V6_S46_PRIORITY the client performs the following steps:

   1.  Check the contents of the DHCPv6 message for options containing
       valid S46 mechanism configuration.  A candidate list of possible
       S46 mechanisms is created from these option codes.
   2.  Check the contents of OPTION_V6_S46_PRIORITY for the DHCPv6
       option codes contained in the included s46_option_code fields and
       their related s46_priorities.  From this, an S46 mechanism
       priority list is created, ordered from highest to lowest
       s46_priority value.
   3.  Sequentially check the priority list against the candidate list
       until a match is found.
   4.  When a match is found, the client SHOULD configure the resulting
       S46 mechanism.  Configuration for other S46 mechanisms MUST be
       discarded.

   In the event that no match is found between the priority list and the
   candidate list, the client MAY proceed with configuring one or more
   of the provisioned S46 softwire mechanism(s).  In this case, which
   mechanism(s) are chosen by the client is implementation specific and
   not defined here.

   In the event that the client receives OPTION_V6_S46_PRIORITY with the
   following errors, it MUST be discarded:

Boucadair & Farrer       Expires April 21, 2016                 [Page 5]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   o  Less than two instances of s46_option_code/s46_priority key-value
      pair.
   o  Two s46_option_code fields with the same value.

   If an invalid OPTION_V6_S46_PRIORITY option is received, the client
   MAY proceed with configuring the provisioned S46 mechanisms as if
   OPTION_V6_S46_PRIORITY had not been received.

   In the event that a client receives an OPTION_V6_S46_PRIORITY option
   containing a value in s46-option-code representing an S46 mechanism
   which the client has not implemented, this is not considered an
   error.

1.4.  Server Behavior

   Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
   regards to option assignment.  As a convenience to the reader, we
   mention here that the server will send option foo only if configured
   with specific values for foo and if the client requested it.

   Option OPTION_V6_S46_PRIORITY is a singleton.  Servers MUST NOT send
   more than one instance of the OPTION_V6_S46_PRIORITY option.

1.5.  S46 Mechanisms and their Identifying Option Codes

   The following table shows the currently defined option codes and the
   S46 mechanisms which they represent.  This list is complete at the
   time of writing, but should not be considered definitive as new S46
   mechanisms may be defined in the future.

             +-------------+--------------------+-----------+
             | Option Code |   S46 Mechanism    | Reference |
             +-------------+--------------------+-----------+
             | 64          |      DS-Lite       |  RFC6334  |
             | 88          | DHCPv6 over DHCPv6 |  RFC7341  |
             | 94          |       MAP-E        |  RFC7598  |
             | 95          |       MAP-T        |  RFC7598  |
             | 96          | Lightweight 4over6 |  RFC7598  |
             +-------------+--------------------+-----------+

             Table 1: DHCPv6 Option to S46 Mechanism Mappings

2.  Security Considerations

   Security considerations discussed in [RFC6334] and [RFC7598] apply
   for this document.

Boucadair & Farrer       Expires April 21, 2016                 [Page 6]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   Misbehaving intermediate nodes may alter the content of the S46
   option.  This may lead to setting a different IPv4 service continuity
   mechanism than the one initially preferred by the network side.

3.  IANA Considerations

   IANA is kindly requested to allocate the following DHCPv6 option
   code:

      TBD for OPTION_V6_S46_PRIORITY

   All values should be added to the DHCPv6 option code space defined in
   Section 24.3 of [RFC3315].

4.  Acknowledgements

   Many thanks to O.  Troan, S.  Barth.  A.  Yourtchenko, B.  Volz T.
   Mrugalski for their input and suggestions.

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <http://www.rfc-editor.org/info/rfc2473>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <http://www.rfc-editor.org/info/rfc6052>.

Boucadair & Farrer       Expires April 21, 2016                 [Page 7]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
              <http://www.rfc-editor.org/info/rfc6333>.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, DOI 10.17487/RFC6334, August 2011,
              <http://www.rfc-editor.org/info/rfc6334>.

   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the Dual-
              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
              July 2015, <http://www.rfc-editor.org/info/rfc7596>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/RFC7597, July 2015,
              <http://www.rfc-editor.org/info/rfc7597>.

   [RFC7598]  Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
              Configuration of Softwire Address and Port-Mapped
              Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
              <http://www.rfc-editor.org/info/rfc7598>.

5.2.  Informative References

   [RFC7040]  Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4-over-IPv6 Access Network", RFC 7040,
              DOI 10.17487/RFC7040, November 2013,
              <http://www.rfc-editor.org/info/rfc7040>.

   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
              RFC 7341, DOI 10.17487/RFC7341, August 2014,
              <http://www.rfc-editor.org/info/rfc7341>.

Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes
   France

   Email: mohamed.boucadair@orange.com

Boucadair & Farrer       Expires April 21, 2016                 [Page 8]
Internet-Draft   Generic v4inv6 CPE Provisioning Profile    October 2015

   Ian Farrer
   Deutsche Telekom
   Germany

   Email: ian.farrer@telekom.de

Boucadair & Farrer       Expires April 21, 2016                 [Page 9]