Re: [dhcwg] about mip6-hiopt I-D

Hi, Francis.
Thanks for your concerns for this draft.
Kindly see my opinion.

1. First of all, the mechanism proposed by a hiopt draft is a part of the integrated scenario
which has been designed by MIP6 DT initially. The whole architectures and the complete 
procedures are described in [draft-ietf-mip6-bootstrapping]. 

In this scenario, when the Diameter/Radius performs authentication/authorization
for the network access, it also determines whether the user is authorized to the MIPv6 service.
Based on the result, the server returns MIPv6 bootstraping parameters to the NAS  according to 
[draft-ietf-dime-mip6-integrated] or [ietf-mip6-radius]. The parameters covers the policy 
and specific home/local HA information. So, this information will be delivered to the DHCP
server from the NAS, and finally to the MN. 

Therefore, I don't think that iterative DHCP query to the remote DHCP servers is an efficient
way for home network information discovery. The home network parameters are a specific information 
to the requesting MN and different from the DNS server information which is usually shared to all nodes.

2. I remeber that we already had a discussion on this as below. You proposed this concept as a name 
of agent-concep, that is, if the relay can answer to the request, it replies to the MN as a server, otherwise
it acts as a relay and forwards the request to the other servers/relays.

I agree that such a agent concept is a flexible approach for dicovery by using DHCP from the 
perspective of implementation. However, the current specificiation does not mention this, 
and it requires major changes to basic DHCP relay/server functionality- for example, at least 
the relay should be modified to look into all options of relayed DHCP packets in order to know
it can answer or not. .This is not just limited to the hiopt draft but issues for the basic/generic 
DHCP fucntionality. 
Previously, you answered that there is no document for this, so we cannot say it as a "standard". 
I've contact a DHCP implementor, but he told that 'server' is a fixed entity, and does not dynamically
change  easily between relay or server. If I missed something kindly let me know. 

- Best regards, 
Heejin.

---------------------------------------------------------------------------------------------------------------------
<Feb 7, 2008 1:04 AM> 

.....
Firstly, I'd like to know such relay behavior is just implementers' view
  or it is documented somewhere. If there is some documents describing such
  relay's behavior, kindly let me know that. Or we can ask this to AD or
  DHC wg folks.

=> I don't believe there is a document about this so it is just
implementors' view for DHCPv6. But the RFC describes only the
minimal/required behavior of relays and servers, implementers
are allowed to propose smart relays and servers, for instance
for failover, as soon as the service they provide is at least
the specified DHCP service. So in the real world you can have
server-server communication, etc, which come into RFCs only
when users ask for a non-proprietary solution.

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Francis Dupont
> Sent: Saturday, March 22, 2008 10:26 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] about mip6-hiopt I-D
> 
> I have still a concern about draft-ietf-mip6-hiopt-11.txt (I 
> reviewed for the gen-art the version 10) but I'd like to know 
> if someone shares my opinion.
> My concernis the MIP6 Relay Agent Option (section 3.2 page 
> 10) which carries a part of replies from the relay to 
> servers. IMHO this is not the right way to do this:
>  - if the local network has enough information so it could simply
>   answer (a request can be about or partially about local stuff so
>   ther should be a local DHCPv6 server).
>  - if the local network has not enough information requests should be
>   simply forwarded to a remote DHCPv6 server.
>  - if the local network has the information but needs an AAA decision
>   which can be done only at the remote network, requests should be
>   forwarded to the remote network with a remote-id or subscriber-id
>   carrying identification and AAA stuff about the client.
> So in fact I can't see where Mobile IPv6 is special in this 
> case and why the standard way could not be used...
> 
> Thanks
> 
> Francis.Dupont@fdupont.fr
> 
> PS: the home network prefix sub-option has the same layout 
> than an IA_PD because I suggest to use the same layout to 
> give the same infos.
> But it is an information (sub-)option, not a resource one 
> (the whole hiopt is stateless).
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg