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

Just for my clarification, we did not handle 
draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which 
document is meant here then? I assume 
draft-ietf-radext-ip-port-radius-ext is meant here, right.

- Jouni

7/25/2014 9:33 PM, Arran Cudbard-Bell kirjoitti:
> 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
>
>
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>