[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPv6 Address Option
Alan DeKok [aland@destroyingradius.com] writes:
> 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.
Or useful; maybe they're the same thing?
>
> >
> >> IPv6-Route-Option-Preference
> > Per your review - I too agree that a signed integer is somewhat
> > confusing however this is a direct copy of a DHCP option
I think it's actually from a Router Advertisement message, but no matter.
> 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.
Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
single octet.
>
> 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.
That's a fine idea.
...
> >> Prefix-Lifetime-Service-Type
> > 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.
Again, a single octet should suffice, no?
...
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>