Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
draft-zhou-dime-4over6-provisioning-03

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Cathy Zhou  , Tom Taylor  , Qiong Sun  , Mohamed Boucadair 
Last updated 2014-07-21
Stream (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                                  C. Zhou
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                               T. Taylor
Expires: January 22, 2015                           PT Taylor Consulting
                                                                  Q. Sun
                                                           China Telecom
                                                            M. Boucadair
                                                          France Telecom
                                                           July 21, 2014

  Attribute-Value Pairs For Provisioning Customer Equipment Supporting
                 IPv4-Over-IPv6 Transitional Solutions
                 draft-zhou-dime-4over6-provisioning-03

Abstract

   During the transition from IPv4 to IPv6, customer equipment may have
   to support one of the various transition methods that have been or
   are currently being defined for carrying IPv4 packets over IPv6.
   Work is currently in progress to enumerate the information that needs
   to be provisioned on a customer edge router to support a list of
   transition techniques based on tunneling IPv4 in IPv6, with a view to
   defining reusable components for a reasonable transition path between
   these techniques.  To the extent that the provisioning is done
   dynamically, AAA support is needed to provide the information to the
   network server responsible for passing the information to the
   customer equipment.  This document specifies Diameter attribute-value
   pairs to be used for that purpose.

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 22, 2015.

Zhou, et al.            Expires January 22, 2015                [Page 1]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

Copyright Notice

   Copyright (c) 2014 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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Description of the Parameters Required By Each Transition
       Method  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Parameters For Dual-Stack Lite  . . . . . . . . . . . . .   4
     2.2.  Light Weight IPv4 Over IPv6 (LW4over6)  . . . . . . . . .   4
     2.3.  Mapping of Address and Port with Encapsulation (MAP-E)  .   5
     2.4.  Summary and Discussion  . . . . . . . . . . . . . . . . .   6
   3.  Derived AVP Data Formats: AddressOrPrefix . . . . . . . . . .   7
   4.  Attribute-Value Pair Definitions  . . . . . . . . . . . . . .   7
     4.1.  Border-Router-Name AVP  . . . . . . . . . . . . . . . . .   7
     4.2.  Tunnel-Source-Pref-Or-Addr AVP  . . . . . . . . . . . . .   8
     4.3.  Port-Set-Identifier . . . . . . . . . . . . . . . . . . .   8
     4.4.  LW4over6-Binding  . . . . . . . . . . . . . . . . . . . .   8
     4.5.  MAP-E-Attributes  . . . . . . . . . . . . . . . . . . . .   9
     4.6.  MAP-Mapping-Rule  . . . . . . . . . . . . . . . . . . . .  10
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   A number of transition technologies have been or are being defined to
   allow IPv4 packets to pass between hosts and IPv4 networks over an
   intervening IPv6 network while minimizing the number of public IPv4
   addresses that need to be consumed by the hosts.  Different operators
   will deploy different technologies, and sometimes one operator will

Zhou, et al.            Expires January 22, 2015                [Page 2]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   use more than one technology, depending on what is supported by the
   available equipment and upon other factors both technical and
   economic.

   Each technique requires the provisioning of some subscriber-specific
   information on the customer edge device.  The provisioning may be by
   DHCP or by some other method.  This document is indifferent to the
   specific provisioning technique used, but assumes a deployment in
   which that information is managed by AAA (Authentication,
   Authorization, and Accounting) servers.  It further assumes that this
   information is delivered to intermediate network nodes for onward
   provisioning using the Diameter protocol [RFC6733].

   As described below, in the particular case where the Light Weight
   IPv4 Over IPv6 (LW4o6) [I-D.ietf-softwire-lw4over6] transition method
   has been deployed, per-subscriber-site information almost identical
   to that passed to the subscriber site [I-D.ietf-softwire-map-dhcp] or
   collected from it [I-D.fsc-softwire-dhcp4o6-saddr-opt] also needs to
   be delivered to the border router serving that site.  The Diameter
   protocol may be used for this purpose too.

   This document analyzes the information required to configure the
   customer edge equipment for the following set of transition methods:

   o  Dual-Stack Lite [RFC6333],

   o  Light Weight IPv4 Over IPv6 (LW4over6)
      [I-D.ietf-softwire-lw4over6], and

   o  Mapping of Address and Port with Encapsulation (MAP-E)
      [I-D.ietf-softwire-map].

   On the basis of that analysis it specifies a number of attribute-
   value pairs (AVPs) to allow the necessary subscriber-site-specific
   configuration information to be carried in Diameter.

   This document is intended to be complementary to documents such as
   [RFC6519], [I-D.sun-softwire-lw4over6-radext], and
   [I-D.ietf-softwire-map-radius] which provide RADIUS attributes to
   carry similar configuration information for the respective transition
   methods.  Reconciliation of the present document with these other
   documents is a work in progress.

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

Zhou, et al.            Expires January 22, 2015                [Page 3]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   The abbreviation "CE" denotes the equipment at the customer edge that
   terminates the customer end of an IPv6 transitional tunnel.  This
   will usually be a router, but could be a host directly connected to
   the network.

   The term "tunnel source address" is used to denote the IPv6 source
   address used in the outer header of packets sent from the CE through
   an LW4over6 transitional tunnel to the border router.

2.  Description of the Parameters Required By Each Transition Method

   This section reviews the parameters that need to be provisioned for
   each of the transition methods listed above.  This enumeration
   provides the justification for the AVPs defined in the next section.
   Since two of the three transition methods dealt with here are works
   in progress, this section is subject to modification in future
   versions.

   A means is required to indicate which transition method(s) a given
   subscriber is allowed to use.  The approach taken in this document is
   to specify grouped AVPs specific to LW4over6 and MAP-E.  The operator
   can control which of these two transition methods a given subscriber
   uses by ensuring that AAA passes only the grouped AVP relevant to
   that method.  A grouped AVP is unnecessary for Dual-Stack Lite, since
   (as the next section indicates) AAA has to provide only one
   parameter.  Hence the absence of either of the grouped AVPs indicates
   that the subscriber equipment will use Dual-Stack Lite.

2.1.  Parameters For Dual-Stack Lite

   Dual-Stack Lite is documented in [RFC6333].  The Basic Bridging
   BroadBand (B4) element at the customer premises needs to be
   provisioned with the IPv6 address of the AFTR (border router).
   Optionally, it could also be configured with the IPv4 address of the
   B4 interface facing the tunnel, where the default value in the
   absence of provisioning is 192.0.0.2 and valid values are 192.0.0.2
   through 192.0.0.7.  Provisioning this information through AAA is
   problematic because it is most likely used in a case where multiple
   B4 instances occupy the same device.  This document therefore assumes
   that the B4 interface address is determined by other means
   (implementation-dependent or static assignment).

2.2.  Light Weight IPv4 Over IPv6 (LW4over6)

   Light Weight IPv4 Over IPv6 (LW4over6) is documented in
   [I-D.ietf-softwire-lw4over6].  LW4over6 requires four parameters to
   be provisioned to the customer equipment:

Zhou, et al.            Expires January 22, 2015                [Page 4]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   o  IPv6 address of the border router.

   o  IPv6 prefix used by the CE to construct the tunnel source address.
      In the terminology of [I-D.ietf-softwire-lw4over6], this is the
      IPv6 Binding Prefix.

   o  an IPv4 address to be used on the external side of the CE; and

   o  if the IPv4 address is shared, a specification of the port set the
      subscriber site is allowed to use.

   As discussed in Section 4 of [I-D.ietf-softwire-lw4over6], it is
   necessary to synchronize this configuration with corresponding per-
   subscriber configuration at the border router.  The border router
   information consists of the same public IPv4 address and port set
   parameters that are passed to the CE, bound together with the full
   /128 IPv6 address (not just the Binding Prefix) configured as the
   tunnel source address at the CE.

   [I-D.fsc-softwire-dhcp4o6-saddr-opt] proposes a means whereby a
   DHCPv6 server can influence the choice of this address and collect it
   from the CE.  Depending on the provisioning architecture deployed in
   a given network, it is possible that the tunnel source address is
   passed to AAA as an intermediate step before the binding information
   is passed on to the border router.

2.3.  Mapping of Address and Port with Encapsulation (MAP-E)

   Mapping of Address and Port with Encapsulation (MAP-E) is described
   in [I-D.ietf-softwire-map].  MAP-E requires the provisioning of the
   following per-subscriber information at the customer edge device:

   o  the IPv6 address of one or more border routers;

   o  the unique End-user IPv6 prefix for the customer edge device;

   o  the Basic Mapping Rule for the customer edge device.  This
      includes the following parameters:

      *  the rule IPv6 prefix and length;

      *  the rule IPv4 prefix and length;

      *  the number of "Extended Address" (EA) bits included in the End-
         user IPv6 prefix;

      *  of those Extended Address bits, the number that precede the
         port set identifier.  The default value is 6.

Zhou, et al.            Expires January 22, 2015                [Page 5]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

      *  optionally, a specification of the port set the subscriber site
         is allowed to use if the EA bits do not convey it (final case
         of Section 5.2 of the MAP-E document).

   o  whether the device is to operate in mesh or hub-and-spoke mode;

   o  in mesh mode only, zero or more Forwarding Mapping Rules,
      described by the same set of parameters as the Basic Mapping Rule;

   As indicated in Section 5, bullet 1 of the MAP-E document, a MAP CE
   can be provisioned with multiple End-user IPv6 prefixes, each
   associated with its own Basic Mapping Rule.  This does not change the
   basic requirement for representation of the corresponding information
   in the form of Diameter AVPs, but adds a potential requirement for
   multiple instances of both types of AVP to be present.

   The border router needs to be configured with the superset of the
   Mapping Rules passed to the customer sites it serves.  Since this
   requirement does not require direct coordination with CE
   configuration in the way LW4over6 does, it is out of scope of the
   present document.

2.4.  Summary and Discussion

   It appears that one item is common to the different transition
   methods and the corresponding AVP to carry it can be reused:

   o  a representation of the IPv6 address of a border router;

   [RFC6519] sets a precedent for representation of the IPv6 address of
   a border router as an FQDN.  This can be dereferenced to one or more
   IP addresses by the provisioning system before being passed to the
   customer equipment, or left as an FQDN as it is in [RFC6334].

   The remaining requirements are transition-method-specific:

   o  for LW4over6, a representation of a binding between either the
      IPv6 Binding Prefix or a full /128 IPv6 address, a public IPv4
      address, and a port set identifier;

   o  for MAP-E, a representation of a Mapping Rule;

   o  for MAP-E, an indication of whether mesh mode or hub-and-spoke
      mode is to be used.

Zhou, et al.            Expires January 22, 2015                [Page 6]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

3.  Derived AVP Data Formats: AddressOrPrefix

   The above requirements involve IP addresses and prefixes in a number
   of contexts.  To simplify specification of these attributes, this
   section defines a new derived AVP data format, AddressOrPrefix,
   according to the rules given in Section 4.3 of [RFC6733].

   AddressOrPrefix

      The AddressOrPrefix data format is an extension of the Address
      data format defined in Section 4.3.1 of [RFC6733].  Like the
      Address data format, it is derived from the OctetString basic AVP
      format.  As well as an AddressType, it contains a PrefixLength
      field.  The detailed specification is as follows:

      *  As with the Address AVP, the first two octets represent the
         AddressType, which contains an Address Family, defined in
         [IANAADFAM].

      *  The next two octets are interpreted as a 16-bit unsigned
         integer representing the PrefixLength.  Valid values of
         PrefixLength are from 0 to 32 for IPv4 and from 0 to 128 for
         IPv6.  The value 0 is included in each range to allow for
         presentation of a "null prefix", the meaning of which must be
         defined by applications that use AVPs based on the
         AddressOrPrefix data format.

      *  The remaining octets present the prefix or address, most
         significant octet first.  If the prefix does not extend to an
         octet boundary, the low-order bits of the final octet are
         padded with zeroes.

4.  Attribute-Value Pair Definitions

   This section provides the specifications for the AVPs needed to meet
   the requirements summarized in Section 2.4.  Within the context of
   their usage, all of these AVPs MUST have the M bit set and the V bit
   cleared.

4.1.  Border-Router-Name AVP

   Following on the precedent set by [RFC6334] and [RFC6519], this
   document identifies a border router using an FQDN rather than an
   address.  The Border-Router-Name AVP (AVP Code TBD01) is of type
   OctetString.  The rules for encoding the FQDN are the same as those
   for the FQDN variant of the derived type DiameterIdentity
   (Section 4.3.1 of [RFC6733]).

Zhou, et al.            Expires January 22, 2015                [Page 7]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

4.2.  Tunnel-Source-Pref-Or-Addr AVP

   The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) is of type
   AddressOrPrefix.  It conveys either a prefix or a full address that
   is configured as the tunnel source address on the CE.  Within the
   scope of application of this document it is intended for use to
   convey the LW4over6 Binding Prefix from AAA to the provisioning
   system or to carry a full IPv6 tunnel source address that has been
   collected from the CE, either from the provisioning system to AAA or
   from AAA to the border router.  This AVP is defined separately from
   the LW4over6-Binding AVP (which includes it) to provide flexibility
   in the transport of the tunnel source address from the provisioning
   system to AAA.

   The Tunnel-Endpoint-Pref-Or-Addr AVP

4.3.  Port-Set-Identifier

   The Port-Set-Identifier AVP (AVP Code TBD03) is a structured
   OctetString with four octets of data, hence a total AVP length of 12.
   The description of the structure which follows refers to quantities
   illustrated in Figure 9, Appendix B of [I-D.ietf-softwire-map].  The
   derivation of port numbers from these parameters is described in that
   appendix.

   o  The first (high-order) octet is the Offset field.  It is
      interpreted as an 8-bit unsigned integer giving the offset 'a'
      from the beginning of a port number to the beginning of the port
      set identifier (PSID) to which that port belongs.  Valid values
      are from 0 to 15.

   o  The next octet, the PSIDLength, is also interpreted as an 8-bit
      unsigned integer and gives the length in bits of the port set
      identifier (PSID).  This corresponds to the value 'k' in the
      figure referred to above.  Valid values are from 1 to (16 - a).

   o  The final two octets constitute the PSIDValue field and are
      interpreted as a 16-bit unsigned integer.  They give the value of
      the PSID itself, right-justified within the field.  That is, the
      value of the PSID occupies the 'k' lowest-order bits of the
      PSIDValue field.

4.4.  LW4over6-Binding

   The LW4over6-Binding AVP (AVP Code TBD04) is of type Grouped.  It
   contains the elements of configuration that constitute the binding
   between an LW4over6 tunnel and IPv4 packets sent through that tunnel.

Zhou, et al.            Expires January 22, 2015                [Page 8]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

                    LW4over6-Binding  ::= < AVP Header: TBD04 >
                             { Tunnel-Source-Pref-Or-Addr }
                             { LW4over6-External-IPv4-Addr }
                             [ Port-Set-Identifier ]
                            *[ AVP ]

                                 Figure 1

   The Tunnel-Source-Pref-Or-Addr AVP is defined in Section 4.2 and
   provides either the Binding Prefix or the full IPv6 tunnel source
   address.  This AVP MUST be present.

   The LW4over6-External-IPv4-Addr AVP (AVP Code TBD05) is of type
   AddressOrPrefix.  Within the LW4over6-Binding AVP, it provides the
   external IPv4 address used as the source address for packets outgoing
   from the CE through the LW4over6 tunnel associated with the given
   binding, or destination address for incoming packets.  This AVP MUST
   be present.

   The Port-Set-Identifier AVP is defined in Section 4.3.  It identifies
   the specific set of ports assigned to the LW4over6 tunnel.  This AVP
   MUST be present except when 1-1 mapping mode is being provisioned,
   when it MUST NOT be present.

4.5.  MAP-E-Attributes

   The MAP-E-Attributes AVP (AVP Code TBD06) is of type Grouped.  It
   contains the configuration data identified in Section 2.3, for a
   single MAP domain.  If a CE belongs to more than one MAP domain, AAA
   will have to provide an instance of the MAP-E-Attributes AVP for each
   domain.

                    MAP-E-Attributes  ::= < AVP Header: TBD06 >
                           1*{ Border-Router-Name }
                           1*{ MAP-Mapping-Rule }
                             [ MAP-Mesh-Mode ]
                             [ MAP-End-User-IPv6-Prefix ]
                            *[ AVP ]

                                 Figure 2

   The Border-Router-Name AVP is defined in Section 4.1.  It provides
   the FQDN of a MAP border relay at the edge of the MAP domain to which
   the containing MAP-E-Attributes AVP relates.  The provisioning system
   will typically resolve this FQDN into one or more IPv6 addresses
   before passing it to the CE.  At least one instance of this AVP MUST
   be present.

Zhou, et al.            Expires January 22, 2015                [Page 9]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   The MAP-Mapping-Rule AVP is defined in Section 4.6.  At least one
   instance of this AVP MUST be present.  If the MAP-E domain supports
   mesh mode, additional MAP-Mapping-Rule instances MAY be present.  If
   the MAP-E domain is operating in hub-and-spoke mode, additional MAP-
   Mapping-Rule instances MUST NOT be present.

   The MAP-Mesh-Mode AVP (AVP Code TBD07) is of type OctetString but has
   no data.  Hence the AVP length is always 8.  The absence of the mesh
   mode indicator attribute indicates that the CE is required to operate
   in hub- and-spoke mode.

   The MAP-End-User-IPv6-Prefix AVP (AVP Code TBD08) is of type
   AddressOrPrefix.  Within the MAP-E-Attributes AVP, it provides the
   end- user IPv6 prefix assigned to the CE for the MAP domain to which
   the containing MAP-E-Attributes AVP relates.  This attribute is
   optional because, depending on deployment, the end-user IPv6 prefix
   may be provided by AAA or by another support system.

4.6.  MAP-Mapping-Rule

   The MAP-Mapping-Rule AVP (AVP Code TBD09) is of type Grouped, and is
   used only in conjunction with MAP-based transition methods (MAP-E and
   potentially 4rd and MAP-T).  Mapping rules are required both by the
   MAP border relay and by the CE.  The components of the MAP-Mapping-
   Rule AVP provide the contents of a mapping rule as described in
   Section 2.3.

   The syntax of the MAP-Mapping-Rule AVP is as follows:

            MAP-Mapping-Rule  ::= < AVP Header: TBD09 >
                             { Rule-IPv4-Addr-Or-Prefix }
                             { Rule-IPv6-Prefix    }
                             { EA-Field-Length     }
                             [ Port-Set-Identifier ]
                            *[ AVP ]

                                 Figure 3

   The Rule-IPv4-Addr-Or-Prefix AVP (AVP Code TBD10) is of type
   AddressOrPrefix.  The prefix length can range from 0 to 32, based on
   the different cases identified in Section 5.2 of
   [I-D.ietf-softwire-map].  A prefix length of 0 indicates that the
   entire IPv4 address or prefix is coded in the Extended Address (EA)
   bits of the end-user IPv6 prefix rather than in the mapping rule.
   This AVP MUST be present.

   The Rule-IPv6-Prefix AVP (AVP Code TBD11) is also of type
   AddressOrPrefix.  The prefix length MUST be less than or equal to the

Zhou, et al.            Expires January 22, 2015               [Page 10]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   length of the prefix in the MAP-End-User-IPv6-Prefix AVP contained in
   the same instance of the MAP-E-Attributes AVP as the MAP-Mapping-Rule
   AVP instance to which the Rule-IPv6-Prefix AVP belongs.  The Rule-
   IPv6-Prefix AVP MUST be present.

   The EA-Field-Length AVP (AVP Code TBD12) is of type Unsigned32.
   Valid values range from 0 to 48.  See Section 5.2 of
   [I-D.ietf-softwire-map] for a description of the use of this
   parameter in deriving IPv4 address and port number configuration.
   This AVP MUST be present.

   The Port-Set-Identifier AVP is defined in Section 4.3.  It MUST be
   present if the value of EA-Field-Length AVP is 0, and is redundant
   (SHOULD NOT be present) otherwise.

5.  Acknowledgements

   Tom Taylor performed work on earlier versions of this document with
   funding from Huawei Technologies.

6.  IANA Considerations

   This memo requests to IANA to register the following Diameter AVP
   codes:

          +-------+-----------------------------+---------------+
          |  Code | Attribute Name              | Reference     |
          +-------+-----------------------------+---------------+
          | TBD01 | Border-Router-Name          | This document |
          | TBD02 | Tunnel-Source-Pref-Or-Addr  | This document |
          | TBD03 | Port-Set-Identifier         | This document |
          | TBD04 | LW4over6-Binding            | This document |
          | TBD05 | LW4over6-External-IPv4-Addr | This document |
          | TBD06 | MAP-E-Attributes            | This document |
          | TBD07 | MAP-Mesh-Mode               | This document |
          | TBD08 | MAP-End-User-IPv6-Prefix    | This document |
          | TBD09 | MAP-Mapping-Rule            | This document |
          | TBD10 | Rule-IPv4-Addr-Or-Prefix    | This document |
          | TBD11 | Rule-IPv6-Prefix            | This document |
          | TBD12 | EA-Field-Length             | This document |
          +-------+-----------------------------+---------------+

                                  Table 1

Zhou, et al.            Expires January 22, 2015               [Page 11]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

7.  Security Considerations

   To come.

8.  References

8.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 (work in progress)", March 2014.

   [I-D.ietf-softwire-map]
              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP) (work in progress)", January
              2014.

   [IANAADFAM]
              IANA, "Address Family Numbers",
              <http://www.iana.org/assignments/address-family-numbers>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

8.2.  Informative References

   [I-D.fsc-softwire-dhcp4o6-saddr-opt]
              Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6
              Source Address Option (Work in progress)", June 2014.

   [I-D.ietf-softwire-map-dhcp]
              Mrugalski, T., Troan, O., Farrer, I., Perrault, S., Dec,
              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
              configuration of Softwire Address and Port Mapped Clients
              (Work in progress)", March 2014.

   [I-D.ietf-softwire-map-radius]
              Jiang, S., Fu, Y., Liu, B., and P. Deacon, "RADIUS
              Attribute for MAP (Work in progress)", June 2014.

Zhou, et al.            Expires January 22, 2015               [Page 12]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   [I-D.sun-softwire-lw4over6-radext]
              Xie, C., Sun, Q., Sun, Q., Zhou, C., Tsou, T., and Z. Liu,
              "Radius Extension for Lightweight 4over6 (Work in
              progress)", March 2014.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

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

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, August 2011.

   [RFC6519]  Maglione, R. and A. Durand, "RADIUS Extensions for Dual-
              Stack Lite", RFC 6519, February 2012.

Authors' Addresses

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com

   T. Taylor
   PT Taylor Consulting
   Ottawa
   Canada

   Email: tom.taylor.stds@gmail.com

Zhou, et al.            Expires January 22, 2015               [Page 13]
Internet-Draft       AVPs For 4over6 CE Provisioning           July 2014

   Qiong Sun
   China Telecom
   P.R.China

   Phone: 86 10 58552936
   Email: sunqiong@ctbri.com.cn

   M. Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

Zhou, et al.            Expires January 22, 2015               [Page 14]