draft-ietf-dime-nat-control-09.txt | draft-ietf-dime-nat-control-10.txt | |||
---|---|---|---|---|
Internet Engineering Task Force F. Brockners | Internet Engineering Task Force F. Brockners | |||
Internet-Draft S. Bhandari | Internet-Draft S. Bhandari | |||
Intended status: Standards Track Cisco | Intended status: Standards Track Cisco | |||
Expires: January 11, 2012 V. Singh | Expires: March 5, 2012 V. Singh | |||
V. Fajardo | V. Fajardo | |||
Telcordia Technologies | Telcordia Technologies | |||
July 10, 2011 | September 2, 2011 | |||
Diameter Network Address and Port Translation Control Application | Diameter Network Address and Port Translation Control Application | |||
draft-ietf-dime-nat-control-09 | draft-ietf-dime-nat-control-10 | |||
Abstract | Abstract | |||
This document describes the framework, messages, and procedures for | This document describes the framework, messages, and procedures for | |||
the Diameter Network address and port translation Control | the Diameter Network address and port translation Control | |||
Application. This Diameter application allows per endpoint control | Application. This Diameter application allows per endpoint control | |||
of Network Address Translators and Network Address and Port | of Network Address Translators and Network Address and Port | |||
Translators, which are added to networks to cope with IPv4-address | Translators, which are added to networks to cope with IPv4-address | |||
space depletion. This Diameter application allows external devices | space depletion. This Diameter application allows external devices | |||
to configure and manage a Network Address Translator device - | to configure and manage a Network Address Translator device - | |||
skipping to change at page 2, line 7 | skipping to change at page 2, line 7 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 11, 2012. | This Internet-Draft will expire on March 5, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3. Deployment Framework . . . . . . . . . . . . . . . . . . . . . 7 | 3. Deployment Framework . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 7 | 3.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 8 | |||
3.2. Diameter NAPT Control Application Overview . . . . . . . . 9 | 3.2. Diameter NAPT Control Application Overview . . . . . . . . 10 | |||
3.3. Deployment Scenarios For DNCA . . . . . . . . . . . . . . 10 | 3.3. Deployment Scenarios For DNCA . . . . . . . . . . . . . . 10 | |||
4. DNCA Session Establishment and Management . . . . . . . . . . 12 | 4. DNCA Session Establishment and Management . . . . . . . . . . 13 | |||
4.1. Session Establishment . . . . . . . . . . . . . . . . . . 12 | 4.1. Session Establishment . . . . . . . . . . . . . . . . . . 13 | |||
4.2. Session Re-Authorization . . . . . . . . . . . . . . . . . 14 | 4.2. Session Re-Authorization . . . . . . . . . . . . . . . . . 16 | |||
4.3. Session and Binding Query . . . . . . . . . . . . . . . . 17 | 4.3. Session and Binding Query . . . . . . . . . . . . . . . . 18 | |||
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 18 | 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 20 | |||
4.5. Session Abort . . . . . . . . . . . . . . . . . . . . . . 19 | 4.5. Session Abort . . . . . . . . . . . . . . . . . . . . . . 21 | |||
4.6. Failure cases of the DNCA Diameter peers . . . . . . . . . 20 | 4.6. Failure cases of the DNCA Diameter peers . . . . . . . . . 22 | |||
5. Use Of The Diameter Base Protocol . . . . . . . . . . . . . . 21 | 5. Use of the Diameter Base Protocol . . . . . . . . . . . . . . 23 | |||
5.1. Securing Diameter Messages . . . . . . . . . . . . . . . . 21 | 5.1. Securing Diameter Messages . . . . . . . . . . . . . . . . 23 | |||
5.2. Accounting Functionality . . . . . . . . . . . . . . . . . 22 | 5.2. Accounting Functionality . . . . . . . . . . . . . . . . . 24 | |||
5.3. Use Of Sessions . . . . . . . . . . . . . . . . . . . . . 22 | 5.3. Use of Sessions . . . . . . . . . . . . . . . . . . . . . 24 | |||
5.4. Routing Considerations . . . . . . . . . . . . . . . . . . 22 | 5.4. Routing Considerations . . . . . . . . . . . . . . . . . . 24 | |||
5.5. Advertising Application Support . . . . . . . . . . . . . 22 | 5.5. Advertising Application Support . . . . . . . . . . . . . 24 | |||
6. DNCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 22 | 6. DNCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
6.1. NAT-Control Request (NCR) Command . . . . . . . . . . . . 22 | 6.1. NAT-Control Request (NCR) Command . . . . . . . . . . . . 24 | |||
6.2. NAT-Control Answer (NCA) Command . . . . . . . . . . . . . 23 | 6.2. NAT-Control Answer (NCA) Command . . . . . . . . . . . . . 25 | |||
7. NAT Control Application Session State Machine . . . . . . . . 24 | 7. NAT Control Application Session State Machine . . . . . . . . 26 | |||
8. DNCA AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 8. DNCA AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
8.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 27 | 8.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 30 | |||
8.2. Additional Result-Code AVP Values . . . . . . . . . . . . 28 | 8.2. Additional Result-Code AVP Values . . . . . . . . . . . . 30 | |||
8.2.1. Success . . . . . . . . . . . . . . . . . . . . . . . 28 | 8.2.1. Success . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
8.2.2. Transient Failures . . . . . . . . . . . . . . . . . . 28 | 8.2.2. Transient Failures . . . . . . . . . . . . . . . . . . 31 | |||
8.2.3. Permanent Failures . . . . . . . . . . . . . . . . . . 29 | 8.2.3. Permanent Failures . . . . . . . . . . . . . . . . . . 31 | |||
8.3. Reused NASREQ Diameter Application AVPs . . . . . . . . . 30 | 8.3. Reused NASREQ Diameter Application AVPs . . . . . . . . . 32 | |||
8.4. Reused AVPs from RFC 4675 . . . . . . . . . . . . . . . . 30 | 8.4. Reused AVPs from RFC 4675 . . . . . . . . . . . . . . . . 32 | |||
8.5. Reused AVPs from Diameter QoS Application . . . . . . . . 31 | 8.5. Reused AVPs from Diameter QoS Application . . . . . . . . 33 | |||
8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter | 8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter | |||
Application . . . . . . . . . . . . . . . . . . . . . . . 31 | Application . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
8.7. DNCA Defined AVPs . . . . . . . . . . . . . . . . . . . . 32 | 8.7. DNCA Defined AVPs . . . . . . . . . . . . . . . . . . . . 34 | |||
8.7.1. NC-Request-Type AVP . . . . . . . . . . . . . . . . . 32 | 8.7.1. NC-Request-Type AVP . . . . . . . . . . . . . . . . . 35 | |||
8.7.2. NAT-Control-Install AVP . . . . . . . . . . . . . . . 33 | 8.7.2. NAT-Control-Install AVP . . . . . . . . . . . . . . . 36 | |||
8.7.3. NAT-Control-Remove AVP . . . . . . . . . . . . . . . . 33 | 8.7.3. NAT-Control-Remove AVP . . . . . . . . . . . . . . . . 36 | |||
8.7.4. NAT-Control-Definition AVP . . . . . . . . . . . . . . 33 | 8.7.4. NAT-Control-Definition AVP . . . . . . . . . . . . . . 36 | |||
8.7.5. NAT-Internal-Address AVP . . . . . . . . . . . . . . . 34 | 8.7.5. NAT-Internal-Address AVP . . . . . . . . . . . . . . . 37 | |||
8.7.6. NAT-External-Address AVP . . . . . . . . . . . . . . . 34 | 8.7.6. NAT-External-Address AVP . . . . . . . . . . . . . . . 37 | |||
8.7.7. Max-NAT-Bindings . . . . . . . . . . . . . . . . . . . 35 | 8.7.7. Max-NAT-Bindings . . . . . . . . . . . . . . . . . . . 38 | |||
8.7.8. NAT-Control-Binding-Rule AVP . . . . . . . . . . . . . 35 | 8.7.8. NAT-Control-Binding-Template AVP . . . . . . . . . . . 38 | |||
8.7.9. Duplicate-Session-Id AVP . . . . . . . . . . . . . . . 35 | 8.7.9. Duplicate-Session-Id AVP . . . . . . . . . . . . . . . 38 | |||
9. Accounting Commands . . . . . . . . . . . . . . . . . . . . . 35 | 8.7.10. NAT-External-Port-Style AVP . . . . . . . . . . . . . 38 | |||
9.1. NAT Control Accounting Messages . . . . . . . . . . . . . 36 | 9. Accounting Commands . . . . . . . . . . . . . . . . . . . . . 39 | |||
9.2. NAT Control Accounting AVPs . . . . . . . . . . . . . . . 36 | 9.1. NAT Control Accounting Messages . . . . . . . . . . . . . 39 | |||
9.2.1. NAT-Control-Record . . . . . . . . . . . . . . . . . . 36 | 9.2. NAT Control Accounting AVPs . . . . . . . . . . . . . . . 40 | |||
9.2.2. NAT-Control-Binding-Status . . . . . . . . . . . . . . 36 | 9.2.1. NAT-Control-Record . . . . . . . . . . . . . . . . . . 40 | |||
9.2.3. Current-NAT-Bindings . . . . . . . . . . . . . . . . . 37 | 9.2.2. NAT-Control-Binding-Status . . . . . . . . . . . . . . 40 | |||
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 37 | 9.2.3. Current-NAT-Bindings . . . . . . . . . . . . . . . . . 40 | |||
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 41 | ||||
10.1. DNCA AVP Table for NAT Control Initial and Update | 10.1. DNCA AVP Table for NAT Control Initial and Update | |||
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 37 | Requests . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
10.2. DNCA AVP Table for Session Query request . . . . . . . . . 38 | 10.2. DNCA AVP Table for Session Query request . . . . . . . . . 42 | |||
10.3. DNCA AVP Table for Accounting Message . . . . . . . . . . 38 | 10.3. DNCA AVP Table for Accounting Message . . . . . . . . . . 42 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 | |||
11.1. Application Identifier . . . . . . . . . . . . . . . . . . 39 | 11.1. Application Identifier . . . . . . . . . . . . . . . . . . 43 | |||
11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 39 | 11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 43 | |||
11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 39 | 11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 39 | 11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 43 | |||
11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 39 | 11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 43 | |||
11.6. NAT-Control-Binding-Status AVP . . . . . . . . . . . . . . 39 | 11.6. NAT-External-Port-Style AVP . . . . . . . . . . . . . . . 43 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 40 | 11.7. NAT-Control-Binding-Status AVP . . . . . . . . . . . . . . 44 | |||
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 | 12. Security Considerations . . . . . . . . . . . . . . . . . . . 44 | |||
14. Change History (to be removed prior to publication as an | 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 13.1. DNCA Session Establishment Example . . . . . . . . . . . . 46 | |||
15. Normative References . . . . . . . . . . . . . . . . . . . . . 43 | 13.2. DNCA Session Update with Port Style Example . . . . . . . 49 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 | 13.3. DNCA Session Query Example . . . . . . . . . . . . . . . . 50 | |||
13.4. DNCA Session Termination Example . . . . . . . . . . . . . 51 | ||||
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 | ||||
15. Change History (to be removed prior to publication as an | ||||
RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 | ||||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 | ||||
16.1. Normative References . . . . . . . . . . . . . . . . . . . 57 | ||||
16.2. Informative References . . . . . . . . . . . . . . . . . . 57 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 | ||||
1. Introduction | 1. Introduction | |||
Internet service providers have started to deploy Network Address | Internet service providers deploy Network Address Translators (NATs) | |||
Translators (NATs) and Network Address and Port Translators (NAPTs) | and Network Address and Port Translators (NAPTs) [RFC3022] in their | |||
in their networks to deal with the depletion of available public IPv4 | networks. A key motivation for doing so is the depletion of | |||
addresses. This document defines a Diameter application allowing | available public IPv4 addresses. This document defines a Diameter | |||
providers to control the behavior of these NAT and NAPT devices. The | application allowing providers to control the behavior of NAT and | |||
use of a Diameter application allows for simple integration into the | NAPT devices that implement IPv4-to-IPv4 network address and port | |||
existing Authentication, Authorization and Accounting (AAA) | translation [RFC2663] as well as stateful IPv6-to-IPv4 address family | |||
environment of a provider. | translation translation as defined in [RFC2663], [RFC6145], and | |||
[RFC6146]. The use of a Diameter application allows for simple | ||||
integration into the existing Authentication, Authorization and | ||||
Accounting (AAA) environment of a provider. | ||||
The Diameter Network address and port translation Control Application | The Diameter Network address and port translation Control Application | |||
(DNCA) offers the following capabilities: | (DNCA) offers the following capabilities: | |||
1. Limits or defines the number of NAPT/NAT bindings made available | 1. Limits or defines the number of NAPT/NAT bindings made available | |||
to an individual end point or user. The main motivation for | to an individual end point or user. The main motivation for | |||
restricting the number of bindings on a per end point basis is to | restricting the number of bindings on a per end point basis is to | |||
protect the service of the service provider against denial of | protect the service of the service provider against denial of | |||
service attacks. If multiple end points share a single public IP | service attacks. If multiple end points share a single public IP | |||
address, these end points can share fate. If one end point would | address, these end points can share fate. If one end point would | |||
skipping to change at page 5, line 36 | skipping to change at page 5, line 39 | |||
mal-ware, etc.) be able to consume all available bindings for a | mal-ware, etc.) be able to consume all available bindings for a | |||
given single public IP address, service would be hampered (or | given single public IP address, service would be hampered (or | |||
might even become unavailable) for those other end points sharing | might even become unavailable) for those other end points sharing | |||
the same public IP address. The efficiency of a NAPT deployment | the same public IP address. The efficiency of a NAPT deployment | |||
depends on the maximum number of bindings an end point could use. | depends on the maximum number of bindings an end point could use. | |||
Given that the typical number of bindings an end point uses | Given that the typical number of bindings an end point uses | |||
depends on the type of end point (e.g. a personal computer of a | depends on the type of end point (e.g. a personal computer of a | |||
broadband user is expected to use a higher number of bindings | broadband user is expected to use a higher number of bindings | |||
than a simple mobile phone) and a NAPT device is often shared by | than a simple mobile phone) and a NAPT device is often shared by | |||
different types of end points, it is desirable to actively manage | different types of end points, it is desirable to actively manage | |||
the maximum number of bindings. | the maximum number of bindings. This requirement is specified in | |||
REQ-3 of [I-D.ietf-behave-lsn-requirements] | ||||
2. Supports the allocation of specific NAPT/NAT bindings. Two types | 2. Supports the allocation of specific NAPT/NAT bindings. Two types | |||
of specific bindings can be distinguished: | of specific bindings can be distinguished: | |||
* Allocation of a pre-defined NAT binding: Both the internal and | * Allocation of a pre-defined NAT binding: Both the internal and | |||
external IP address and port pair are specified within the | external IP address and port pair are specified within the | |||
request. Some deployment cases, such as access to a web- | request. Some deployment cases, such as access to a web- | |||
server within a user's home network with IP address and port, | server within a user's home network with IP address and port, | |||
benefit from statically configured bindings. | benefit from statically configured bindings. | |||
skipping to change at page 6, line 22 | skipping to change at page 6, line 26 | |||
example, a list of IP-subnets. Such external address pools can | example, a list of IP-subnets. Such external address pools can | |||
be used to select the external IP address in NAPT/NAT bindings | be used to select the external IP address in NAPT/NAT bindings | |||
for multiple subscribers. | for multiple subscribers. | |||
4. Generates reports and accounting records: Reports established | 4. Generates reports and accounting records: Reports established | |||
bindings for a particular user. The collected information is | bindings for a particular user. The collected information is | |||
used by accounting systems for statistical purposes. | used by accounting systems for statistical purposes. | |||
5. Queries and retrieves details about bindings on demand: This | 5. Queries and retrieves details about bindings on demand: This | |||
feature complements the previously mentioned accounting | feature complements the previously mentioned accounting | |||
functionality (see item 4). | functionality (see item 4). This feature can be used by an | |||
entity to find NAT-bindings belonging to one or multiple end | ||||
points on the NAT-device. The entity is not required to create a | ||||
DNCA control session to perform the query. | ||||
6. Identifies a subscriber or endpoint on multiple network devices | 6. Identifies a subscriber or endpoint on multiple network devices | |||
(NAT/NAPT device, the AAA-server, or the Network Access Server | (NAT/NAPT device, the AAA-server, or the Network Access Server | |||
(NAS)): Endpoint identification is facilitated through a Global | (NAS)): Endpoint identification is facilitated through a Global | |||
Endpoint ID. Endpoints are identified through a single or a set | Endpoint ID. Endpoints are identified through a single or a set | |||
of classifiers, such as IP address, Virtual Local Area Network | of classifiers, such as IP address, Virtual Local Area Network | |||
(VLAN) identifier, or interface identifier which uniquely | (VLAN) identifier, or interface identifier which uniquely | |||
identify the traffic associated with a particular global | identify the traffic associated with a particular global | |||
endpoint. | endpoint. | |||
With the above capabilities, DNCA qualifies as a MIDCOM protocol | ||||
[RFC3303], [RFC3304], [RFC5189] for middle boxes which perform NAT. | ||||
The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a | ||||
candidate protocol for MIDCOM. DNCA provides the extensions to the | ||||
Diameter base protocol [RFC3588] following the MIDCOM protocol | ||||
requirements, such as the support of NAT-specific rule transport, | ||||
support for oddity of mapped ports, as well as support for | ||||
consecutive range port numbers. DNCA adds to the MIDCOM protocol | ||||
capabilities in that it allows to maintain the reference to an end | ||||
point representing a user or subscriber in the control operation, | ||||
enabling the control of the behavior of a NAT-device on a per end | ||||
point basis. Following the requirements of different operators and | ||||
deployments, different management protocols are employed. Examples | ||||
include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can both be | ||||
used for device configuration. Similarly, DNCA is complementing | ||||
existing MIDCOM implementations, offering a MIDCOM protocol option | ||||
for operators with an operational environment that is Diameter- | ||||
focused which desire to use Diameter to perform per end point NAT | ||||
control. | ||||
This document is structured as follows: Section 2 lists terminology, | This document is structured as follows: Section 2 lists terminology, | |||
while Section 3 provides an introduction to DNCA and its overall | while Section 3 provides an introduction to DNCA and its overall | |||
deployment framework. Sections 4 to 8 cover DNCA specifics, with | deployment framework. Sections 4 to 8 cover DNCA specifics, with | |||
Section 4 describing session management, Section 5 the use of the | Section 4 describing session management, Section 5 the use of the | |||
Diameter base protocol, Section 6 new commands, Section 7 AVPs used, | Diameter base protocol, Section 6 new commands, Section 7 Attribute | |||
and Section 8 accounting aspects. Section 9 presents an AVP | Value Pairs(AVPs) used, and Section 8 accounting aspects. Section 9 | |||
occurence table. IANA and security considerations are addressed in | presents AVP occurrence tables. IANA and security considerations are | |||
Sections 10 and 11. | addressed in Sections 10 and 11. | |||
2. Conventions | 2. Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Abbreviations used in this document: | Abbreviations used in this document: | |||
AAA: Authentication, Authorization, Accounting | AAA: Authentication, Authorization, Accounting | |||
DNCA: Diameter Network address and port translation Control | DNCA: Diameter Network address and port translation Control | |||
Application | Application | |||
NAPT: Network Address and Port Translation | NAPT: Network Address and Port Translation, see also [RFC3022] | |||
NAT: Network Address Translation (NAT and NAPT are used in this | NAT: Network Address Translation (NAT and NAPT are used in this | |||
document interchangeably) | document interchangeably) | |||
NAT-binding or binding: Association of two IP address/port pairs | NAT-binding or binding: Association of two IP address/port pairs | |||
(with one IP address typically being private and the other one | (with one IP address typically being private and the other one | |||
public) to facilitate NAT | public) to facilitate NAT | |||
NAT Binding Predefined template: Is a policy template or | ||||
configuration that is predefined at the NAT-device. It may | ||||
contain NAT-bindings, IP-address pools for allocating the external | ||||
IP-address of a NAT-binding, the maximum number of allowed NAT- | ||||
bindings for end-points, etc. | ||||
NAT-device: Network Address Translator or Network Address and Port | NAT-device: Network Address Translator or Network Address and Port | |||
Translator: An entity performing NAT or NAPT | Translator: An entity performing NAT or NAPT. | |||
NAT-controller: Entity controlling the behavior of a NAT-device | NAT-controller: Entity controlling the behavior of a NAT-device. | |||
NAS: Network Access Server | NAS: Network Access Server | |||
NCR: NAT Control Request | NCR: NAT Control Request | |||
NCA: NAT Control Answer | NCA: NAT Control Answer | |||
NAT44: IPv4 to IPv4 network address and port translation, see | ||||
[RFC2663] | ||||
NAT64: IPv6 to IPv4 address family translation, see [RFC6145] and | ||||
[RFC6146] | ||||
PPP: Point-to-Point Protocol [RFC1661] | ||||
3. Deployment Framework | 3. Deployment Framework | |||
3.1. Deployment Scenario | 3.1. Deployment Scenario | |||
Figure 1 shows a typical network deployment for Internet access. A | Figure 1 shows a typical network deployment for IPv4-Internet access. | |||
user's IPv4 host gains access to the Internet though a NAS, which | A user's IPv4 host gains access to the Internet though a NAS, which | |||
facilitates the authentication of the endpoint and configures the | facilitates the authentication of the endpoint and configures the | |||
user's connection according to the authorization and configuration | user's connection according to the authorization and configuration | |||
data received from the AAA-server upon successful authentication. | data received from the AAA-server upon successful authentication. | |||
Public IPv4 addresses are used throughout the network. | Public IPv4 addresses are used throughout the network. | |||
+---------+ | +---------+ | |||
| | | | | | |||
| AAA | | | AAA | | |||
| | | | | | |||
+---------+ | +---------+ | |||
skipping to change at page 8, line 24 | skipping to change at page 8, line 51 | |||
+---------+ +---------+ +----------+ | +---------+ +---------+ +----------+ | |||
| IPv4 | | | | IPv4 | | | IPv4 | | | | IPv4 | | |||
| Host |----------| NAS |-------------| Internet | | | Host |----------| NAS |-------------| Internet | | |||
| | | | | | | | | | | | | | |||
+---------+ +---------+ +----------+ | +---------+ +---------+ +----------+ | |||
<-------------------- Public IPv4 ----------------------> | <-------------------- Public IPv4 ----------------------> | |||
Figure 1: Typical network deployment for internet access | Figure 1: Typical network deployment for internet access | |||
Figure 2 depicts the deployment scenario when a service provider | Figure 2 depicts the deployment scenario where a service provider | |||
introduces a NAT-device to increase the efficiency of the global IPv4 | places a NAT between the host and the public Internet. The objective | |||
address pool utilization. The objective is to provide the customer | is to provide the customer with connectivity to the public IPv4 | |||
with connectivity to the public IPv4 Internet. The NAT-device | Internet. The NAT-device performs network address and port (and | |||
performs network address and port (and optionally address family) | optionally address family) translation, depending on whether the | |||
translation, depending on whether the access network uses private | access network uses private IPv4 addresses or public IPv6 addresses, | |||
IPv4 addresses or public IPv6 addresses, to public IPv4 addresses. | to public IPv4 addresses. Note that there may be more than one NAS, | |||
NAT-device, or AAA-entity in a deployment, although the figures only | ||||
depict one entity each for clarity. | ||||
If the NAT-device would be put in place without any endpoint | If the NAT-device would be put in place without any endpoint | |||
awareness, the service offerings of the service provider could be | awareness, the service offerings of the service provider could be | |||
impacted. This includes cases like: | impacted as detailed in [I-D.ietf-behave-lsn-requirements]. This | |||
includes cases like: | ||||
o Provisioning static NAT bindings for particular endpoints | o Provisioning static NAT bindings for particular endpoints | |||
o Using different public IP address pools for different set of | o Using different public IP address pools for different set of | |||
endpoints (for example, residential or business customers) | endpoints (for example, residential or business customers) | |||
o Reporting allocated bindings on a per endpoint basis | o Reporting allocated bindings on a per endpoint basis | |||
o Integrate control of the NAT-device into the already existing per | o Integrate control of the NAT-device into the already existing per | |||
endpoint management infrastructure of the service provider | endpoint management infrastructure of the service provider | |||
skipping to change at page 9, line 14 | skipping to change at page 9, line 38 | |||
+---------+ | +---------+ | |||
| | | | | | |||
| AAA | | | AAA | | |||
| | | | | | |||
+---------+ | +---------+ | |||
| | | | |||
| | | | |||
| | | | |||
| | | | |||
+--------+ +---------+ +--------+ +----------+ | +--------+ +---------+ +--------+ +----------+ | |||
| IPv4/ | | | | | | IPv4 | | | | | | | | | | | |||
| IPv6 |----| NAS |----| NAT- |----| Internet | | | Host |----| NAS |----| NAT- |----| IPv4- | | |||
| Host | | | | device | | | | | | | | | device | | Internet | | |||
+--------+ +---------+ +--------+ +----------+ | +--------+ +---------+ +--------+ +----------+ | |||
<-------- Private IPv4 ----------><--- Public IPv4 ---> | ||||
<-------- Public IPv6 ----------><--- Public IPv4 ---> | For NAT44 deployments (IPv4 host): | |||
<----- Private IPv4 ----------><--- Public IPv4 ---> | ||||
For NAT64 deployments (IPv6 host): | ||||
<----- Public IPv6 ----------><--- Public IPv4 ---> | ||||
Figure 2: Access network deployment with NAT | Figure 2: Access network deployment with NAT | |||
Figure 2 shows a typical deployment for IPv4-Internet access | ||||
involving a NAT-device within the service provider network. The | ||||
figure describes two scenarios: One where an IPv4-host (with a | ||||
private IPv4 address) accesses the IPv4-Internet, as well as one | ||||
where an IPv6-host accesses the IPv4-Internet. | ||||
3.2. Diameter NAPT Control Application Overview | 3.2. Diameter NAPT Control Application Overview | |||
DNCA runs between two DNCA Diameter peers. One DNCA Diameter peer | DNCA runs between two DNCA Diameter peers. One DNCA Diameter peer | |||
resides within the NAT-device, the other DNCA Diameter peer resides | resides within the NAT-device, the other DNCA Diameter peer resides | |||
within the NAT-Controller. DNCA allows per endpoint control and | within a NAT-controller (discussed in Section 3.3). DNCA allows per | |||
management of NAT within the NAT-device. Based on Diameter, DNCA | endpoint control and management of NAT within the NAT-device. Based | |||
integrates well with the suite of Diameter applications deployed for | on Diameter, DNCA integrates well with the suite of Diameter | |||
per endpoint authentication, authorization, accounting, and policy | applications deployed for per endpoint authentication, authorization, | |||
control in service provider networks. | accounting, and policy control in service provider networks. | |||
DNCA offers: | DNCA offers: | |||
o Request and answer commands to control the allowed number of NAT | o Request and answer commands to control the allowed number of NAT | |||
bindings per endpoint , to request the allocation of specific | bindings per endpoint to request the allocation of specific | |||
bindings for an endpoint, to define the address pool to be used | bindings for an endpoint, to define the address pool to be used | |||
for an endpoint. | for an endpoint. | |||
o Provides per endpoint reporting of the allocated NAT bindings. | o Provides per endpoint reporting of the allocated NAT bindings. | |||
o Provides unique identification of an endpoint on NAT-device, AAA- | o Provides unique identification of an endpoint on NAT-device, AAA- | |||
server and NAS, to simplify correlation of accounting data | server and NAS, to simplify correlation of accounting data | |||
streams. | streams. | |||
DNCA allows controlling the behavior of a NAT-device on a per | DNCA allows controlling the behavior of a NAT-device on a per | |||
endpoint basis during initial session establishment and at later | endpoint basis during initial session establishment and at later | |||
stages by providing an update procedure for already established | stages by providing an update procedure for already established | |||
sessions. Using DNCA, per endpoint NAT binding information can be | sessions. Using DNCA, per endpoint NAT binding information can be | |||
retrieved either using accounting mechanisms or through an explicit | retrieved either using accounting mechanisms or through an explicit | |||
session query to the NAT. | session query to the NAT. | |||
3.3. Deployment Scenarios For DNCA | 3.3. Deployment Scenarios For DNCA | |||
DNCA can be deployed in different ways. Two common deployment | DNCA can be deployed in different ways. DNCA supports deployments | |||
scenarios are outlined in Figure 3 ("integrated deployment") and | with "n" NAT-controllers and "m" NAT-devices, with n and m equal to | |||
Figure 4 ("autonomous deployment"). The two scenarios differ in | or greater than 1. For DNCA, the session representing a particular | |||
which entity fulfills the role of the NAT-controller. Within the | endpoint is atomic. Any deployment MUST ensure that for every given | |||
figures (C) denotes the network element performing the role of the | endpoint only a single NAT-controller and only a single NAT-device | |||
NAT-controller. | are active at any point in time. This is to ensure that NAT-devices | |||
controlled by multiple NAT-controllers do not receive conflicting | ||||
control requests for a particular endpoint, or would be unclear which | ||||
NAT-controller to send accounting information to. | ||||
Two common deployment scenarios are outlined in Figure 3 ("integrated | ||||
deployment") and Figure 4 ("autonomous deployment"). Per the note | ||||
above, multiple instances of NAT-controllers and NAT-devices could be | ||||
deployed. The figures only show single instances for reasons of | ||||
clarity. The two shown scenarios differ in which entity fulfills the | ||||
role of the NAT-controller. Within the figures (C) denotes the | ||||
network element performing the role of the NAT-controller. | ||||
The integrated deployment approach hides the existence of the NAT- | The integrated deployment approach hides the existence of the NAT- | |||
device from external servers, such as the AAA-server. It is suited | device from external servers, such as the AAA-server. It is suited | |||
for environments where minimal changes to the existing AAA deployment | for environments where minimal changes to the existing AAA deployment | |||
are desired. The NAS and the NAT-device are Diameter peers | are desired. The NAS and the NAT-device are Diameter peers | |||
supporting the DNCA. The Diameter peer within the NAS, performing | supporting the DNCA. The Diameter peer within the NAS, performing | |||
the role of the NAT-controller, initiates and manages sessions with | the role of the NAT-controller, initiates and manages sessions with | |||
the NAT-device, exchanges NAT specific configuration information and | the NAT-device, exchanges NAT specific configuration information and | |||
handles reporting and accounting information. The NAS receives | handles reporting and accounting information. The NAS receives | |||
reporting and accounting information from NAT-device. With this | reporting and accounting information from the NAT-device. With this | |||
information, the NAS can provide a single accounting record for the | information, the NAS can provide a single accounting record for the | |||
endpoint. A system correlating the accounting information received | endpoint. A system correlating the accounting information received | |||
from NAS and NAT-device would not be needed. | from the NAS and NAT-device would not be needed. | |||
An example network attachment for an integrated NAT deployment can be | An example network attachment for an integrated NAT deployment can be | |||
described as follows: An endpoint connects to the network, with the | described as follows: An endpoint connects to the network, with the | |||
NAS being the point of attachment. After successful authentication, | NAS being the point of attachment. After successful authentication, | |||
the NAS receives endpoint related authorization data from the AAA- | the NAS receives endpoint related authorization data from the AAA- | |||
server. A portion of the authorization data applies to per endpoint | server. A portion of the authorization data applies to per endpoint | |||
configuration on the NAS itself, another portion describes | configuration on the NAS itself, another portion describes | |||
authorization and configuration information for NAT control aimed at | authorization and configuration information for NAT control aimed at | |||
the NAT-device. The NAS initiates a DNCA session to the NAT-device | the NAT-device. The NAS initiates a DNCA session to the NAT-device | |||
and sends relevant authorization and configuration information for | and sends relevant authorization and configuration information for | |||
skipping to change at page 11, line 14 | skipping to change at page 12, line 14 | |||
+---------+ | +---------+ | |||
| | | | | | |||
| AAA | | | AAA | | |||
| | | | | | |||
+---------+ | +---------+ | |||
| | | | |||
| | | | |||
| | | | |||
+--------+ +---------+ +--------+ +----------+ | +--------+ +---------+ +--------+ +----------+ | |||
| IPv4/ | | (C) | | | | IPv4 | | | | | (C) | | | | | | |||
| IPv6 |----| NAS |----| NAT- |----| Internet | | | Host |----| NAS |----| NAT- |----| IPv4- | | |||
| Host | | | | device | | | | | | | | | device | | Internet | | |||
+--------+ +---------+ +--------+ +----------+ | +--------+ +---------+ +--------+ +----------+ | |||
<-------- Public IPv6 ----------><--- Public IPv4 ---> | ||||
<-------- Private IPv4 ----------><--- Public IPv4 ---> | For NAT44 deployments (IPv4 host): | |||
<----- Private IPv4 ----------><--- Public IPv4 ---> | ||||
For NAT64 deployments (IPv6 host): | ||||
<----- Public IPv6 ----------><--- Public IPv4 ---> | ||||
Figure 3: NAT control deployment: Integrated deployment | Figure 3: NAT control deployment: Integrated deployment | |||
The autonomous deployment approach decouples user management on NAS | Figure 3 shows examples of integrated deployments. The figure | |||
and NAT-device. In the autonomous deployment approach, the AAA- | describes two scenarios: One where an IPv4-host (with a private IPv4 | |||
address) accesses the IPv4-Internet, as well as one where an IPv6- | ||||
host accesses the IPv4-Internet. | ||||
The autonomous deployment approach decouples user management on the | ||||
NAS and NAT-device. In the autonomous deployment approach, the AAA- | ||||
system and the NAT-device are the Diameter peers running the DNCA. | system and the NAT-device are the Diameter peers running the DNCA. | |||
The AAA-system also serves as NAT-controller. It manages the | The AAA-system also serves as NAT-controller. It manages the | |||
connection to the NAT-device, controls the per endpoint | connection to the NAT-device, controls the per endpoint | |||
configuration, and also receives accounting and reporting information | configuration, and also receives accounting and reporting information | |||
from the NAT-device. Different from the integrated deployment | from the NAT-device. Different from the integrated deployment | |||
scenario, the autonomous deployment scenario does not "hide" the | scenario, the autonomous deployment scenario does not "hide" the | |||
existence of the NAT-device from the AAA infrastructure. Here two | existence of the NAT-device from the AAA infrastructure. Here two | |||
accounting streams are received by the AAA-server for one particular | accounting streams are received by the AAA-server for one particular | |||
endpoint, one from the NAS, and one from the NAT-device. | endpoint, one from the NAS, and one from the NAT-device. | |||
+---------+ | +---------+ | |||
| (C) | | | (C) | | |||
| AAA |--------- | | AAA |--------- | |||
| | | | | | | | |||
+---------+ | | +---------+ | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+--------+ +---------+ +---------+ +----------+ | +--------+ +---------+ +---------+ +----------+ | |||
| IPv4/ | | | | | | IPv4 | | | IPv4/ | | | | | | IPv4 | | |||
| IPv6 |----| NAS |----| NAT- |----| Internet | | | IPv6 |----| NAS |----| NAT- |----| Internet | | |||
| Host | | | | device | | | | | Host | | | | device | | | | |||
+--------+ +---------+ +---------+ +----------+ | +--------+ +---------+ +---------+ +----------+ | |||
<-------- Public IPv6 ----------><---- Public IPv4 ---> | ||||
<-------- Private IPv4 ----------><---- Public IPv4 ---> | For NAT44 deployments (IPv4 host): | |||
<----- Private IPv4 ----------><--- Public IPv4 ---> | ||||
For NAT64 deployments (IPv6 host): | ||||
<----- Public IPv6 ----------><--- Public IPv4 ---> | ||||
Figure 4: NAT control deployment: Autonomous deployment | Figure 4: NAT control deployment: Autonomous deployment | |||
Figure 4 shows examples of autonomous deployments. The figure | ||||
describes two scenarios: One where an IPv4-host (with a private IPv4 | ||||
address) accesses the IPv4-Internet, as well as one where an IPv6- | ||||
host accesses the IPv4-Internet. | ||||
4. DNCA Session Establishment and Management | 4. DNCA Session Establishment and Management | |||
Note that this section forward references some of the commands and | Note that this section forward references some of the commands and | |||
AVPs defined for DNCA. Please refer to Section 6 and Section 8 for | AVPs defined for DNCA. Please refer to Section 6 and Section 8 for | |||
details. DNCA runs between a Diameter peer residing in a NAT- | details. DNCA runs between a Diameter peer residing in a NAT- | |||
controller and a Diameter peer residing in a NAT-device. The | controller and a Diameter peer residing in a NAT-device. The | |||
Diameter peer within the NAT-controller is always the control | Diameter peer within the NAT-controller is always the control | |||
requesting entity: It initiates, updates, or terminates the sessions. | requesting entity: It initiates, updates, or terminates the sessions. | |||
Sessions are initiated when the NAT-controller learns about a new | Sessions are initiated when the NAT-controller learns about a new | |||
endpoint (i.e., host) that requires a NAT service. This could for | endpoint (i.e., host) that requires a NAT service. This could for | |||
example be due to the entity hosting the NAT-controller receiving | example be due to the entity hosting the NAT-controller receiving | |||
authentication, authorization, or accounting requests for or from the | authentication, authorization, or accounting requests for or from the | |||
endpoint. Alternate methods that could trigger session set up | endpoint. Alternate methods that could trigger session setup include | |||
include local configuration, receipt of a packet from a formerly | local configuration, receipt of a packet from a formerly unknown IP- | |||
unknown IP-address, etc. | address, etc. | |||
4.1. Session Establishment | 4.1. Session Establishment | |||
The DNCA Diameter peer within the NAT-controller establishes a | The DNCA Diameter peer within the NAT-controller establishes a | |||
session with the DNCA Diameter peer within the NAT-device to control | session with the DNCA Diameter peer within the NAT-device to control | |||
the behavior of the NAT function within the NAT-device. During | the behavior of the NAT function within the NAT-device. During | |||
session establishment, the DNCA Diameter peer within the NAT- | session establishment, the DNCA Diameter peer within the NAT- | |||
controller passes along configuration information to DNCA Diameter | controller passes along configuration information to DNCA Diameter | |||
peer within the NAT-device. The session configuration information | peer within the NAT-device. The session configuration information | |||
comprises the maximum number of bindings allowed for the endpoint | comprises the maximum number of bindings allowed for the endpoint | |||
skipping to change at page 12, line 46 | skipping to change at page 14, line 25 | |||
NAT-device with NC-Request-Type AVP set to INITIAL_REQUEST to | NAT-device with NC-Request-Type AVP set to INITIAL_REQUEST to | |||
initiate a Diameter NAT control session. On receipt of a NCR the | initiate a Diameter NAT control session. On receipt of a NCR the | |||
DNCA Diameter peer within the NAT-device sets up a new session for | DNCA Diameter peer within the NAT-device sets up a new session for | |||
the endpoint associated with the endpoint classifier(s) contained in | the endpoint associated with the endpoint classifier(s) contained in | |||
the NCR. The DNCA Diameter peer within the NAT-device notifies its | the NCR. The DNCA Diameter peer within the NAT-device notifies its | |||
DNCA Diameter peer within the NAT-controller about successful session | DNCA Diameter peer within the NAT-controller about successful session | |||
setup using a NAT-Control Answer (NCA) message with Result-Code set | setup using a NAT-Control Answer (NCA) message with Result-Code set | |||
to DIAMETER_SUCCESS. Figure 5 shows the initial protocol interaction | to DIAMETER_SUCCESS. Figure 5 shows the initial protocol interaction | |||
between the two DNCA Diameter peers. | between the two DNCA Diameter peers. | |||
The initial NAT-Control-Request may contain configuration information | The initial NAT-Control-Request MAY contain configuration information | |||
for the session, which specifies the behavior of the NAT-device for | for the session, which specifies the behavior of the NAT-device for | |||
the session. The configuration information which may be included, | the session. The configuration information that MAY be included, | |||
comprises: | comprises: | |||
o A list of NAT bindings, which should be pre-allocated for the | o A list of NAT bindings, which should be pre-allocated for the | |||
session; for example, in case a user requires a fixed external IP- | session; for example, in case a user requires a fixed external IP- | |||
address/port pair for one of his applications. | address/port pair for one of his applications. | |||
o The maximum number of NAT-bindings allowed for an endpoint. | o The maximum number of NAT-bindings allowed for an endpoint. | |||
o A description of the external IP-address pool(s) to be used for | o A description of the external IP-address pool(s) to be used for | |||
the session. | the session. | |||
o A reference to a predefined binding rule on the NAT-device, which | o A reference to a NAT Binding Predefined template on the NAT- | |||
is applied to the session. Such a predefined binding rule on the | device, which is applied to the session. Such a NAT Binding | |||
NAT-device may contain, for example, the name of the IP-address | Predefined template on the NAT-device may contain, for example, | |||
pool that external IP-addresses should be allocated from, the | the name of the IP-address pool that external IP-addresses should | |||
maximum number of bindings permitted for the endpoint, etc. | be allocated from, the maximum number of bindings permitted for | |||
the endpoint, etc. | ||||
In certain cases, the NAT-device may not be able to perform the tasks | In certain cases, the NAT-device may not be able to perform the tasks | |||
requested within the NCR. These include the following: | requested within the NCR. These include the following: | |||
o If a DNCA Diameter peer within the NAT-device receives a NCR from | o If a DNCA Diameter peer within the NAT-device receives a NCR from | |||
a DNCA Diameter peer within a NAT-controller with NC- Request-Type | a DNCA Diameter peer within a NAT-controller with NC-Request-Type | |||
AVP set to INITIAL_REQUEST that identifies an already existing | AVP set to INITIAL_REQUEST that identifies an already existing | |||
session; that is, DNCA Diameter peer and endpoint identifier match | session; that is, DNCA Diameter peer and endpoint identifier match | |||
an already existing session, the DNCA Diameter peer within the | an already existing session, the DNCA Diameter peer within the | |||
NAT-device returns NCA with Result-Code set to SESSION_EXISTS, and | NAT-device MUST return an NCA with Result-Code set to | |||
provides the Session-Id of the existing session in the Duplicate- | SESSION_EXISTS, and provide the Session-Id of the existing session | |||
Session-Id AVP. | in the Duplicate-Session-Id AVP. | |||
o If a DNCA Diameter peer within the NAT-device receives a NCR from | o If a DNCA Diameter peer within the NAT-device receives a NCR from | |||
a DNCA Diameter peer within a NAT-controller with NC- Request-Type | a DNCA Diameter peer within a NAT-controller with NC-Request-Type | |||
AVP set to INITIAL_REQUEST that matches more than one of the | AVP set to INITIAL_REQUEST that matches more than one of the | |||
already existing sessions; that is, DNCA Diameter peer and | already existing sessions; that is, DNCA Diameter peer and | |||
endpoint identifier match already existing sessions, the DNCA | endpoint identifier match already existing sessions, the DNCA | |||
Diameter peer within the NAT-device returns a NCA with Result-Code | Diameter peer within the NAT-device MUST return an NCA with | |||
set to INSUFFICIENT-CLASSIFIERS. In case a DNCA Diameter peer | Result-Code set to INSUFFICIENT-CLASSIFIERS. In case a DNCA | |||
receives a NCA that reports Insufficient-Classifiers, it may | Diameter peer receives a NCA that reports Insufficient- | |||
choose to retry establishing a new session using additional or | Classifiers, it MAY choose to retry establishing a new session | |||
more specific classifiers. | using additional or more specific classifiers. | |||
o If the NCR contains a binding rule not defined on the NAT-device, | o If the NCR contains a NAT Binding Predefined template not defined | |||
the DNCA Diameter peer within the NAT-device returns NCA with | on the NAT-device, the DNCA Diameter peer within the NAT-device | |||
Result-Code AVP set to UNKNOWN_BINDING_RULE. | MUST return an NCA with Result-Code AVP set to | |||
UNKNOWN_BINDING_TEMPLATE_NAME. | ||||
o In case the NAT-device is unable to establish all of the bindings | o In case the NAT-device is unable to establish all of the bindings | |||
requested in the NCR, the DNCA Diameter peer will return a NCA | requested in the NCR, the DNCA Diameter peer MUST return an NCA | |||
with Result-Code set to BINDING_FAILURE. A DNCA Diameter peer | with Result-Code set to BINDING_FAILURE. A DNCA Diameter peer | |||
within a NAT-device treats a NCR as an atomic operation; hence | within a NAT-device MUST treat a NCR as an atomic operation; hence | |||
none of the requested bindings will be established by the NAT- | none of the requested bindings will be established by the NAT- | |||
device. Either all requested actions within a NCR are completed | device. Either all requested actions within a NCR MUST be | |||
successfully, or the entire request fails. | completed successfully, or the entire request fails. | |||
o If a NAT-device does not have sufficient resources to process a | o If a NAT-device does not have sufficient resources to process a | |||
request, the DNCA Diameter peer returns a NCA with Result-Code set | request, the DNCA Diameter peer MUST return an NCA with Result- | |||
to RESOURCE_FAILURE. | Code set to RESOURCE_FAILURE. | |||
o In case Max-NAT-Binding and NAT-Control-Definition are included in | o In case Max-NAT-Binding, NAT-Control-Definition as well as NAT- | |||
the NCR along with a reference to a binding rule; that is, a | Control-Binding-Template are included in the NCR, and the values | |||
predefined template on NAT-device, and the values in Max-NAT- | in Max-NAT-Binding and NAT-Control-Definition contradict those | |||
Binding and NAT-Control-Definition contradict those specified in | specified in the pre-provisioned template on the NAT-device which | |||
the pre-defined binding rule, Max-NAT-Binding and NAT-Control- | NAT-Control-Binding-Template references, Max-NAT-Binding and NAT- | |||
Definition override the values specified in the binding rule. | Control-Definition MUST override the values specified in the | |||
template that NAT-Control-Binding-Template refers to. | ||||
NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
Trigger | | Trigger | | |||
| | | | | | |||
| NCR | | | NCR | | |||
|------------------------------------------>| | |------------------------------------------>| | |||
| (INITIAL_REQUEST, endpoint classifier, | | ||||
| session id, NAT control config data) | | ||||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| If Able to comply | | If Able to comply | |||
| with Request then | | with Request then | |||
| Create session state | | Create session state | |||
| | | | | | |||
| | | | | | |||
| NCA | | | NCA | | |||
|<------------------------------------------| | |<------------------------------------------| | |||
| (result code) | | ||||
| | | | | | |||
| | | | | | |||
Figure 5: Initial NAT control request and session establishment | Figure 5: Initial NAT control request and session establishment | |||
Note: The DNCA Diameter peer within the NAT-device creates session | Note: The DNCA Diameter peer within the NAT-device creates session | |||
state only if it is able to comply with the NCR. On success it will | state only if it is able to comply with the NCR. On success it will | |||
reply with a NCA with Result-Code set to DIAMETER_SUCCESS. | reply with an NCA with Result-Code set to DIAMETER_SUCCESS. | |||
4.2. Session Re-Authorization | 4.2. Session Re-Authorization | |||
Session re-authorization is performed if the NAT-controller desires | Session re-authorization is performed if the NAT-controller desires | |||
to change the behavior of the NAT-device for an existing session. | to change the behavior of the NAT-device for an existing session. | |||
Session re-authorization could be used, for example, to change the | Session re-authorization could be used, for example, to change the | |||
number of allowed bindings for a particular session, or establish or | number of allowed bindings for a particular session, or establish or | |||
remove a pre-defined binding. | remove a pre-defined binding. | |||
The DNCA Diameter peer within the NAT-controller generates a NCR | The DNCA Diameter peer within the NAT-controller generates a NCR | |||
message to DNCA Diameter peer within NAT-device with NC-Request-Type | message to the DNCA Diameter peer within the NAT-device with NC- | |||
AVP set to UPDATE_REQUEST upon receiving a trigger signal. If the | Request-Type AVP set to UPDATE_REQUEST upon receiving a trigger | |||
session is updated successfully, the DNCA Diameter peer within the | signal. If the session is updated successfully, the DNCA Diameter | |||
NAT-device notifies the DNCA Diameter peer within the NAT-controller | peer within the NAT-device notifies the DNCA Diameter peer within the | |||
about the successful session update using a NAT-Control Answer (NCA) | NAT-controller about the successful session update using a NAT- | |||
message with Result-Code set to DIAMETER_SUCCESS. Figure 6 shows the | Control Answer (NCA) message with Result-Code set to | |||
protocol interaction between the two DNCA Diameter peers. | DIAMETER_SUCCESS. Figure 6 shows the protocol interaction between | |||
the two DNCA Diameter peers. | ||||
In certain cases, the NAT-device may not be able to perform the tasks | In certain cases, the NAT-device may not be able to perform the tasks | |||
requested within the NCR. These include the following: | requested within the NCR. These include the following: | |||
o If DNCA Diameter peer within a NAT-device receives a NCR update or | o If DNCA Diameter peer within a NAT-device receives an NCR update | |||
query request for a non-existent session, it sets Result-Code in | or query request for a non-existent session, it MUST set Result- | |||
the answer to DIAMETER_UNKNOWN_SESSION_ID. | Code in the answer to DIAMETER_UNKNOWN_SESSION_ID. | |||
o If the NCR contains a binding rule not defined on the NAT-device, | o If the NCR contains a NAT Binding Predefined template not defined | |||
a NCA with Result-Code AVP set to UNKNOWN_BINDING_RULE is | on the NAT-device, an NCA with Result-Code AVP set to | |||
returned. | UNKNOWN_BINDING_TEMPLATE_NAME MUST be returned. | |||
o If the NAT-device cannot establish the requested binding because | o If the NAT-device cannot establish the requested binding because | |||
the maximum number of allowed bindings has been reached for the | the maximum number of allowed bindings has been reached for the | |||
endpoint classifier, a NCA with Result-Code AVP set to | endpoint classifier, an NCA with Result-Code AVP set to | |||
MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT by the DNCA Diameter peer. | MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT MUST be returned to the DNCA | |||
Diameter peer. | ||||
o If the NAT-device cannot establish some or all of the bindings | o If the NAT-device cannot establish some or all of the bindings | |||
requested in a NCR, but has not yet reached the maximum number of | requested in an NCR, but has not yet reached the maximum number of | |||
allowed bindings for the endpoint, a NCA with Result-Code set to | allowed bindings for the endpoint, an NCA with Result-Code set to | |||
BINDING_FAILURE is returned. As already noted, the DNCA Diameter | BINDING_FAILURE MUST be returned. As already noted, the DNCA | |||
peer in a NAT-device treats a NCR as an atomic operation. Hence | Diameter peer in a NAT-device MUST treat an NCR as an atomic | |||
none of the requested bindings will be established by the NAT- | operation. Hence none of the requested bindings will be | |||
device in case of failure. Actions requested within a NCR are | established by the NAT-device in case of failure. Actions | |||
either all successful or all fail. | requested within a NCR are either all successful or all fail. | |||
o If the NAT-device does not have sufficient resources to process a | o If the NAT-device does not have sufficient resources to process a | |||
request, a NCA with Result-Code set to RESOURCE_FAILURE is | request, an NCA with Result-Code set to RESOURCE_FAILURE MUST be | |||
returned. | returned. | |||
o If a NCR redefines the maximum number of NAT-bindings allowed for | o If an NCR redefines the maximum number of NAT-bindings allowed for | |||
the endpoint, the new value will override any previously defined | the endpoint, the new value MUST override any previously defined | |||
limit on NAT bindings. It depends on the implementation of the | limit on NAT bindings. It depends on the implementation of the | |||
NAT-device on how the NAT-device copes with a case where the new | NAT-device on how the NAT-device copes with a case where the new | |||
value is lower than the actual number of allocated bindings. | value is lower than the actual number of allocated bindings. The | |||
Typically the NAT-device refrains from enforcing the new limit | NAT-device MAY refrain from enforcing the new limit immediately | |||
immediately; that is, actively remove bindings, but rather | (that is, actively remove bindings), but rather disallows the | |||
disallow the establishment of new bindings until the current | establishment of new bindings until the current number of bindings | |||
number of bindings is lower than the newly established maximum | is lower than the newly established maximum number of allowed | |||
number of allowed bindings. | bindings. | |||
o If a NCR specifies a new binding rule, predefined on the NAT- | o If an NCR specifies a new NAT Binding Predefined template on the | |||
device, the binding rule overrides any previously defined rule for | NAT-device, the NAT Binding Predefined template overrides any | |||
the session. | previously defined rule for the session. | |||
o If Max-NAT-Binding and NAT-Control-Definition AVPs are included in | o In case Max-NAT-Binding, NAT-Control-Definition as well as NAT- | |||
the NCR along with a reference to a binding rule (a predefined | Control-Binding-Template are included in the NCR, and the values | |||
template on the NAT-device) and the values in Max-NAT-Binding and | in Max-NAT-Binding and NAT-Control-Definition contradict those | |||
NAT-Control-Definition AVPs contradict those specified in the pre- | specified in the pre-provisioned template on the NAT-device which | |||
defined binding rule, Max-NAT-Binding and NAT-Control-Definition | NAT-Control-Binding-Template references, Max-NAT-Binding and NAT- | |||
AVPs override the values specified in the binding rule. | Control-Definition MUST override the values specified in the | |||
template that the NAT-Control-Binding-Template refers to. | ||||
Note: Already established bindings for the session will not be | Note: Already established bindings for the session SHOULD NOT be | |||
affected in case the tasks requested within the NCR cannot be | affected in case the tasks requested within the NCR cannot be | |||
completed. | completed. | |||
NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
Change of session | | Change of session | | |||
attributes | | attributes | | |||
| | | | | | |||
| NCR | | | NCR | | |||
|------------------------------------------>| | |------------------------------------------>| | |||
| (UPDATE_REQUEST session id, | | ||||
| NAT control config data) | | ||||
| | | | | | |||
| | | | | | |||
| If able to comply | | If able to comply | |||
| with the request: | | with the request: | |||
| Update session state | | Update session state | |||
| | | | | | |||
| | | | | | |||
| NCA | | | NCA | | |||
|<------------------------------------------| | |<------------------------------------------| | |||
| (result code) | | ||||
| | | ||||
| | | | | | |||
Figure 6: NAT control request for session update | Figure 6: NAT control request for session update | |||
4.3. Session and Binding Query | 4.3. Session and Binding Query | |||
Session query can be used by the DNCA Diameter peer within the NAT- | A Session and NAT-binding query MAY be used by the DNCA Diameter peer | |||
controller to either retrieve information on the current bindings for | within the NAT-controller to either retrieve information on the | |||
a particular session at the NAT-device or discover the session | current bindings for a particular session at the NAT-device or | |||
identifier for a particular external IP address/port pair. | discover the session identifier for a particular external IP address/ | |||
port pair. | ||||
A DNCA Diameter peer within the NAT-controller starts a session query | A DNCA Diameter peer within the NAT-controller starts a session query | |||
by sending a NCR message with NC-Request-Type AVP set to | by sending an NCR message with NC-Request-Type AVP set to | |||
QUERY_REQUEST. Figure 7 shows the protocol interaction between the | QUERY_REQUEST. Figure 7 shows the protocol interaction between the | |||
DNCA Diameter peers. | DNCA Diameter peers. | |||
Two types of query requests exist. The first type of query request | Two types of query requests exist. The first type of query request | |||
uses the session ID as input parameter to the query. It is to allow | uses the session ID as input parameter to the query. It is to allow | |||
the DNCA Diameter peer within the NAT-controller to retrieve the | the DNCA Diameter peer within the NAT-controller to retrieve the | |||
current set of bindings for a specific session. The second type of | current set of bindings for a specific session. The second type of | |||
query request is used to retrieve the session identifiers, along with | query request is used to retrieve the session identifiers, along with | |||
the associated bindings, matching a criteria. This enables the DNCA | the associated bindings, matching a criteria. This enables the DNCA | |||
Diameter peer within the NAT-controller to find those sessions, which | Diameter peer within the NAT-controller to find those sessions, which | |||
utilize a specific external IP-address. | utilize a specific external IP-address. | |||
1. Request a list of currently allocated NAT bindings for a | 1. Request a list of currently allocated NAT bindings for a | |||
particular session: On receiving a NCR, the NAT-device looks up | particular session: On receiving a NCR, the NAT-device SHOULD | |||
the session information for the session ID contained in the NCR, | look up the session information for the session ID contained in | |||
and reports all currently active NAT-bindings for the session | the NCR, and report all currently active NAT-bindings for the | |||
using a NCA message with Result-Code set to DIAMETER_SUCCESS. In | session using an NCA message with Result-Code set to | |||
this case the NCR MUST NOT contain a NAT-Control-Definition AVP. | DIAMETER_SUCCESS. In this case the NCR MUST NOT contain a NAT- | |||
Each NAT-binding is reported in a NAT-Control-Definition AVP. In | Control-Definition AVP. Each NAT-binding is reported in a NAT- | |||
case the session ID is unknown, the DNCA Diameter peer within the | Control-Definition AVP. In case the session ID is unknown, the | |||
NAT-device returns NCA with Result-Code set to | DNCA Diameter peer within the NAT-device MUST return an NCA | |||
DIAMETER_UNKNOWN_SESSION_ID. | message with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. | |||
2. Retrieve session IDs and internal IP address/port pairs for one | 2. Retrieve session IDs and internal IP address/port pairs for one | |||
or multiple external IP-address/port pairs: If the DNCA Diameter | or multiple external IP-address/port pairs: If the DNCA Diameter | |||
peer within the NAT-controller wishes to retrieve the session | peer within the NAT-controller wishes to retrieve the session | |||
ID(s) for one or multiple external IP-address/port pairs, it MUST | ID(s) for one or multiple external IP-address/port pairs, it MUST | |||
include the external IP-address/port pair(s) as part of the NAT- | include the external IP-address/port pair(s) as part of the NAT- | |||
Control-Definition AVP of the NCR. The session ID is not | Control-Definition AVP of the NCR. The external IP-address/port | |||
included in the NCR or the NCA for this type of a query. The | pair(s) are pre-known to the controller via configuration, AAA | |||
DNCA Diameter peer within the NAT-device reports the NAT-bindings | interactions, or other means. The session ID is not included in | |||
and associated session IDs corresponding to the external IP- | the NCR or the NCA for this type of a query. The DNCA Diameter | |||
address/port pairs in a NCA message with Result-Code set to | peer within the NAT-device SHOULD report the NAT-bindings and | |||
DIAMETER_SUCCESS with the same session ID, which was used in NCR. | associated session IDs corresponding to the external IP-address/ | |||
In case an external IP-address/port pair has no associated | port pairs in an NCA message using one or multiple instances of | |||
existing NAT-binding, the NAT-Control-Definition AVP contained in | the NAT-Control-Definition AVP. The Result-Code is set to | |||
the reply just contains the NAT-External-Address AVP. | DIAMETER_SUCCESS. In case an external IP-address/port pair has | |||
no associated existing NAT-binding, the NAT-Control-Definition | ||||
AVP contained in the reply just contains the NAT-External-Address | ||||
AVP. | ||||
NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
DNCA Session Established | | DNCA Session Established | | |||
| | | | | | |||
| NCR | | | NCR | | |||
|------------------------------------------>| | |------------------------------------------>| | |||
| (QUERY_REQUEST) | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| Look up corresponding session | | Look up corresponding session | |||
| and associated NAT-bindings | | and associated NAT-bindings | |||
| | | | | | |||
| NCA | | | NCA | | |||
|<------------------------------------------| | |<------------------------------------------| | |||
| (Result-Code) | | | | | |||
| | | | | | |||
| | | | | | |||
Figure 7: Session query | Figure 7: Session query | |||
4.4. Session Termination | 4.4. Session Termination | |||
Similar to session initiation, session tear down is always initiated | Similar to session initiation, session tear down MUST be initiated by | |||
by the DNCA Diameter peer within the NAT-controller. The DNCA | the DNCA Diameter peer within the NAT-controller. The DNCA Diameter | |||
Diameter peer sends a Session Terminate Request (STR) message to its | peer sends a Session Terminate Request (STR) message to its peer | |||
peer within the NAT-device upon receiving a trigger signal. The | within the NAT-device upon receiving a trigger signal. The source of | |||
source of the trigger signal is outside the scope of this document. | the trigger signal is outside the scope of this document. As part of | |||
In response, the DNCA Diameter peer within the NAT-device sends an | STR message processing the DNCA Diameter peer within the NAT-device | |||
accounting stop record reporting all bindings and notifies its DNCA | MAY send an accounting stop record reporting all bindings. All the | |||
Diameter peer about successful session termination using a Session | NAT-bindings belonging to the session are removed and the session | |||
Terminate Answer (STA) message with Result-Code set to | state is cleaned up. The DNCA Diameter peer within the NAT-device | |||
DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between | MUST notify its DNCA Diameter peer in the NAT-controller about | |||
the two DNCA Diameter peers. | successful session termination using a Session Terminate Answer (STA) | |||
message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the | ||||
protocol interaction between the two DNCA Diameter peers. | ||||
If a DNCA Diameter peer within a NAT-device receives a STR and fails | If a DNCA Diameter peer within a NAT-device receives a STR and fails | |||
to find a matching session, the DNCA Diameter peer returns a STA with | to find a matching session, the DNCA Diameter peer MUST return a STA | |||
Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. | with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. | |||
NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | |||
| | | | | | |||
| | | | | | |||
Trigger | | Trigger | | |||
| | | | | | |||
| STR | | | STR | | |||
|------------------------------------------->| | |------------------------------------------->| | |||
| (session id) | | ||||
| | | | | | |||
| | | | | | |||
| Remove NAT-bindings | | | | |||
| of session | ||||
| | | | | | |||
| | | | | | |||
| Send accounting stop | | | Send accounting stop | | |||
|<-------------------------------------------| | |<-------------------------------------------| | |||
| reporting all session bindings | | | reporting all session bindings | | |||
| | | | | | |||
| | | ||||
| Remove NAT-bindings | ||||
| of session | ||||
| | | ||||
| Terminate session / | | Terminate session / | |||
| Remove session state | | Remove session state | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| STA | | | STA | | |||
|<-------------------------------------------| | |<-------------------------------------------| | |||
| (Result-Code) | | | | | |||
| | | | | | |||
Figure 8: Terminate NAT control session | Figure 8: Terminate NAT control session | |||
4.5. Session Abort | 4.5. Session Abort | |||
An Abort-Session-Request (ASR) message is sent from the DNCA Diameter | An Abort-Session-Request (ASR) message is sent from the DNCA Diameter | |||
peer within the NAT-device to the DNCA Diameter peer within the NAT- | peer within the NAT-device to the DNCA Diameter peer within the NAT- | |||
controller when it is unable to maintain a session due to resource | controller when it is unable to maintain a session due to resource | |||
limitations. The DNCA Diameter peer within the NAT-controller | limitations. The DNCA Diameter peer within the NAT-controller MUST | |||
acknowledges successful session abort using a Abort Session Answer | acknowledge successful session abort using a Abort Session Answer | |||
(ASA) message with Result-Code set to DIAMETER_SUCCESS. Figure 9 | (ASA) message with Result-Code set to DIAMETER_SUCCESS. Figure 9 | |||
shows the protocol interaction between the DNCA Diameter peers. The | shows the protocol interaction between the DNCA Diameter peers. The | |||
DNCA Diameter peers will start a session termination procedure as | DNCA Diameter peers will start a session termination procedure as | |||
described in Section 4.4 following an ASA with Result-Code set to | described in Section 4.4 following an ASA with Result-Code set to | |||
DIAMETER_SUCCESS. | DIAMETER_SUCCESS. | |||
If the DNCA Diameter peer within a NAT-controller receives an ASR but | If the DNCA Diameter peer within a NAT-controller receives an ASR but | |||
fails to find a matching session, it returns an ASA with Result-Code | fails to find a matching session, it MUST return an ASA with Result- | |||
set to DIAMETER_UNKNOWN_SESSION_ID. If the DNCA Diameter peer within | Code set to DIAMETER_UNKNOWN_SESSION_ID. If the DNCA Diameter peer | |||
the NAT-controller is unable to comply with the ASR for any other | within the NAT-controller is unable to comply with the ASR for any | |||
reason, an ASA with Result-Code set to DIAMETER_UNABLE_TO_COMPLY is | other reason, an ASA with Result-Code set to | |||
returned. | DIAMETER_UNABLE_TO_COMPLY MUST be returned. | |||
NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) | |||
| | | | | | |||
| | | | | | |||
| Trigger | | Trigger | |||
| | | | | | |||
| ASR | | | ASR | | |||
|<-------------------------------------------| | |<-------------------------------------------| | |||
| (session id) | | | | | |||
| | | | | | |||
| | | | | | |||
| ASA | | | ASA | | |||
|------------------------------------------->| | |------------------------------------------->| | |||
| (Result-Code) | | | | | |||
| | | | | | |||
| | | | | | |||
| On successful ASA | | | On successful ASA | | |||
|<------Session Termination Procedure------->| | |<------Session Termination Procedure------->| | |||
Figure 9: Abort NAT control session | Figure 9: Abort NAT control session | |||
4.6. Failure cases of the DNCA Diameter peers | 4.6. Failure cases of the DNCA Diameter peers | |||
This document does not specify the behavior in case NAT-device and | This document does not specify the behavior in case the NAT-device | |||
NAT-controller, or their respective DNCA Diameter peers are out of | and NAT-controller, or their respective DNCA Diameter peers are out | |||
sync. This could happen for example if one of the entities restarts, | of sync or lose state. This could happen for example if one of the | |||
in case of a (temporary) loss of network connectivity etc. The | entities restarts, in case of a (temporary) loss of network | |||
peering entities MUST have built-in redundancy support to recover | connectivity etc. Example failure cases include the following: | |||
state in case of failure. | ||||
Example failure cases include the following: | ||||
o NAT-controller and the DNCA Diameter peer within the NAT- | o NAT-controller and the DNCA Diameter peer within the NAT- | |||
controller lose state (e.g. due to a restart). In this case, | controller lose state (e.g., due to a restart). In this case, | |||
* the DNCA Diameter peer within the NAT-device may receive a NCR | * the DNCA Diameter peer within the NAT-device MAY receive an NCR | |||
with NC-Request-Type AVP set to INITIAL_REQUEST that matches an | with NC-Request-Type AVP set to INITIAL_REQUEST that matches an | |||
existing session of the DNCA Diameter peer within the NAT- | existing session of the DNCA Diameter peer within the NAT- | |||
device. The DNCA Diameter peer within the NAT-device returns a | device. The DNCA Diameter peer within the NAT-device MUST | |||
Result-Code that contains Duplicate-Session-Id AVP to report | return Result-Code that contains Duplicate-Session-Id AVP to | |||
the Session-ID of the existing session. The DNCA Diameter peer | report the Session-ID of the existing session. The DNCA | |||
within the NAT-controller may send an explicit Session | Diameter peer within the NAT-controller MAY send an explicit | |||
Terminate Request (STR) for the older session, which was lost. | Session Terminate Request (STR) for the older session, which | |||
was lost. | ||||
* a DNCA Diameter peer may receive accounting records for a | * a DNCA Diameter peer MAY receive accounting records for a | |||
session that does not exist. The DNCA Diameter peer sends an | session that does not exist. The DNCA Diameter peer sends an | |||
accounting answer with Result-Code set to | accounting answer with Result-Code set to | |||
DIAMETER_UNKNOWN_SESSION_ID in response. On receiving the | DIAMETER_UNKNOWN_SESSION_ID in response. On receiving the | |||
response, the DNCA Diameter peer clears the session and removes | response, the DNCA Diameter peer SHOULD clear the session and | |||
the associated session state. | remove associated session state. | |||
o NAT-device and the DNCA Diameter peer within NAT-device lose | o NAT-device and the DNCA Diameter peer within NAT-device lose | |||
state. In such a case, the DNCA Diameter peer may receive a NCR | state. In such a case, the DNCA Diameter peer MAY receive a NCR | |||
with NC-Request-Type AVP set to UPDATE_REQUEST for a non-existent | with NC-Request-Type AVP set to UPDATE_REQUEST for a non-existent | |||
session. The DNCA Diameter peer returns NCA with Result-Code set | session. The DNCA Diameter peer MUST return an NCA with Result- | |||
to DIAMETER_UNKNOWN_SESSION_ID. | Code set to DIAMETER_UNKNOWN_SESSION_ID. | |||
o The DNCA Diameter peer within the NAT-controller is unreachable, | o The DNCA Diameter peer within the NAT-controller is unreachable, | |||
for example detected by Diameter watchdog, or down and accounting | for example detected by Diameter device watchdog messages (as | |||
defined in Section 5.5 of [RFC3588]), or down and accounting | ||||
requests from the DNCA Diameter peer fail to get a response. The | requests from the DNCA Diameter peer fail to get a response. The | |||
mechanism to ensure that a DNCA Diameter peer within the NAT- | mechanism to ensure that a DNCA Diameter peer within the NAT- | |||
controller no longer has associated state for a session which was | controller no longer has associated state for a session which was | |||
cleared or removed by the DNCA Diameter peer within the NAT-device | cleared or removed by the DNCA Diameter peer within the NAT-device | |||
is beyond the scope of this document. | is beyond the scope of this document. | |||
o The DNCA Diameter peer within the NAT-device is unreachable or | o The DNCA Diameter peer within the NAT-device is unreachable or | |||
down and NCR requests fail to get a response. Handling of this | down and NCR fails to get a response. Handling of this case | |||
case depends on the actual service offering of the service | depends on the actual service offering of the service provider. | |||
provider. The service provider could for example choose to stop | The service provider could for example choose to stop offering | |||
offering connectivity service. | connectivity service. | |||
5. Use Of The Diameter Base Protocol | 5. Use of the Diameter Base Protocol | |||
The Diameter Base Protocol defined by [RFC3588] applies with the | The Diameter Base Protocol defined by [RFC3588] applies with the | |||
clarifications listed in the present specification. | clarifications listed in the present specification. | |||
5.1. Securing Diameter Messages | 5.1. Securing Diameter Messages | |||
For secure transport of Diameter messages recommendations in | For secure transport of Diameter messages, the recommendations in | |||
[RFC3588] apply. | [RFC3588] apply. | |||
DNCA Diameter peers MAY verify their identity during the Capabilities | DNCA Diameter peers SHOULD verify their identity during the | |||
Exchange Request procedure. | Capabilities Exchange Request procedure. | |||
A DNCA Diameter peer within the NAT-device MAY verify that a DNCA | A DNCA Diameter peer within the NAT-device SHOULD verify that a DNCA | |||
Diameter peer that issues a NCR command is allowed to do so based on: | Diameter peer that issues a NCR command is allowed to do so based on: | |||
o The identity of the DNCA Diameter peer | o The identity of the DNCA Diameter peer | |||
o The type of NCR Command | o The type of NCR Command | |||
o The content of the NCR Command | o The content of the NCR Command | |||
o Any combination of the above | o Any combination of the above | |||
5.2. Accounting Functionality | 5.2. Accounting Functionality | |||
Accounting functionality (accounting session state machine, related | Accounting functionality (accounting session state machine, related | |||
command codes and AVPs) is defined in Section 9 below. | command codes and AVPs) is defined in Section 9 below. | |||
5.3. Use Of Sessions | 5.3. Use of Sessions | |||
Each DNCA session MUST have a globally unique Session-ID as defined | Each DNCA session MUST have a globally unique Session-ID as defined | |||
in [RFC3588], which MUST NOT be changed during the lifetime of a DNCA | in [RFC3588], which MUST NOT be changed during the lifetime of a DNCA | |||
session. The Diameter Session-ID serves as the global endpoint | session. The Diameter Session-ID serves as the global endpoint | |||
identifier. The DNCA Diameter peers maintain state associated with | identifier. The DNCA Diameter peers maintain state associated with | |||
the Session-ID. This globally unique Session-ID is used for | the Session-ID. This globally unique Session-ID is used for | |||
updating, accounting, and terminating the session. DNCA session MUST | updating, accounting, and terminating the session. A DNCA session | |||
NOT have more than one outstanding request at any given instant. A | MUST NOT have more than one outstanding request at any given instant. | |||
DNCA Diameter peer sends an Abort-Session-Request as defined in | A DNCA Diameter peer sends an Abort-Session-Request as defined in | |||
[RFC3588] if it is unable to maintain sessions due to resource | [RFC3588] if it is unable to maintain sessions due to resource | |||
limitation. | limitation. | |||
5.4. Routing Considerations | 5.4. Routing Considerations | |||
It is assumed that the DNCA Diameter peer within a NAT-controller | It is assumed that the DNCA Diameter peer within a NAT-controller | |||
knows the DiameterIdentity of the Diameter peer within a NAT-device | knows the DiameterIdentity of the Diameter peer within a NAT-device | |||
for a given endpoint. Both the Destination-Realm and Destination- | for a given endpoint. Both the Destination-Realm and Destination- | |||
Host AVPs are present in the request from a DNCA Diameter peer within | Host AVPs are present in the request from a DNCA Diameter peer within | |||
a NAT-controller to a DNCA Diameter peer within a NAT-device. | a NAT-controller to a DNCA Diameter peer within a NAT-device. | |||
skipping to change at page 23, line 6 | skipping to change at page 25, line 6 | |||
bindings. | bindings. | |||
6.1. NAT-Control Request (NCR) Command | 6.1. NAT-Control Request (NCR) Command | |||
The NAT-Control Request (NCR) command, indicated by the command field | The NAT-Control Request (NCR) command, indicated by the command field | |||
set to TBD and the "R" bit set in the Command Flags field, is sent | set to TBD and the "R" bit set in the Command Flags field, is sent | |||
from the DNCA Diameter peer within the NAT-controller to the DNCA | from the DNCA Diameter peer within the NAT-controller to the DNCA | |||
Diameter peer within the NAT-device in order to install NAT-bindings. | Diameter peer within the NAT-device in order to install NAT-bindings. | |||
User-Name, Logical-Access-Id, Physical-Access-ID, Framed-IP-Address, | User-Name, Logical-Access-Id, Physical-Access-ID, Framed-IP-Address, | |||
Framed-IPv6-Prefix , Framed-Interface-Id, EGRESS-VLANID, NAS-Port-ID, | Framed-IPv6-Prefix, Framed-Interface-Id, EGRESS-VLANID, NAS-Port-ID, | |||
Address-Realm, Calling-Station-ID AVPs serve as identifiers for the | Address-Realm, Calling-Station-ID AVPs serve as identifiers for the | |||
endpoint. | endpoint. | |||
Message format: | Message format: | |||
< NC-Request > ::= < Diameter Header: TBD, REQ, PXY> | < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> | |||
[ Session-Id ] | [ Session-Id ] | |||
{ Auth-Application-Id } | { Auth-Application-Id } | |||
{ Origin-Host } | { Origin-Host } | |||
{ Origin-Realm } | { Origin-Realm } | |||
{ Destination-Realm } | { Destination-Realm } | |||
skipping to change at page 24, line 30 | skipping to change at page 26, line 30 | |||
[ Redirect-Host-Usage ] | [ Redirect-Host-Usage ] | |||
[ Redirect-Max-Cache-Time ] | [ Redirect-Max-Cache-Time ] | |||
* [ Proxy-Info ] | * [ Proxy-Info ] | |||
* [ Route-Record ] | * [ Route-Record ] | |||
* [ Failed-AVP ] | * [ Failed-AVP ] | |||
* [ AVP ] | * [ AVP ] | |||
7. NAT Control Application Session State Machine | 7. NAT Control Application Session State Machine | |||
This section contains a set of finite state machines, representing | This section contains a set of finite state machines, representing | |||
the life cycle of DNCA session, which MUST be observed by all | the life cycle of a DNCA session, which MUST be observed by all | |||
implementations of the DNCA Diameter application. The DNCA Diameter | implementations of the DNCA Diameter application. The DNCA Diameter | |||
peers are stateful and the state machine maintained is similar to the | peers are stateful and the state machine maintained is similar to the | |||
stateful Client and Server authorization state machine described in | stateful Client and Server authorization state machine described in | |||
[RFC3588]. When a session is moved to the Idle state, any resources | [RFC3588]. When a session is moved to the Idle state, any resources | |||
that were allocated for the particular session must be released. Any | that were allocated for the particular session must be released. Any | |||
event not listed in the state machines MUST be considered as an error | event not listed in the state machines MUST be considered as an error | |||
condition, and an answer, if applicable, MUST be returned to the | condition, and an answer, if applicable, MUST be returned to the | |||
originator of the message. | originator of the message. | |||
In the state table, the event 'Failure to send NCR' means that the | In the state table, the event 'Failure to send NCR' means that the | |||
DNCA Diameter peer within the NAT-controller is unable to send the | DNCA Diameter peer within the NAT-controller is unable to send the | |||
NCR command to the desired destination. This could be due to the | NCR command to the desired destination. This could be due to the | |||
peer being down, or due to the peer sending back the transient | peer being down, or due to the peer sending back the transient | |||
failure or temporary protocol error notification DIAMETER_TOO_BUSY or | failure or temporary protocol error notification DIAMETER_TOO_BUSY or | |||
DIAMETER_LOOP_DETECTED in the Result-Code AVP of NCA. | DIAMETER_LOOP_DETECTED in the Result-Code AVP of an NCA. | |||
In the state table "FAILED NCA" means that the DNCA Diameter peer | In the state table "FAILED NCA" means that the DNCA Diameter peer | |||
within the NAT-device was not able to honor the corresponding NCR. | within the NAT-device was not able to honor the corresponding NCR. | |||
This can happen due to any transient and permanent error at the NAT- | This can happen due to any transient and permanent error at the NAT- | |||
device or its associated DNCA Diameter peer within indicated by the | device or its associated DNCA Diameter peer within indicated by the | |||
following error Result-Code values: RESOURCE_FAILURE, | following error Result-Code values: RESOURCE_FAILURE, | |||
UNKNOWN_BINDING_RULE_NAME, BINDING_FAILURE, | UNKNOWN_BINDING_TEMPLATE_NAME, BINDING_FAILURE, | |||
MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, SESSION_EXISTS, | MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, SESSION_EXISTS, | |||
INSUFFICIENT_CLASSIFIERS. | INSUFFICIENT_CLASSIFIERS. | |||
The following state machine is observed by a DNCA Diameter peer | The following state machine is observed by a DNCA Diameter peer | |||
within a NAT-controller. The state machine description uses the term | within a NAT-controller. The state machine description uses the term | |||
"access session" to describe the connectivity service offered to the | "access session" to describe the connectivity service offered to the | |||
endpoint or host. "Access session" should not be confused with the | endpoint or host. "Access session" should not be confused with the | |||
Diameter session ID. | Diameter session ID. | |||
DNCA Diameter peer within a NAT-controller | DNCA Diameter peer within a NAT-controller | |||
skipping to change at page 25, line 32 | skipping to change at page 27, line 32 | |||
Idle ASR Received Send ASA Idle | Idle ASR Received Send ASA Idle | |||
for unknown session with | for unknown session with | |||
Result-Code | Result-Code | |||
= UNKNOWN_ | = UNKNOWN_ | |||
SESSION_ID | SESSION_ID | |||
Pending Successful NCA Setup Open | Pending Successful NCA Setup Open | |||
received complete | received complete | |||
Pending Successful NCA Sent STR Discon | Pending Successful NCA Send STR Discon | |||
received | received | |||
but peer unable to provide | but peer unable to provide | |||
service | service | |||
Pending Error processing successful Sent STR Discon | Pending Error processing successful Send STR Discon | |||
NCA | NCA | |||
Pending Failed Cleanup Idle | Pending Failed Clean up Idle | |||
NCA received | NCA received | |||
Open NAT control Send Open | Open NAT control Send Open | |||
update required NCR Update | update required NCR Update | |||
Request | Request | |||
Open Successful Open | Open Successful Open | |||
NCA received | NCA received | |||
Open Failed Cleanup Idle | Open Failed Clean up Idle | |||
NCA received. | NCA received | |||
Open Access session end detected Send STR Discon | Open Access session end detected Send STR Discon | |||
Open ASR Received, Send ASA Discon | Open ASR Received, Send ASA Discon | |||
access session will be with | access session will be with | |||
terminated Result-Code | terminated Result-Code | |||
= SUCCESS, | = SUCCESS, | |||
Send STR. | Send STR | |||
Open ASR Received, Send ASA Open | Open ASR Received, Send ASA Open | |||
access session will not with | access session will not with | |||
be terminated Result-Code | be terminated Result-Code | |||
!= SUCCESS | != SUCCESS | |||
Discon ASR Received Send ASA Idle | Discon ASR Received Send ASA Idle | |||
Discon STA Received Discon. Idle | Discon STA Received Discon. Idle | |||
user/device | user/device | |||
The following state machine is observed by a DNCA Diameter peer | The following state machine is observed by a DNCA Diameter peer | |||
within a NAT-device. | within a NAT-device. | |||
DNCA Diameter peer within a NAT-device | DNCA Diameter peer within a NAT-device | |||
State Event Action New State | State Event Action New State | |||
------------------------------------------------------------- | ------------------------------------------------------------- | |||
Idle NCR request Send Open | Idle NCR Query request Send Idle | |||
received, and successful | received, and successful | |||
able to provide requested NCA | able to provide requested NCA | |||
NAT Binding report | ||||
Idle NCR received Send Open | ||||
and able to successful | ||||
provide requested NCA | ||||
NAT control service | NAT control service | |||
Idle NCR request Send Idle | Idle NCR request Send Idle | |||
received, and failed | received, and failed | |||
unable to provide requested NCA | unable to provide requested NCA | |||
NAT control service | NAT control service | |||
Open NCR request Send Open | Open NCR request Send Open | |||
received, and successful | received, and successful | |||
able to provide requested NCA | able to provide requested NCA | |||
NAT control service | NAT control service | |||
Open NCR request Send Idle | Open NCR request Send Idle | |||
received, and failed | received, and failed | |||
unable to provide requested NCA, | unable to provide requested NCA, | |||
NAT control service Cleanup | NAT control service Clean up | |||
Open Unable to continue Send ASR Discon | Open Unable to continue Send ASR Discon | |||
providing requested | providing requested | |||
NAT control service | NAT control service | |||
Discon Failure to send ASR Wait, Discon | Discon Failure to send ASR Wait, Discon | |||
resend ASR | resend ASR | |||
Discon ASR successfully sent and Cleanup Idle | Discon ASR successfully sent and Clean up Idle | |||
ASA Received with Result-Code | ASA Received with Result-Code | |||
Not ASA Received None No change | Not ASA Received None No change | |||
Discon | Discon | |||
Any STR Received Send STA, Idle | Any STR Received Send STA, Idle | |||
Cleanup. | Clean up | |||
8. DNCA AVPs | 8. DNCA AVPs | |||
8.1. Reused Base Protocol AVPs | 8.1. Reused Base Protocol AVPs | |||
AVPs reused from Diameter Base Protocol [RFC3588] are listed below. | The following table describes the AVPs reused from Diameter Base | |||
Protocol [RFC3588]; their AVP Code values, types, and possible flag | ||||
+-------------------+ | values; and whether the AVP MAY be encrypted.The [RFC3588] specifies | |||
| AVP Flag rules | | the AVP Flag rules for AVPs in section 4.5. The Diameter AVP rules | |||
are defined in the [RFC3588], section 4. | ||||
+---------+ | ||||
| AVP | | ||||
| Flag | | ||||
| rules | | ||||
+-----------------------------------------------|-----+---+---------+ | +-----------------------------------------------|-----+---+---------+ | |||
| AVP | | | May | | | AVP | | | | | |||
| Attribute Name Code Data Type |MUST |MAY| encrypt | | | Attribute Name Code Data Type |MUST |MAY| Encr | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|Acct-Interim-Interval 85 Unsigned32 | M | P | Y | | |Acct-Interim-Interval 85 Unsigned32 | M | P | Y | | |||
|Auth-Application-Id 258 Unsigned32 | M | P | N | | |Auth-Application-Id 258 Unsigned32 | M | P | N | | |||
|Destination-Host 293 DiamIdent | M | P | N | | |Destination-Host 293 DiamIdent | M | P | N | | |||
|Destination-Realm 283 DiamIdent | M | P | N | | |Destination-Realm 283 DiamIdent | M | P | N | | |||
|Error-Message 281 UTF8String | M | P | N | | |Error-Message 281 UTF8String | M | P | N | | |||
|Error-Reporting-Host 294 DiamIdent | M | P | N | | |Error-Reporting-Host 294 DiamIdent | M | P | N | | |||
|Failed-AVP 279 Grouped | M | P | N | | |Failed-AVP 279 Grouped | M | P | N | | |||
|Origin-Host 264 DiamIdent | M | P | N | | |Origin-Host 264 DiamIdent | M | P | N | | |||
|Origin-Realm 296 DiamIdent | M | P | N | | |Origin-Realm 296 DiamIdent | M | P | N | | |||
|Origin-State-Id 278 Unsigned32 | M | P | N | | |Origin-State-Id 278 Unsigned32 | M | P | N | | |||
|Proxy-Info 284 Grouped | M | P | N | | |Proxy-Info 284 Grouped | M | P | N | | |||
|Result-Code 268 Unsigned32 | M | P | N | | |Result-Code 268 Unsigned32 | M | P | N | | |||
|Route-Record 282 DiamIdent | M | | N | | |Route-Record 282 DiamIdent | M | | N | | |||
|Session-Id 263 UTF8String | M | P | Y | | |Session-Id 263 UTF8String | M | P | Y | | |||
|User-Name 1 UTF8String | M | P | Y | | |User-Name 1 UTF8String | M | P | Y | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be | | Table 1: DIAMETER AVPs used from Diameter base | |||
| supported and recognized by a Diameter entity in order the | | ||||
| message, which carries this AVP, to be accepted. | | ||||
|P - Indicates the need for encryption for end-to-end security. | | ||||
+-------------------------------------------------------------------+ | ||||
Figure 10: DIAMETER AVPs used from Diameter base | ||||
The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to | The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to | |||
Diameter applications. The value of the Auth-Application-Id for the | Diameter applications. The value of the Auth-Application-Id for the | |||
Diameter NAT Control Application is TBD. | Diameter NAT Control Application is TBD. | |||
8.2. Additional Result-Code AVP Values | 8.2. Additional Result-Code AVP Values | |||
This section defines new values for the Result-Code AVP which SHALL | This section defines new values for the Result-Code AVP which SHALL | |||
be supported by all Diameter implementations that conform to the | be supported by all Diameter implementations that conform to the | |||
present document. | present document. | |||
skipping to change at page 29, line 24 | skipping to change at page 31, line 29 | |||
8.2.3. Permanent Failures | 8.2.3. Permanent Failures | |||
The Result-Code AVP values, which fall within the permanent failures | The Result-Code AVP values, which fall within the permanent failures | |||
category are used to inform the peer that the request failed, and | category are used to inform the peer that the request failed, and | |||
should not be attempted again. The request may be able to be | should not be attempted again. The request may be able to be | |||
satisfied in the future. | satisfied in the future. | |||
The following new values of the Result-Code AVP are defined: | The following new values of the Result-Code AVP are defined: | |||
UNKNOWN_BINDING_RULE_NAME (TBD) | UNKNOWN_BINDING_TEMPLATE_NAME (TBD) | |||
The DNCA Diameter peer within the NAT-device indicates that the | The DNCA Diameter peer within the NAT-device indicates that the | |||
binding could not be installed or a new session could not be | binding could not be installed or a new session could not be | |||
created because the specified NAT-Control-Binding-Rule AVP, | created because the specified NAT-Control-Binding-Template AVP, | |||
that refers to a predefined policy template in the NAT-device, | that refers to a predefined policy template in the NAT-device, | |||
is unknown. | is unknown. | |||
BINDING_FAILURE (TBD) | BINDING_FAILURE (TBD) | |||
DNCA indicates that the requested binding(s) could not be | DNCA indicates that the requested binding(s) could not be | |||
installed. For example: Requested ports are already in use. | installed. For example: Requested ports are already in use. | |||
MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (TBD) | MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (TBD) | |||
skipping to change at page 30, line 14 | skipping to change at page 32, line 16 | |||
INSUFFICIENT_CLASSIFIERS (TBD) | INSUFFICIENT_CLASSIFIERS (TBD) | |||
The DNCA Diameter peer within the NAT-device requests to | The DNCA Diameter peer within the NAT-device requests to | |||
initialize a new session, if the classifiers in the request | initialize a new session, if the classifiers in the request | |||
match more than one of the existing sessions on the DNCA | match more than one of the existing sessions on the DNCA | |||
Diameter peer within the NAT-device. | Diameter peer within the NAT-device. | |||
8.3. Reused NASREQ Diameter Application AVPs | 8.3. Reused NASREQ Diameter Application AVPs | |||
The following AVPs are reused from Diameter Network Access Server | The following table describes the AVPs reused from the Diameter | |||
Application [RFC4005]. | Network Access Server Application [RFC4005]; their AVP Code values, | |||
types, and possible flag values; and whether the AVP MAY be | ||||
encrypted.The [RFC3588] specifies the AVP Flag rules for AVPs in | ||||
section 4.5. The Diameter AVP rules are defined in the [RFC3588], | ||||
section 4. | ||||
+---------------------+ | +---------------------+ | |||
| AVP Flag rules | | | AVP Flag rules | | |||
+------------------+------+------------|----+-----+----+-----|----+ | +------------------+------+------------|----+-----+----+-----|----+ | |||
| | AVP | | | |SHLD| MUST| | | | | AVP | | | |SHLD| MUST| | | |||
| Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| | | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| | |||
|------------------|------|------------|----+-----+----+-----|----| | |------------------|------|------------|----+-----+----+-----|----| | |||
| NAS-Port | 5 | Unsigned32 | M | P | | V | Y | | | NAS-Port | 5 | Unsigned32 | M | P | | V | Y | | |||
| NAS-Port-Id | 87 | UTF8String | M | P | | V | Y | | | NAS-Port-Id | 87 | UTF8String | M | P | | V | Y | | |||
| Calling-Station- | 31 | UTF8String | M | P | | V | Y | | | Calling-Station- | 31 | UTF8String | M | P | | V | Y | | |||
| Id | | | | | | | | | | Id | | | | | | | | | |||
| Framed-IP-Address| 8 | OctetString| M | P | | V | Y | | | Framed-IP-Address| 8 | OctetString| M | P | | V | Y | | |||
| Framed-IP-Netmask| 9 | OctetString| M | P | | V | Y | | ||||
| Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y | | | Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y | | |||
| Id | | | | | | | | | | Id | | | | | | | | | |||
| Framed-IPv6- | 97 | OctetString| M | P | | V | Y | | | Framed-IPv6- | 97 | OctetString| M | P | | V | Y | | |||
| Prefix | | | | | | | | | | Prefix | | | | | | | | | |||
+------------------+------+------------|----+-----+----+-----|----+ | +------------------+------+------------|----+-----+----+-----|----+ | |||
Table 2: Reused NASREQ Diameter application AVPs | ||||
Figure 11: Reused NASREQ Diameter application AVPs | ||||
8.4. Reused AVPs from RFC 4675 | 8.4. Reused AVPs from RFC 4675 | |||
The following AVPs are reused from "RADIUS Attributes for Virtual LAN | The following table describes the AVPs reused from "RADIUS Attributes | |||
and Priority Support" specification [RFC4675]. | for Virtual LAN and Priority Support" specification [RFC4675]; their | |||
AVP Code values, types, and possible flag values; and whether the AVP | ||||
MAY be encrypted.The [RFC3588] specifies the AVP Flag rules for AVPs | ||||
in section 4.5. The Diameter AVP rules are defined in the [RFC3588], | ||||
section 4. | ||||
+---------------------+ | +---------------------+ | |||
| AVP Flag rules | | | AVP Flag rules | | |||
+------------------+------+------------|----+-----+----+-----|----+ | +------------------+------+------------|----+-----+----+-----|----+ | |||
| | AVP | | | |SHLD| MUST| | | | | AVP | | | |SHLD| MUST| | | |||
| Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| | | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| | |||
|------------------|------|------------|----+-----+----+-----|----| | |------------------|------|------------|----+-----+----+-----|----| | |||
| Egress-VLANID | 56 | OctetString| M | P | | V | Y | | | Egress-VLANID | 56 | OctetString| M | P | | V | Y | | |||
+------------------+------+------------|----+-----+----+-----|----+ | +------------------+------+------------|----+-----+----+-----|----+ | |||
Table 3: Reused attributes from RFC 4675 | ||||
Figure 12: Reused attributes from RFC 4675 | ||||
8.5. Reused AVPs from Diameter QoS Application | 8.5. Reused AVPs from Diameter QoS Application | |||
The following AVPs are reused from the Traffic Classification and | The following table describes the AVPs reused from the Traffic | |||
Quality of Service (QoS) Attributes for Diameter [RFC5777]. | Classification and Quality of Service (QoS) Attributes for Diameter | |||
+-------------------+ | [RFC5777]; their AVP Code values, types, and possible flag values; | |||
| AVP Flag rules | | and whether the AVP MAY be encrypted.The [RFC3588] specifies the AVP | |||
Flag rules for AVPs in section 4.5. The Diameter AVP rules are | ||||
defined in the [RFC3588], section 4. | ||||
+---------+ | ||||
| AVP | | ||||
| Flag | | ||||
| rules | | ||||
+-----------------------------------------------|-----+---+---------+ | +-----------------------------------------------|-----+---+---------+ | |||
| AVP | | | May | | | AVP | | | | | |||
| Attribute Name Code Data Type |MUST |MAY| encrypt | | | Attribute Name Code Data Type |MUST |MAY| Encr | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|Port TBD Integer32 | M | P | Y | | |Port 530 Integer32 | M | P | Y | | |||
|IP-Address-Mask TBD Grouped | M | P | Y | | |Protocol 513 Enumerated | M | P | Y | | |||
|Protocol TBD Enumerated | M | P | Y | | |Direction 514 Enumerated | M | P | Y | | |||
|Direction TBD Enumerated | M | P | Y | | ||||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be | | ||||
| supported and recognized by a Diameter entity in order the | | ||||
| message, which carries this AVP, to be accepted. | | ||||
|P - Indicates the need for encryption for end-to-end security. | | ||||
+-------------------------------------------------------------------+ | ||||
Figure 13: Reused QoS-attributes | Table 4: Reused QoS-attributes | |||
8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter Application | 8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter Application | |||
The following AVPs are reused from the Diameter e4 Application | The following table describes the AVPs reused from the Diameter e4 | |||
[ETSIES283034]. | Application [ETSIES283034]; their AVP Code values, types, and | |||
+-------------------+ | possible flag values; and whether the AVP MAY be encrypted.The | |||
| AVP Flag rules | | [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. The | |||
Diameter AVP rules are defined in the [RFC3588], section 4. The | ||||
Vendor-ID field in these AVP header will be set to ETSI (13019). | ||||
+---------+ | ||||
| AVP | | ||||
| Flag | | ||||
| rules | | ||||
+-----------------------------------------------|-----+---+---------+ | +-----------------------------------------------|-----+---+---------+ | |||
| AVP | | | May | | | AVP | | | | | |||
| Attribute Name Code Data Type |MUST |MAY| encrypt | | | Attribute Name Code Data Type |MUST |MAY| Encr | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|Address-Realm 301 OctetString | M,V | | Y | | |Address-Realm 301 OctetString | M,V | | Y | | |||
|Logical-Access-Id 302 OctetString | V | M | Y | | |Logical-Access-Id 302 OctetString | V | M | Y | | |||
|Physical-Access-ID 313 UTF8String | V | M | Y | | |Physical-Access-ID 313 UTF8String | V | M | Y | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be | | ||||
| supported and recognized by a Diameter entity in order the | | ||||
| message, which carries this AVP, to be accepted. | | ||||
|P - Indicates the need for encryption for end-to-end security. | | ||||
|V - Indicates whether the optional Vendor-ID field is present | | ||||
| in the AVP header. Vendor-Id header of all AVPs in | | ||||
| this table will be set to ETSI (13019). | | ||||
+-------------------------------------------------------------------+ | ||||
Figure 14: Reused AVPs from Diameter e4 application | Table 5: Reused AVPs from Diameter e4 application | |||
8.7. DNCA Defined AVPs | 8.7. DNCA Defined AVPs | |||
The following table describes the new Diameter AVPs used in this | The following table describes the new Diameter AVPs defined in this | |||
document. | document; their AVP Code values, types, and possible flag values; and | |||
+-------------------+ | whether the AVP MAY be encrypted.The [RFC3588] specifies the AVP Flag | |||
| AVP Flag rules | | rules for AVPs in section 4.5. The Diameter AVP rules are defined in | |||
the [RFC3588], section 4. The AVPs defined here MUST NOT have the V | ||||
bit in the AVP Flag set. | ||||
+---------+ | ||||
| AVP | | ||||
| Flag | | ||||
| rules | | ||||
+-----------------------------------------------|-----+---+---------+ | +-----------------------------------------------|-----+---+---------+ | |||
| AVP Section | | | May | | | AVP | | | | | |||
| Attribute Name Code Defined Data Type |MUST |MAY| encrypt | | | Attribute Name Code Data Type |MUST |MAY| Encr | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|NC-Request-Type TBD 8.7.1 Enumerated | M | P | Y | | |NC-Request-Type TBD 8.7.1 Enumerated | M | P | Y | | |||
|NAT-Control-Install TBD 8.7.2 Grouped | M | P | Y | | |NAT-Control-Install TBD 8.7.2 Grouped | M | P | Y | | |||
|NAT-Control-Remove TBD 8.7.3 Grouped | M | P | Y | | |NAT-Control-Remove TBD 8.7.3 Grouped | M | P | Y | | |||
|NAT-Control-Definition TBD 8.7.4 Grouped | M | P | Y | | |NAT-Control-Definition TBD 8.7.4 Grouped | M | P | Y | | |||
|NAT-Internal-Address TBD 8.7.5 Grouped | M | P | Y | | |NAT-Internal-Address TBD 8.7.5 Grouped | M | P | Y | | |||
|NAT-External-Address TBD 8.7.6 Grouped | M | P | Y | | |NAT-External-Address TBD 8.7.6 Grouped | M | P | Y | | |||
|Max-NAT-Bindings TBD 8.7.7 Unsigned32 | M | P | Y | | |Max-NAT-Bindings TBD 8.7.7 Unsigned32 | M | P | Y | | |||
|NAT-Control- TBD 8.7.8 OctetString| M | P | Y | | |NAT-Control- TBD 8.7.8 OctetString| M | P | Y | | |||
| Binding-Rule | | | | | | Binding-Template | | | | | |||
|Duplicate- TBD 8.7.9 UTF8String | M | P | Y | | |Duplicate- TBD 8.7.9 UTF8String | M | P | Y | | |||
| Session-ID | | | | | | Session-ID | | | | | |||
|NAT-External-Port- TBD 8.7.10 Enumerated | M | P | Y | | ||||
| Style | | | | | ||||
|NAT-Control-Record TBD 9.2.1 Grouped | M | P | Y | | |NAT-Control-Record TBD 9.2.1 Grouped | M | P | Y | | |||
|NAT-Control- TBD 9.2.2 Enumerated | M | P | Y | | |NAT-Control- TBD 9.2.2 Enumerated | M | P | Y | | |||
| Binding-Status | | | | | | Binding-Status | | | | | |||
|Current-NAT-Bindings TBD 9.2.3 Unsigned32 | M | P | Y | | |Current-NAT-Bindings TBD 9.2.3 Unsigned32 | M | P | Y | | |||
+-----------------------------------------------+-----+---+---------+ | +-----------------------------------------------+-----+---+---------+ | |||
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be | | ||||
| supported and recognized by a Diameter entity in order the | | ||||
| message, which carries this AVP, to be accepted. | | ||||
|P - Indicates the need for encryption for end-to-end security. | | ||||
+-------------------------------------------------------------------+ | ||||
Figure 15: New Diameter AVPs | Table 6: New Diameter AVPs | |||
8.7.1. NC-Request-Type AVP | 8.7.1. NC-Request-Type AVP | |||
The NC-Request-Type AVP (AVP Code TBD) is of type Enumerated and | The NC-Request-Type AVP (AVP Code TBD) is of type Enumerated and | |||
contains the reason for sending the NAT-Control-Request command. It | contains the reason for sending the NAT-Control-Request command. It | |||
shall be present in all NAT-Control-Request messages. | shall be present in all NAT-Control-Request messages. | |||
The following values are defined: | The following values are defined: | |||
INITIAL_REQUEST (1) | INITIAL_REQUEST (1) | |||
skipping to change at page 33, line 18 | skipping to change at page 36, line 14 | |||
QUERY_REQUEST (3) | QUERY_REQUEST (3) | |||
Query Request is used to query a NAT-device about the currently | Query Request is used to query a NAT-device about the currently | |||
installed bindings for an endpoint classifier. | installed bindings for an endpoint classifier. | |||
8.7.2. NAT-Control-Install AVP | 8.7.2. NAT-Control-Install AVP | |||
The NAT-Control AVP (AVP code TBD) is of type Grouped, and it is used | The NAT-Control AVP (AVP code TBD) is of type Grouped, and it is used | |||
to activate or install NAT bindings. It also contains Max-NAT- | to activate or install NAT bindings. It also contains Max-NAT- | |||
Bindings that defines the maximum number of NAT bindings to be | Bindings that defines the maximum number of NAT bindings allowed for | |||
allowed for a subscriber and the NAT-Control-Binding-Rule that | an end point and the NAT-Control-Binding-Template that references a | |||
references a predefined policy template on the NAT-device that may | predefined template on the NAT-device that may contain static | |||
contain static binding, a maximum number of bindings allowed, an IP- | binding, a maximum number of bindings allowed, an IP-address pool | |||
address pool from which external binding addresses should be | from which external binding addresses should be allocated, etc. If | |||
allocated. | the NAT-External-Port-Style AVP is present, then the NAT-device MUST | |||
select the external ports for the NAT-Bindings as per the style | ||||
specified. The NAT-External-Port-Style is applicable for NAT- | ||||
Bindings defined by the NAT-Control-Definition AVPs whose NAT- | ||||
External-Address or Port AVPs within the NAT-External-Address are | ||||
unspecified. | ||||
AVP format: | AVP format: | |||
NAT-Control-Install ::= < AVP Header: TBD > | NAT-Control-Install ::= < AVP Header: TBD > | |||
* [ NAT-Control-Definition ] | * [ NAT-Control-Definition ] | |||
[ NAT-Control-Binding-Rule ] | [ NAT-Control-Binding-Template ] | |||
[ Max-NAT-Bindings] | [ Max-NAT-Bindings ] | |||
[ NAT-External-Port-Style ] | ||||
* [ AVP ] | * [ AVP ] | |||
8.7.3. NAT-Control-Remove AVP | 8.7.3. NAT-Control-Remove AVP | |||
The NAT-Control-Remove AVP (AVP code TBD) is of type Grouped, and it | The NAT-Control-Remove AVP (AVP code TBD) is of type Grouped, and it | |||
is used to deactivate or remove NAT-bindings. | is used to deactivate or remove NAT-bindings. At least one of the | |||
two AVPs (NAT-Control-Definition AVP, NAT-Control-Binding-Template | ||||
AVP) SHOULD be present in the NAT-Control-Remove AVP. | ||||
AVP format: | AVP format: | |||
NAT-Control-Remove ::= < AVP Header: TBD > | NAT-Control-Remove ::= < AVP Header: TBD > | |||
* [ NAT-Control-Definition ] | * [ NAT-Control-Definition ] | |||
[ NAT-Control-Binding-Rule ] | [ NAT-Control-Binding-Template ] | |||
* [ AVP ] | * [ AVP ] | |||
8.7.4. NAT-Control-Definition AVP | 8.7.4. NAT-Control-Definition AVP | |||
The NAT-Control-Definition AVP (AVP code TBD) is of type Grouped, and | The NAT-Control-Definition AVP (AVP code TBD) is of type Grouped, and | |||
it describes a binding. | it describes a binding. | |||
The NAT-Control-Definition AVP uniquely identifies the binding | The NAT-Control-Definition AVP uniquely identifies the binding | |||
between the DNCA Diameter peers. | between the DNCA Diameter peers. | |||
If both the NAT-Internal-Address and NAT-External-Address AVP(s) are | If both the NAT-Internal-Address and NAT-External-Address AVP(s) are | |||
supplied, it is a pre-defined binding. | supplied, it is a pre-defined binding. | |||
If the NAT-External-Address AVP is not specified then the NAT-device | ||||
MUST select the external port as per the NAT-External-Port-Style AVP, | ||||
if present in the NAT-Control-Definition AVP. | ||||
The Protocol AVP describes the transport protocol for the binding. | The Protocol AVP describes the transport protocol for the binding. | |||
The NAT-Control-Definition AVP can contain either zero or one | The NAT-Control-Definition AVP can contain either zero or one | |||
Protocol AVP. If the Protocol AVP is omitted and if both internal | Protocol AVP. If the Protocol AVP is omitted and if both internal | |||
and external IP-address are specified then the binding reserves the | and external IP-address are specified then the binding reserves the | |||
IP-addresses for all transport protocols. | IP-addresses for all transport protocols. | |||
The Direction AVP is of type Enumerated. It specifies the direction | The Direction AVP is of type Enumerated. It specifies the direction | |||
for the binding. The values of the enumeration applicable in this | for the binding. The values of the enumeration applicable in this | |||
context are: "IN","OUT". If Direction AVP is OUT or absent, the NAT- | context are: "IN","OUT". If Direction AVP is OUT or absent, the NAT- | |||
Internal-Address refers to the IP-address of the endpoint that needs | Internal-Address refers to the IP-address of the endpoint that needs | |||
skipping to change at page 34, line 44 | skipping to change at page 37, line 51 | |||
AVP format: | AVP format: | |||
NAT-Internal-Address ::= < AVP Header: TBD > | NAT-Internal-Address ::= < AVP Header: TBD > | |||
[ Framed-IP-Address ] | [ Framed-IP-Address ] | |||
[ Framed-IPv6-Prefix ] | [ Framed-IPv6-Prefix ] | |||
[ Port] | [ Port] | |||
* [ AVP ] | * [ AVP ] | |||
8.7.6. NAT-External-Address AVP | 8.7.6. NAT-External-Address AVP | |||
The NAT-External-Address AVP (AVP code TBD) is of type Grouped, and | The NAT-External-Address AVP (AVP code TBD) is of type Grouped, and | |||
it describes the external IP-address and port for a binding. IP- | it describes the external IP-address and port for a binding. Framed- | |||
Address-Mask AVP can only be specified when the Framed-IP-Address AVP | IP-Netmask AVP can only be specified when the Framed-IP-Address AVP | |||
is present. The external IP-address specified in this attribute can | is present. The external IP-address specified in this attribute can | |||
be reused for multiple endpoints by specifying the same address in | be reused for multiple endpoints by specifying the same address in | |||
the respective NAT-External-Address AVPs. | the respective NAT-External-Address AVPs. If the external IP-address | |||
is not specified and the NAT-External-Port-Style AVP is specified in | ||||
the NAT-Control-Definition AVP then the NAT-device MUST select | ||||
external port as per the NAT-External-Port-Style AVP. | ||||
AVP format: | AVP format: | |||
NAT-External-Address ::= < AVP Header: TBD > | NAT-External-Address ::= < AVP Header: TBD > | |||
[ Framed-IP-Address ] | [ Framed-IP-Address ] | |||
[ IP-Address-Mask ] | [ Framed-IP-Netmask ] | |||
[ Port ] | [ Port ] | |||
* [ AVP ] | * [ AVP ] | |||
8.7.7. Max-NAT-Bindings | 8.7.7. Max-NAT-Bindings | |||
The Max-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32. It | The Max-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32. It | |||
indicates the maximum number of NAT-bindings allowed for a particular | indicates the maximum number of NAT-bindings allowed for a particular | |||
endpoint. | endpoint. | |||
8.7.8. NAT-Control-Binding-Rule AVP | 8.7.8. NAT-Control-Binding-Template AVP | |||
The NAT-Control-Binding-Rule AVP (AVP code TBD) is of type | The NAT-Control-Binding-Template AVP (AVP code TBD) is of type | |||
OctetString. It defines a name for a policy template that is | OctetString. It defines a name for a policy template that is | |||
predefined at the NAT-device. Details on the contents and structure | predefined at the NAT-device. Details on the contents and structure | |||
of the template and configuration are outside the scope of this | of the template and configuration are outside the scope of this | |||
document. The policy to which this AVP refers to may contain NAT- | document. The policy to which this AVP refers to may contain NAT- | |||
bindings, IP-address pool for allocating the external IP-address of a | bindings, IP-address pool for allocating the external IP-address of a | |||
NAT-binding, and maximum number of allowed NAT-bindings. Such policy | NAT-binding, and maximum number of allowed NAT-bindings. Such policy | |||
template can be reused by specifying the same NAT-Control-Binding- | template can be reused by specifying the same NAT-Control-Binding- | |||
Rule AVP in the corresponding NAT-Control-Install AVPs of multiple | Template AVP in the corresponding NAT-Control-Install AVPs of | |||
endpoints. | multiple endpoints. | |||
8.7.9. Duplicate-Session-Id AVP | 8.7.9. Duplicate-Session-Id AVP | |||
The Duplicate-Session-Id AVP (AVP Code TBD) is of type UTF8String. | The Duplicate-Session-Id AVP (AVP Code TBD) is of type UTF8String. | |||
It is used to report errors and contains the Session-Id of an | It is used to report errors and contains the Session-Id of an | |||
existing session. | existing session. | |||
8.7.10. NAT-External-Port-Style AVP | ||||
The NAT-External-Port-Style AVP (AVP Code TBD) is of type Enumerated | ||||
and contains the style to be followed while selecting the external | ||||
port for a NAT-Binding relative to the internal port. | ||||
The following values are defined: | ||||
FOLLOW_INTERNAL_PORT_STYLE (1) | ||||
External port numbers selected MUST follow the same sequence | ||||
and oddity as the internal ports of the NAT-bindings. The port | ||||
odditity is required to support protocols like RTP and RTCP as | ||||
defined in [RFC3550]. If for example the internal port in a | ||||
requested NAT-binding is odd numbered then the external port | ||||
allocated MUST also be odd numbered, and vice versa for an even | ||||
numbered port. In addition, the sequence of port numbering is | ||||
maintained: If internal ports are consecutive, then the NAT- | ||||
device MUST choose consecutive external ports for the NAT- | ||||
bindings. | ||||
9. Accounting Commands | 9. Accounting Commands | |||
The DNCA reuses session based accounting as defined in the Diameter | The DNCA reuses session based accounting as defined in the Diameter | |||
Base Protocol[RFC3588] to report the bindings per endpoint. This | Base Protocol[RFC3588] to report the bindings per endpoint. This | |||
reporting is achieved by sending Diameter Accounting Requests (ACR) | reporting is achieved by sending Diameter Accounting Requests (ACR) | |||
[Start, Interim and Stop] from the DNCA Diameter peer within the NAT- | [Start, Interim and Stop] from the DNCA Diameter peer within the NAT- | |||
device to its associated DNCA Diameter peer within the NAT- | device to its associated DNCA Diameter peer within the NAT- | |||
controller. | controller. | |||
The DNCA Diameter peer within the NAT-device sends an ACR Start on | The DNCA Diameter peer within the NAT-device sends an ACR Start on | |||
skipping to change at page 36, line 12 | skipping to change at page 39, line 42 | |||
Request-Type AVP set to UPDATE_REQUEST, or periodically as specified | Request-Type AVP set to UPDATE_REQUEST, or periodically as specified | |||
in Acct-Interim-Interval by the DNCA Diameter peer within the NAT- | in Acct-Interim-Interval by the DNCA Diameter peer within the NAT- | |||
controller, or when it creates or tears down bindings. An ACR Stop | controller, or when it creates or tears down bindings. An ACR Stop | |||
is sent by the DNCA Diameter peer within the NAT-device on receiving | is sent by the DNCA Diameter peer within the NAT-device on receiving | |||
STR. | STR. | |||
The function of correlating the multiple bindings used by an endpoint | The function of correlating the multiple bindings used by an endpoint | |||
at any given time is relegated to the post processor. | at any given time is relegated to the post processor. | |||
The DNCA Diameter peer within the NAT-device may trigger an interim | The DNCA Diameter peer within the NAT-device may trigger an interim | |||
accounting record when maximum number of bindings, if received in | accounting record when the maximum number of bindings, if received in | |||
NCR, is reached. | an NCR, is reached. | |||
9.1. NAT Control Accounting Messages | 9.1. NAT Control Accounting Messages | |||
The ACR and ACA messages are reused as defined in Diameter Base | The ACR and ACA messages are reused as defined in the Diameter Base | |||
Protocol [RFC3588] for exchanging endpoint NAT binding details | Protocol [RFC3588] for exchanging endpoint NAT binding details | |||
between the DNCA Diameter peers. DNCA Application ID is used in the | between the DNCA Diameter peers. The DNCA Application IDs is used in | |||
accounting commands. ACR contains one or more optional NAT-Control- | the accounting commands. ACR contains one or more optional NAT- | |||
Record AVP to report the bindings. The NAT-device indicates the | Control-Record AVPs to report the bindings. The NAT-device indicates | |||
number of allocated NAT bindings to NAT-controller using the Current- | the number of allocated NAT bindings to the NAT-controller using the | |||
NAT-Bindings AVP. This number needs to match the number of bindings | Current-NAT-Bindings AVP. This number needs to match the number of | |||
identified as active within the NAT-Control-Record AVP. | bindings identified as active within the NAT-Control-Record AVP. | |||
9.2. NAT Control Accounting AVPs | 9.2. NAT Control Accounting AVPs | |||
In addition to AVPs for ACR specified in [RFC3588], the DNCA Diameter | In addition to AVPs for ACR specified in [RFC3588], the DNCA Diameter | |||
peer within the NAT-device must add the NAT-Control-Record AVP. | peer within the NAT-device must add the NAT-Control-Record AVP. | |||
9.2.1. NAT-Control-Record | 9.2.1. NAT-Control-Record | |||
The NAT-Control-Record AVP (AVP code TBD) is of type Grouped. It | The NAT-Control-Record AVP (AVP code TBD) is of type Grouped. It | |||
describes a binding and its status. If NAT-Control-Binding-Status is | describes a binding and its status. If NAT-Control-Binding-Status is | |||
skipping to change at page 37, line 20 | skipping to change at page 40, line 50 | |||
NAT binding is active. | NAT binding is active. | |||
Removed (3) | Removed (3) | |||
NAT binding was removed. | NAT binding was removed. | |||
9.2.3. Current-NAT-Bindings | 9.2.3. Current-NAT-Bindings | |||
The Current-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32. | The Current-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32. | |||
It indicates number of NAT bindings active on NAT-device. | It indicates the number of NAT bindings active on the NAT-device. | |||
10. AVP Occurrence Table | 10. AVP Occurrence Table | |||
The following sections presents the AVPs defined in this document and | The following sections present the AVPs defined in this document and | |||
specifies the Diameter messages in which, they MAY be present. Note: | specify the Diameter messages in which they can be present. Note: | |||
AVPs that can only be present within a Grouped AVP are not | AVPs that can only be present within a Grouped AVP are not | |||
represented in this table. | represented in this table. | |||
The table uses the following symbols: | The table uses the following symbols: | |||
0 The AVP MUST NOT be present in the message. | 0 The AVP MUST NOT be present in the message. | |||
0+ Zero or more instances of the AVP MAY be present in the | 0+ Zero or more instances of the AVP can be present in the | |||
message. | message. | |||
0-1 Zero or one instance of the AVP MAY be present in the | 0-1 Zero or one instance of the AVP can be present in the | |||
message. It is considered an error if there is more | message. It is considered an error if there is more | |||
than one instance of the AVP. | than one instance of the AVP. | |||
1 One instance of the AVP MUST be present in the message. | 1 One instance of the AVP MUST be present in the message. | |||
1+ At least one instance of the AVP MUST be present in the | 1+ At least one instance of the AVP MUST be present in the | |||
message. | message. | |||
10.1. DNCA AVP Table for NAT Control Initial and Update Requests | 10.1. DNCA AVP Table for NAT Control Initial and Update Requests | |||
The following table lists DNCA specific AVPs that have to be present | The following table lists DNCA specific AVPs that have to be present | |||
in NCR and NCA with NC-Request-Type set to INITIAL_REQUEST or | in NCRs and NCAs with NC-Request-Type set to INITIAL_REQUEST or | |||
UPDATE_REQUEST. | UPDATE_REQUEST. | |||
+-------------------+ | +-------------------+ | |||
| Command Code | | | Command Code | | |||
+-----------------------------------+-------------------+ | +-----------------------------------+-------------------+ | |||
| Attribute Name NCR NCA | | | Attribute Name NCR NCA | | |||
+-------------------------------------------------------+ | +-------------------------------------------------------+ | |||
|NC-Request-Type 1 1 | | |NC-Request-Type 1 1 | | |||
|NAT-Control-Install 0-1 0 | | |NAT-Control-Install 0-1 0 | | |||
|NAT-Control-Remove 0-1 0 | | |NAT-Control-Remove 0-1 0 | | |||
|NAT-Control-Definition 0 0 | | |NAT-Control-Definition 0 0 | | |||
|Current-NAT-Bindings 0 0 | | |Current-NAT-Bindings 0 0 | | |||
skipping to change at page 38, line 18 | skipping to change at page 41, line 46 | |||
| Attribute Name NCR NCA | | | Attribute Name NCR NCA | | |||
+-------------------------------------------------------+ | +-------------------------------------------------------+ | |||
|NC-Request-Type 1 1 | | |NC-Request-Type 1 1 | | |||
|NAT-Control-Install 0-1 0 | | |NAT-Control-Install 0-1 0 | | |||
|NAT-Control-Remove 0-1 0 | | |NAT-Control-Remove 0-1 0 | | |||
|NAT-Control-Definition 0 0 | | |NAT-Control-Definition 0 0 | | |||
|Current-NAT-Bindings 0 0 | | |Current-NAT-Bindings 0 0 | | |||
|Duplicate-Session-Id 0 0-1 | | |Duplicate-Session-Id 0 0-1 | | |||
+-------------------------------------------------------+ | +-------------------------------------------------------+ | |||
Note that any combination of "NAT-Control-Install" and "NAT-Control- | ||||
Remove" AVPs could be present in an update or initial requests. | ||||
Consider the following examples: | ||||
Neither "NAT-Control-Install AVP" nor "NAT-Control-Remove AVP" are | ||||
present: This could for example be the case if the NAT-controller | ||||
would only want to receive accounting information, but not control | ||||
NAT-bindings. | ||||
Only "NAT-Control-Install AVP" is present: This could for example | ||||
be the case if a new NAT-binding is installed for an existing | ||||
session. | ||||
Only "NAT-Control-Remove AVP" is present: This could for example | ||||
be the case if a new NAT-binding is removed from an existing | ||||
session. | ||||
Both, "NAT-Control-Install AVP" and "NAT-Control-Remove AVP" are | ||||
present: This could for example be the case if a formerly created | ||||
NAT-binding is removed and a new NAT-binding is established within | ||||
the same request. | ||||
10.2. DNCA AVP Table for Session Query request | 10.2. DNCA AVP Table for Session Query request | |||
The following table lists DNCA specific AVPs that have to be present | The following table lists DNCA specific AVPs that have to be present | |||
in NCR and NCA with NC-Request-Type set to QUERY_REQUEST. | in NCRs and NCAs with NC-Request-Type set to QUERY_REQUEST. | |||
+-------------------+ | +-------------------+ | |||
| Command Code | | | Command Code | | |||
+-----------------------------------+-------------------+ | +-----------------------------------+-------------------+ | |||
| Attribute Name NCR NCA | | | Attribute Name NCR NCA | | |||
+-------------------------------------------------------+ | +-------------------------------------------------------+ | |||
|NC-Request-Type 1 1 | | |NC-Request-Type 1 1 | | |||
|NAT-Control-Install 0 0 | | |NAT-Control-Install 0 0 | | |||
|NAT-Control-Remove 0 0 | | |NAT-Control-Remove 0 0 | | |||
|NAT-Control-Definition 0 0+ | | |NAT-Control-Definition 0 0+ | | |||
|Current-NAT-Bindings 0 1 | | |Current-NAT-Bindings 0 1 | | |||
skipping to change at page 39, line 27 | skipping to change at page 43, line 32 | |||
11.2. Command Codes | 11.2. Command Codes | |||
This specification uses the value <TBD> from the Command code | This specification uses the value <TBD> from the Command code | |||
namespace defined in [RFC3588] for the NAT-Control-Request (NCR), | namespace defined in [RFC3588] for the NAT-Control-Request (NCR), | |||
NAT-Control-Answer (NCA) commands. See Section 6.1 and Section 6.2 | NAT-Control-Answer (NCA) commands. See Section 6.1 and Section 6.2 | |||
for more information on these commands. | for more information on these commands. | |||
11.3. AVP Codes | 11.3. AVP Codes | |||
This specification assigns the values <TBD> from the AVP code | This specification assigns the values <TBD> from the AVP code | |||
namespace defined in [RFC3588]. See Figure 15for the assignment of | namespace defined in [RFC3588]. See Section 8.7 for the assignment | |||
the namespace in this specification. | of the namespace in this specification. | |||
11.4. Result-Code AVP Values | 11.4. Result-Code AVP Values | |||
This specification assigns the values <TBD> (4xxx, 5xxx, 5xxx, 5xxx, | This specification assigns the values <TBD> (4xxx, 5xxx, 5xxx, 5xxx, | |||
5xxx,5xxx) from the Result-Code AVP value namespace defined in | 5xxx,5xxx) from the Result-Code AVP value namespace defined in | |||
[RFC3588]. See Section 8.2 for the assignment of the namespace in | [RFC3588]. See Section 8.2 for the assignment of the namespace in | |||
this specification. | this specification. | |||
11.5. NC-Request-Type AVP | 11.5. NC-Request-Type AVP | |||
As defined in Section 8.7.1, the NC-Request-Type AVP includes | As defined in Section 8.7.1, the NC-Request-Type AVP includes | |||
Enumerated type values 1 - 3. IANA has created and is maintaining a | Enumerated type values 1 - 3. IANA has created and is maintaining a | |||
namespace for this AVP. All remaining values are available for | namespace for this AVP. All remaining values are available for | |||
assignment by a Designated Expert [RFC5226]. | assignment by a Designated Expert [RFC5226]. | |||
11.6. NAT-Control-Binding-Status AVP | 11.6. NAT-External-Port-Style AVP | |||
As defined in Section 8.7.10, the NAT-External-Port-Style AVP | ||||
includes Enumerated type value 1. IANA has created and is | ||||
maintaining a namespace for this AVP. All remaining values are | ||||
available for assignment by a Designated Expert [RFC5226]. | ||||
11.7. NAT-Control-Binding-Status AVP | ||||
As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP | As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP | |||
includes Enumerated type values 1 - 3. IANA has created and is | includes Enumerated type values 1 - 3. IANA has created and is | |||
maintaining a namespace for this AVP. All remaining values are | maintaining a namespace for this AVP. All remaining values are | |||
available for assignment by a Designated Expert [RFC5226]. | available for assignment by a Designated Expert [RFC5226]. | |||
12. Security Considerations | 12. Security Considerations | |||
This document describes procedures for controlling NAT related | This document describes procedures for controlling NAT related | |||
attributes and parameters by an entity, which is non-local to the | attributes and parameters by an entity, which is non-local to the | |||
device performing NAT. This section discusses security | device performing NAT. This section discusses security | |||
considerations for DNCA. This includes the interactions between the | considerations for DNCA. This includes the interactions between the | |||
Diameter peers within a NAT-controller and a NAT-device as well as | Diameter peers within a NAT-controller and a NAT-device as well as | |||
general considerations for NAT-control in a service provider network. | general considerations for NAT-control in a service provider network. | |||
Security between NAT-controller and NAT-device has a number of | Security between a NAT-controller and a NAT-device has a number of | |||
components: authentication, authorization, integrity, and | components: authentication, authorization, integrity, and | |||
confidentiality. | confidentiality. | |||
Authentication refers to confirming the identity of an originator for | Authentication refers to confirming the identity of an originator for | |||
all datagrams received from the originator. Lack of authentication | all datagrams received from the originator. Lack of authentication | |||
of Diameter messages between the Diameter peers can jeopardize the | of Diameter messages between the Diameter peers can jeopardize the | |||
fundamental service of the peering network elements. A consequence | fundamental service of the peering network elements. A consequence | |||
of not authenticating the message sender by the recipient would be | of not authenticating the message sender by the recipient would be | |||
that an attacker could spoof the identity of a "legitimate" | that an attacker could spoof the identity of a "legitimate" | |||
authorizing entity in order to change the behavior of the receiver. | authorizing entity in order to change the behavior of the receiver. | |||
An attacker could for example launch a denial of service attack by | An attacker could for example launch a denial of service attack by | |||
setting the maximum number of bindings for a session on the NAT- | setting the maximum number of bindings for a session on the NAT- | |||
device to zero; provision bindings on a NAT-device which include IP- | device to zero; provision bindings on a NAT-device which include IP- | |||
addresses already in use in other parts of the network; or request | addresses already in use in other parts of the network; or request | |||
session termination of the Diameter session and hamper a user's | session termination of the Diameter session and hamper a user's | |||
connectivity. Lack of authentication of a NAT-device to a NAT- | connectivity. Lack of authentication of a NAT-device to a NAT- | |||
controller could lead to situations where the NAT-device could | controller could lead to situations where the NAT-device could | |||
provide a wrong view of the resources (i.e. NAT-bindings). In | provide a wrong view of the resources (i.e. NAT-bindings). In | |||
addition, templates on the NAT-device specifying pre-defined binding | addition, NAT Binding Predefined template on the NAT-device could be | |||
rules could be configured differently than expected by the NAT- | configured differently than expected by the NAT-controller. Failing | |||
controller. Failing of any of the two DNCA Diameter peers to provide | of any of the two DNCA Diameter peers to provide the required | |||
the required credentials should be subject to logging. | credentials should be subject to logging. The corresponding logging | |||
infrastructure of the operator SHOULD be built in a way that it can | ||||
mitigate potential denial of service attacks resulting from large | ||||
amounts of logging events. This could include proper dimensioning of | ||||
the logging infrastructure combined with policing the maximum amount | ||||
of logging events accepted by the logging system to a threshold which | ||||
the system is known to be able to handle. | ||||
Authorization refers to whether a particular authorizing entity is | Authorization refers to whether a particular authorizing entity is | |||
authorized to signal a network element requests for one or more | authorized to signal a network element requests for one or more | |||
applications, adhering to a certain policy profile. Failing the | applications, adhering to a certain policy profile. Failing the | |||
authorization process might indicate a resource theft attempt or | authorization process might indicate a resource theft attempt or | |||
failure due to administrative and/or credential deficiencies. In | failure due to administrative and/or credential deficiencies. In | |||
either case, the network element should take the proper measures to | either case, the network element should take the proper measures to | |||
log such attempts. | log such attempts. | |||
Integrity is required to ensure that a Diameter message exchanged | Integrity is required to ensure that a Diameter message exchanged | |||
skipping to change at page 41, line 14 | skipping to change at page 45, line 31 | |||
Confidentiality protection of Diameter messages ensures that the | Confidentiality protection of Diameter messages ensures that the | |||
signaling data is accessible only to the authorized entities. When | signaling data is accessible only to the authorized entities. When | |||
signaling messages between the DNCA Diameter peers traverse untrusted | signaling messages between the DNCA Diameter peers traverse untrusted | |||
networks, lack of confidentiality will allow eavesdropping and | networks, lack of confidentiality will allow eavesdropping and | |||
traffic analysis. | traffic analysis. | |||
Diameter offers security mechanisms to deal with the functionality | Diameter offers security mechanisms to deal with the functionality | |||
demanded above. DNCA makes use of the capabilities offered by | demanded above. DNCA makes use of the capabilities offered by | |||
Diameter and the underlying transport protocols to deliver these | Diameter and the underlying transport protocols to deliver these | |||
requirements (see Section 5.1 ). If the DNCA communication traverses | requirements (see Section 5.1). If the DNCA communication traverses | |||
untrusted networks, it is assumed that messages between DNCA Diameter | untrusted networks, messages between DNCA Diameter peers SHOULD be | |||
peers are secured using either IPsec or TLS. Please refer to | secured using either IPsec or TLS. Please refer to [RFC3588], | |||
[RFC3588], section 13 for details. DNCA Diameter peers MAY perform | section 13 for details. DNCA Diameter peers SHOULD perform bilateral | |||
bilateral authentication, authorization as well as procedures to | authentication, authorization as well as procedures to ensure | |||
ensure integrity and confidentiality of the information exchange. | integrity and confidentiality of the information exchange. | |||
It is assumed that the DNCA Diameter peers are typically in the same | DNCA Diameter peers SHOULD have a mutual trust setup. This document | |||
domain and have a mutual trust set up. This document does not | does not specify a mechanisms for authorization between the DNCA | |||
specify a mechanisms for authorization between the DNCA Diameter | Diameter peers. The DNCA Diameter peers SHOULD be provided with | |||
peers. It is assumed that the DNCA Diameter peers are provided with | ||||
sufficient information to make an authorization decision. The | sufficient information to make an authorization decision. The | |||
information can come from various sources, for example the peering | information can come from various sources, for example the peering | |||
devices could store local authentication policy, listing the | devices could store local authentication policy, listing the | |||
identities of authorized peers. | identities of authorized peers. | |||
Any mechanism or protocol providing control of a NAT-device, and DNCA | Any mechanism or protocol providing control of a NAT-device, and DNCA | |||
is an example of such a control mechanism, could allow for misuse of | is an example of such a control mechanism, could allow for misuse of | |||
the NAT-device given that it enables the definition of per- | the NAT-device given that it enables the definition of per- | |||
destination or per-source rules. Misuse could include anti- | destination or per-source rules. Misuse could include anti- | |||
competitive practices among providers, censorship, crime, etc. NAT- | competitive practices among providers, censorship, crime, etc. NAT- | |||
control could be used as a tool for preventing or redirecting access | control could be used as a tool for preventing or redirecting access | |||
to particular sites. For instance, by controlling the NAT bindings, | to particular sites. For instance, by controlling the NAT bindings, | |||
one could ensure that end points aren't able to receive particular | one could ensure that end points aren't able to receive particular | |||
flows, or that those flows are redirected to a relay that snoops or | flows, or that those flows are redirected to a relay that snoops or | |||
tampers with traffic instead of directly forwarding the traffic to | tampers with traffic instead of directly forwarding the traffic to | |||
the intended end point. In addition one could setup a binding in a | the intended end point. In addition one could set up a binding in a | |||
way that the source IP address used is one of a relay so that traffic | way that the source IP address used is one of a relay so that traffic | |||
coming back can be snooped on or interfered with. The protections on | coming back can be snooped on or interfered with. The protections on | |||
DNCA and its Diameter protocol exchanges don't prevent such abuses of | DNCA and its Diameter protocol exchanges don't prevent such abuses of | |||
NAT-control. A service provider deploying DNCA needs to make sure | NAT-control. A service provider deploying DNCA needs to make sure | |||
that higher layer processes and procedures are put in place which | that higher layer processes and procedures are put in place which | |||
allow them to detect and mitigate misuses. | allow them to detect and mitigate misuses. | |||
13. Acknowledgements | 13. Examples | |||
The authors would like to thank Wesley Eddy, Miguel A. Garcia, Jouni | This section shows example DNCA message content and exchange. | |||
Korhonen, Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel | ||||
Morand, Hannes Tschofenig, Shashank Vikram, Greg Weber, and Glen Zorn | ||||
for their input on this document. | ||||
14. Change History (to be removed prior to publication as an RFC) | 13.1. DNCA Session Establishment Example | |||
Figure 15 depicts a typical call flow for DNCA session establishment. | ||||
In this example, the NAT-controller: | ||||
a. requests a maximum of 100 NAT-bindings for the end point. | ||||
b. defines a static binding for a TCP connection which associates | ||||
the internal IP-Address:Port 192.0.2.1:80 with the external IP- | ||||
Address:Port 198.51.100.1:80 for the end point. | ||||
c. requests the use of a preconfigured template called "local- | ||||
policy" while creating NAT-bindings for the end point. | ||||
end point NAT-Controller (within NAS) NAT-device | ||||
| | | | ||||
| | | | ||||
| 1. Trigger | | | ||||
|--------------------------->| | | ||||
| +-------------------------------------+ | | ||||
| | 2. Determine that NAT control | | | ||||
| | is required for the end point | | | ||||
| +-------------------------------------+ | | ||||
| | | | ||||
| | | | ||||
| ................................... | ||||
| .| 3. Diameter Base CER/CEA |. | ||||
| .|<----------------------------->|. | ||||
| ................................... | ||||
| | | | ||||
| | | | ||||
| | 4. NCR | | ||||
| |------------------------------>| | ||||
| | | | ||||
| | 5. DNCA session | ||||
| | established | ||||
| | | | ||||
| | 6. NCA | | ||||
| |<------------------------------| | ||||
| | | | ||||
| | | | ||||
| 7. Data traffic | | ||||
|----------------------------------------------------------->| | ||||
| | | | ||||
| | | | ||||
| | 8. NAT Bindings | ||||
| | created as per | ||||
| | directives in the | ||||
| | DNCA session | ||||
| | | | ||||
Figure 15: Initial NAT control request and session establishment | ||||
example | ||||
Detailed description of the steps shown in Figure 15: | ||||
1. The NAT-controller (co-located with the NAS here) creates state | ||||
for an end point based on a trigger. This could for example be | ||||
the successful establishment of a Point-to-Point Protocol (PPP) | ||||
[RFC1661] access session. | ||||
2. Based on the configuration of the DNCA Diameter peer within the | ||||
NAT-controller, the NAT-controller determines that NAT-control is | ||||
required and is to be enforced at a NAT-device. | ||||
3. If there is no Diameter session already established with the DNCA | ||||
Diameter peer within NAT-device, a Diameter connection is | ||||
established and Diameter Base CER/CEA are exchanged. | ||||
4. The NAT-Controller creates an NCR message (see below) and sends | ||||
it to the NAT-device. This example shows IPv4 to IPv4 address | ||||
and port translation. For IPv6 to IPv4 translation, the Framed- | ||||
IP-Address AVP would be replaced by the Framed-IPv6-Address AVP | ||||
with the value set to the IPv6 address of the end point. | ||||
< NC-Request > ::= < Diameter Header: TBD, REQ, PXY> | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Auth-Application-Id = <DNCA Application ID> | ||||
Origin-Host = "natC.example.com" | ||||
Origin-Realm = "example.com" | ||||
Destination-Realm = "example.com" | ||||
Destination-Host = "nat-device.example.com" | ||||
NC-Request-Type = INITIAL_REQUEST | ||||
User-Name = "subscriber_example1" | ||||
Framed-IP-Address = "192.0.2.1" | ||||
NAT-Control-Install = { | ||||
NAT-Control-Definition = { | ||||
Protocol = TCP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 80 | ||||
} | ||||
NAT-External-Address = { | ||||
Framed-IP-Address = "198.51.100.1" | ||||
Port = 80 | ||||
} | ||||
} | ||||
Max-NAT-Bindings = 100 | ||||
NAT-Control-Binding-Template = "local-policy" | ||||
} | ||||
5. The NAT-device establishes a DNCA session as it is able to comply | ||||
with the request. | ||||
6. The NAT-device sends an NCA to indicate the successful completion | ||||
of the request. | ||||
<NC-Answer> ::= < Diameter Header: TBD, PXY > | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Origin-Host = "nat-device.example.com" | ||||
Origin-Realm = "example.com" | ||||
NC-Request-Type = INITIAL_REQUEST | ||||
Result-Code = DIAMETER_SUCCESS | ||||
7. The end point sends packets that reach the NAT-device. | ||||
8. The NAT-device performs NAT for traffic received from the end | ||||
point with source address 192.0.2.1. Traffic with source IP- | ||||
address 192.0.2.1 and port 80 are translated to the external IP- | ||||
address 198.51.100.1 and port 80. Traffic with source IP-address | ||||
192.0.2.1 and a source port different from 80 will be translated | ||||
to IP-address 198.51.100.1 and a port chosen by the NAT-device. | ||||
Note that this example assumes that the NAT-device follows | ||||
typical binding allocation rules for end points, in that only a | ||||
single external IP-address is used for all traffic received from | ||||
a single IP-address of an end point. The NAT-device will allow a | ||||
maximum of 100 NAT-bindings be created for the end point. | ||||
13.2. DNCA Session Update with Port Style Example | ||||
This section gives an example for a DNCA session update: A new set of | ||||
NAT-bindings is requested for an existing session. The request | ||||
contains a directive ( the "NAT-External-Port-Style" AVP set to | ||||
FOLLOW_INTERNAL_PORT_STYLE) that directs the NAT-device to maintain | ||||
port-sequence and port-oddity for the newly created NAT-bindings. In | ||||
the example shown, the internal ports are UDP port 1036 and 1037. | ||||
The NAT-device follows the directive selects the external ports | ||||
accordingly. The NAT-device would for example create a mapping of | ||||
192.0.2.1:1036 to 198.51.100.1:5056 and 192.0.2.1:1037 to | ||||
198.51.100.1:5057, thereby maintaining port oddity (1036->5056, | ||||
1037->5057) and sequence ( the consecutive internal ports 1036 and | ||||
1037 map to the consecutive external ports 5056 and 5057). | ||||
< NC-Request > ::= < Diameter Header: TBD, REQ, PXY> | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Auth-Application-Id = <DNCA Application ID> | ||||
Origin-Host = "natC.example.com" | ||||
Origin-Realm = "example.com" | ||||
Destination-Realm = "example.com" | ||||
Destination-Host = "nat-device.example.com" | ||||
NC-Request-Type = UPDATE_REQUEST | ||||
NAT-Control-Install = { | ||||
NAT-Control-Definition = { | ||||
Protocol = UDP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 1035 | ||||
} | ||||
} | ||||
NAT-Control-Definition = { | ||||
Protocol = UDP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 1036 | ||||
} | ||||
} | ||||
NAT-External-Port- | ||||
Style = FOLLOW_INTERNAL_PORT_STYLE | ||||
} | ||||
13.3. DNCA Session Query Example | ||||
This section shows an example for DNCA session query for a subscriber | ||||
whose internal IP-Address is 192.0.2.1. | ||||
< NC-Request > ::= < Diameter Header: TBD, REQ, PXY> | ||||
Auth-Application-Id = <DNCA Application ID> | ||||
Origin-Host = "natC.example.com" | ||||
Origin-Realm = "example.com" | ||||
Destination-Realm = "example.com" | ||||
Destination-Host = "nat-device.example.com" | ||||
NC-Request-Type = QUERY_REQUEST | ||||
Framed-IP-Address = "192.0.2.1" | ||||
The NAT-device constructs an NCA to report all currently active NAT- | ||||
bindings whose internal address is 192.0.2.1. | ||||
<NC-Answer> ::= < Diameter Header: TBD, PXY > | ||||
Origin-Host = "nat-device.example.com" | ||||
Origin-Realm = "example.com" | ||||
NC-Request-Type = QUERY_REQUEST | ||||
NAT-Control-Definition = { | ||||
Protocol = TCP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 80 | ||||
} | ||||
NAT-External-Address = { | ||||
Framed-IP-Address = "198.51.100.1" | ||||
Port = 80 | ||||
} | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
} | ||||
NAT-Control-Definition = { | ||||
Protocol = TCP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 1036 | ||||
} | ||||
NAT-External-Address = { | ||||
Framed-IP-Address = "198.51.100.1" | ||||
Port = 5056 | ||||
} | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
} | ||||
NAT-Control-Definition = { | ||||
Protocol = TCP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 1037 | ||||
} | ||||
NAT-External-Address = { | ||||
Framed-IP-Address = "198.51.100.1" | ||||
Port = 5057 | ||||
} | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
} | ||||
13.4. DNCA Session Termination Example | ||||
In this example the NAT-controller decides to terminate the | ||||
previously established DNCA session. This could for example be the | ||||
case as a result of an access session (e.g. a PPP session) associated | ||||
with an end point been torn down. | ||||
NAT-Controller NAT-device | ||||
| | | ||||
| | | ||||
+--------------+ | | ||||
| 1. Trigger | | | ||||
+--------------+ | | ||||
| | | ||||
| | | ||||
| 2. STR | | ||||
|-------------------------------------->| | ||||
| | | ||||
| 3. DNCA session | ||||
| lookup | ||||
| 4. ACR | | ||||
|<--------------------------------------| | ||||
| | | ||||
| 5. ACA | | ||||
|-------------------------------------->| | ||||
| | | ||||
| | | ||||
| 6. DNCA bindings | ||||
| and session cleanup | ||||
| | | ||||
| 7. STA | | ||||
|<--------------------------------------| | ||||
| | | ||||
Figure 20: NAT control session termination example | ||||
The following steps describe the sequence of events for tearing down | ||||
the DNCA session in the example above: | ||||
1. The NAT-controller receives a trigger that a DNCA session | ||||
associated with a specific end point should be terminated. An | ||||
example event could be the termination of the PPP [RFC1661] | ||||
access session to an end point in a NAS. The NAS correspondingly | ||||
triggers the NAT-controller request tear-down of the associated | ||||
DNCA session. | ||||
2. The NAT-controller creates the required NCR message and sends it | ||||
to the NAT-device: | ||||
< STR > ::= < Diameter Header: 275, REQ, PXY> | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Auth-Application-Id = <DNCA Application ID> | ||||
Origin-Host = "natC.example.com" | ||||
Origin-Realm = "example.com" | ||||
Destination-Realm = "example.com" | ||||
Destination-Host = "nat-device.example.com" | ||||
Termination-Cause = DIAMETER_LOGOUT | ||||
3. The NAT-device looks up the DNCA session based on the Session-Id | ||||
AVP and finds a previously established active session. | ||||
4. The NAT-device reports all NAT-bindings established for that | ||||
subscriber using an ACR: | ||||
< ACR > ::= < Diameter Header: 271, REQ, PXY> | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Auth-Application-Id = <DNCA Application ID> | ||||
Origin-Host = "nat-device.example.com" | ||||
Origin-Realm = "example.com" | ||||
Destination-Realm = "example.com" | ||||
Destination-Host = "natC.example.com" | ||||
Accounting-Record-Type = STOP_RECORD | ||||
Accounting-Record-Number = 1 | ||||
NAT-Control-Record = { | ||||
NAT-Control-Definition = { | ||||
Protocol = TCP | ||||
Direction = OUT | ||||
NAT-Internal-Address = { | ||||
Framed-IP-Address = "192.0.2.1" | ||||
Port = 5001 | ||||
} | ||||
NAT-External-Address = { | ||||
Framed-IP-Address = "198.51.100.1" | ||||
Port = 7777 | ||||
} | ||||
} | ||||
NAT-Control-Binding-Status = Removed | ||||
} | ||||
5. The NAT-controller receives and processes the ACR as per its | ||||
configuration. It responds with an ACA to the NAT-device. | ||||
<ACA> ::= < Diameter Header: 271, PXY > | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Origin-Host = "natC.example.com" | ||||
Origin-Realm = "example.com" | ||||
Result-Code = DIAMETER_SUCCESS | ||||
Accounting-Record-Type = STOP_RECORD | ||||
Accounting-Record-Number = 1 | ||||
6. On receipt of the ACA the NAT-device cleans up all NAT-bindings | ||||
and associated session state for the end point. | ||||
7. NAT-device sends an STA. On receipt of the STA the NAT- | ||||
controller will clean up the corresponding session state. | ||||
<STA> ::= < Diameter Header: TBD, PXY > | ||||
Session-Id = "natC.example.com:33041;23432;" | ||||
Origin-Host = "nat-device.example.com" | ||||
Origin-Realm = "example.com" | ||||
Result-Code = DIAMETER_SUCCESS | ||||
14. Acknowledgements | ||||
The authors would like to thank Jari Arkko, Wesley Eddy, Stephen | ||||
Farrell, Miguel A. Garcia, David Harrington, Jouni Korhonen, Matt | ||||
Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Robert | ||||
Sparks, Martin Stiemerling, Dave Thaler, Hannes Tschofenig, Sean | ||||
Turner, Shashank Vikram, Greg Weber, and Glen Zorn for their input on | ||||
this document. | ||||
15. Change History (to be removed prior to publication as an RFC) | ||||
Changes from -00 to -01 | Changes from -00 to -01 | |||
a. new values for Result-Code AVP used - instead of Experimental- | a. new values for Result-Code AVP used - instead of Experimental- | |||
Result AVP | Result AVP | |||
b. added support for transport specific binding (UDP/TCP) | b. added support for transport specific binding (UDP/TCP) | |||
c. added support for twice-NAT | c. added support for twice-NAT | |||
skipping to change at page 43, line 46 | skipping to change at page 56, line 28 | |||
a. expanded on the need for an SP controlling the maximum number of | a. expanded on the need for an SP controlling the maximum number of | |||
bindings of an end point (see introduction section) | bindings of an end point (see introduction section) | |||
b. added a paragraph in the security section outlining general mis- | b. added a paragraph in the security section outlining general mis- | |||
uses of NAT-control (non specific to DNCA), with DNCA being an | uses of NAT-control (non specific to DNCA), with DNCA being an | |||
example of such a NAT-control protocol | example of such a NAT-control protocol | |||
c. editorial changes | c. editorial changes | |||
15. Normative References | Changes from -09 to -10 | |||
a. Section 4 and security considerations updated with RFC 2119 | ||||
language | ||||
b. NAT-External-Port-Style AVP added to aid external port oddity | ||||
requirement as per MIDCOM framework | ||||
c. NAT related RFCs added in normative reference | ||||
d. Section 13 added to provide example DNCA message exchange flows | ||||
e. Added a description to provide DNCA comparison with MIDCOM | ||||
f. n:1 deployment model for NAT-controllers and NAT-devices | ||||
explicitly specified | ||||
g. editorial changes as per IESG DISCUSS comments | ||||
16. References | ||||
16.1. Normative References | ||||
[ETSIES283034] | [ETSIES283034] | |||
ETSI, "Telecommunications and Internet Converged Services | ETSI, "Telecommunications and Internet Converged Services | |||
and Protocols for Advanced Networks (TISPAN),Network | and Protocols for Advanced Networks (TISPAN),Network | |||
Attachment Sub-System (NASS),e4 interface based on the | Attachment Sub-System (NASS),e4 interface based on the | |||
Diameter protocol.", September 2008. | Diameter protocol.", September 2008. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
skipping to change at page 44, line 30 | skipping to change at page 57, line 35 | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., | [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., | |||
and A. Lior, "Traffic Classification and Quality of | and A. Lior, "Traffic Classification and Quality of | |||
Service (QoS) Attributes for Diameter", RFC 5777, | Service (QoS) Attributes for Diameter", RFC 5777, | |||
February 2010. | February 2010. | |||
16.2. Informative References | ||||
[I-D.ietf-behave-lsn-requirements] | ||||
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., | ||||
and H. Ashida, "Common requirements for Carrier Grade NAT | ||||
(CGN)", draft-ietf-behave-lsn-requirements-03 (work in | ||||
progress), August 2011. | ||||
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, | ||||
RFC 1661, July 1994. | ||||
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address | ||||
Translator (NAT) Terminology and Considerations", | ||||
RFC 2663, August 1999. | ||||
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | ||||
Address Translator (Traditional NAT)", RFC 3022, | ||||
January 2001. | ||||
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and | ||||
A. Rayhan, "Middlebox communication architecture and | ||||
framework", RFC 3303, August 2002. | ||||
[RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, | ||||
"Middlebox Communications (midcom) Protocol Requirements", | ||||
RFC 3304, August 2002. | ||||
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An | ||||
Architecture for Describing Simple Network Management | ||||
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, | ||||
December 2002. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | ||||
Jacobson, "RTP: A Transport Protocol for Real-Time | ||||
Applications", STD 64, RFC 3550, July 2003. | ||||
[RFC4097] Barnes, M., "Middlebox Communications (MIDCOM) Protocol | ||||
Evaluation", RFC 4097, June 2005. | ||||
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox | ||||
Communication (MIDCOM) Protocol Semantics", RFC 5189, | ||||
March 2008. | ||||
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation | ||||
Algorithm", RFC 6145, April 2011. | ||||
[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. | ||||
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | ||||
Bierman, "Network Configuration Protocol (NETCONF)", | ||||
RFC 6241, June 2011. | ||||
Authors' Addresses | Authors' Addresses | |||
Frank Brockners | Frank Brockners | |||
Cisco | Cisco | |||
Hansaallee 249, 3rd Floor | Hansaallee 249, 3rd Floor | |||
DUESSELDORF, NORDRHEIN-WESTFALEN 40549 | DUESSELDORF, NORDRHEIN-WESTFALEN 40549 | |||
Germany | Germany | |||
Email: fbrockne@cisco.com | Email: fbrockne@cisco.com | |||
Shwetha Bhandari | Shwetha Bhandari | |||
Cisco | Cisco | |||
Cessna Business Park, Sarjapura Marathalli Outer Ring Road | Cessna Business Park, Sarjapura Marathalli Outer Ring Road | |||
Bangalore, KARNATAKA 560 087 | Bangalore, KARNATAKA 560 087 | |||
India | India | |||
Email: shwethab@cisco.com | Email: shwethab@cisco.com | |||
Vaneeta Singh | Vaneeta Singh | |||
18, Cambridge Road | 18, Cambridge Road | |||
Bangalore 560008 | Bangalore 560008 | |||
India | India | |||
Email: vaneeta.singh@gmail.com | Email: vaneeta.singh@gmail.com | |||
Victor Fajardo | Victor Fajardo | |||
Telcordia Technologies | Telcordia Technologies | |||
1 Telcordia Drive #1S-222 | 1 Telcordia Drive #1S-222 | |||
End of changes. 174 change blocks. | ||||
451 lines changed or deleted | 1055 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |