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

From: Stefan Winter <[email-masked]>
Date: Mon, 14 Nov 2011 10:56:51 +0100

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

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 15 Nov 2011 00:26:48 +0000

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: [email-masked] [[email-masked]] on behalf of Stefan Winter [[email-masked]]
Sent: 14 November 2011 17:56
To: [email-masked]
Subject: [Softwires] 6rd RADIUS attribute - grouped attributes

Hello softwires,

Greetings,

Stefan Winter
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Stefan Winter <[email-masked]>
Date: Tue, 15 Nov 2011 02:16:21 +0100

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