=== 1. Summary ===
The document shepherd is Lionel Morand.
The responsible Area Director is Kathleen Moriarty.
This document defines three new RADIUS attributes. For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.
Three new attributes (IP-Port-Limit-Info, IP-Port-Range, IP-Port-Forwarding-Map)are defined as "Extended Type" using the "TLV" data type, both defined in RFC6929). The "tlv" data type is an encapsulation layer that permits the "Value" field the attribute to contain new sub-attributes and this nesting is used to group data into logical containers.
This document provides also a mapping between RADIUS sub-TLV and IPFIX Information Element Identifiers, defining new IPFIX Information Elements when required.
=== 2. Review and Consensus ===
After detailed reviews and clean-up, this document is ready to be published.
These new attributes are useful when a RADIUS server is used to configure TCP/UDP port (or ICMP identifier) mapping behaviors in Carrier-Grade NAT or to report to the RADIUS Server the port/identifier mapping behavior applied by the CGN to a user session, as part of the accounting information sent to a RADIUS server.
The proposed RADIUS extensions are simple (definition of new TLV attributes allocated from the RADIUS "Extended Type" code space defined in RFC6929), and there was no difficulty in coming to consensus on the definition of these TLVs.
The IANA considerations section has been reviewed and is consistent with the body of the document. There is no discussion regarding the attribute type values assigned from the Short Extended Space defined in RFC6929. The attribute type value assignment by IANA should be straightforward. However, there was a discussion in the WG regarding the allocation of TLV-Type values for the sub-TLVs.
Some of the sub-TLVs are reused in the three attributes defined in this document. Therefore, two approaches were discussed after the shepherd review:
Approach#1: allocate a fixed TLV-Type for a same sub-TLV reused in multiple parent attributes.
Approach#2: allocate a TLV-Type meaningful only within the context defined by the parent attribute.
In the approach 1, using fixed values for sub-TLV used in any attribute is straightforward from a dictionary/configuration point of view, i.e. the same information is identified by the same name/value independently of the parent attribute. However it would mean defining a flat allocation space for sub-TLV, allowing only 253 values for the definition of sub-TLVs in the Extended-Type space.
In the approach 2, the guidelines given in the RFC6929 are strictly enforced, i.e. for nested TLVs, the TLV-Type is allocated in the type space defined by the parent attribute, of the form "Type.Extended-Type.TLV-Type.TLV-Type", allowing the definition of 253 TLV per extended attribute. However this implies extra-complexity to manage the same TLV with different name/id in different parent attributes.
Both approaches were considered as valid and the WG has decided to let IANA decide what the approach is preferred when allocating the TLV-Type for the sub-TLVs defined in this document. If required, the IANA section will be updated according to the final decision.
=== 3. Intellectual Property ===
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.
=== 4. Other Points ===
ID nits tool confirms that document meets the internet drafts checklists.
One specification put as informative reference is still in progress:
However, it is not essential for this specification.