Subject: RE: Relayed lease extension

From: Bernie Volz <[email-masked]>
Date: Mon, 1 May 2000 11:45:29 -0400

Barr:

>This set-up might be used in other instances where the end-client never
>gets an address via DHCP itself (if I recall, PPP sends it in the inital
>negotiation to the client and thus the client isn't running DHCP at
>all). If the BigBox gets the lease on the address for a shorter time
>than the client is connected, it will need to renew the lease and hence
>the situation Wim is looking at.
>
>...Bernie, did you really mean to say that?  It seems to me that in the case
>you describe, BigBox (and NOT its downstream client) is the host known to a
>DHCP server as the DHCP client.  If you are suggesting a different
>interpretation, such as BigBox acting as proxy for its client, then the
>protocol may not adequately cover all implementation cases.

For renewals, how are they handled? The renewl is sent by BigBox with
the client's IP address. If the response is send back to the cleint's
IP address, then either:
a) BigBox must take steps to prevent it from going to the client and
intercept it.
b) The renewal will go directly to the client and in the case of PPP
where the client isn't running DHCP, it will not have the desired
effect.

Since the original lease was done by BigBox on behalf of the client, the
renewal must also be done by BigBox on behalf of the client.

- Bernie

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 1 May 2000 09:34:56 -0700

>For renewals, how are they handled? The renewal is sent by BigBox with

>renewal must also be done by BigBox on behalf of the client.

I think that this does make an argument for updating the RFC. I also
think that it also indicates that having a different address assignment
mechanism for PPP was a mistake. That's one reason why we're trying
to leverage DHCP in the VPN case, so that we don't make the same
mistake there.

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 1 May 2000 10:13:55 -0700

If the response is send back to the cleint's IP address, then either:
a) BigBox must take steps to prevent it from going to the client and
intercept it.
b) The renewal will go directly to the client and in the case of PPP
where the client isn't running DHCP, it will not have the desired
effect.

...I'm in agreement with what you said above.

--Barr

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 1 May 2000 10:13:56 -0700

[Bernard]

...for about a year there has been a growing list of items needing
clarification and amplification:  Ted volunteered [or maybe got suckered
into doing so???] to coordinate these items at the WG meeting in Washington,
DC.

Ted, I'm not trying to put you on the spot, especially since I haven't
finished a couple of my work items either, but it does look as if the list
has started growing again.  I'll volunteer to assist you in accumulating and
codifying the work items list for discussion [hopefully] at the summer WG
meeting.

Ralph, we're not stepping on anybody else's work by doing this, are we?

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 01 May 2000 13:24:40 -0400

I will point out to those of you who are favoring an update of the
spec that while I agree that this is worth doing, updating the spec
doesn't actually solve the problem.  The only thing that would solve
the problem would be if the spec had taken this into account when the
servers with which this new client is intended to interoperate were
implemented.  Changing the spec now doesn't change old
implementations.  So from a pragmatic standpoint, the right thing to
tell him is how he can reliably get the behaviour he wants given the
*current* spec.

			       _MelloN_

---

From: [email-masked]
Date: Tue, 02 May 2000 15:33:33 +0900

> renewal must also be done by BigBox on behalf of the client.

I agree.

It may be acceptable to make the DHCP server to see giaddr field in
DHCPREQUEST from RENEWING client. Although, IMHO, it is semantically
correct that BigBox send RENEWING request.

--
Akihiro TOMINAGA, Ph.D
WIDE Project.
			Akihiro Tominaga ([email-masked])