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]
