[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
See also section 2.5 in the document.
Dan
> -----Original Message-----
> From: Dave Nelson [mailto:d.b.nelson@comcast.net]
> Sent: Wednesday, January 14, 2009 7:33 PM
> To: Romascanu, Dan (Dan); aaa-doctors@ietf.org; radiusext@ops.ietf.org
> Subject: RE: [AAA-DOCTORS] AAA / RADIUS content
> indraft-ietf-softwire-hs-framework-l2tpv2
>
> Dan Romascanu writes...
>
> > Can somebody please have a look to the content of these sections?
>
>
> 4.3. Authentication Authorization Accounting
>
> RFC 2865 "Remote Authentication Dial In User Service (RADIUS)"
> [RFC2865].
>
> DBN: Current document. Updated by RFC2868, RFC3575, RFC5080.
>
> RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol
> Support" [RFC2867].
>
> DBN: Current document.
>
> RFC 2868 "RADIUS Attributes for Tunnel Protocol Support"
> [RFC2868].
>
> DBN: Current document.
>
> RFC 3162 "RADIUS and IPv6" [RFC3162].
>
> DBN: Current document.
>
> DBN: I can't attest that this list of references is necessary
> and sufficient to the requirements of Softwires, however.
>
>
> 9.1. RADIUS Accounting
>
> RADIUS Accounting for L2TP and PPP are documented (see
> Section 4.3).
>
> When deploying Softwire solutions, operators may experience
> difficulties to differentiate the address family of the traffic
> reported in accounting information from RADIUS. This problem and
> some potential solutions are described in
> [I-D.stevant-softwire-accounting].
>
> DBN: I have not reviewed the referenced I-D, but it's quite
> likely that a lack of (standardized) RADIUS attributes
> capable of representing address families might inhibit the
> straightforward application of RADIUS Accounting.
>
>
>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>