[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-client
Subject:    Re: Need fix for the BUG
From:       Ted Lemon <Ted.Lemon () nominum ! com>
Date:       2000-10-01 18:21:39
[Download RAW message or body]

   *** From dhcp-client -- To unsubscribe, see the end of this message. ***


> mmm, I want some more explanation, what & why is a mistake.
> Is there any reference about this?

Read the mailing list archives.  It was never intended that text
options be NUL-terminated, nor is it consistently supportable.  If you
look at all the IETF drafts, as well as the previous version of the
RFC, there is no language requiring that clients or servers accept
NUL-terminated options.

The reason that this wound up in RFC2132 was that some programmer at
Microsoft didn't read the protocol specification (this has actually
happened quite a few times now, with different programmers).   This
programmer assumed that options should be NUL-terminated, and so
used data sent by the server as if it *was* NUL-terminated.   So if
you are running Windows 95, and you get a domain name from the DHCP
server that's not NUL-terminated, garbage appears after the domain
name, and it doesn't work.

This actually shipped with Windows 95 for years before Microsoft fixed
it.   The ISC DHCP server has a workaround to deal with this - if it
gets a host-name option from the client that is NUL-terminated, it
NUL-terminates all text strings that are sent back.   We can do this
because internally we can tell the difference between this:

	option host-name "foo";

and this:

	option host-name 4c:69:2a:31;

In the former case, we add a NUL; in the latter case we do not.

Unfortunately, there is no reliable way to tell that an option sent by
a peer is NUL-terminated.   Some options are specified to be NVT
ASCII, for example, and some are not.   The language added to RFC2132
doesn't say what to do if the format of the option is not specified,
and there are options in common use that can either be binary data or
a text string.   It also doesn't say what to do about user-defined
options.   Also, for example, Microsoft defined its own ad-hoc option
codes that Internet Explorer uses, and different versions of Internet
Explorer have mutually incompatible ways of handling NUL-termination -
in some version, if you NUL-terminate, it loses.   In some versions,
if you *don't* NUL-terminate, it loses.

So the language in RFC2132 is technically unimplementable.   The draft
should not say this, because it encourages implementors to
NUL-terminate text strings and expect text strings to be
NUL-terminated, which causes interoperability problems like the one
you are experiencing.

As I said, I have implemented a workaround in 3.0b2pl6 which sort of
deals with this problem.   But it can't work reliably, 100% of the
time.   The correct solution is to *require* that DHCP agents not
NUL-terminate text string options, and not expect them to be
NUL-terminated, which was the original intent of the working group.
I frankly have no idea how this language made it into the RFC, and
when I discovered it about a year ago, I was very sad to see it there.

			       _MelloN_

-----------------------------------------------------------------------
To unsubscribe from this list, visit http://www.isc.org/dhcp-lists.html
or send mail to dhcp-client-request@isc.org with the subject line of
'unsubscribe'.
-----------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]