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: [email protected] [[email protected]] on behalf of > Stefan Winter [[email protected]] > Sent: 14 November 2011 17:56 > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
