Skip to main content

Shepherd writeup
draft-ietf-radext-ip-port-radius-ext

=== 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:
* I-D.gundavelli-v6ops-community-wifi-svcs
However, it is not essential for this specification.
Back