[dhcwg] IESG Review Comments on draft-ietf-dhc-3315id-for-v4-04.txt

Hi All,

The IESG reviewed draft-ietf-dhc-3315id-for-v4-04.txt on our telechat 
yesterday.  There were several comments on the document, included 
below.  Issues marked "discuss" are blocking issues that need to be 
resolved before the document will be approved for publication. 
Non-blocking comments, marked "comment", should also be considered by 
the WG and authors, but approval is not blocked pending their 
resolution.

Some of these issues are fairly straight forward to address, but the 
issue raised by Brian Carpenter and the long set of comments from 
David Kessens will probably warrant WG discussion.

Thanks,
Margaret

Brian Carpenter:
Discuss:
[2005-05-12] I expected to find some words stating what happens when 
a client following this spec meets a server that doesn't, or vice 
versa. Are these failure scenarios or is there implicit backwards 
compatibility? This really isn't obvious and should probably be added 
to the applicability section.

Ted Hardie:
Comment:
[2005-05-10] The document's IANA considerations says:

This document deprecates all 'client
   identifier' type codes other than 255, and thus there is no need
   for the IANA to track additional possible values for the type field
   of the 'client identifier' option.

I got a bit confused about whether any values registered in this:
http://www.iana.org/assignments/bootp-dhcp-parameters

are deprecated, or this only deprecates further registration.  A
clarification may be in order.

Sam Hartman:
Comment:
[2005-05-08] I didn't find this document particularly clear it seemed harder to
follow than it should be.  I think that's probably because it is a set
of diffs to other behavior and has too many references to stand on its
own.  However I did eventually follow it and I don't think anything I
found should block publication at this stage.

Russ Housley:
Discuss:
[2005-05-09]
   The Introduction says:
   >
   > This supersedes the behaviour specified in RFC2131 and RFC2132.
   >
   The header and the abstract need to indicate that this document
   updates RFC 2131 and RFC 2132.

Comment:
[2005-05-09]
   Section 2.4 says:
   >
   > Like the client identifier format recommended by RFC2131, this
   > suffers from the problems previously described in (2) and (3).
   >
   Section numbers are needed to refer to the previous problems.

David Kessens:
Discuss:
[2005-05-12] I received the following comment from the OPS 
directorate. I understand from the comment that the issue might have 
been discussed in the past. I would appreciate if you could 
reconsider this issue:

How is a server expected to handle the case where a single computer first
chooses to identify itself with a client identifier, and then later chooses
not to supply an identifier at all?  This is never clearly explained in
any section of RFC2131/2132, so there are three possible interpretations:

A) Treat them as two separate, discrete clients.

B) Synthesize a client identifier out of the CHADDR field - thus treating
   clients who identify themselves with their ethernet MAC address as the
   same client which didn't identify themself, on the same MAC address.

C) 'Slide' identities between the two clients.  In essence, the lack of a
   client-identifier is like an "ANY" tag - any lease which was allocated
   to a client using that CHADDR contents is fair game, and vice versa...
   any lease which did not have a client identifier but had the same CHADDR
   is fair game.

It might seem that the worst such different interpretations might cause
is redundant address allocations - something that gets solved by itself
when addresses expire.  It's true that this happens, and it's highly
undesirable by DHCP server administrators, especially in the case where
clients are limited to a certain number of leases (due to contractual
levels of service).

There exists a "Windows for Embedded Devices" whose product name escapes
me right at this moment.  Consider then the following reference case:

1) PXE boots and obtains an IP address and configuration via DHCP - it is
   told to download the Windows boot image.

         - A server now has a lease allocated to this MAC address in its
           database, as allocated to a client that did not supply a client
           identifier.

2) Execution is passed to the Windows boot image - the system already has
   an IP address, configured by PXE, but Windows wants to query the DHCP
   server with more, vendor-specific, options added to the 'Options Request
   List' to get extra configuration state the original PXE client did not
   know it needed to know.

         - The Windows boot image sends a DISCOVER message with the address
           as obtained by PXE in a 'Requested Address' option, and a client
           identifier whose contents match the CHADDR field.

         - A server as implimenting interpretation A (above) allocates a new
           address for the client, since the Windows client did supply a
           client identifier, and this is interpreted as meaning it is a
           seperate, distinct client from the former.

         - The Windows boot image, running within PXE, is unable to alter the
           network configuration, and instead of REQUESTing the lease it was
           just offered, continues to resend DISCOVER messages.

3) The system ultimately times out and reboots itself - goto 1).

This actually represents an insidious compatibility problem, and I
submit it stems from poor definition of the client identifier option
in RFC2131/2132.

Now, this draft has fine goals - the DHCPv6 Node Identifier that is being
duplicated here is the right way to go about client identifiers, and it will
serve useful purposes.  Not only for the dual-stack purposes of being able
to detect what specific clients (as identified by their DUID's) are using
both ipv4 and ipv6 addresses, but also for things like Dynamic DNS, and for
unusual client configurations (clients having more than one interface - since
the server can peek into the client-identifier it can see that a client has
multiple interfaces active within a given broadcast domain - you may want
to allocate the same address, different addresses, or even different
addresses in different subnets within that broadcast domain).

Since the old identifiers were 'completely opaque', it's also a reverse
compatible approach - servers that treat the client identifier as an
opaque field will work acceptably well under all imaginable circumstances
when clients supply identifiers in this draft's suggested formats.

These are all good things, and we need this draft to reach RFC at some
point.

But I think we have learned from the past that not defining a "MUST"
behaviour for this case - where a client presents itself at different
times with a mixture of identities - produces incompatibilities due to
differing interpretations.
Producing a new format of the client identifier option, and not at least
describing this problem much less addressing it, seems to be "not learning
from our own mistakes."

Understand that the problem is magnified in this draft -

In the old RFC2131/2132 world, we could (as I described above) just
synthesize a client-identiifer out of the ethernet MAC address and address
99.9% of the problematic cases.

But in this draft, we have defined a whole new encoding for the client
identifier that has never appeared elsewhere and cannot be synthesized by
the DHCP server from any other DHCP packet contents.

The only option I believe systems administrators will employ to avoid
deployment problems with products conforming to this draft as delivered
by products that don't (PXE), is to disable their server's implementation
of client identifiers entirely.

Which is not at all what we want.

So it's a good draft, with good contents, features that we need, but also
with what I think is a serious potential problem that I think should be
addressed at least as it applies to this draft, if not in general.

Bert Wijnen:
Discuss:
[2005-05-12] I see RFC2119 luanguage (keywords SHOULD and such) 
without a citation
and a normative reference.

Comment:
[2005-05-12] Mmm... I see citations in the abstract. My understanding is that
those are not allowed. Easy to fix, just use perenthesis instead
of square brackets.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg