Re: [Softwires] 6rd RADIUS attribute - grouped attributes

[Stefan Winter <[e-mail]>]

Hi,

sure, no problem. The sketch of it is as below:

There is one fundamental choice to make: can the total length of all the
information be >253 bytes? If so, use a "Flagged" extended attribute; it
glues contents above 253 bytes together. If not, use a non-flagged
extended attribute.

Your draft limits the total length to below 253 by stating that there
are only 58 BG addresses allowed. Note that with the extended
attributes, you don't need to feel constrained in that; we can do more
now :-).

Then, it's about defining the TLV container and its contents. A first go
for your attribute would be like (numbers below are just examples;
subject to IANA allocation):

242.1 IPv6-6rd-Configuration (Type: TLV)
242.1.1 IPv6-6rd-Configuration-IPv4-Prefixlength (Type: integer)
242.1.2 IPv6-6rd-Configuration-Flagfield (Type: undistinguished octet
(Length: 1))
242.1.3 IPv6-6rd-Configuration-IPv6-Prefixlength (Type: integer)
242.1.4 IPv6-6rd-Configuration-IPv6-Prefix (Type: IPv6-Address)
242.1.5 IPv6-6rd-Configuration-IPv4-Border-Gateway-Address (Type:
IPv4-Address)

You also need an occurence table stating that sub-attributes 1-4 need to
be present exactly once, and number 5 has 1+ occurence.

And then - done! :-)

I guess I should have another read as I'm pretty jetlagged right now,
but I think you should get the idea...

Greetings,

Stefan Winter

On 15.11.11 01:26, Sheng Jiang wrote:
> Hi, Stefan,
>
> Thanks for your information. Since we are not really radius experts, if you can suggested the specific format or modification we should make in the draft, it would be real appreciated.
>
> Best regards,
>
> Sheng
> ________________________________________
> From: [e-mail] [[e-mail]] on behalf of Stefan Winter [[e-mail]]
> Sent: 14 November 2011 17:56
> To: [e-mail]
> Subject: [Softwires] 6rd RADIUS attribute - grouped attributes
>
> Hello softwires,
>
> this is to let you know of recent developments in the radext working
> group: there's a draft draft-ietf-radext-radius-extensions (-02) that
> describes new attribute formats.
>
> Among them is a data type "TLV" which is container for sub-attributes.
>
> Looking at the 6rd-radius-attributes draft, I read the statement in 4.1:
>   "Given that RADIUS currently has no
>    recommended way of grouping multiple attributes, the below design
>    appears to be a reasonable compromise."
>
> See http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-02
>
> The radius-extensions document already had a WGLC (currently resolving
> comments). You might want to reconsider your usage of a complex
> attribute encoding and use a (cleaner) TLV-with-subattributes approach
> instead.
>
> You should consider it especially because an existing BCP RFC makes
> clear that complex attribute encodings shouldn't be used if a viable
> alternative exists (RFC6158).
>
> Greetings,
>
> Stefan Winter
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires