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

From: Wojciech Dec <[email-masked]>
Date: Mon, 01 Aug 2011 12:47:38 -0400

Hi All,

Allow me to share some comments:

* There is precedent of multiple “specific” named pools; Framed-Pool,
Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is
also a special code in the Framed-IPX-Network attribute that conveys it pool
like characteristics.
* There is little that disallows a vendor from implementing just one named
pool for all protocols and all methods of assignment ( the Framed-Pool
appears to have been envisaged for that ) and then using some implementation
specific logic (eg parsing for a name) to figure out/how it’s to be used.
* The problem with relying on implementation specific features riding on
standard Attributes, as opposed to say VSAs, is that nothing indicates to
the server/client if the recipient actually supports such special features
and assures correct interpretation. Eg if we used the Framed-Pool as the ONE
named pool attribute, with a carried string “IPv4”, “IPv6” or “DHCPv6-PD”,
etc, parsed/whatever to indicate the role, it would be all doable, but a
likely mess should anything go wrong (eg a device not supporting some mode),
without clear indication of error.

Since the Radius specification is NOT about specifying implementation the
only reliable/unambiguous manner in which different pools/methods can be
utilized would appear to be using different attributes as proposed in the
current draft. Time (precedent) also appears to have proved this as a
desirable protocol characteristic.
Are there any other options/solutions available that do not call on implicit
features being there?

Regards,
Wojciech.

On 26/07/2011 22:51, "Leaf yeh" <[email-masked]> wrote:

> [RM] NAS can have many pools configured locally: how does the NAS know which
> pool is for SLAAC and which pool is for DHCPv6?
> 
>  
> 
> I supposed the local configuration on the NAS will answer this question.
> 
>  
> 
> Best Regards,
> 
> Leaf
> 
>  
> 
>  
> 
> 
> 发件人: Maglione Roberta [[email-masked]]
> 发送时间: 2011年7月27日 3:54
> 到: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> 主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
> 
>  
>  
> 
> 
> From: Leaf yeh [mailto:[email-masked]]
> Sent: martedì 26 luglio 2011 21.50
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> Subject: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
>  
> 
> [RM] All the configured pools are the same for the NAS, in this case an extra
> logic would be needed to instruct the NAS about which pool is for SLAAC and
> which one is for DHCPv6
> 
>  
> 
> The pools configured on the NAS are not necessary to be the same. AAA server
> doesn't really need to instruct the NAS the specified type of pools, which is
> already configured on the NAS. Right?
> 
>  
> 
> [RM] NAS can have many pools configured locally: how does the NAS know which
> pool is for SLAAC and which pool is for DHCPv6?
> 
>  
> 
> Roberta
> 
>  
> 
> Best Regards,
> 
> Leaf
> 
>  
> 
>  
> 
>  
> 
> 
> 发件人: Maglione Roberta [[email-masked]]
> 发送时间: 2011年7月27日 2:27
> 到: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> 主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
> 
> Please see inline.
>  
> Best regards,
> Roberta
>  
> 
> 
> From: Leaf yeh [mailto:[email-masked]]
> Sent: martedì 26 luglio 2011 20.22
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [email-masked]; [email-masked];
> [email-masked]; Qiujin; Wangshuxiang
> Subject: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
>  
> 
> Roberta - If you use the same attribute for both scenarios how does the NAS
> know if that pool is for SLAAC or for Stateful DHCPv6?
> 
> NAS already has those pool names in its configuration, right?
> 
> [RM] yes pools are already configured in the NAS
> 
>  
> 
> NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6
> address pool. 
> 
>  
> 
> [RM] All the configured pools are the same for the NAS, in this case an extra
> logic would be needed to instruct the NAS about which pool is for SLAAC and
> which one is for DHCPv6
> 
>  
> 
>  
> 
>  
> 
> That’s why in my opinion the Stateful-IPv6-Address-Pool is required.
> 
>  
> 
>  
> 
> Best Regards,
> 
> Leaf
> 
>  
> 
>  
> 
> 
> 发件人: Maglione Roberta [[email-masked]]
> 发送时间: 2011年7月27日 2:13
> 到: 'Jacni Qin'
> Cc: Leaf yeh; [email-masked];
> [email-masked]; [email-masked]; Qiujin; Wangshuxiang
> 主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
> 
> Hi Jacni,
>    If you use the same attribute for both scenarios how does the NAS know if
> that pool is for SLAAC or for Stateful DHCPv6?
> 
> Thanks,
> Regards,
> Roberta
> 
> 
> 
> 
> 
> ________________________________________
> From: Jacni Qin [mailto:[email-masked]]
> Sent: martedì 26 luglio 2011 20.03
> To: Maglione Roberta
> Cc: Leaf yeh; [email-masked];
> [email-masked]; [email-masked]; Qiujin; Wangshuxiang
> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
> 
> Hi Roberta,
> 
> I agree with you about the semantical logic, while
> "Stateful-IPv6-Address-Pool" is not necessary, IMHO.
> 
> 
> Cheers,
> Jacni
> On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta
> <[email-masked]> wrote:
> Hello Leaf,
>     The different attributes proposed in this draft for the pools name have
> all the same format (a string), but semantically they are different, as they
> coved different scenarios.
> As you also summarized in your email below,
> 
> Framed-Pool was designed for the IPv4 address pool;
> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;
> 
> So each attribute covers a different use-case/scenario and they can appear in
> the same RADIUS packet at the same time.
> If you want to use a single pool name use to cover all the 4 use cases listed
> above, you would also need to define a standard format/syntax for the pool
> name that allows the NAS to be able to disambiguate among the different
> scenarios and in order to do that the NAS would need to have an extra logic to
> infer the semantic of that specific attribute from the assigned name.
> Instead if you have a specific attribute for each specific scenario, the
> semantic is mapped to the attribute name, thus the NAS does not need an extra
> logic to discovery the purpose of that pool and the pool name can be any
> string, no limitation or special syntax is forced for the pool name.
> 
> 
> Thanks,
> Regards,
> Roberta
> 
> 
> 
> 
> 
> ________________________________________
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leaf yeh
> Sent: lunedì 25 luglio 2011 18.23
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Qiujin; Wangshuxiang
> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext
> session
> 
> Question for clarification:
> 
> We already have the following Radius Attributes for the address/prefix pools:
> 
> Framed-Pool (88, section 5.18 of RFC2869),
> Framed-IPv6-Pool (100, section 2.6 of RFC3162).
> 
> http://www.iana.org/assignments/radius-types/radius-types.xml
> 
> The foramt are the same as follows:
> 
> 0                   1                   2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     Type      |    Length     |     String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for
> address/prefix pools:
> 
> Delegated-IPv6-Prefix-Pool,
> Stateful-IPv6-Address-Pool,
> 
> the fomat of these 2 attributes are the same as the above one.
> 
> 
> Supposed the above attributes could be explained as follows:
> 
> Framed-Pool was designed for the IPv4 address pool;
> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;
> 
> All above attributes are only used to provide the name of the address/prefix
> pools in a 'string'. I doubt the necessity to make so many 'name' or 'string'
> attributes for the different address/prefix pools to prevent the ambiguity. I
> guess 1 attribute for the name of the address/prefix pools might be enough. In
> fact, the NAS take the role to interpret the meaning of the pook name, right?
> 
> I think Framed-Pool can be re-used for the design purpose of
> Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of
> Framed-Pool for IPv6?
> I think Framed-IPv6-Pool can be re-used for the design purpose of
> Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could
> even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a
> IPv6 prefix/address pool per the same logic. Am I right?
> 
> 
> Best Regards,
> Leaf
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
> Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> 
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail
> se non è necessario.
>  
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail
> se non è necessario.
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Aug 2011 15:48:13 -0700

In general, the concern that has lead to defining these distinct pools is the possibility that multiple pool types might be enabled for a single session.  For example, it's possible that an IPv6 address might be assigned from a pool, and at the same time that a Prefix might be delegated from a pool, for the same user and session.  In such a situation,  using the same pool name for multiple purposes could be ambiguous and/or under-specified.  

A note about Woj's concern about errors.  With respect to a server sending an attribute that a client does not understand, RFC 5080 Section 2.5 provides guidance:

   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.As a result, it is possible that a client not implementing the IPv6 Access RFC will ignore the attributes (e.g. not implement the SHOULD) rather than refusing to provide service. 

Date: Mon, 1 Aug 2011 12:47:38 -0400
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

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

Hi All,

There is precedent of multiple “specific” named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network attribute that conveys it pool like characteristics. 
There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it’s to be used. 
The problem with relying on implementation specific features riding on standard Attributes, as opposed to say VSAs, is that nothing indicates to the server/client if the recipient actually supports such special features and assures correct interpretation. Eg if we used the Framed-Pool as the ONE named pool attribute, with a carried string “IPv4”, “IPv6” or “DHCPv6-PD”, etc, parsed/whatever to indicate the role, it would be all doable, but a likely mess should anything go wrong (eg a device not supporting some mode), without clear indication of error.

Since the Radius specification is NOT about specifying implementation the only reliable/unambiguous manner in which different pools/methods can be utilized would appear to be using different attributes as proposed in the current draft. Time (precedent) also appears to have proved this as a desirable protocol characteristic. 

Are there any other options/solutions available that do not call on implicit features being there?

Regards,

Wojciech.

[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?

 

Best Regards,

Leaf

 

发送时间: 2011年7月27日 3:54

到: Leaf yeh; 'Jacni Qin'

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

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

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

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

[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6

The pools configured on the NAS are not necessary to be the same. AAA server doesn't really need to instruct the NAS the specified type of pools, which is already configured on the NAS. Right?

[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?

Roberta

Best Regards,

Leaf

 

发送时间: 2011年7月27日 2:27

到: Leaf yeh; 'Jacni Qin'

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

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

Please see inline.

Best regards,

Roberta

Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

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

Roberta - If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?

 

NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 address pool. 

[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6

 

 

Best Regards,

Leaf

 

发送时间: 2011年7月27日 2:13

到: 'Jacni Qin'

Cc: Leaf yeh; [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

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

Hi Jacni,

   If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,

Regards,

Roberta

To: Maglione Roberta

Cc: Leaf yeh; [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang

Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Address-Pool" is not necessary, IMHO.

Cheers,

Jacni

On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <[email-masked]> wrote:

Hello Leaf,

    The different attributes proposed in this draft for the pools name have all the same format (a string), but semantically they are different, as they coved different scenarios.

So each attribute covers a different use-case/scenario and they can appear in the same RADIUS packet at the same time.

If you want to use a single pool name use to cover all the 4 use cases listed above, you would also need to define a standard format/syntax for the pool name that allows the NAS to be able to disambiguate among the different scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that specific attribute from the assigned name.

Instead if you have a specific attribute for each specific scenario, the semantic is mapped to the attribute name, thus the NAS does not need an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitation or special syntax is forced for the pool name.

Thanks,

Regards,

Roberta

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf yeh

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

0                   1                   2

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools:

All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6?

I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right?

Best Regards,

Leaf

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non è necessario. 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Leaf yeh <[email-masked]>
Date: Mon, 15 Aug 2011 11:19:20 +0000

Wojciech - There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it’s to be used.

I agree.

Wojciech - Since the Radius specification is NOT about specifying implementation the only reliable/unambiguous manner in which different pools/methods can be utilized would appear to be using different attributes as proposed in the current draft. Are there any other options/solutions available that do not call on implicit features being there?

A new attribute designed to indicate the ‘User-Type’ sounds a more straight manner and will have the potential extensibility to prevent this kind of ambiguity, which has been proposed in  section 4.1 of draft-yeh-radext-dual-stack-access-02.

The ‘User-Type’ can cover the following cases for both PPPoE and IPoE access model by now.

IPv4-only Host
IPv6-only Host(Numbered by SLAAC)
IPv6-only Host(Numbered by DHCPv6)
IPv6-only Customer Router(Unnumbered)
IPv6-only Customer Router(Numbered by SLAAC)
IPv6-only Customer Router(Numbered by DHCPv6)
Dual stack - IPv4 Host + IPv6 Host(Numbered by SLAAC)
Dual stack - IPv4 Host + IPv6 Host(Numbered by DHCPv6)
Dual stack - IPv4 Host + IPv6 Customer Router(Unnumbered)
Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by SLAAC)
Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by DHCPv6)

Another usage (or design purpose) of ‘User-Type’ is for the default behavior of the NAS. When the NAS has not received the pool-name attributes (Framed-Pool, Framed-IPv6-Pool, etc) from AAA server, it can directly assign the address/prefix from the default pools.

Section 4.1 of draft-tan-v6ops-fast6-aaa-01 might give us a new reference.
"User-Type" attribute can simplify the way how BRAS determines the user type.  In addition, BRAS can allocate appropriate IP addresses for the user even without the address pool attribute sent by RADIUS serve, if default address pool is defined by BRAS.

Best Regards,
Leaf

From: Bernard Aboba [mailto:[email-masked]]
Sent: Wednesday, August 03, 2011 6:48 AM
To: [email-masked]; Leaf yeh; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Qiujin; Wangshuxiang
Subject: RE: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

   it as an Access-Reject, as directed in [RFC2865] Section 1.1<http://tools.ietf.org/html/rfc2865#section-1.1>.  On

   ignored by RADIUS clients.
As a result, it is possible that a client not implementing the IPv6 Access RFC will ignore the attributes (e.g. not implement the SHOULD) rather than refusing to provide service.
________________________________
Date: Mon, 1 Aug 2011 12:47:38 -0400
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi All,

  *   There is precedent of multiple “specific” named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network attribute that conveys it pool like characteristics.
  *   There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it’s to be used.
  *   The problem with relying on implementation specific features riding on standard Attributes, as opposed to say VSAs, is that nothing indicates to the server/client if the recipient actually supports such special features and assures correct interpretation. Eg if we used the Framed-Pool as the ONE named pool attribute, with a carried string “IPv4”, “IPv6” or “DHCPv6-PD”, etc, parsed/whatever to indicate the role, it would be all doable, but a likely mess should anything go wrong (eg a device not supporting some mode), without clear indication of error.

Regards,
Wojciech.

On 26/07/2011 22:51, "Leaf yeh" <[email-masked]<http://[email-masked]>> wrote:
[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?

Best Regards,

Leaf

________________________________
发件人: Maglione Roberta [[email-masked]<http://[email-masked]>]
发送时间: 2011年7月27日 3:54
到: Leaf yeh; 'Jacni Qin'
Cc: [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang
主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

________________________________
From: Leaf yeh [mailto:[email-masked]]
Sent: martedì 26 luglio 2011 21.50
To: Maglione Roberta; 'Jacni Qin'
Cc: [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang
Subject: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Roberta

Best Regards,

Leaf

________________________________
发件人: Maglione Roberta [[email-masked]<http://[email-masked]>]
发送时间: 2011年7月27日 2:27
到: Leaf yeh; 'Jacni Qin'
Cc: [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang
主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Please see inline.

Best regards,
Roberta

________________________________
From: Leaf yeh [mailto:[email-masked]]
Sent: martedì 26 luglio 2011 20.22
To: Maglione Roberta; 'Jacni Qin'
Cc: [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang
Subject: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Best Regards,

Leaf

________________________________
发件人: Maglione Roberta [[email-masked]<http://[email-masked]>]
发送时间: 2011年7月27日 2:13
到: 'Jacni Qin'
Cc: Leaf yeh; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang
主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Hi Jacni,

Thanks,
Regards,
Roberta

Cc: Leaf yeh; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang

Hi Roberta,

Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <[email-masked]<http://[email-masked]>> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the pools name have all the same format (a string), but semantically they are different, as they coved different scenarios.
As you also summarized in your email below,

Thanks,
Regards,
Roberta

________________________________________
From: [email-masked]<http://[email-masked]> [mailto:[email-masked]] On Behalf Of Leaf yeh
Sent: lunedì 25 luglio 2011 18.23
To: [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>
Cc: [email-masked]<http://[email-masked]>; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

0                   1                   2

Best Regards,
Leaf

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 15 Aug 2011 11:43:31 +0000 (UTC)

> PPPoE and IPoE access model by now.

The proposed values for this attribute seem to describe properties of the attached host.  In RADIUS, the term "user" refers to a human, for whom account and service provisioning has been established.  I would suggest calling this proposed attribute something else, more accurately descriptive. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 15 Aug 2011 14:09:12 +0200

Hello Leaf,

If I understand it correctly, you’re proposing that the end user/host types
be enumerated as part of a new attribute, which would then drive the
addressing behavior, eg selection of pools. If so, it looks very much as
relying on the special NAS feature to interpret *the contents* of the
attribute as to the pools to be used, only this time with the contents being
laid down as the enumerated type code points in a 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.
Besides the above, as with any enumerated type, issues will start should
there be another combination that someone comes up with or wants...

Frankly, other than it being another way of doing things, I personally don’t
see much of a benefit.

Regards,
Woj.

On 15/08/2011 13:19, "Leaf yeh" <[email-masked]> wrote:

> Wojciech - There is little that disallows a vendor from implementing just one
> named pool for all protocols and all methods of assignment ( the Framed-Pool
> Wojciech - Since the Radius specification is NOT about specifying
> implementation the only reliable/unambiguous manner in which different
> pools/methods can be utilized would appear to be using different attributes as
> proposed in the current draft. Are there any other options/solutions available
> that do not call on implicit features being there?
> 
> 
> A new attribute designed to indicate the ‘User-Type’ sounds a more straight
> manner and will have the potential extensibility to prevent this kind of
> ambiguity, which has been proposed in  section 4.1 of
> draft-yeh-radext-dual-stack-access-02.
>  
> Another usage (or design purpose) of ‘User-Type’ is for the default behavior
> of the NAS. When the NAS has not received the pool-name attributes
> (Framed-Pool, Framed-IPv6-Pool, etc) from AAA server, it can directly assign
> the address/prefix from the default pools.
>  
> "User-Type" attribute can simplify the way how BRAS determines the user type.
> In addition, BRAS can allocate appropriate IP addresses for the user even
> without the address pool attribute sent by RADIUS serve, if default address
> pool is defined by BRAS.
>  
>  
> Best Regards,
> Leaf
>  
>  
>  
> 
> In general, the concern that has lead to defining these distinct pools is the
> possibility that multiple pool types might be enabled for a single session.
> For example, it's possible that an IPv6 address might be assigned from a pool,
> and at the same time that a Prefix might be delegated from a pool, for the
> same user and session.  In such a situation,  using the same pool name for
> multiple purposes could be ambiguous and/or under-specified.
> 
> A note about Woj's concern about errors.  With respect to a server sending an
> attribute that a client does not understand, RFC 5080 Section 2.5 provides
> guidance:
>    it as an Access-Reject, as directed in [RFC2865] Section 1.1
> <http://tools.ietf.org/html/rfc2865#section-1.1> .  On
> As a result, it is possible that a client not implementing the IPv6 Access RFC
> will ignore the attributes (e.g. not implement the SHOULD) rather than
> refusing to provide service.
> 
> 
> CC: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 
> Hi All,
> 
> pool for all protocols and all methods of assignment ( the Framed-Pool appears
> to have been envisaged for that ) and then using some implementation specific
> logic (eg parsing for a name) to figure out/how it’s to be used.
> standard Attributes, as opposed to say VSAs, is that nothing indicates to the
> server/client if the recipient actually supports such special features and
> assures correct interpretation. Eg if we used the Framed-Pool as the ONE named
> pool attribute, with a carried string “IPv4”, “IPv6” or “DHCPv6-PD”, etc,
> parsed/whatever to indicate the role, it would be all doable, but a likely
> mess should anything go wrong (eg a device not supporting some mode), without
> clear indication of error.
> 
> Since the Radius specification is NOT about specifying implementation the only
> reliable/unambiguous manner in which different pools/methods can be utilized
> would appear to be using different attributes as proposed in the current
> draft. Time (precedent) also appears to have proved this as a desirable
> protocol characteristic.
> On 26/07/2011 22:51, "Leaf yeh" <[email-masked]
> <http://[email-masked]> > wrote:
> 发件人: Maglione Roberta [[email-masked]
> <http://[email-masked]> ]
> 发送时间: 2011年7月27日 3:54
> 到: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> 发件人: Maglione Roberta [[email-masked]
> <http://[email-masked]> ]
> 发送时间: 2011年7月27日 2:27
> 到: Leaf yeh; 'Jacni Qin'
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> Cc: [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> 发件人: Maglione Roberta [[email-masked]
> <http://[email-masked]> ]
> 发送时间: 2011年7月27日 2:13
> 到: 'Jacni Qin'
> Cc: Leaf yeh; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> Cc: Leaf yeh; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]> ; Qiujin; Wangshuxiang
> <[email-masked] <http://[email-masked]>
> > wrote:
> Hello Leaf,
> From: [email-masked] <http://[email-masked]>
> [mailto:[email-masked]] On Behalf Of Leaf yeh
> To: [email-masked]
> <http://[email-masked]> ; [email-masked]
> <http://[email-masked]>
> Cc: [email-masked] <http://[email-masked]> ; Qiujin; Wangshuxiang

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 15 Aug 2011 15:21:51 +0000 (UTC)

> ... 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,

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

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

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

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

-- Dave

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 15 Aug 2011 17:52:40 +0200

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

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

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

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

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

---

From: Leaf yeh <[email-masked]>
Date: Tue, 16 Aug 2011 07:27:22 +0000

How about the replacement of 'Node-type' or 'Access-type'?  or any other suggestion?

Best Regards,
Leaf

PS. http://www.iana.org/assignments/radius-types/radius-types.xml 

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

The proposed values for this attribute seem to describe properties of the attached host.  In RADIUS, the term "user" refers to a human, for whom account and service provisioning has been established.  I would suggest calling this proposed attribute something else, more accurately descriptive. 
h�{.n�+���zwZ��,j��������ު笶�l��_��0��m��(�ۧ���r��z)ڲ)���b�欶�z���^���w&�r�zm���(��b��?��b�Ǳ�

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 16 Aug 2011 16:58:02 +0200

On 16/08/2011 16:33, "Dave Nelson" <[email-masked]> wrote:

> 
> I have no problem with string encodings of pool names.   Since pools
> can be named arbitrarily by the NAS system administrator, anything
> other than a string encoding would be unnatural.  My issue is when we
> try to mix in a fixed set of address assignment methods with the pool
> names.  Separation of concerns.

Well, I think we're in agreement and when you come to read the WG proposal
in draft-ietf-radext-ipv6 you will find it NOT to have the above issue.
The origin of this email thread, it seems appropriate to recall it, is that
some folks claimed that the proposal in the draft is not needed and that
solving the case by overloading pool naming is better, followed on by a
second proposal for the enumerated type.

>> called for in this situation.
> 
> Why not?

Example given below, and it is one that is perfectly legitimate.

> 
>> 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...
> 
> I don't think that specific values for *combinations* of options is a
> good way to go.

It's rather clear that an enumerated attribute cannot handle this case.

> I'll find some time to do that, soon.

Please do. I think we're in agreement here and there is no need of changes.

Regards,
Woj.
> Dave
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636

---

From: Leaf yeh <[email-masked]>
Date: Tue, 16 Aug 2011 15:33:02 +0000

David - It's almost always the *contents* of attributes that is interpreted by the NAS...

I agree.

I thought AAA server just need to indicate single or multiple pool names, whose meaning & purpose should definitely be known in advanced by AAA server.

I doubted the attributes of 'Delegated-IPv6-Prefix-Pool' and 'Stateful-IPv6-Address-Pool' will make NAS's life easier than before. :-) I believe NAS will double check the type of pool against the name string in the different type container of the attributes (or proposed attributes) including Framed-Pool, Framed-IPv6-Pool, Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Address-Pool. Right?

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

-- Dave

---

From: Leaf yeh <[email-masked]>
Date: Tue, 16 Aug 2011 15:42:08 +0000

Wojciech - Ok. So help me out here: An operator has two pools, A for business

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:[email-masked]]
Sent: Monday, August 15, 2011 11:53 PM
To: David B. Nelson
Cc: [email-masked]; [email-masked]; fine sz; Qiujin; Wangshuxiang; [email-masked]; Leaf yeh; roberta maglione; [email-masked]; Bernard Aboba
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Thanks,
Wojciech.

---

From: Leaf yeh <[email-masked]>
Date: Wed, 17 Aug 2011 07:09:36 +0000

The original design of 'User-Type' defined in the section 4.1 of draft-yeh-radext-dual-stack-access-02 includes the differentiation between PPPoE & IPoE through different attribute-code-value. Though 'Address-Assignment-Type' sounds not have this differentiation, it is still fine to me. It does categorize the users by the prefix/address assignment, which is the most important part of the authorization. Could we have a better choice? Or 'Access-Address-Assignment-Type'?

Best Regards,
Leaf

-----Original Message-----
From: Dave Nelson [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 7:35 PM
To: Leaf yeh
Cc: David B. Nelson; [email-masked]; [email-masked]; Bernard Aboba
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

> How about the replacement of 'Node-type' or 'Access-type'?  or any other suggestion?

If the intent of this attribute is solely to control various types of
IP address and/or prefix assignment methods from a number of
pre-configured pools within the NAS, then I'd suggest something more
specific.  Perhaps 'Address-Assignment-Type'.  I wouldn't worry about
keeping it very short, and I wouldn't name it overly broadly, lest
future developers be tempted to conflate other NAS properties into the
same attribute.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
-��칻�&ޱ��jg������v+�{kz����)�'�~���+a����n�˛���m�jȧ�W��w���^��,j�{[�ܚ��b��m������o��l�������

---

From: Leaf yeh <[email-masked]>
Date: Wed, 17 Aug 2011 07:10:10 +0000

Dave - If there are in fact two independent variables at play (a) address
assignment method and (b) adress pool selection, then it seems to me
that we need one attribute (or set of attributes) to name the pool and
a second one to name the address assignment method.

Dave - I'm proposing that the (ad-hoc) precedent is a bad
design choice and that in standardizing this feature we perhaps should
make another choice.  I always prefer an enumerated type encoding over
a string encoding when the underlying semantics and data model of the
object is a set of discreet choices.

Dave - I have no problem with string encodings of pool names.   Since pools

I think the above explanations are good enough from the stand points of my view.

Best Regards,
Leaf

-----Original Message-----
From: Dave Nelson [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 10:34 PM
To: Wojciech Dec
Cc: David B. Nelson; [email-masked]; [email-masked]; fine sz; Qiujin; Wangshuxiang; [email-masked]; Leaf yeh; roberta maglione; [email-masked]; Bernard Aboba
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

> How does the NAS pick  the right pool based on receiving a single
> attribute containing an enumerated code-point for Foo-bar?

If there are in fact two independent variables at play (a) address
assignment method and (b) adress pool selection, then it seems to me
that we need one attribute (or set of attributes) to name the pool and
a second one to name the address assignment method.

> in the current ipv6-access draft.

I understand. I'm proposing that the (ad-hoc) precedent is a bad
design choice and that in standardizing this feature we perhaps should
make another choice.  I always prefer an enumerated type encoding over
a string encoding when the underlying semantics and data model of the
object is a set of discreet choices.

Why not?

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Leaf yeh <[email-masked]>
Date: Wed, 17 Aug 2011 07:12:06 +0000

Woj - >> Should an operator choose to say assign 2 prefixes to a subscriber
>> get an IANA code point...
Dave - > I don't think that specific values for *combinations* of options is a
> good way to go.

Woj - It's rather clear that an enumerated attribute cannot handle this case.

For the above case, 'Access/Address-Assignment/User-Type' [for Customer Router (Numbered by SLAAC) ] + 3*'Framed-Pool'(2 for DHCPv6-PD pool name, 1 for SLACC pool name) will be authorized by AAA server for users. Right?

Best Regards,
Leaf

-----Original Message-----
From: Wojciech Dec [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 10:58 PM
To: Dave Nelson
Cc: David B. Nelson; [email-masked]; [email-masked]; fine sz; Qiujin; Wangshuxiang; [email-masked]; Leaf yeh; roberta maglione; [email-masked]; Bernard Aboba
Subject: Re: 答复: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

Regards,
Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 17 Aug 2011 10:05:42 +0200

On 17/08/2011 09:10, "Leaf yeh" <[email-masked]> wrote:

>  My issue is when we

This is interesting, given that the root of this thread is your email
proposal for just that:
https://ops.ietf.org/lists/radiusext/2010/msg00959.html

Quote from the above:
" I think Framed-IPv6-Pool can be re-used for the design purpose of
Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could
even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of
a IPv6 prefix/address pool per the same logic"

draft-ietf-radext-ipv6-access-05 has no such issues does not mix pool naming
with addressing method. It defines separate string attributes for each
addressing method, and allows arbitrary pool name(s) for each.

Thanks,
Woj.