Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt

I have some questions about this document. 

RFC 5080 Section 2.1.1 lays out the requirements for use of a State attribute: 

   The only permissible values for a State attribute are values provided
   in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
   Request packet.  A RADIUS client MUST use only those values for the
   State attribute that it has previously received from a server.  An
   Access-Request sent as a result of a new or restarted authentication
   run MUST NOT include the State attribute, even if a State attribute
   has previously been received in an Access-Challenge for the same user
   and port.
This requirement exists to ensure that a State attribute ties back to an authenticated RADIUS session.  

Within the document, the flow diagram describes "cooperation between DHCP and RADIUS":

     6rd CE                       BNG                       AAA Server
         |                          |                             |
         |-------DHCPDISCOVER------>|                             |
         |                          |--Access-Request(6rd Attr)-->|
         |                          |                             |
         |                          |<--Access-Accept(6rd Attr)---|
         |<-------DHCPOFFER---------|                             |
         |                          |                             |
         |--------DHCPREQUEST------>|                             |
         |      (6rd Option)        |                             |
         |<--------DHCPACK----------|                             |
         |      (6rd option)        |                             |
         |                          |                             |
                   DHCP                         RADIUS
                Figure 1: the cooperation between DHCP and RADIUS
This
 diagram neither indicates that the RADIUS Access-Request/Accept 
sequence is authenticated, nor does it show any previous previous 
authenticated RADIUS interaction.   It therefore appears to violate the 
RFC 5080 requirement. 

> From: rdroms.ietf@gmail.com
> Date: Tue, 2 Oct 2012 11:37:07 -0400
> To: aaa-doctors@ietf.org
> Subject: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt
> 
> draft-ietf-softwire-6rd-radius-attrib-06.txt has been submitted for publication.  As it defines a RADIUS attribute, I'd like to get a review of the document from aaa-doctors.  In particular, is the complex datatype format of the attribute acceptable, or would some other format such as String carrying the DHCP 6rd option as opaque data be more appropriate?
> 
> - Ralph
> 
> _______________________________________________
> AAA-DOCTORS mailing list
> AAA-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/aaa-doctors