[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 6rd attribute compromise?
Hi, Alan,
Thanks for your reply. It is much clearer now.
After carefully read RFC 6158, we don't think the attribute can be referred to a pre-existing data format because this attribute should be parsed by the Radius server. In 6rd scenarios, it is the Radius server who manages the user configuration information. Therefore, this 6rd attribute can NOT "be treated as opaque data by the RADIUS server."
So, it leaves TLVs the best choice.
As the below, I slightly modified Peter's proposal by removing the Reserved byte.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SubType (1) | SubLen (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4MaskLen | SubType (2) | SubLen (19) | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType (3) | SubLen (6) | 6rdBRIPv4Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any further comments? Peter, do you have any particular reasons to add the Reserved byte back?
Sheng
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
> On Behalf Of Alan DeKok
> Sent: Tuesday, April 12, 2011 1:44 PM
> To: Jiangsheng
> Cc: Peter Deacon; radiusext
> Subject: Re: 6rd attribute compromise?
>
> Jiangsheng wrote:
> > The format design of this 6rd attribute was to be the same with 6rd
> DHCPv4 Option, please see section 7.1.1 of RFC 5969.
>
> Please see RFC 6158, Section 3.2.4. If you are transporting a
> pre-defined data type in RADIUS, then don't re-define it in RADIUS.
> Instead, just say "this attribute has the format as described in RFC
> 5969 Section 7.1.1"
>
> > However, if this is not compatible with RADIUS, we would like to
> accept any suggestion from RADEXT WG. So, the first question is whether
> our current 6rd attr design is NOT acceptable by RADIUS.
>
> It does not follow the guidelines set down in RFC 6158.
>
> > If the answer is NO, Peter's suggestion looks good for us except why
> a Reserved byte.
>
> I think using TLVs for this attribute would be a good choice, but not
> necessarily better than referring to a pre-existing data format.
>
> > We do not understand Alan's third approach. Could Alan explain a
> little bit more, "An alternative approach would be to publish a "new
> data types" RFC,
> > containing just TLV and 64-bit integer data types." And how this
> relevant to our 6rd attribute?
>
> You could use the new data types in the document, rather than
> inventing a data type which is incompatible with existing RADIUS
> practice.
>
> Alan DeKok.
>
> --
> 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/>
--
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/>