RE: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

[Leaf yeh <[e-mail]>]

Wojciech - Ok. So help me out here: An operator has two pools, A for business
customers, B for residential. In both cases the operator expects Foo-bar
addressing method to be used and customers in A or B. How does the NAS pick
the right pool based on receiving a single attribute containing an
enumerated code-point for Foo-bar?

The default behavior configured on the NAS will pick the right address/prefix pools per the 'User-Type' (or Node/Access-Type), if it has not received the attributes of pool-name attributes (Framed-Pool, Framed-IPv6-Pool, or Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool ) from AAA server.

The 2nd use case of 'User/Node/Access-Type' is that the attributes combination of 'User/Node/Access-Type' + single (or multiple) attributes of 'Framed-Pool' [ or Framed-IPv6-Pool' (if we'd like to keep this attribute) or 'Delegated-IPv6-Prefix-Pool' (if we insist on using this attribute) or 'Stateful-IPv6-Address-Pool' (if we insist on using this attribute) ] can be used to indicate the right address/prefix pools for that specified user after authentication.

In the case defined above, the attributes authorized by AAA server can be 'User/Node/Access-Type' + 'Framed-Pool' containing A or 'User/Node/Access-Type ' + 'Framed-Pool' containing B. But if the pool B is in the default configuration of NAS, the attribute authorized by AAA server can only include 'User/Node/Access-Type'.

In any case, the AAA server need definitely understand the name & type & purpose of the various type of pools condifured on the NAS before the authorization for the users. NAS need definitely interpret those name strings containing in the pool-name attributes (Framed-Pool or etc) received from the AAA server.

That might means we don't really need to indicate the category (or type) of the pool names.


Wojciech - Precedent = rfc3162, rfc4818, and earlier non IPv6 ones, each define named pools for a specific purpose.

RFC4818 has not defined any concept for pools.
http://datatracker.ietf.org/doc/rfc4818/?include_text=1
http://www.iana.org/assignments/radius-types/radius-types.xml


Best Regards,

Leaf

-----Original Message-----
From: Wojciech Dec [mailto:[e-mail]]
Sent: Monday, August 15, 2011 11:53 PM
To: David B. Nelson
Cc: [e-mail]; [e-mail]; fine sz; Qiujin; Wangshuxiang; [e-mail]; Leaf yeh; roberta maglione; [e-mail]; Bernard Aboba
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session




On 15/08/2011 17:21, "David B. Nelson" <[e-mail]> wrote:

>> ... it looks very much as relying on the special NAS feature
>> to interpret *the contents* of the attribute as to the pools...
>
> Special NAS feature?  Why is the interpretation of this proposed RADIUS
> attribute any more special than NAS behavior that interprets any other
> attribute?  It's almost always the *contents* of attributes that is
> interpreted by the NAS,

Ok. So help me out here: An operator has two pools, A for business
customers, B for residential. In both cases the operator expects Foo-bar
addressing method to be used and customers in A or B. How does the NAS pick
the right pool based on receiving a single attribute containing an
enumerated code-point for Foo-bar?


>
>> ...to be used, only this time with the contents being laid down as
>> the enumerated type code points in a draft.
>
> I think an enumerated type is preferable to parsing strings when the semantics
> of the attribues is to apply one of a limited number of discreet choices.

The alternative, which is what I and others are proposing is to follow
precedent and use separate string attributes for their role - *as proposed*
in the current ipv6-access draft.
>
>> This does not help given a) past precedent in terms of Radius
>> pool definitions (there are already 2 pools, and they are being
>> used), nor b) give the operator an explicit indication regarding
>> the use of a pool, rather than implicit.
>
> I don't undertand either of these points.  What *RADIUS* precedent exists, and
> by that I mean a precedent in normative text?  If you're referring to ad-hoc
> implementation practice, in the absence of any normative guidance, I suggest
> that in standardizing a solution to that sort of gap in the protocol, one
> would not be unduly influenced by the fact that various ad-hoc solutions had
> been implemented.  That would defeat the purpose of standardizing behavior.

Precedent = rfc3162, rfc4818, and earlier non IPv6 ones, each define named
pools for a specific purpose.


>
>> Besides the above, as with any enumerated type, issues will start
>> should there be another combination that someone comes up with or
>> wants...
>
> The IANA code point allocation procedures should be sufficiently open to
> permit adding additional "flavors" without invoking IETF consensus or WG
> approvals.

Sure. We appear to be talking about code-points for values within a single
attribute, fine examples, ( for which no IANA code points were assigned)
include the existing Service-Type and Error-Cause attributes.
In enumerating this, by definition there is a restriction which is not
called for in this situation. Should an operator choose to say assign 2
prefixes to a subscriber for DHCP-PD, but one for SLAAC, they would need to
get an IANA code point... And then have the vendor(s) support that, etc.
Never mind open IANA code point allocation procedures - this looks to be
practically unwise.

>
>> Frankly, other than it being another way of doing things, I personally
>> don¹t see much of a benefit.
>
> If you are invested in an existing implementation using another approach I can
> understand that, but a clearly defined, enumerated value attribute seems more
> attractive to me.

Before going further, perhaps you could consider/comment on the current
proposal in: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-05

Thanks,
Wojciech.
>
> -- Dave