Subject: RE: [dhcwg] IESG Review Comments ondraft-ietf-dhc-3315id-for-v4-04.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 1 Jun 2005 16:11:57 -0400

I figured Ted was most likely to review and comment on these, but here
are my thoughts (inline below).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ralph Droms (rdroms)
> Sent: Wednesday, June 01, 2005 2:57 PM
> To: [email-masked]
> Cc: [email-masked]; Wijnen, Bert (Bert); David 
> Kessens; Brian E Carpenter; Russ Housley
> Subject: Re: [dhcwg] IESG Review Comments 
> ondraft-ietf-dhc-3315id-for-v4-04.txt
> 
> I don't believe there was any followup discussion in response to
> Margaret's post about issues raised by the IESG regarding draft-ietf-
> dhc-3315id-for-v4-04.txt.  Please review and comment so we can resolve
> the IESG issues and publish this document...
> 
> - Ralph
> 
> On Fri, 2005-05-13 at 05:35 -0400, Margaret Wasserman wrote:
> > 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.

There is no failure or problem with this -- the old server will just use
the opaque bytes as the identifier for the client.

Of course, some of the benefits of using this new form of client
identifier aren't available because the server needs to be upgraded to
properly deal with it. But, nothing will break just because someone
decides to deploy a "new" client.

> > 
> > 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.

RFC 2132 says:

   The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
   hardware type of 0 (zero) should be used when the value field
   contains an identifier other than a hardware address (e.g. a fully
   qualified domain name).

So, there is nothing for IANA to deprecate and stop tracking for DHCP.
The text should be adjusted.

> > 
> > 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.

This (A) is the expected behavior. B and C are dangerous.

> > 
> > 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 is already an issue today ... The boot prom may use the mac address
and the OS uses a client identifier. So, this is nothing new and means
that two addresses are used. However, you can configure many servers to
use "short" lease times for PXE requests and longer times for non-PXE
requests.

> > 
> > 
> > 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.

This is only true for some platforms and for cases were users haven't
changed the client identifier. I don't think 99.9% is true at all.

> > 
> > 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.

This problem is NO different than what already exists with deployed
clients where PXE (or other boot prom code) uses the MAC address and the
OS uses a client identifier. I really don't get that this is such a big
problem today and why would making use of this DUID based client
identifier make this problem any worse.

Note also that the DUID actually reduces problems in the long run
because the clients can use a Client Identifier consistently if they use
2 out of the 3 possible format of DUIDs. That should be considered a
benefit. Yes, it will require upgrades to the boot proms to do this.

> > 
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jun 2005 11:09:35 +0200

> decides to deploy a "new" client.

Yes, I understand that now, but it wasn't at all clear from reading
the -04 draft with the eye of a potential user site. I cleared my
DISCUSS anyway, but there's a slight lack of clarity in the -04 text,
which I'm hoping Ted Lemon will fix following earlier email.

     Brian

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 2 Jun 2005 11:11:50 -0700

> decides to deploy a "new" client.

I'm confused by the idea of upgrading servers for it at all.

The draft doesn't currently describe any special handling the server might
be allowed to partake of, and doesn't redefine the field as anything other
than an opaque value (RFC2131 section 2, just under Figure 1, is
unchanged).

I think this is the right approach - define the client behaviour, and
after clients are deployed (which won't break the old servers) allow
servers to experiment, and then document server behaviours.

If the intent is different from what I just described, then perhaps it
should edit that clause I mentioned above as well.

> This (A) is the expected behavior. B and C are dangerous.

But (B), hopefully not (C), is also, as I am given to understand from
previous discussion on this list, the deployed "de facto standard".

No?

> that two addresses are used.

It is an issue today.  It is not new.

But from what I understood of what I have been told of this issue from
other DHCP server manufacturers, only ISC DHCP will supply multiple IP
addresses.  Everyone else supplies the same address.

Microsoft's DHCP server allows client identifiers that match the hardware
address to identify the same client as one that didn't supply a client
identifier but has the same CHADDR field.  The proof is in the pudding -
the PXE->XPe boot process gets the same address both times.

Nominum's, I am also given to understand (but have no direct experience
with), does the same.

And from our discussion on this list about this issue previously, I was
given to understand that Cisco's is similarly implemented as that was
the advice I thought I was getting from Bernie.  But now that Bernie
has spoken in staunch criticism of any interpretation other than (A), I
question this perception of mine.

Perhaps I misread this?

> However, you can configure many servers to

I can also verify that this is an issue today, but the short lease time
approach has not been universally, or even generally, accepted by our
customers.  That solution is more generally regarded as ignoring the
problem, particularly from those who limit customers at a given location
to a fixed number of leases (it still causes them billing nightmares
to identify one physical machine as two).

Conversely, given the options available, the two most widespread
solutions to this problem I have perceived is to disable client
identifiers entirely via third-party software patches, or to simply
not allow PXE clients to receive a lease.

DHCP assumes that a server is allowed to offer a different address to
a client.  This allowance is absolutely a necessity, we all know why.
But to make it mandatory in any corner condition is simply not going
to work.  It will not be accepted by the users.

I think it's because such consistent addressing is far more desirable
to sysadmins than the very features the client-identifier was created
to provide.

And so we're stuck.

> changed the client identifier. I don't think 99.9% is true at all.

I wasn't even aware there were additional "problematic cases" other
than the one described (PXE booting into XPe).  There are several
additional undesirable cases (PXE booting prior to any other form of
Windows, platforms that have multiple operating systems - linux,
freebsd, and Windows), about which I receive complaints frequently.

But I guess I'm also not aware of any cases where the solution is not
the described synthesis (or any equivalent allowed matching).

> identifier make this problem any worse.

I think the difference is that the previous problem can be worked around:
servers can (and do!) treat client-identified clients the same as those
without identifiers so long as the client-id matches the chaddr.

There is no such workaround in this draft.  But 2 of the 3 3315 id's
might be similarly worked around, possibly with undesirable results, if
implementors are left to their own interpretation again.

Is this really something we can afford to leave open to interpretation?

> benefit. Yes, it will require upgrades to the boot proms to do this.

I think you mean specifically the "2" and "3" DUID types.

In not so distant memory, Intel tried to make a serial number acheivable
by applications running on their processors.  There wasn't a lot of
market adoption.  The feature was user-disabled out of existence.  If
anything at the system level can pass information from hardware (anything
PXE can receive) to the running operating system that identifies the
system uniquely, then I have to imagine as this is equivalent to a
processor serial number, it will suffer an identical fate.

So, I think that light at the end of the tunnel you see is actually
a train.

I've been thnking about this for awhile, and I've only come up with
four options.  None of which I'm particularly fond of.

1) Do nothing, or perhaps just hope that we will do something later.

2) Embrace "Interpretation 'A'".  The incompatibility noted here, where
PXE boots into XPe and can't get any further, is something a good DHCP
client implementor would never let happen - because there would be clear
language within this draft that spells it out: that's broken.  So a client
that produces this option will simply not exist in coexistence with an
alter ego that does not.

3) Embrace "Interpretation 'B'".  Define in the draft under what
circumstances a non-identified or differently-identified client may
be identified as the same client, and what circumstances they absolutely
must not.

4) Define an "aliases" extension to the identifier.  A client can then
inform the server that it is known as (client identifier A) OR (chaddr)
at different times, and is in fact the same client and should receive
the same address.  In the case where NICs do move between systems, this
implies a conscious decision on part of the client that the address is
allowed to move if a (CHADDR) identity boots before it does.

As I said, I don't like any of these options.

But I really think 'do nothing' is going to result in the client-id
being unused, if not misused.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg