[radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback

[Arran Cudbard-Bell <[e-mail]>]

Following up from the meeting at IETF90

SCTP/UDP encapsulation
----------------------
RFC6951 does allow SCTP to be encapsulated by UDP packets.
The reasons stated in the RFC are for legacy NAT traversal, and to allow SCTP to be
implemented on hosts which do not allow direct access to the IP layer.

When tunnelling SCTP UDP/9899 is used, though this is not a requirement, and the RFC states 
that other ports can be used.

Do people feel that it would be useful to be able to represent tunnelling with the attributes 
of cgn-cfg?

Protocol enumeration
--------------------
Majority of NAT'd communications will likely be TCP/UDP ICMP, but there is no reason why 
SCTP and other more exotic protocols couldn't be NAT'd.

To support arbitrary protocols, the extended IP-Port-Type attribute could reference the 
IANA protocol numbers registry, with the caveat that the protocol referenced used ports 
as connection identifiers.

Multiple IP-Port-Type attributes could be included to represent a port mapping in multiple 
protocols (where enum values 1 and 2 are used currently).

Explicit references to TCP/UDP/ICMP other than where used as examples would then be removed.

Reporting for dynamic CGN sessions (PCP)
----------------------------------------
ISPs are looking at NAT44 as a stopgap measure until v6 connectivity is sufficient to
run v6 only on CPEs.

UPnP to PCP gateways on the CPE allow legacy applications to work, by requesting specific
public ports on the NAT44 device.

Reporting for all N to 1 mappings required when used by ISPs for compliance reasons 
(in the UK at least). Law enforcement needs to be able to map Public IP/Port to private
IP and subscriber.

Just to check, in these cases would IP-Port-Forwarding-Map would be used to report these 
mappings, in a similar way as to how IP-Port-Range is used in Section 4.1.2?

Clarification around IP Port Allocation/De-allocation
-----------------------------------------------------
Section 4.1.2 describes a method of reporting range allocation and range deallocation but 
does not describe how to differentiate between the two.

Making an inference from other parts of the document, it seems that each Accounting-Request
packet records information about a single IP-Port-Range or IP-Port-Forwarding-Map 
allocation/deallocation.

Are separate RADIUS accounting sessions then, generated for each IP-Port-Range or 
IP-Port-Forwarding-Map? Should these sessions be linked to the subscriber's BNG session 
with Acct-Multi-Session-Id?

Or alternatively are each of the Accounting-Requests just Interim-Updates, and if so how
do we know when a port allocation is being reported as opposed to deallocation?

-Arran