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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Cathy Zhou  , Tom Taylor 
Last updated 2013-03-10
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                                                 T. Taylor
Intended status: Standards Track                     Huawei Technologies
Expires: September 12, 2013                               March 11, 2013

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

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 September 12, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Zhou & Taylor          Expires September 12, 2013               [Page 1]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Description of the Parameters Required By Each Transition
       Method  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Parameters For Dual-Stack Lite  . . . . . . . . . . . . .   3
     2.2.  Public IPv4 Over IPv6 . . . . . . . . . . . . . . . . . .   4
     2.3.  Light Weight IPv4 Over IPv6 (LW4o6) . . . . . . . . . . .   4
     2.4.  Mapping of Address and Port with Encapsulation (MAP-E)  .   5
     2.5.  Summing Up  . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Attribute-Value Pair Definitions  . . . . . . . . . . . . . .   6
     3.1.  Border Router IPv6 Address  . . . . . . . . . . . . . . .   6
     3.2.  IPv4 Prefix or Address  . . . . . . . . . . . . . . . . .   7
     3.3.  IPv6 Prefix or Address  . . . . . . . . . . . . . . . . .   7
     3.4.  Port Set Identifier . . . . . . . . . . . . . . . . . . .   7
     3.5.  Transition Method Indicator . . . . . . . . . . . . . . .   7
     3.6.  NAT Pool Identifier . . . . . . . . . . . . . . . . . . .   8
     3.7.  Binding Between An IPv4 Address and IPv6 Address/Prefix
           Assigned to a Customer Edge Device  . . . . . . . . . . .   8
     3.8.  MAP Rule AVP  . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

Zhou & Taylor          Expires September 12, 2013               [Page 2]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

   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
   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 that the
   information originates in the AAA infrastructure.  To allow the
   information to be carried in Diameter [RFC6733], this document
   specifies a number of attribute-value pairs (AVPs) for the purpose.

   This document takes as its scope the set of transition methods
   provided for by [I_D.softwire-unified-cpe].  That document enumerates
   the information that must be provisioned in the customer edge router
   to support Dual-Stack Lite [RFC6333], Public IPv4 Over IPv6
   [I-D.ietf-softwire-public-4over6], Light Weight IPv4 Over IPv6
   (LW4o6) [I-D.cui-softwire-b4-translated-ds-lite], and Mapping of
   Address and Port with Encapsulation (MAP-E) [I-D.ietf-softwire-map].

   Several documents provide related specifications for RADIUS
   [RFC2865], for individual transition methods.  Potentially there
   could be a reconciliation between the contents of those documents and
   the present one, but that has not been done in the present version of
   this document.

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.  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 most of the transition methods dealt with here are works in
   progress, this section is subject to modification in future versions.

2.1.  Parameters For Dual-Stack Lite

Zhou & Taylor          Expires September 12, 2013               [Page 3]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

   Dual-Stack Lite is documented in [RFC6333].  It requires the
   following parameters to be provisioned at the B4 at the customer
   premises.  This enumeration does not include the normal provisioning
   of an IPv6 prefix to the customer equipment.  The section numbers
   shown are where these requirements are indicated in [RFC6333].

   o  IPv6 address of the border router (AFTR) (sec.  5.4);

   o  IPv6 address of a DNS recursive server (sec.  5.5).  This is
      probably supplied already independently of transition technology,
      so does not have to be covered here.

   o  an indicator that DS-Lite is to be used rather than some other
      transition method (sec.  5.6).  Note that [RFC6333] says that the
      choice should be made by unspecified means during initialization,
      while [I_D.softwire-unified-cpe] specifies how to infer the
      intended method from other DHCP parameters received.  Thus the
      indicator suggested here may not come from AAA.

   o  optionally, 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 (sec.
      5.7).

   The AFTR may also require an item of per-subscriber information (sec.
   8.1):

   o  the identity of the NAT pool to which the subscriber is to be
      assigned.

2.2.  Public IPv4 Over IPv6

   Public IPv4 Over IPv6 is described in
   [I-D.ietf-softwire-public-4over6].  Besides the usual IPv6 prefix or
   address information, it requires two parameters to be provisioned to
   the customer equipment:

   o  a public IPv4 address;

   o  IPv6 address of the border router

   It also requires per-subscriber provisioning on the border router:

   o  binding between the customer IPv4 address and the customer IPv6
      prefix, for routing of incoming packets to the correct tunnel.

2.3.  Light Weight IPv4 Over IPv6 (LW4o6)

Zhou & Taylor          Expires September 12, 2013               [Page 4]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

   Light Weight IPv4 Over IPv6 (LW4o6) is documented in
   [I-D.cui-softwire-b4-translated-ds-lite].  Its provisioning
   requirements are exactly the same as those for Public 4over6 with one
   addition:

   o  both the customer equipment and the border router are provided
      with a port set identifier identifying the set of ports to which
      the subscriber's incoming and outgoing packets on the public side
      are restricted.  The port selection algorithm and port set
      identifier as such are not discussed in the draft.  For the
      present version of this document, it is assumed that the algorithm
      is known in advance and the port set identifier has the form of an
      index ranging from zero to the number of subscribers sharing a
      given address less 1.  This is similar to the port set identifier
      in MAP-E, described next.

2.4.  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  whether the device is to operate in mesh or hub-and-spoke mode;

   o  the IPv6 address of the border router, also known as the Default
      Mapping rule;

   o  the specially constructed End-user IPv6 prefix for the customer
      edge device.  [I-D.ietf-softwire-map] suggests that this would be
      supplied as part of normal IPv6 provisioning, so it can be ignored
      as a requirement here.

   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.  This is currently a matter of discussion,
         whether it should default to 4 or 6 or be fixed at either of
         these values.

Zhou & Taylor          Expires September 12, 2013               [Page 5]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

   o  in mesh mode only, zero or more Forwarding Mapping Rules,
      containing the same parameters as the Basic Mapping rule.

   o  optionally, the port set identifier if the EA bits do carry it.

   The border router needs to be configured with the superset of the
   Forwarding MAP Rules passed to the customer sites it serves.  Since
   this is not subscriber-specific, even though it introduces no new
   requirements to this document, it is out of scope.

2.5.  Summing Up

   It appears that the following items are common to two or more methods
   and should therefore be specified in method-independent fashion:

   o  the IPv6 address of the border router;

   o  an IPv4 prefix and length (could be a /32);

   o  a port set identifier;

   o  tentatively, a method indicator, indicating which of the above
      transition methods the customer edge device must use.

   The remaining requirements are method-specific:

   o  for DS-Lite, the identity of the NAT pool to which the subscriber
      is assigned;

   o  for Public 4over6 and LW4o6, a binding between a customer IPv6
      prefix or address and an IPv4 address;

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

   o  for MAP-E, a Grouped AVP expressing a MAP Rule.

3.  Attribute-Value Pair Definitions

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

3.1.  Border Router IPv6 Address

   The Border-Router-IPv6-Address (AVP Code TBD01) is of type Address as
   defined in Section 4.3 of [RFC6733] and contains the IPv6 address of

Zhou & Taylor          Expires September 12, 2013               [Page 6]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

   a border router supporting an IPv6 transition method which will be
   used by the customer edge device on which this address is
   provisioned.  The address MAY be an anycast address.  Since the
   content is an IPv6 address, the AVP Length MUST be set to 26 and the
   first two octets MUST contain 0x0002 (IPv6).

3.2.  IPv4 Prefix or Address

   The IPv4-Prefix-Or-Addr (AVP Code TBD02) is derived from base type
   OctetString.  It is a discriminated union representing the
   combination of the prefix length (number of bits) in the first octet,
   followed by the prefix itself, most significant octet first, padded
   with zeroes at the low-order end to an octet boundary.  Valid values
   of the prefix length are from 0 to 32, where 0 indicates that the
   prefix is absent and 32 indicates a complete address.
   Correspondingly, the AVP Length can range from 9 to 13.

3.3.  IPv6 Prefix or Address

   The IPv6-Prefix-Or-Addr (AVP Code TBD03) is derived from base type
   OctetString.  It is a discriminated union representing the
   combination of the prefix length (number of bits) in the first octet,
   followed by the prefix itself, most significant octet first, padded
   with zeroes at the low-order end to an octet boundary.  Valid values
   of the prefix length are from 0 to 128, where 0 indicates that the
   prefix is absent and 128 indicates a complete address.
   Correspondingly, the AVP Length can range from 9 to 25.

3.4.  Port Set Identifier

   The Port-Set-Identifier AVP (AVP Code TBD04) is of type Unsigned32
   and indicates a set of ports defined by an otherwise-specified
   algorithm.  For a given shared address, each Port-Set-Identifier
   value MUST identify a separate set of ports.  AVP Length for the
   Port-Set-Identifier AVP MUST be set to 12.

3.5.  Transition Method Indicator

   The Transition-Method AVP (AVP Code TBD05) is of type Enumerated and
   indicates the IPv6 transition method to be used.  This document
   specifies the following values:

      0 NO_METHOD

      1 DUAL_STACK

      2 DS_LITE

Zhou & Taylor          Expires September 12, 2013               [Page 7]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

      3 PUBLIC_4OVER6

      4 LIGHT_WEIGHT_4OVER6

      5 MAP_WITH_ENCAPSULATION

   NO_METHOD indicates that the network will not support any transition
   method, and expects only IPv6 packets.  DUAL_STACK indicates that the
   network will accept either IPv4 or IPv6 packets.  [Maybe references
   should be added for the other values?]

   The AVP Length for the Transition-Method AVP MUST be set to 12.

3.6.  NAT Pool Identifier

   NAT-Poolid (AVP Code TBD06) is of type Unsigned32 and indicates the
   NAT pool on a network-based NAT to which a subscriber is to be
   assigned.  The set of valid values for this AVP is a local matter.
   The AVP Length for the NAT-Poolid AVP MUST be set to 12.

3.7.  Binding Between An IPv4 Address and IPv6 Address/Prefix Assigned
      to a Customer Edge Device

   4to6-Binding (AVP Code TBD07) is of type Grouped.  It provides an
   IPv4 address or prefix assigned to a customer edge device, a
   corresponding IPv6 address or prefix assigned to the tunnel interface
   at the customer edge device, and, if the IPv4 address is shared, a
   port set identifier indicating the valid set of ports for this
   customer edge device.  The contents of the 4to6-Binding AVP are
   required at the border router when Public 4over6 or Light-Weight
   4over6 is being used.

   If the port set identifier is present, the IPv4 address MUST be a
   full IPv4 address.  The port set identifier is relevant only if
   Light-Weight 4over6 is being used.

   The syntax of the 4to6-Binding AVP is given as follows, where the
   component AVPs were defined above.  The final *[ AVP ] component is
   added for extensibility.

         4to6-Binding  ::= < AVP Header: TBD07 >
                          { IPv4-Prefix-Or-Addr }
                          { IPv6-Prefix-Or-Addr }
                       0*1{ Port-Set-Identifier }
                         *[ AVP ]

                                 Figure 1

Zhou & Taylor          Expires September 12, 2013               [Page 8]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

3.8.  MAP Rule AVP

   The MAP-Rule AVP (AVP Code TBD08) is of type Grouped, and is used
   only in conjunction with the MAP-E transition method.  MAP rules are
   required both by the border router and by the customer edge device.
   The components of the MAP-Rule AVP are the rule IPv4 prefix or
   address, the rule IPv6 prefix, the length in bits of the Extended
   Address field in the End-User IPv6 Prefix assigned to the customer
   edge device, and the offset in a port number beyond which the port
   set identifier begins.

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

         MAP-Rule      ::= < AVP Header: TBD08 >
                          { IPv4-Prefix-Or-Addr }
                          { IPv6-Prefix-Or-Addr }
                          { EA-Field-Length     }
                          [ PSID-Offset         ]
                         *[ AVP ]

                                 Figure 2

   The IPv4-Prefix-Or-Addr and IPv6-Prefix-Or-Addr AVPs were defined
   above.  The EA-Field-Length AVP (AVP Code TBD09) and PSID-Offset AVP
   (AVP Code TBD10) are of type Unsigned32.  The valid range for EA-
   Field-Length extends from 0 to a maximum value defined by
   [I-D.ietf-softwire-map].  The valid range for PSID-Offset extends
   from 0 to 15, with a default value given by [I-D.ietf-softwire-map]
   if the parameter is absent.

4.  Acknowledgements

   TBD

5.  IANA Considerations

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

          +-------+----------------------------+---------------+
          |  Code | Attribute Name             | Reference     |
          +-------+----------------------------+---------------+
          | TBD01 | Border-Router-IPv6-Address | This document |
          | TBD02 | IPv4-Prefix-Or-Addr        | This document |
          | TBD03 | IPv6-Prefix-Or-Addr        | This document |
          | TBD04 | Port-Set-Identifier        | This document |
          | TBD05 | Transition-Method          | This document |
          | TBD06 | NAT-Poolid                 | This document |

Zhou & Taylor          Expires September 12, 2013               [Page 9]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

          | TBD07 | 4to6-Binding               | This document |
          | TBD08 | MAP-Rule                   | This document |
          | TBD09 | EA-Field-Length            | This document |
          | TBD10 | PSID-Offset                | This document |
          +-------+----------------------------+---------------+

                                  Table 1

   This document further requests IANA to establish a new sub- directory
   of the Diameter AVP Specific Values directory entitled Transition-
   Method AVP Values (code TBD05).  The initial set of values for this
   registry are as follows:

         +------------+------------------------+----------------+
         | AVP Values | Attribute Name         | Reference      |
         +------------+------------------------+----------------+
         |     0      | NO_METHOD              | This document. |
         |     1      | DUAL_STACK             | This document. |
         |     2      | DS_LITE                | This document. |
         |     3      | PUBLIC_4OVER6          | This document. |
         |     4      | LIGHT_WEIGHT_4OVER6    | This document. |
         |     5      | MAP_WITH_ENCAPSULATION | This document. |
         +------------+------------------------+----------------+

                                  Table 2

6.  Security Considerations

   To come.

7.  References

7.1.  Normative References

   [I-D.cui-softwire-b4-translated-ds-lite]
              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)", February 2013.

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

   [I-D.ietf-softwire-public-4over6]
              Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4 over IPv6 Access Network", October 2012.

Zhou & Taylor          Expires September 12, 2013              [Page 10]
Internet-Draft      AVPs For 4over6 CPE Provisioning          March 2013

   [I_D.softwire-unified-cpe]
              Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6
              Softwire CPE (work in progress)", January 2013.

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

7.2.  Informative References

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

Authors' Addresses

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

   Email: cathy.zhou@huawei.com

   T. Taylor
   Huawei Technologies
   Ottawa
   Canada

   Email: tom.taylor.stds@gmail.com

Zhou & Taylor          Expires September 12, 2013              [Page 11]