[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                             C. Xie
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                           China Telecom
Expires: September 5, 2014                                        Q. Sun
                                                     Tsinghua University
                                                                 C. Zhou
                                                     Huawei Technologies
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                                  Z. Liu
                                                     Tsinghua University
                                                           March 4, 2014


                Radius Extension for Lightweight 4over6
                 draft-sun-softwire-lw4over6-radext-01

Abstract

   lightweight 4over6(lw4over6) [I-D.ietf-softwire-lw4over6] is an
   extension to DS-Lite in which the amount of state maintained in
   lwAFTR has been reduced to per-subscriber-level.  The lwB4 needs to
   be provisioned with the public IPv4 address and port set it is
   allowed to use.  The DHCPv4 over DHCPv6 Transport [I.D-ietf-dhc-
   dhcpv4-over-dhcpv6] and Dynamic Host Configuration Protocol (DHCP)
   Option for Port Set [I.D-sun-dhc-port-set-option] can be used for
   lwB4 to provison with the public IPv4 address and port set.

   However, in many networks, the configuration information may be
   stored in Authentication Authorization and Accounting (AAA) servers
   while user configuration is mainly from Broadband Network Gateway
   (BNG).  This document defines a Remote Authentication Dial In User
   Service (RADIUS) attribute that carries lightweight 4over6
   configuration information from AAA server to BNG.

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




Xie, et al.             Expires September 5, 2014               [Page 1]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


   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 5, 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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Lightweight 4over6 configuration process with RADIUS  . . . .   3
   4.  Attributes  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  lw4o6_binding Attribute . . . . . . . . . . . . . . . . .   6
   5.  Table of attributes . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Lightweight 4over6 (lw4over6) [I-D.ietf-softwire-lw4over6] defines a
   model for providing IPv4 access over an IPv6 network in which the
   Network Address Translation (NAT) function is performed by the
   Customer-Premises Equipment (CPE) instead of being centralized on a
   Carrier-Grade NAT (CGN).  Lightweight 4over6 features keeping per-
   subscriber binding state in the service provider's network.  This
   per-subscriber binding state is assigned by the provisioning system
   and should be synchronized between lwAFTRs.  In lw4over6, there are
   multiple mechanisms to provision an lwB4 with the binding state,




Xie, et al.             Expires September 5, 2014               [Page 2]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


   including [I.D-ietf-dhc-dhcpv4-over-dhcpv6], [I-D.ietf-softwire-map-
   dhcp] , or [I-D.ietf-pcp-port-set], etc.

   In many networks, user configuration information may be managed by
   AAA (Authentication, Authorization, and Accounting) servers.  Current
   AAA servers communicate using the Remote Authentication Dial In User
   Service (RADIUS) [RFC2865] protocol.  In a fixed line broadband
   network, the Broadband Network Gateways (BNGs) act as the access
   gateway of users.  For lw4over6 case, the BNGs are assumed to embed a
   DHCPv4-over-DHCPv6 server function which allows them to locally
   handle any DHCPv4-over-DHCPv6 requests issued by hosts.  The
   operators may per-configure subscriber's binding state in AAA server
   which then passes the information to a BNG and in turn populates the
   mapping of the subscribe.

   This document defines a new RADIUS attribute that can be used in
   lightweight 4over6 to carry subscriber's binding state.

2.  Terminology

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

   Terminology defined in [I-D.ietf-softwire-lw4over6] is used
   extensively in this document.

3.  Lightweight 4over6 configuration process with RADIUS

   The below Figure 1 illustrates how the RADIUS protocol and DHCPv4
   -over-DHCPv6 cooperate to provide lwB4 with the binding state.




















Xie, et al.             Expires September 5, 2014               [Page 3]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


       lwB4                           BNG        lwAFTR            AAA
        |                             |                           Server
        |--PPP LCP Config-Request---->|            |                |
        |                             |            |                |
        |<--PPP LCP Config-ACK  ------|            |                |
        |--PPP IPv6CP Config-Request->|            |                |
        |<-PPP IPv6CP Config-ACK  ----|            |                |
        |-------DHCPv6 Solicit------->|            |                |
        |<------DHCPv6 Advertisement--|            |                |
        |-------DHCPv6 Request------->|            |                |
        |<------DHCPv6 Reply----------|            |                |
        |                             |            |                |
        |--------DHCPv4-QUERY-------> |            |                |
        |    (OPTION_DHCPV4_MSG)      |-------Access-Request------->|
        |                             |     (lw4o6 attr)            |
        |                             |            |<-Configuration-|
        |                             |            |   (Optional)   |
        |                             |            |-----ACK------->|
        |                             |<------Access-Accept---------|
        |                             |     (lw4o6 attr)            |
        |<-------DHCPv4-RESPONSE----- |            |                |
        |     (OPTION_DHCPV4_MSG)     |            |                |
        |                             |            |                |

            DHCPv4-over-DHCPv6            RADIUS

   Figure 1: Lightweight 4over6 configuration process with RADIUS case 1

   BNGs act as a client of RADIUS and as a Unified server.  The lwB4
   will firstly get the IPv6 address via DHCPv6 process.  It then
   initiates a DHCPv4-QUERY message with OPTION_DHCPV4_MSG Option.
   Since the lwB4 has known the address of the Unified server in
   advance, it is recommanded to send the DHCPv4-QUERY message using
   unicast address.  When receving the DHCPv4-QUERY from lwB4, the BNG
   SHOULD intercept the subscriber's IPv6 address and stored locally.
   Then, the BNG SHOULD initiate a RADIUS Access-Request message, in
   which the User-Name attribute (1) SHOULD be filled by the lwB4 MAC
   address, to the RADIUS server,the User-password attribute (2) SHOULD
   be filled by the shared lw4over6 password that has been preconfigured
   on the DHCPv6 server to get lw4over6 attribute.  The IPv6 address in
   lw4o6 attribute should be filled by the subscriber's IPv6 address.
   The AAA server will then determine the IPv4 address and Port Set for
   the subscriber.

   The subscriber's binding state should be syncronized between AAA
   server and lwAFTR.  If the bindings are pre-configured statically in
   both AAA server and lwAFTR, the AAA server does not need to configure
   lwAFTR anymore.  Otherwise, if the bindings are locally creately in



Xie, et al.             Expires September 5, 2014               [Page 4]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


   AAA server on-demand, it should inform the lwAFTR with the
   subscriber's binding state using [I-D.zhou-dime-4over6-provisioning]
   or COA requests.

   Figure 2 illustrates how the RADIUS protocol and DHCPv6 cooperate to
   provide lwB4 and lwAFTR with tunnel configuration information.

    lwB4                 BNG                 AAA Server            lwAFTR
      |                     |                     |                   |
      | --DHCPv6 Request--> |                     |                   |
      |(OPTION_S46_CONT_LW) |                     |                   |
      |                     | --Access-Request--> |                   |
      |                     |    (lw4o6 attr)     |                   |
      |                     |                     |--configuration--> |
      |                     |                     |    (Optional)     |
      |                     |                     | <------ACK------- |
      |                     | <--Access-Accept--- |                   |
      |                     |    (lw4o6 attr)     |                   |
      | <--DHCPv6 Reply---- |                     |                   |
      |(OPTION_S46_CONT_LW) |                     |                   |
             DHCPv6                 Radius

   Figure 2: Lightweight 4over6 configuration process with RADIUS case 2

   BNGs act as a RADIUS client and as a DHCPv6 server.  Before the
   tunnel establishes, lwB4 MAY initiate a DHCPv6 Solicit message that
   includes an Option Request option[RFC3315] with OPTION_S46_CONT_LW
   option defined in [I-D.ietf-softwire-map-dhcp].  When BNG receives
   the SOLICIT, it SHOULD initiates radius Access-Request message, in
   which the User-Name attribute (1) SHOULD be filled by the lwB4 MAC
   address, to the RADIUS server,the User-password attribute (2) SHOULD
   be filled by the shared lw4over6 password that has been preconfigured
   on the DHCPv6 server to get lw4over6 attribute.

   If the authentication request is approved by the AAA server, AAA
   server will determine the IPv6 address, IPv4 address and Port Set for
   the subscriber.  The subscriber's binding state should be syncronized
   between AAA server and lwAFTR.  If the bindings are pre-configured
   statically in both AAA server and lwAFTR, the AAA server does not
   need to configure lwAFTR anymore.  Otherwise, if the bindings are
   locally creately in AAA server on-demand, it should inform the lwAFTR
   as mentioned above.

   Similarly, BNGs can act as a RADIUS client and as a PCP server in
   case an lwB4 runs a PCP client (as depicted in Figure 3).






Xie, et al.             Expires September 5, 2014               [Page 5]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


      lwB4                           BNG        lwAFTR        AAA Server
       |                             |            |                |
       |---PCP_PORT_SET Request----->|            |                |
       |                             |-------Access-Request------->|
       |                             |     (lw4o6 attr)            |
       |                             |            |<-Configuration-|
       |                             |            |   (Optional)   |
       |                             |            |-----ACK------->|
       |                             |<------Access-Accept---------|
       |                             |     (lw4o6 attr)            |
       |<---PCP_PORT_SET Request---- |            |                |
       |                             |            |                |
       |                             |            |                |

           PCP Port_set           RADIUS

   Figure 3: Lightweight 4over6 configuration process with RADIUS case 3

   In the above-mentioned scenarios, Message-Authenticator (type 80)
   [RFC2865] SHOULD be used to protect both Access-Request and Access-
   Accept messages.

   After receiving the lw4over6-binding attribute in the initial Access-
   Accept, the BNG SHOULD store the received lw4over6 configuration
   parameters locally.  When the lw4over6 CE sends a DHCP or PCP Request
   message to request an extension of the lifetime for the assigned
   address, the BNG does not have to initiate a new Access-Request
   towards the AAA server to request the lw4o6 binding state.  The BNG
   could retrieve the previously stored lw4o6 configuration parameters
   and use them in its reply.  The BNG will then inform the AAA server
   with updated lifetime.

   If the BNG does not receive the lw4over6-binding attribute in the
   Access-Accept or if the BNG receives an Access-Reject, the tunnel
   cannot be established.

4.  Attributes

   This section defines the lw4o6_binding attribute that is used in both
   above-mentioned scenarios.  The attribute design follows [RFC6158]
   and refers to [RFC6929].

4.1.  lw4o6_binding Attribute

   The lw4o6_binding RADIUS attribute contains the subscriber's binding
   information including IPv6 address, IPv4 address and the port-set.
   The BNG SHALL use the binding entry returned in the RADIUS
   lw4o6_binding attribute to populate the requests.



Xie, et al.             Expires September 5, 2014               [Page 6]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


   If the BNG includes the lw4o6_binding attribute, but the AAA server
   does not recognize it, this attribute MUST be ignored by the AAA
   server.

   If the BNG does not receive the lw4o6_binding attribute in the
   Access-Accept message and there is the unified server in BNG is not
   configured to allocate the port-set by itself, the unified SHOULD not
   response and the tunnel can not be established.

   When the Access-Request message is triggered by a DHCP Rebind
   message, if the binding attribute received in the Access-Accept
   message is different from the currently used one for that session,
   the BNG MUST force the lwB4 to re-establish the tunnel using the new
   binding information received in the Access-Accept message.

   The lw4o6_binding Attribute is structured as follows:



































Xie, et al.             Expires September 5, 2014               [Page 7]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |    Length     |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     IPv6 address                              |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     IPv4 address                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port Set Index             |        Port Set Mask          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

           TBD

         Length

           28
         Port Set Index:
              Port Set Index identifies a set of ports assigned
              to a device.  The first k bits on the left of the 2-octet
              field is the Port Set Index value, with the rest of the
              field right padding zeros.
         Port Set Mask:
              Port Set Mask indicates the position of the bits
              used to build the mask.  The first k bits on the left is
              padding ones while the remained (16-k) bits of the 2-octet
              field on the right is padding zeros.
         IPv4 address
           The translated IPv4 address for a subscriber.
         IPv6 address
           The IPv6 address for a subscriber.

                  Figure 4: Lightweight 4over6 Attribute

5.  Table of attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.








Xie, et al.             Expires September 5, 2014               [Page 8]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


  Request Accept Reject Challenge Accounting  #  Attribute
                                    Request
    0-1     0-1     0      0         0-1      TBD1 lw4o6-binding
    0-1     0-1     0      0         0-1      1    User-Name
    0-1     0       0      0         0        2    User-Password
    0-1     0-1     0      0         0-1      6    Service-Type
    0-1     0-1     0-1    0-1       0-1      80   Message-Authenticator

  The following table defines the meaning of the above table entries.

   0     This attribute MUST NOT be present in packet.
   0+    Zero or more instances of this attribute MAY be present in
         packet.
   0-1   Zero or one instance of this attribute MAY be present in
         packet.
   1     Exactly one instance of this attribute MUST be present in
         packet.

               Figure 5: Lightweight 4over6 Attribute Table

6.  Security Considerations

   TO BE COMPLETED

7.  IANA Considerations

   This document has no IANA actions.

8.  Acknowledgements

   The authors would like to thank the following individuals who have
   participated in the drafting, review, and discussion of this memo: TO
   BE COMPLETED

9.  References

9.1.  Normative References

   [I-D.ietf-pcp-port-set]
              Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
              and S. Perreault, "Port Control Protocol (PCP) Extension
              for Port Set Allocation", draft-ietf-pcp-port-set-00 (work
              in progress), March 2013.








Xie, et al.             Expires September 5, 2014               [Page 9]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


   [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", draft-ietf-softwire-lw4over6-00 (work in
              progress), April 2013.

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

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

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

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

9.2.  Informative References

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

Authors' Addresses

   Chongfeng Xie
   China Telecom
   P.R.China

   Phone: 86 10 58552116
   Email: xiechf@ctbri.com.cn


   Qiong Sun
   China Telecom
   P.R.China

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









Xie, et al.             Expires September 5, 2014              [Page 10]


Internet-Draft   Radius Extension for Lightweight 4over6      March 2014


   Qi Sun
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: sunqibupt@gmail.com


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

   Email: cathy.zhou@huawei.com


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA 95050
   USA

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com


   ZiLong Liu
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: liuzilong8266@126.com















Xie, et al.             Expires September 5, 2014              [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/