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

From: Stefan Winter <[email-masked]>
Date: Wed, 21 Dec 2011 10:26:55 +0100

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: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 21 Dec 2011 15:12:29 +0100

Hi,

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

If that were to change, the two approaches are indeed very nicely
aligned. ASCII-art below:

  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     |    SubType    |    SubLen     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4MaskLen   |    SubType    |    SubLen     |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  6rdPrefixLen |    SubType    |    SubLen     |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   +                                                               +
   |                     6rdPrefix                                 |
   +                                                               +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |   SubType     |    SubLen     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SubLen     | 6rdBRIPv4Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into
one blob in -04?

> The compromise allowed someone to *choose* to implement the TLV type
> generically OR a much less flexible parser capable of handling just this
> attribute without having to also support extensions.
> 
> Some vendors already support the TLV concept as it is necessary for
> wimax. It is possible to configure the -04 draft today with just
> configuration in some systems already supporting TLV.

That's quite good to hear. As said above, the only thing I'm wondering
is why there's a glued datatype for prefixlen+preifx in one go.

> My understanding they were not willing to wait for extensions to move
> ahead with the 6rd draft.  In that light my view was something that
> looked like a "TLV" was better than the alternative fixed format.
> 
> If this constraint is invalid and they are willing to wait allowing 6rd
> draft to be dependent on extensions I agree it would certainly be the
> best approach for all concerned.

If you take the ASCII art above and add 16 bits of "reserved" after the
overall length, the rest of the attribute would even be bitwise aligned
with a later extended attribute (the space that an extended-attr would
fill with Extended-Type and Flags. Not sure if that's important or even
helpful for implementers though.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 21 Dec 2011 14:45:59 +0000

No, we don't want to wait for extensions draft. 6rd technical is actually in a little bit emerge. We'd like to get this document published as soon as possible.

6rdPrefixLen and 6rdPrefix are bound together because the 6rdPrefixLen is explain hom many bits with in 6rdPrefix are real valid. They are actually on parameter.

So, looks for me, the format in 04 version is already the best choice.

Cheers,

Sheng
________________________________________
From: Stefan Winter [[email-masked]]
Sent: 21 December 2011 22:12
To: Peter Deacon
Cc: Sheng Jiang; Alan DeKok; GuoDayong; Maglione Roberta; [email-masked]
Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes

Hi,

  0                   1                   2                   3

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 22 Dec 2011 08:39:05 +0100

Hi,

> 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

Tel: +352 424409 1
Fax: +352 422473