Re: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks

[Wojciech Dec <wdec@cisco.com>]

Hello Peter,


On 26/04/2010 19:37, "Peter Deacon" <peterd@iea-software.com> wrote:

> On Mon, 26 Apr 2010, Wojciech Dec (wdec) wrote:
> 
>> Hello Peter,
>> As part of the resolution of Issue 335, we're proposing the addition of
>> the following text/section into the draft. Please let us know if this is
>> satisfactory.
> 
>> "Syntactically, the Framed-IPv6-Address and the RFC3162
>> Framed-IPv6-Prefix attributes are identical. In terms of their intended
>> semantics however the former represents a statefully assigned IPv6
>> address while the latter a prefix intended for application on a target
>> interface and are envisaged to be used in co-existence. Thus, in order
>> to preserve this semantical distinction it is recommended that each
>> attribute be used for its intended purpose, with the functional
>> substitution of one attribute for the other being an optional
>> configuration feature of a Radius client."
> 
> Hi Woj,
> 
> For Accounting messages in only the narrow case where Framed-IPv6-Address
> is assigned and no prefix is ultimatly allocated to the user what do you
> think about a recommendation for the /128 prefix be sent as well?

Yes, I would expect this to be already captured in the attribute usage
section/table with the 0+ notation. It's my understanding that the inclusion
of such optional Radius attributes is always made configurable.

> 
> Regardless your text works for me as-is, thank you.
>
Thanks,
Woj. 
> regards,
> Peter
> 
>> Thanks,
>> Woj.
> 
>>> -----Original Message-----
>>> From: Peter Deacon [mailto:peterd@iea-software.com]
>>> Sent: 03 March 2010 21:19
>>> To: Wojciech Dec (wdec)
>>> Cc: radiusext@ops.ietf.org
>>> Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access
>>> Networks
>>> 
>>> On Wed, 3 Mar 2010, Wojciech Dec (wdec) wrote:
>>> 
>>>>> My suggestion WRT an accounting restriction is based on a scenario:
>>>>> Accounting system relies on RFC 3162 to report client IP.
>>> 
>>>>> NAS decides to send IPv6-Framed-Address rather than RFC 3162
>> method.
>>>>> Accounting system requires modification to continue to
>>>>> understand the same information.
>>> 
>>>> Yes, I see your point. Don't you think however that this could be
>>>> handled by a client knob/implementation? I.E. If in an access-accept
>>> a
>>>> server sends the IPv6-Framed-Address, then the NAS client can
>>> interpret
>>>> it to mean that its ok to use this attribute in accounting messages.
>>> If
>>> 
>>>> an IPv6-Framed-Address does not come down in an access-accept, then
>>> the
>>>> NAS would use by default "whatever it uses today", unless it has
>> been
>>>> explicitly configured to send accounting info with using
>>>> IPv6-Framed-Address.
>>> 
>>>> This would seem to cover your concerns. What do you think?
>>> 
>>> Yes, sounds reasonable.
>>> 
>>> regards,
>>> Peter
>> 


--
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/>