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

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Apr 2008 23:52:34 +0300

Francis,

As I understand, you are questioning the need for DHCP relay sending the
AAA-delivered info to the DHCP server.

This is for the case where NAS is co-located with the DHCP relay, and there
is a separate DHCP server somewhere else in the same "local" network.  The
AAA-delivered info needs to be provided to the DHCP server, so that the DHCP
server delivers it to the DHCP client. Yes the info needs to zig-zag, but
that's necessary unless the node acting as DHCP relay assumes the role of a
DHCP server.

Alper

>  In your previous mail you wrote:
> 
>    > 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...
> 
>    The scheme you described above is the "standard"? Is it documented
> anywhere?
> 
> => it is the way relays (including DHCPv4 relays even DHCPv6 relays are
> more flexible) are used so documentation is in RFC 3315, 4580 and 4649
> (and about policy stuff in DOCSIS specs).
> 
>    I agree it could be done that way, but I perceived this as an
> optimization
>    when I first saw your comment.
> 
> => if the optimization is to cache the infos locally the idea is not mine
> but the I-D (and bootstrapping scenario) one. My point is to put the
> infos from relay to server way doesn't make sense.
> 
> Thanks
> 
> [email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Apr 2008 23:53:36 +0200

=> yes, the path followed by the infos is silly IMHO.

=> I believe you share a misconception with I-D's author: there is no
such "the server" thing. The DHCP service can be provided by multiple
servers in parallel (because requests are multicasted at different
layers). So it is possible and even natural to reply, perhaps partially,
locally. You give a way to implement it (this is the most efficient)
but there are others, for instance co-locate a server or simply have
the relay forwards to a local server too.
So I still do not like the zig-zag...

Thanks

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Apr 2008 15:05:21 +0300

Francis,

If you are not objecting to documenting the support for DHCP relay passing
the info to the DHCP server and simply seeking some text that describes the
other possibility of NAS acting as DHCP server, then I'm fine with that. 

But if you are asking us to remove support for DHCP relay options carrying
the info, then that's not fine. 

Alper 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 03, 2008 12:54 AM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [dhcwg] about mip6-hiopt I-D
>

---

From: Francis Dupont <[email-masked]>
Date: Mon, 07 Apr 2008 15:59:08 +0200

=> so this is not fine because IMHO the DHCP relay options are useless
(and the zig-zag a silly way to provide the infos to the client).

Thanks