Re: assumption about number of octets encoding PENs

Romascanu, Dan (Dan) wrote:
> This is related to draft-liang-iana-pen-00 and
> draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest
> defines new Vendor-Id fields in a way consistent with RFC 2865, which
> used three octets. However, in draft-liang-iana-pen-00 we say that a PEN
> is a non-negative integer, which I think assumes (0..2**32-1) range. 

  I'm the author of draft-ietf-radext-radius-extensions-05.txt

> Questions:

  I have little input to those questions.

> What will happen to RFC 2865 implementations (and maybe other protocols)
> that assumed Vendor-Id is limited to three octets - this will probably
> need to be dealt by the RADEXT WG. 

  I'm aware of a number of widely-used RADIUS implementations which have
a 16-bit limit on PECs.  These implementations won't be able to handle a
larger PEC.  They require substantial re-engineering of their internals.

  The current maximum PEN is ~40K.  At the current rate, we have a few
years left before 2^16 is reached.  We should recommend that
implementations be fixed before then.

  My $0.02 is that we should require protocols to support 32-bit PENs.
That should be enough for quite a while.

  Alan DeKok.