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]