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

[Peter Deacon <[e-mail]>]

On Wed, 21 Dec 2011, Stefan Winter wrote:

>> I don't think this is correct.  The extensions document describes a
>> *data type* 'TLV'.  My suggestion simply leverages this type in the same
>> way IPv4 Address and IPv6 prefix type from existing RFCs are already
>> being leveraged.
>>
>> If you implement extensions RFC in the future your implementation
>> supports the TLV data type giving you the ability to encode and decode
>> this attribute with configuration dictionaries.  The wire format of
>> IPv6-6rd-Configuration was intentionally made to be the same as a TLV.

> Ah! I'm just looking at the -04 with this extra context. It's certainly
> close. I think there's only one thing which is not inline: 6rdprefixLen
> and 6rdPrefix immediately follow each other. In a version
> compatible/analogous to the radius-extensions draft, the former would be
> of type integer, the latter of type IPv6Address, and each would have its
> own (Subtype,SubLen) tuple.

> 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.

regards,
Peter