[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/>