RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option an d RADIUS Attributes sub-option

Kuntal,

At 01:54 PM 10/29/2004, Kuntal Chowdhury wrote:
>The intent in your draft i.e. configure MN with HA/HoA/HL information can be
>achieved with:
>
>http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt

Thanks for bringing to our attention the existence of this new draft. 
Somehow, I have not seen
its announcement before, at least not in the dhc or mip6 mailing list.

>Unlike your draft this draft:
>
>1. Does not require the DHCP server to parse vendor-specific RADIUS
>attributes.

But it requires the DHCP relay-agent to parse and understand the newly 
defined, yet-to-be standardized RADIUS Attributes carrying 
HA/HoA/Home-link-prefix as described in
draft-chowdhury-mip6-bootstrap-radius-00.txt and similar yet-to-be
defined attributes if DIAMETER is used.

>2. Has no interdomain (ASP-MSP) tight coupling assumption.
>3. Provides integrity and authenticity of the information that is exchanged.
>4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER.
>5. Does not assume a 3GPP2 centric architecture. It is generic.

>Regards,
>Kuntal

I just did a quick pass thru it but did not find any description addressing 
the issue where
the NAS/DHCP relay-agent and the AAA belongs to a different domain and 
RADIUS is used as
the AAA protocol. (This is precisely the same issue you raised for the 
DHCPv6 Relay Information Option/RADIUS Attributes sub-option draft.). So, 
would you point to the specific text in the draft which substantiates your 
claims 2) and 4) simultaneously ?

Currently, the draft just conveniently states:
"The AAA procedures using RADIUS is defined in [MIP6-RADIUS]", but

    [MIP6-RADIUS]
               Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6
               bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01
               (work in progress), July 2004.

cannot be found in public (I meant -01 version cannot be found, only -00 is 
available).
On the other hand, I cannot see how the cross-domain scenario described 
in  -00 version of  draft-chowdhury-mip6-bootstrap-radius the draftis 
different than the one in draft-droms-dhc-v6-relayopt-00.txt.

Am I missing something here ?

I would also like to point out that the DHCPv6 Relay Info Option/ RADIUS 
Attribute sub-option actually addresses 2 level of  needs:

1. The ability of DHCPv6 Relay agent to tag along additional "info" as it 
forwards requests from the DHCP client to the DHCP server, regardless of 
the specific nature of the "info". This is a "general"
capability for the DHCPv6 Relay agent which is absent from the RFC 3315. It 
seems like both your
and our draft needs such capability. The main difference is that, in 
draft-chowdhury-dhc-mip6-agentop-00.txt, newly defined MIP6-bootstrapping 
options are relayed while in draft-droms-dhc-v6-relayopt-00.txt, the info 
got relayed are RADIUS attributes.

2. As for the relay-agent RADIUS option, it is a feature of its own right, 
the example given in our draft is just one of its use which can help 
address an immediate issue in 3GPP2 835D.

3. As stated in draft-droms-dhc-v6-relayopt-00.txt,
" This document uses 3GPP2 access authentication as an example to
    motivate the use of the Relay Agent Information option and the RADIUS
    Attributes sub-option by a NAS. The Relay Agent Information option is
    not limited to use in conjunction with RADIUS sub-option when other
    sub-options are defined in the future. The RADIUS Attributes sub-
    option for the Relay Agent Information option described in this
    document is not limited to use in conjunction with 3GPP2 and can be
    used to carry RADIUS attributes obtained by the relay agent for any
    reason.  That is, the sub-option is not limited to use with 3GPP2,
    but is constrained by RADIUS semantics."

Regards,

Wing 