Subject: Re: [dhcwg] Issues with RFC 4361 reusing option 61

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Mar 2008 15:15:14 -0700

On 3/14/08 6:38 AM, "Mark Stapp" <[email-masked]> wrote:
 > but there are several ways to address the practical problem that  
you're
 >    concerned about, right?
 >
 > - the database containing the reservations' client-id values could be
 > updated programmatically (if there's an algorithm that can convert  
a MAC
 > to a DUID)

It seems to me that this is really the only correct way to do it.   If  
the client sends DUID-LLT, it's really easy, too.   The way I would be  
tempted to implement this is to have a flag on the server that enables  
a transition mode.   When this flag is on, the server first looks for  
the client ding the DUID identifier.   If it finds a client using the  
DUID identifier, it proceeds normally.

If no such client is found, it constructs a client identifier option  
using chaddr.   It then uses this to look up a client record.   If one  
is found, it changes the client identifier on that record to be the  
identifer the client actually sent.   The client record is then used  
to configure the client; the next time it hears from the client, the  
record will be keyed off the new client identifier, and the migration  
for that client will be complete.

 > - the code in the affected servers could be updated to test chaddr
 > instead of the client-id option value (that's the one I'd pick,  
because
 > you already have the database, and this way it'd still work)

This is broken, though - you can't claim to be following RFC4361 if  
you do this.

 > - the clients could send the old client-id value in, for example, a
 > vendor-specific option, and the servers could test that value if it's
 > present

Now you have a server that complies neither with RFC4361 nor with the  
DHCP RFCs that it updates.

 > - everyone involved could change to using some other identifier,  
based
 > on the user logged in, or the geographical location, or the
 > department+building+floor+power socket+...
 >
 > none of those requires a _protocol_ change. they're just operational
 > steps that'd be part of a migration plan. other than "scrap the  
RFC," is
 > there some protocol change or enhancement that you think would make a
 > rollout that changes client-ids work better?

I think this is the key point.   This is an operational issue, not a  
protocol issue.

 > Santosh Chandwani wrote:
 >> IMO, a better way to address these deployment challenges would be  
to use
 >> a new option number for the DUID+IAID. This would allow for more
 >> seamless migration and interop between older clients/servers which
 >> assume the link-layer address is included in option 61, and newer
 >> clients/servers which want to use the DUID+IAID.

This wouldn't work, which is why we didn't do that.   The client  
identifier is what identifies the client.   RFC4361 does away with the  
old duality of client identifiers, where you sometimes used chaddr and  
sometimes used the client identifier option.   Adding a third option  
would have made this problem worse, not better.

 >> Since RFC 4701 assumes that clients implement RFC 4361, this issue  
also
 >> blocks us from cleanly implementing DHCID-RR support.

This isn't true.   Whether or not a client implements RFC4361, the  
DHCID-RR should Just Work, because it doesn't care how the client  
derived its identifier.   4701 doesn't assume anything; it just  
doesn't work well if you have a dual-stack DHCPv4+DHCPv6 client that  
doesn't follow RFC4361.   For single-stack cases, it has no effect at  
all.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 19 Mar 2008 08:37:30 -0700

> It seems to me that this is really the only correct way to do it.   If  

I know that we have discussed this in the past, and so I write this
chiefly for the benefit of those who weren't around for that
discussion.  We've already agreed to disagree.

> for that client will be complete.

This approach presumes a great deal about the will of the operator,
in particular it presumes that the address(es) in question were not
allocated to a physical piece of hardware, "the tower sitting on the
desk in office 12", but rather to a specific piece of software, an
operating system, running upon that hardware.

The presumption is either:

A) That the operator is happy with multiple address allocations for
   every multi-boot operating system on this single piece of hardware.

B) That all multi-boot operating systems (or network boot such as PXE)
   will collaborate to find a single shared DUID.

As these presumptions are not necessarily always true, I am less
convinced that the approach you have outlined is "the only correct way
to do it."

In my view, where the above presumptions are always considered false,
or at least skeptically false, the correct way to do it differs
between "fixed" or "reserved" assignments, and "dynamic" assignments.

For "fixed" assignments, where the operator has expresed his will to
allocate a fixed address to a single mac address, the correct
behaviour is to retain the mac address indefinitely, and assign the
fixed address to all software reporting from that mac address.

For "dyanmic" assignments, it's tricky.  First, express the operator's
will (which may be to identify all or some clients by mac address, by
switch port, or anything else), and in its absence ("by default")
treat clients that are chaddr-identified separately from clients that
are client-identified, EXCEPT:  Where a client-identified client
specifically requests a chaddr-identified lease, permit that lease to
'upgrade'.  This latter exception is mandatory in order to
interoperate with deployed software (PXE-booted WinCE).

At no time, in my opinion, is it correct for a server to inspect
chaddr and specific DUID subcontents to upgrade lease assignment
based on a match.  Any client-id contents are best left opaque except
to the extent as is described in existing RFCs (e.g., for the DHCID
RR contents).

> This is broken, though - you can't claim to be following RFC4361 if  

As it is also not explicitly disallowed by any text, RFC2131 included,
one cannot claim they are not following RFC4361 either.

> DHCP RFCs that it updates.

But again, doesn't non-conform with them either.

-- 
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://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2008 11:12:28 -0700

> discussion.  We've already agreed to disagree.

Okay, but I guess then I need to re-state my response... :')

>    will collaborate to find a single shared DUID.

True.

> convinced that the approach you have outlined is "the only correct way

It is the only correct way in the sense that it is the only way is in compliance with the specification.   Your proposed way to do it is a valid workaround, but it's not in compliance with the spec, and could produce interoperability problems.   So in that limited sense, it is not "correct," and that is how I intended the word "correct" to be read - I'm sorry for having implied a broader reading of it.

> fixed address to all software reporting from that mac address.

You can do this, and I think it will not generally produce interoperability problems, but it's probably going to produce results in some cases that are arguably incorrect - in the case of a server that does both fixed and dynamic allocations, the correct thing to do here is to dynamically allocate a lease to the client with the DUID.   But you're right that that's probably not the desired outcome.

> interoperate with deployed software (PXE-booted WinCE).

This will produce an interoperability problem because the DHCP server will allocate a new lease to the boot prom every time, and then WinCE will get the same lease; that is, a different lease than it had last time.

> to the extent as is described in existing RFCs (e.g., for the DHCID

I can't argue too strenuously with this.

> one cannot claim they are not following RFC4361 either.

RFC4361 does in fact specifically disallow the use of chaddr as a client identifier.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 19 Mar 2008 11:27:41 -0700

> RFC4361 does in fact specifically disallow the use of chaddr as a client identifier.

Only by clients.  No normative language defines server not-behaviour
in the way you have represented.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 19 Mar 2008 12:33:14 -0700

On Wed, Mar 19, 2008 at 11:27:41AM -0700, David W. Hankins wrote:
> Only by clients.

Sorry, this is insufficiently vague of me.

RFC4361 does require that clients include a DUID-based client
identifier option.  It does not require that clients do not include
any field in any other part of the packet that may, intentionally or
not, be interpreted as an identity.

So it is false to suggest the proposed client behaviour is in non-
conformance.  In fact, such a client is conforming.

---

From: Damien Neil <[email-masked]>
Date: Wed, 19 Mar 2008 18:39:29 -0700

> in the way you have represented.

Actually, RFC 4361 contains explicit language permitting server  
implementations to use the contents of chaddr for fixed-address  
assignment:

    DHCPv4 servers MAY use administrator-supplied values for chaddr and
    htype to identify the client in the case where the administrator is
    assigning a fixed IP address to the client, even if the client sends
    a client identifier option.  This is ONLY permitted in the case  
where
    the DHCPv4 server administrator has provided the values for chaddr
    and htype, because in this case if it causes a problem, the
    administrator can correct the problem by removing the offending
    configuration information.

              - Damien

---

From: Santosh Chandwani <[email-masked]>
Date: Tue, 25 Mar 2008 02:31:51 +0800

Yes, your suggested migration strategy of replacing the chaddr with the client ID in the reservation records will work. However, I don't follow your argument of why a new option number wouldn't work. There is no duality in case where the order of precedence is clearly defined.

DHCID-RR doesn't well for both dual-stacked and multi-homed scenarios. Even in single-stack cases (IPv4 alone), RFC 4701 implementations don't work in common scenarios such as laptops with both wired as well as wireless interfaces if clients don't implement RFC 4361.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: 18 March 2008 03:45
To: [email-masked] WG
Subject: Re: [dhcwg] Issues with RFC 4361 reusing option 61

you're
a MAC

because

based
RFC," is

to use

also

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 24 Mar 2008 13:15:10 -0700

On Tue, Mar 25, 2008 at 02:31:51AM +0800, Santosh Chandwani wrote:
> However, I don't follow
> your argument of why a new option number wouldn't work. There is no
> duality in case where the order of precedence is clearly defined.

As it stands today with the client id option contents and the chaddr
header fields, we have different and incompatible implementations of
client identification.  Precedence is unimportant if even in the
presence of clear precedence (as we have today), and universal
implementation of same (as we have today), what you then _do_ with the
field after varies wildly and can be never defined better than "magic
happens."

The problem is with undefined corner cases that historically we are
not very good at capturing.  What do you do when the fields are all
the same (modulo formatting, such as a DUID-LL in the new option,
client-id, and chaddr all identical)?  What do you do when the client
sends these identical contents unreliably (sometimes not sending an
identity option, sometimes including it later)?

We have this problem today with just two fields; and servers have
different answers, which causes some interoperability headaches at
the worst of times.

Adding a third field for client identification is not a strict
requirement since there are migration strategies without it, also it
would not be compatible with existing deployed servers.  So it would
serve only to make the above situation substantially worse in
triplication...especially if it uncovers new corner cases we weren't
aware of.  Just by making the situation more complicated than it
already is, it is undesirable.

So although I'm not sure I would agree with Ted that a third
identifier field is a technical impossibility (I suspect this
implication is just a mistake of his writing style), I do agree in
spirit that there are effective barriers from making it a plausible
reality, and hopefully I have explained at least my thinking why.

> DHCID-RR doesn't well for both dual-stacked and multi-homed scenarios.
> Even in single-stack cases (IPv4 alone), RFC 4701 implementations don't
> work in common scenarios such as laptops with both wired as well as
> wireless interfaces if clients don't implement RFC 4361.

This is basically true, but I don't see how a third identifier would
help matters any.

I mentioned at IETF 71 in the hallways to someone that I perceive that
the integration and migration problems set before ddns updates are
going to cause a number of differing "update policies" (as 4703 calls
them) to emerge, and that I think it would be more or less good to
have some formal way to name the different policies and describe their
intentions (calling 4703 "default" perhaps), even with vague
handwaving definitions ("do this, but omit this step").

We saw this at the DHCPv6 bake-off in Philadelphia, when two systems
did interoperate with DHCID RR's, but not until after their owners had
realized they were using different update policies.

I have something of a backlog of drafts to attend to myself, but I do
not wish to hold a monopoly on the above idea...if anyone is willing
to explore it, I think it would be beneficial.