[Dime] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125)

["Amanda Baber via RT" <[e-mail]>]

Hi all,

These RADIUS Attribute Type registrations now read as follows:

Value: 124
Description: MIP6-Feature-Vector
Data Type: integer64
Reference: [RFC5447]

Value: 125
Description: MIP6-Home-Link-Prefix
Data Type: string
Reference: [RFC5447]

Please see
https://www.iana.org/assignments/radius-types

These updates were made after we received confirmation from Lionel Morand and Benjamin Kaduk.

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Mon Aug 06 13:00:05 2018, [e-mail] wrote:
> On Aug 6, 2018, at 8:01 AM, Denis Ovsienko <[e-mail]>
> wrote:
> > Recently I was reviewing some code that adds support for two RFC 5447
> > RADIUS AVPs below:
> >
> > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString
> > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and
> >
> > It turned out, the current RADIUS Types registry at
> > https://www.iana.org/assignments/radius-types/radius-types.xhtml
> > lists both attributes with wrong types:
> >
> > 125   MIP6-Home-Link-Prefix   ipv6prefix      [RFC5447]
> 
> That is definitely wrong.  The "ipv6prefix" format is different than
> the one used by MIP6-Home-Link-Prefix in RFC 5337.
> 
> > 124   MIP6-Feature-Vector     string  [RFC5447]
> 
> That issue is a bit different.  64-bit integers were defined in RFC
> 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC
> 5447 was published.
> 
> So at the time RFC 5447 was published, "string" was the correct
> definition.
> 
> > Those incorrect types had propagated from the IANA registry into
> > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home-
> > Link-Prefix, see the discussion and the follow-ups at
> > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested).
> >
> > Having studied this discrepancy thoroughly, I had concluded the AVP
> > definitions are correct in RFC 5447, so I did not file an erratum.
> > The problem seems to be with those IANA allocations only. Could
> > somebody review this issue and put the IANA allocations right?
> 
> In the end, I think that the incorrect IANA allocations were a result
> of the updates done in RFC 8044.  The early drafts had a table which
> updated all of the IANA data types, e.g.:
> 
> https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2
> 
> The MIP6 attributes are listed there as "ipv6prefix" and "string".  As
> the author of RFC 8044, I think that's my mistake.  Updating hundreds
> of attributes required reading many RFCs, and it's understandable that
> a few mistakes were made.
> 
> Unless there are objections from DIME or RADEXT, I think it would be
> best for IANA to update the registry as follows:
> 
> 125     MIP6-Home-Link-Prefix   string  [RFC5447]
> 124     MIP6-Feature-Vector     integer64       [RFC5447]
> 
> We may need approval from the AD (Ben).  Explicit consensus from the
> WG would also be helpful.
> 
> Alan DeKok.