Skip to main content

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

Yes

(Benoît Claise)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Martin Stiemerling)
(Pete Resnick)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 15 and is now closed.

Benoît Claise Former IESG member
Yes
Yes (for -15) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2013-01-17 for -15) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (2013-01-23 for -15) Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection (2013-01-22 for -15) Unknown
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?
Ron Bonica Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-01-21 for -15) Unknown
- 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.
Stewart Bryant Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -15) Unknown