I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I believe the document is almost ready for publication.  

The following are significant issues that need to be addressed:

1.  A RADIUS message used for call-check does not contain any information that would authenticate the request.  Therefore RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet.  

2.   I'm not so familiar with the deployment scenario here so I have a question.  Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user?   If this is the case then the BNG may have received a state attribute in the access-accept message.   Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction.    If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service.  Also if its the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange.  

3.  It was not clear in the specification what is sent in the access-request message is the BNG is looking to get a IPv6-6rd-configuration attribute in the access accept.  It seems that you would need to send this attribute in the request if you expected it in the response or else the AAA server would not be able to un ambiguously be able to service the request; there are other uses for the call-check service.   I think you should specify that the 6rd attribute must be in the request if you want to see it in the response.   

Cheers,

Joe