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

[Stefan Winter <[e-mail]>]

Hi,

added softwires cc. This really belongs on the mailing list.

> My understanding there already was agreement on format.  Recommend
> maintaining current -04 format instead of these changes.

I suggested this on the softwires mailing list because it has a number
of advantages. Right now there are at least two drafts which need to
encode structured information.

There is one agreed model how to encode this, it's the extended type TLV.

If both drafts have their own complex encoding, it's double work:
everyone needs to write their own parser for their own attribute. As
time goes by, there will be more drafts needing to encode some complex
information. Consolidation of such complex types into a common format is
a good thing IMHO.

OTOH, using the new TLVs, only one parser needs to be written, *and*
that code is reusable for future attributes with complex encoding needs
with no extra effort.

>> IPv6-6rd-Configuration Attribute
>>  0                   1                   2                   3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |      Type     |    Length     | Extended-Type |M|    Flag     |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                            Suboptions                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Type 245, extended-type TBD.
> 
> Using Extended-Type means you would have to wait for the extensions
> draft to be an RFC in order to be assigned an Extended-Type.

That's right. It is the only drawback. If you choose to go the
custom-encoding way, you avoid a bit of waiting time at the expense of
extra, non-reusable code in every 6rd implementation.

> Compromised solution I originally suggested (Currently
> draft-ietf-softwire-6rd-radius-attrib-04) sought to avoid dependencies
> on other drafts while at the same time providing maximum compatibility
> with existing and future systems.

It requires an implementer to write one parser specifically for the
6rd-attribute, with no code re-use for other attributes that will be
defined in the future. The code needs to be maintained separately from
the a generic extended-attributes parser. That sounds rather
short-sighted to me and goes contrary to the claim of "compatibility
with future systems".

I'm not sure what "compatibility with existing systems" should mean.
Existing systems can't make anything out of the IPv6-6rd-Configuration
attribute, because they can't parse the content. All they can do is
ignore the attribute. They can do that with an extended-type attribute
just as well.

Greetings,

Stefan Winter

> 
>> IPv4MaskLen suboption
>>  0                   1                   2                   3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   sub-Type    |    Length     |   IPv4MaskLen |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Subtype 1
> 
>> 6rdPrefix suboption
>>  0                   1                   2                   3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   sub-Type    |    Length     |  6rdPrefixLen |               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
>> |                                                               |
>> +                      6rdPrefix                                +
>> |                                                               |
>> +                                                               +
>> |                                                               |
>> +                                               +-+-+-+-+-+-+-+-+
>> |                                               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Subtype 2
> 
> Prefix attribute was implemented a decade ago in RFC 3162 2.3. 1-octet
> reserved field before prefix length is required.
> 
> regards,
> Peter


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