Internet DRAFT - draft-chen-behave-nat64-radius-extension

draft-chen-behave-nat64-radius-extension







Network Working Group                                            G. Chen
Internet-Draft                                              China Mobile
Intended status: Experimental                                   D. Binet
Expires: January 09, 2014                          France Telecom-Orange
                                                           July 08, 2013


                  Radius Attributes for Stateful NAT64
              draft-chen-behave-nat64-radius-extension-00

Abstract

   This document proposes new radius attributes for stateful NAT64.  The
   extensions are used to provide geo-location services with an exact
   IPv6 soruce address.  The message flow to deliver the NAT64 binding
   information between radius clients and servers is also described.
   Therefore, accurate location could be traced out depending on the
   radius method.

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 09, 2014.

Copyright Notice

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



Chen & Binet            Expires January 09, 2014                [Page 1]

Internet-Draft           nat64-radius-extension                July 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Delivery Methods for NAT64 Binding Information  . . . . . . .   3
   5.  Attributes  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  NAT64-Binding-Capable . . . . . . . . . . . . . . . . . .   4
     5.2.  Requested-Binding-Info  . . . . . . . . . . . . . . . . .   5
     5.3.  NAT64-Binding-Information . . . . . . . . . . . . . . . .   6
   6.  Diameter Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Stateful NAT64[RFC6146] has been specified to provide IPv4 services
   access when IPv6-only connectivity is enabled.  This NAT64 function
   could be implemented into routers or firewalls and deployed in
   broadband access networks or mobile core networks.  A public IPv4
   pool is configured in a NAT64 device to represent IPv6 subscribers in
   the IPv4 realm.  Since the public IPv4 address is shared by several
   subscribers, it's hardly for a geo-location service to retrieve
   accurate location information just depending on mapped IPv4 source
   address.  Therefore, it may impact geo-location service provisioning
   in such case due to unsatisfactory inputs.

   [RFC6269] mentions that in order to resolve the location of a host
   based on IP address, "It will be necessary for users of such systems
   to provide more information (e.g., TCP or UDP port numbers), and for
   the systems to use this information to query additional network
   resources (e.g., Network Address Translation - Protocol Translation
   (NAT-PT) binding tables)."  Current geo-location systems may rely on
   a radius database to inspect location information, for example the
   information provided in [RFC5580].  A radius based method may be
   desirable to convey original IPv6 source address in such system
   because it's rather convenient for a geo-location to get actual IPv6
   source address through the same message bus.  This document proposes
   to provide those information using radius methods.





Chen & Binet            Expires January 09, 2014                [Page 2]

Internet-Draft           nat64-radius-extension                July 2013


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

3.  Problem Statement

   IP address sharing solution raises some issues dealing with the
   capability to reveal the actual source address.  A use of stateful
   NAT64 likely has same issues once geo-location systems seek an
   accurate input of a source address.  Unlike NAT44, it may make more
   significances to trace the IPv6 source address other than the mapped
   IPv4 address to locate the
   subscribers.[I-D.ietf-v6ops-nat64-experience] provided more
   descriptions on stateful NAT64 uses.  Once the stateful NAT64
   function is built at a load balancer, XFF (X-Forwarded-For)
   [I-D.ietf-appsawg-http-forwarded] is likely to be adopted to transmit
   the IPv6 source address in HTTP headers.  Those messages would be
   passed on to web-servers for the geo-location processing.  However,
   XFF only handles HTTP-based traffic and may not be implemented, for
   example if the NAT64 function is integrated within routers or
   firewall in an broadband fixed network or a mobile network.
   Requiring NAT64 devices providing some application aware functions to
   insert IPv6 source addresses for each data flow would introduce
   overwhelming complexity and performance degradation.  It's also
   possible to extend Port Control Protocol (PCP) to support those
   network information queries from external servers.  This method can
   be treated as an "out-band" approach.  However, it may require
   additional correlations between different systems.  Therefore, the
   document proposes a radius-based solution to fit into geo-location
   systems with following benefits.

   o  It has few impacts to the NAT64 performance since the radius is a
      independent system which doesn't interact with NAT64 process

   o  Geo-location systems already rely on the radius database.  The
      extended attributes could be transmitted in the same message as
      already occurs over RADIUS[RFC5580]

4.  Delivery Methods for NAT64 Binding Information

   The Figure 1 takes an example to show the message exchanges when the
   NAT64 function is implemented in a Broadband Network Gateway(BNG).

   If the RADIUS client provides a NAT64-Binding-Capable Attribute in
   the Access-Request, then the RADIUS server MAY request NAT64 Binding
   information from the RADIUS client.  The inclusion of the Location-



Chen & Binet            Expires January 09, 2014                [Page 3]

Internet-Draft           nat64-radius-extension                July 2013


   Capable Attribute in an Access-Request message indicates that the BNG
   with stateful NAT64 functions is capable of providing binding
   information in response to an Access-Challenge.  The subsequent
   Access-Challenge message sent from the RADIUS server to the BNG
   provides a hint regarding the desired NAT64 Binding Attributes.  BNG
   would search the corresponding binding information regarding to
   mapped IPv4 address contained in the Requested-Binding-Info
   attribute.  In the shown message flow, the NAT64-Binding-Information
   attributes including IPv6 source address and life-time of the binding
   are then provided in the subsequent Access-Request message.
   Afterwards, RADIUS server should take a authorization procedure to
   evaluate this Access-Request message.

   +---------------+                             +---------------+
   |BNG with NAT64 |                             |Geo-Loc Radius |
   |  Function     |                             |    Server     |
   +---------------+                             +---------------+
           |                                              |
           | Access-Request                               |
           | +NAT64-Binding-Capable                       |
           |--------------------------------------------->|
           | Access-Challenge                             |
           | +Requested-Binding-Info                      |
           |<---------------------------------------------|
           | Access-Request                               |
           | +NAT64-Binding-Information                   |
           |--------------------------------------------->|

               Figure 1: NAT64 Binding Information Delivery

5.  Attributes

5.1.  NAT64-Binding-Capable

   The NAT64-Binding-Capable Attribute allows a network node with
   stateful NAT64 functions to indicate support for the functionality
   specified in this document.  The NAT64-Binding-Capable Attribute MUST
   be sent with the Access-Request messages.  A RADIUS server MAY
   challenge for additional network information once the NAT64-Binding-
   Capable Attribute has been received.

         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        | M | Reserved  |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Type (8 bits)



Chen & Binet            Expires January 09, 2014                [Page 4]

Internet-Draft           nat64-radius-extension                July 2013


            TBD - NAT64-Binding-Capable

          Length (8 bits)

            4

          M flag (2 bits)

          This flag indicates the type of address mapping.
          00 --  Endpoint-Independent Mapping
          01 --  Address-Dependent Mapping
          10 --  Address and Port-Dependent Mapping

          Reserved (6 bits)

          The bits are reserved for the future uses


5.2.  Requested-Binding-Info

   The Requested-Binding-Info Attribute MUST be sent with the Access-
   Challenge depending on the received NAT64-Binding-Capable attributes.
   A stateful NAT64 function with Radius clients SHOULD reply to the
   Access-Challenge with Access-Request message.

         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        |    Protocol   |  Reserved     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Mapped IPv4 address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Mapped Port Number       | Peer's IPv4 address(Optional) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Peer's IPv4 address(Optional) |  Peer's Port Number(Optional) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Type (8 bits)

           TBD - Requested-Binding-Info

          Length (8 bits)

           It indicates the length of attributes

          Protocol (8 bits)

           It indicates the Upper-layer protocol associated with the mapping.



Chen & Binet            Expires January 09, 2014                [Page 5]

Internet-Draft           nat64-radius-extension                July 2013


           Values are taken from the IANA protocol registry. For example,17
           represents UDP mappings while 6 represents TCP mapping

          Reserved (8 bits)

          The bits are reserved for the future uses

          Mapped IPv4 address (32 bits)

          It contains the IPv4 address which represents the IPv6 host
          in the IPv4 Internet.

          Mapped Port Number (16 bits)

          It indicates the assigned port number correlated with the Mapped
          IPv4 address.

          Peer's IPv4 address (32 bits)

          It indicates the IPv4 address that internal hosts connect with.
          The IPv4 address MAY be only carried when Address-Dependent Mapping
          and Address and Port-Dependent Mapping are indicated within the
          received Access-Request message.

          Peer's Port Number (16 bits)

          It indicates the port number correlated with the Peer's IPv4
          address. The Peer's Port Number MAY be only carried when Port-Dependent
          Mapping are indicated within the received Access-Request message.


5.3.  NAT64-Binding-Information

   The NAT64-Binding-Information Attribute MUST be sent with the Access-
   Request responding to Access-Challenge from a radius client to a
   Radius server.

         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        |    Protocol   |  Reserved     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                   IPv6 Source Address                         |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Lifetime                           |



Chen & Binet            Expires January 09, 2014                [Page 6]

Internet-Draft           nat64-radius-extension                July 2013


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Mapped IPv4 address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Mapped Port Number       | Peer's IPv4 address(Optional) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Peer's IPv4 address(Optional) |  Peer's Port Number(Optional) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Type (8 bits)

          TBD - NAT64-Binding-Information

          Length (8 bits)

          It indicates the length of attributes

          Protocol (8 bits)

          It indicates the Upper-layer protocol associated with the mapping.
          Values are taken from the IANA protocol registry.For example,17
          represents UDP mappings while 6 represents TCP mapping

          Reserved (8 bits)

          The bits are reserved for the future uses

          IPv6 Source Address (128 bits)

          It indicates the IPv6 source address corresponding to mapped IPv4
          address and port number

          Lifetime (32 bits)

          It indicates how long the geo-location should assume the IPv6
          address is still correlated with the mapped IPv4 address and port.

          Mapped IPv4 address (32 bits)

          It contains the IPv4 address which represents the IPv6 host
          in the IPv4 Internet.

          Mapped Port Number (16 bits)

          It indicates the assigned port number correlated with the Mapped
          IPv4 address.

          Peer's IPv4 address (32 bits)




Chen & Binet            Expires January 09, 2014                [Page 7]

Internet-Draft           nat64-radius-extension                July 2013


          It indicates the IPv4 address that internal hosts connect with.
          The IPv4 address MAY be only carried when Address-Dependent Mapping
          and Address and Port-Dependent Mapping are indicated within the
          received Access-Request message.

          Peer's Port Number (16 bits)

          It indicates the port number correlated with the Peer's IPv4
          address. The Peer's Port Number MAY be only carried when Port-Dependent
          Mapping are indicated within the received Access-Request message.


   

6.  Diameter Considerations

   This attribute is usable within either RADIUS or Diameter[RFC6733] .
   Since the Attributes defined in this document will be allocated from
   the standard RADIUS type space, no special handling is required by
   Diameter entities.

7.  IANA Considerations

   This document requires the assignment of RADIUS Attribute Type in the
   "Radius Types" registry (currently located at http://www.iana.org/
   assignments/radius-types for the following attributes: o

   o  NAT64-Binding-Capable TBD

   o  Requested-Binding-Info TBD

   o  NAT64-Binding-Information TBD

   IANA should allocate the numbers from the standard RADIUS Attributes
   space using the "IETF Review" policy [RFC5226].

8.  Security Considerations

   The proposed method is RECOMMENDED to be used with [RFC5580].
   Therefore, it shares all the considerations at Section 7 of
   [RFC5580].

9.  References

9.1.  Normative References

   [I-D.ietf-appsawg-http-forwarded]




Chen & Binet            Expires January 09, 2014                [Page 8]

Internet-Draft           nat64-radius-extension                July 2013


              Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              draft-ietf-appsawg-http-forwarded-10 (work in progress),
              October 2012.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5580]  Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
              Aboba, "Carrying Location Objects in RADIUS and Diameter",
              RFC 5580, August 2009.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

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

9.2.  Informative References

   [I-D.ietf-v6ops-nat64-experience]
              Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet,
              "NAT64 Deployment Considerations", draft-ietf-v6ops-
              nat64-experience-01 (work in progress), January 2013.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269, June
              2011.

Authors' Addresses

   Gang Chen
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: phdgang@gmail.com








Chen & Binet            Expires January 09, 2014                [Page 9]

Internet-Draft           nat64-radius-extension                July 2013


   David Binet
   France Telecom-Orange
   Rennes
   35000
   France

   Email: david.binet@orange.com












































Chen & Binet            Expires January 09, 2014               [Page 10]