rfc6929 : combination extended-type/long-extended-type and TLV data type

[Alan DeKok]

On Nov 10, 2015, at 10:31 AM, Vereecke, Katrien (Katrien) <katrien.vereecke at alcatel-lucent.com> wrote:
> I understand that for 'normal attributes' the Radius encoder truncates the data to the max allowed. 

  *All* attributes are normal attributes.  *All* attributes are truncated to the maximum allowed.

> But, if I use the long-extended type 246 with the More bit set then my understanding is that it would not be truncated on the 255 bytes of data.

 If you have an attribute "264.5" of type "octets", it can encode more than 253 bytes of data.

 This does *not* apply to TLVs.  A TLV attribute has an 8 bit length.  This means that it can encode a maximum of 253 bytes of data.

  BUT if a TLV is contained in another attributes which is *also* less than 253 octets, then the TLV length is limited by the attribute which encapsulates it.

  This isn't complicated.  An attribute having maximum length of 253 means that any data carried inside of that attribute can be no more than 253 bytes.

> I see a difference in behavior for e.g 246.5 and 246.11.1 which both contain 320 bytes of data in my users file. 
> 246.5 is not truncated, all data is available,

  Because it can be encoded as multiple fragments.

> fragmented over two attributes while 246.11.1 is truncated at 255 bytes, not all data is available.

  Because it's a TLV.  The TLV-Length is at most 253 bytes.

  How do you expect a TLV to encode 320 bytes in a field which can contain only 253 bytes?  And How do you encode the number "320" into a field which is 8 bits?  8 bits only goes to 255...

  RFC 6929 discusses this.  You *cannot* have "long" attributes inside of a TLV.

  For the "evs" data type, we specifically chose to *not* include a length.  This means that vendor-specific attributes in the "long" space can encode more than 253 bytes in a VSA.

  Alan DeKok.