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:wdec@cisco.com] Sent: Monday, August 15, 2011 11:53 PM To: David B. Nelson Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine sz; Qiujin; Wangshuxiang; draft-tan-v6ops-fast6-aaa@tools.ietf.org; Leaf yeh; roberta maglione; jacniq@gmail.com; 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" <d.b.nelson@comcast.net> 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 |