[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6rd attribute compromise?
Hi, Alan and Peter,
Sorry for the late reply.
The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969.
However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS.
If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte.
The second choice could be we limit 6rdBRIPv4Address to be only 1 instance. Then we have a fixed length attribute. But this need to enable grouping multiple attributes module, which seems RADIUS protocol does not support currently.
We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC,
containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute?
Sheng & Dayong
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.