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

[Stefan Winter <[e-mail]>]

Hi,

>> Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into
>> one blob in -04?
> 
> If you ignore the 6rd references it is describing prefix data type
> defined a decade back in RFC3162 2.3 (Framed-IPv6-Prefix).  Logically it
> counts as one field.

Framed-IPv6-Prefix and your data type are different. Frames-IPv6-Prefix
is of variable length, and requires to insert only those parts of the
IPv6 address which are relevant for the prefix length. You can pad with
more zeroes if you feel like it, but don't have to. (That in itself is a
rather inconvenient construct, and I like yours more than that one
actually.) Sure, if you opt to always pad with zeroes to the full 128
bit, even if not necessary, you get the same fixed length as your
datatype requires.

Still, you have introduced a new data type
"almost-but-not-quite-Framed-IPv6-Address".

If you consider it a good idea, then fine - I'm sure you have much more
experience in terms of actual implementations than I do. From a design
point of view, I'd consider a pair of (int,IPv6-Address) cleaner than an
implicit struct. The "belong together" can be expressed in the RFC as
"both of the sub-TLVs have to appear exactly once".

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]