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

From: Peter Deacon <[email-masked]>
Date: Wed, 21 Dec 2011 02:49:27 -0800 (Pacific Standard Time)

On Wed, 21 Dec 2011, Stefan Winter wrote:

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

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

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.

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.

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.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 21 Dec 2011 08:14:17 -0800 (Pacific Standard Time)

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

> 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

---

From: Peter Deacon <[email-masked]>
Date: Thu, 22 Dec 2011 04:07:45 -0800 (Pacific Standard Time)

On Thu, 22 Dec 2011, Stefan Winter wrote:

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

There are a few areas implementors should take care to read the draft 
carefully.  I don't have a better idea.

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

A IPv6 prefix describes one thing not a collection of related things 
belonging together.  You can't pull apart a prefix into pieces that mean 
anything by themselves.

By convention a prefix is always expressed as a single field wherever it 
is entered or displayed (fe80::/16)

A prefix does not contain an IP Address.

TLVs have no global type space.  Elements of generally applicable 
composite types must be redefined separately within each instance they are 
used.

regards,
Peter