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: wdec@cisco.com To: leaf.y.yeh@huawei.com; roberta.maglione@telecomitalia.it; jacniq@gmail.com CC: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; qiujin@huawei.com; wangshuxiang@huawei.com
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" <leaf.y.yeh@huawei.com> 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 [roberta.maglione@telecomitalia.it]
发送时间: 2011年7月27日 3:54
到: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
主题: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: martedì 26 luglio 2011 21.50
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; 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 [roberta.maglione@telecomitalia.it]
发送时间: 2011年7月27日 2:27
到: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; 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:leaf.y.yeh@huawei.com]
Sent: martedì 26 luglio 2011 20.22
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; 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 [roberta.maglione@telecomitalia.it]
发送时间: 2011年7月27日 2:13
到: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; 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:jacniq@gmail.com]
Sent: martedì 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; 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 <roberta.maglione@telecomitalia.it> 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: lunedì 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; 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.
|