Subject: Web Proxy Auto-Discovery Protocol

From: Thomas Narten <[email-masked]>
Date: Tue, 10 Aug 1999 15:39:43 -0400 (EDT)

DHCP WG:

The document draft-ietf-wrec-wpad-01.txt (among other things) defines
a new DHCP option. It also defines a number of techniques for locating
a configuration file (i.e., one that tells the browser what proxies to
use).

The draft does call for some interesting DHCP behavior I'd be
interested in getting WG feedback on. Specifically, it seems to change
the DHCP model a bit in that you don't just use DHCP when you boot (or
when the DHCP timers tell you to contact the server again). Instead,
it uses the INFORM message to query a DHCP server whenever the browser
thinks it needs to get a new configuration file. Quoting from the
draft:

>    Full client support for DHCP is not as ubiquitous as for DNS. That 
>    is, not all clients are equipped to take advantage of DHCP for their 
>    essential network configuration (assignment of IP address, network 
>    mask, etc). APIs for DHCP are not as widely available. Luckily, 
>    using DHCP for WPAD does not require either of these facilities. It 
>    is relatively easy for web client developers to speak just the 
>    minimal DHCP protocol to perform resource discovery. It entails 
>    building a simple UDP packet, sending it to the subnet broadcast 
>    address, and parsing the reply UDP packet(s) which are received to 
>    extract the WPAD option field. A reference implementation of this 
>    code in C is available [11].

then later:

>    In addition, the client MUST attempt a discovery cycle upon 
>    expiration of a previously downloaded CFILE in accordance with 
>    HTTP/1.1.

I.e. when you find a configuration file and use HTTP to fetch it, the
HTTP header tells you how long you may cache the file. When lifetime
expires, you have to fetch a new config file. But rather than just
fetching the same one, you restart the discovery process, including
rerunning DHCP (not full blown DHCP, just INFORM/ACK).

In the following, my read is that you must rerun DHCP when you start
the browser the first time (or when you restart it):

> 4.2.1.    Upon Startup of the Web Client 
>     
>    For many types of web client (like web browsers) there can be many 
>    instances of the client operating for a given user at one time. This 
>    is often to allow display of multiple web pages in different 
>    windows, for example. There is no need to re-perform WPAD every time 
>    a new instance of the web client is opened. WPAD MUST be performed 
>    when the number of web client instances transitions from 0 to 1. It 
>    SHOULD NOT be performed as additional instances are created. 

Is the above consistent with the intended usage of the INFORM message?
Are folks OK with this sort of extension to the DHCP model? Is DHCP
already being used in this sort of way, or would this be a new thing?

Thomas

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 10 Aug 1999 22:15:10 -0400 (EDT)

> Is the above consistent with the intended usage of the INFORM message?

Seems appropriate usage to me.

> already being used in this sort of way, or would this be a new thing?

I would think that there is an easier path to the same goal, and that is
to define an "HTTP proxy" extension. There are already several
extensions for things like "default home page" and "POP3 server" and so
forth. Why not just do another one for "HTTP proxy" rather than screwing
around with a configuration file? You could use DHCPINFORM on that all
day long without introducing yet another configuration format.

For a list of all the current BOOTP/DHCP extensions, see the IANA's list
at http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-extensions/

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Aug 1999 21:18:32 -0400 (EDT)

At 3:00 PM 8/10/99 -0400, Thomas Narten wrote:
>[...]it uses the INFORM message to query a DHCP server whenever the browser 
>thinks it needs to get a new configuration file.
>[...]

In general, I'm comfortable with the intended usage of the INFORM message.
I don't see that using DHCPINFORM to obtain additional configuration
parameters affects the definition of the protocol or the operation of DHCP
servers.

I am, unsure of a detail, which is both an implementation question and a
theoretical question: If more than one software system (e.g., a DHCP client
and a web client) are trying to share the same incoming UDP port, how are
incoming messages routed to the appropriate system?  For example, in a
system where the DHCP client opens (and leaves open while running as a
daemon - I'm thinking of UNIX-like systems, here) the DHCPC UDP port to
receive incoming DHCP messages, how does the web client arrange to receive
responses to its DHCPINFORM messages?  Even if there is a way for more than
one software system to share the UDP port, how are incoming messages
demuxed to the appropriate destination?  Suppose a web client happens to
send a DHCPINFORM at almost the same time as the DHCP client renews the
host's lease and sends a DHCPREQUEST?  How are the two responses - which
may, of course, arrive in any order - demuxed?

- Ralph

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 13 Aug 1999 00:27:03 -0400 (EDT)

> in a system where the DHCP client opens (and leaves open while
> running as a daemon - I'm thinking of UNIX-like systems, here) the
> DHCPC UDP port to receive incoming DHCP messages, how does the web
> client arrange to receive responses to its DHCPINFORM messages?

I did a light survey of a dozen or so DHCP clients, and the ISC client
is the only way that stays permanently bound to the socket that I know
of. The rest of them release the socket when inactive (as it should be,
IMHO). It's still a valid point mind you, since there's nothing to
prevent a DHCP client from staying permanently bound, but as it stands
today its a non-issue for almost all clients.

---

From: Dave Miner <[email-masked]>
Date: Fri, 13 Aug 1999 11:11:31 -0400 (EDT)

The question that came to my mind in reading this message is this: why
aren't they using SLP (Service Location Protocol) instead?  It seems to
have been designed for just this sort of usage.  Obvious answer is that
SLP isn't deployed (yet), but you probably need some application uses to
get it deployed to begin with, so when would this answer cease to be
acceptable?

Dave

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Tue, 17 Aug 1999 06:14:20 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
----------------------------------------------------------------------------

Hello Dave,

The answer is that WPAD does specify the use of SLP.  And,
in fact, there is a SLP draft for this.  But, since DHCP is
much more widely deployed than SLP, the document authors
seemed reluctant to make SLP the only choice, or even a MUST.

It is perfectly valid for working group discussion to indicate
further refinements on the existing protocol as it is currently
specified in the Internet Draft.

Regards,
Charlie P.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Aug 1999 06:49:57 -0400 (EDT)

At 12:28 AM 8/13/99 -0400, [email-masked] wrote:
>IMHO).

Thanks for taking a look at existing implementations and posting the
results of your survey.

There's still the problem of demuxing incoming DHCP messages.  If both the
DHCP client and an application are trying to use DHCP simultaneously -
e.g., the DHCP client is renewing the host's lease on an address while an
application is obtaining a web proxy address with a DHCPINFORM message -
how would the responses from the DHCP server be routed to the correct
destination?

- Ralph

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 17 Aug 1999 10:42:47 -0400 (EDT)

> If both the DHCP client and an application are trying to use DHCP
> simultaneously - e.g., the DHCP client is renewing the host's lease
> on an address while an application is obtaining a web proxy address
> with a DHCPINFORM message - how would the responses from the DHCP
> server be routed to the correct destination?

Well they shouldn't be able to do it "simultaneously" since UDP ought to
prevent one or the other from binding to the port. However there is a
very high likelihood that the two might "overlap" such as when one of
them issues a request, times out and unbinds, and then the other binds
and receives the response from the first request. I haven't had enough
coffee yet to think this through but it would seem that an opportunity
exists for some sort of failure to occur.

Perhaps there's a generic need for a Transaction-ID option since this
type of usage can practically be counted on. As a side note, this would
also be required for the multicast client and replication structure I
was describing a couple of months ago also (not the multicast relay
agent however). In the latter case, the Transaction-ID could be a
combination of MAC address and local time (synchronized time is not
required; only a unique "key" is needed), and maybe this same format
could be useful here (if it's needed, which I'm not sure it is).

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Tue, 17 Aug 1999 12:07:25 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------------
> could be useful here (if it's needed, which I'm not sure it is).
Such a transaction id already exists in bootp/DHCP (the xid field)
so another option isn't really needed. Of course, some clients have been
known to use the same xid over and over again so this could expose
some interesting problems. Fixing the broken clients should be no 
more difficult then implenting a new option of this type tho.

Dave Lapp

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 1999 09:17:02 -0400 (EDT)

Well, it seems the semantics of shared UDP ports are
implementation-dependent (or at least not well-defined; see below).  There
is a third possible behavior - processes sharing a UDP port are queued
awaiting incoming messages.  Each incoming message is handed to one (FIFO?
randomly selected?) waiting process.  I believe NFS server implementations
using multiple processes are based on this behavior.

- Ralph

At 09:43 AM 8/17/99 -0400, Rich Woundy wrote:
>At 06:50 AM 08/17/1999 -0400, you wrote:
>>There's still the problem of demuxing incoming DHCP messages.
>
>I think that if there are multiple applications on the same machine with
>sockets bound to the same IP address and port number, then the operating
>system will make multiple copies of the inbound packet, and queue one copy
>per matching socket. I remember seeing this in some Unix-y operating system
>source code.

At 07:32 AM 8/17/99 -0700, Eric A. Hall wrote:
>prevent one or the other from binding to the port.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 1999 09:47:52 -0400 (EDT)

Recently on the dhcp-v4 mailing list, we've been having a discussion of the
use
of DHCPINFORM by applications programs, as proposed by the WPAD (web proxy
discovery) proposal,
<http://www.ietf.org/internet-drafts/draft-ietf-wrec-wpad-01.txt>http://www
.ietf.org/internet-drafts/draft-ietf-wrec-wpad-01.txt.  The idea is that an
application (in this case, a web client) would initiate its own exchange of
DHCP messages, independent of the OS DHCP client (used for initial
configuration), to get a DHCP option that would contain a pointer to web proxy
configuration information.

The details of the option aren't so important.  What's come out of the
discussion is a problem in the sharing of the DHCP UDP port by multiple
entities.  For example, suppose the OS DHCP client renews the lease on an IP
address at the same time an application tries to contact the DHCP server for
some application-specific information or an additional IP address.  How will
incoming messages for different processes on the DHCP client be demultiplexed
and delivered to the appropriate recipient?

Not being familiar with UDPv6 (or even if there is an effort to update the
UDPv4 spec to accommodate IPv6), I am unfamiliar with the semantics of shared
UDPv6 ports. I've included a copy of a recent message I sent to the dhcp-v4
mailing list, summarizing several different possible semantics for messages
delivered to a shared UDP(v4) port.

Managing simultaneous independent DHCP message exchanges is probably not an
insoluble problem, especially in DHCPv6 as we have time to fix it now before
any clients are deployed.  But, I think we do need to think about a solution
and include it in the DHCPv6 spec...

- Ralph

=====
(message sent to dhcp-v4 mailing list)

Well, it seems the semantics of shared UDP ports are implementation-dependent
(or at least not well-defined; see below).  There is a third possible behavior
- processes sharing a UDP port are queued awaiting incoming messages.  Each
incoming message is handed to one (FIFO? randomly selected?) waiting process. 
I believe NFS server implementations using multiple processes are based on
this
behavior.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Aug 1999 09:52:50 -0400 (EDT)

> implementation-dependent (or at least not well-defined; see below).

Right, I think the queuing behaviour you've described is correct -
when a packet comes in, probably all the select()s on that descriptor
wake up, and then one of the read()s finishes, or maybe only one
select() wakes up.   Obviously, this can't work for DHCP clients,
since each packet represents a transaction specific to a particular
state machine.

I have two theories for how to deal with this problem in the ISC
client.  One is not to just have it stop listening on the port when
it's idle - this will work most of the time, but if the real DHCP
client happens to need to renew just when some other app is doing a
DHCPINFORM, the client might fail to renew, with potentially
disastrous consequences.  So much as I've been flamed for not doing
the client this way, I think my decision was correct.

Sharing the port using the semantics that NFS uses, probably doesn't
work.  What I think will work, and what I suspect Microsoft may have
done, is to simply have the "official" DHCP client see all packets,
and also pass those packets to any user process that may be listening
on the port.  A kernel-resident DHCP client for BSD or Linux could do
the same thing.   I think for a variety of reasons that a
kernel-resident client is the right thing anyway, so I don't see any
point in trying to solve this problem strictly in userland.

The other solution would be to just define an API for getting the
"official" DHCP client to do DHCPINFORMs.   Theoretically, this is
cleaner, but unless all the DHCP client vendors agree on a standard
API for this, it's probably not terribly useful.   The ISC will be
coming out with an API that could be used in this way, but unless
everybody wants to jump on the bandwagon and support the same API
(don't agree to this until you've seen it!), I don't think it's a real
solution for this issue.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 18 Aug 1999 11:42:57 -0400 (EDT)

> (don't agree to this until you've seen it!), I don't think it's a real

The latest incarnation of OpenTransport in MacOS (not MacOS X) has an
API for their DHCP client now, BTW. I don't know if it allows for INFORM
updates or not.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 18 Aug 1999 13:41:33 -0400 (EDT)

> and delivered to the appropriate recipient?

Unless using several ports or some hack using several addresses is an
option, I think you need a single process to do the demultiplexing. My
first thought on how this could be done is as follows:

Some process say a web browser sends a DHCP request (leaving some fields
blank) to the host's dhcp client on the loopback interface (it's supposed
to always listen on port 546 anyway).

The DHCP client stores the port number the request came from and the
transaction ID somewhere, it then fills in a new transaction ID which
can be used as an index to look up this information later on. It fills
in the missing fields, and sends an ordinary DHCP request.

Then when the DHCP client gets a reply, it uses the transaction ID to
look up to which port on the localhost the reply should be forwarded to,
and what transaction ID it should have.

The process (web browser) gets a reply from the local DHCP client on
the loopback interface with the port it sent the request from.

There are probably some things I haven't thought of, but I think this
could be one way of doing it.

Stig Venaas
UNINETT/NTNU

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 18 Aug 1999 15:31:58 -0400 (EDT)

Stig--

I am a little confused by your note....

[...stuff deleted...]

> to always listen on port 546 anyway).
[...what is port 546?  DHCP clients normally listen only to port 68.  I'm
not conversant about www clients, so is 546 the port normally used by one?
Also, DHCP clients will generally ignore (perhaps rudely!) message types
that differ from what they expect:  a DHCPREQUEST message is normally not
processed by a client, only by a server.  I'm not trying to be difficult
here, but you seem to be suggesting client behavior that may not be
practical, although I do like the simplicity of using the loopback
address...]

> the loopback interface with the port it sent the request from.
[...I'll summarize the above three paragraphs as "...a DHCP client could
simply multiplex application requests for configuration information as part
of its natural function..." -- does that accurately convey what you were
suggesting?

Your suggested approach is a clean way to handle DHCPINFORM requests from
applications without creating a universal DCHP client API, but even this
approach would require concurrence among the vendors of DHCP clients that
should be formalized through the RFC development process.  If the other
readers of the mailing list concur, you should consider writing an
Internet-Draft to cover this behavior (unless Ralph thinks it better to be
part of the core protocol specifications)...]

[...stuff deleted...]

--Barr

---

From: Stig Venaas <[email-masked]>
Date: Wed, 18 Aug 1999 16:26:04 -0400 (EDT)

> I am a little confused by your note....

Sorry about that, I'll try to clarify

> not conversant about www clients, so is 546 the port normally used by one?

I was thinking of DHCPv6 here, but you could do the same with IPv4 on
port 68 of course.

> practical, although I do like the simplicity of using the loopback

Yes, the client would of course have to be modified, and it should ignore
any DHCPREQUEST messages that does not arrive at the loopback interface.
Perhaps one should use some other message type. I haven't really given
this much thought. It was mostly as an input to the discussion and I'm
glad for getting replies.

[...stuff deleted...]
> should be formalized through the RFC development process.  If the other

Yes, I agree that whatever solution is chosen needs to be formalized in
some way.

[...stuff deleted...]

I should perhaps mention that I haven't followed the discussion on the
DHCPv4 lists or looked at the WPAD implementation. I guess it might be
a bad idea to propose something without having followed the discussion.

Stig

-- 
Stig Venås                      Tel:    +47 73 59 53 29
NTNU				Fax:    +47 73 59 80 98
ITEA/Nett, Prof. Brochs g. 6
N-7491 Trondheim, Norway	E-mail: [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 1999 21:58:16 -0400 (EDT)

At 01:42 PM 8/18/99 -0400, Stig Venaas wrote:
>[...] (it's supposed

Ah, right, that differentiates the DHCPv6 case from the DHCPv4 case - in DHCPv6,
the DHCP client is always listening on the DHCP UDP port, while in DHCPv4 the
DHCP client may release the DHCP UDP port...

- Ralph