[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Address Option
MILES DAVID wrote:
>> Uplink-IPv6-Address instead of IPv6-Address
> I know the supporting text says "is assigned to the uplink of
> the user equipment" but uplink may be confusing (the uplink of what) -
> Peer/Subscriber/Host-IPv6-Address perhaps?
Just something more specific than "IPv6-Address". There are a lot of
possible uses for IPv6 addresses. Having an attribute named just
"IPv6-Address" will be confusing.
> Per your review - I too agree that a signed integer is somewhat
> confusing however this is a direct copy of a DHCP option from RFC 4191:
OK. Is this attribute intended to transport that DHCP option, or to
mirror the functionality?
There are no signed integers in RADIUS, and 16 bit integers are not
recommended. I would suggest instead that the RADIUS definition of the
attribute be "2 octets", and that the definition refers to the
appropriate section of RFC 4191.
i.e. leave the practical use of the attribute unchanged. But change
the definition to refer to another specification, rather than
duplicating the definition here.
> Again these 32-bit values are straight out of RFC 4191 and there is a
> requirement to support a value of infinity (0xffffffff). I think you
> could get away with a 24-bit value and a special recognition of
> infinity, but it is not desirable. If we adopt a fixed tag definition
> per Bernard's suggestion, do we still have a problem?
It's still a new data type, but I think the alternatives would be worse.
> Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> integer. IMO this is not a big change one way or another - I have no
> objection to changing this.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.