RADIUS Attributes for IPv6 Access Networks
draft-ietf-radext-ipv6-access-16

1. In section 2:
* s/returns to the attributes used/returns the attributes used/
* While technically correct, it would be clearer to state that IPv6 routes can be returned via NDP rather than ICMPv6.  Given that there is not an RFC for returning route information via DHCPv6, I would suggest dropping that from this section.

2. In the subsections under section 3, there are several ambiguous uses of "server".  It would help with clarity to specify which server (NAS or AAA) is being referenced.

1) In section 2.1, there is a statement that the Framed-Interface-Id
and Framed-IPv6-Prefix attributes are "more natural for use with PPP's
IPv6 Control Protocol than [...] for use with DHCPv6."  The next
paragraph goes on to use SLAAC as the motivation for the
Framed-IPv6-Address.  Is the use of the Framed-Interface-Id and
Framed-IPv6-Prefix attributes for SLAAC defined somewhere?  I can
understand the use of the Framed-IPv6-Prefix for use with SLAAC,
although its use in this context implies to me that ND is used to
support SLAAC in an unusual way if different prefixes are assigned to
hosts on the same link.  How is the Frame-Interface-ID used with
SLAAC?

2) Are there currently deployments that use Framed-IPv6-Prefix and
Framed-Interface-Id attributes for DHCPv6 address assignment?  Does
this text from section 2.1 imply that deployment scenario is no longer
RFC-compliant: "To avoid ambiguity, the Framed-IPv6-Address attribute
is only used for authorization and accounting of DHCPv6-assigned
addresses"

3) If the Framed-IPv6-Address attribute is intended for use with
DHCPv6, should it include preferred and valid lifetime information?

4) Should the Route-IPv6-Information attribute include preference and
lifetime information?

5) Section 3.2 - For consistency/completeness, it might be good to
cite RFC 6106 along with RFC 3646.

The sentence on RADIUS shared secrets in the security considerations document seems out of place - what about that is made special in the context of the attributes this document is defining?

- Can't you give some reference to the "known security
vulnerabilities" in the security considerations?  Maybe [1],
but perhaps that's getting old or [2] but I've not read that,
so maybe its no good:-)

   [1] http://regul.uni-mb.si/~meolic/ptk-seminarske/radius.pdf
   [2] https://computerresearch.org/~comput45/stpr/index.php/gjcst/article/viewPDFInterstitial/649/577

- I'd have preferred if you were able to make some security
mechanisms mandatory to implement, but this isn't the right
document for that. However, an informative reference to e.g.
RFC 6614 or similar might be good.