Subject: [dhcwg] Request for review of 3315id draft...

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2004 13:25:24 -0800

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt

A new rev of the 3315id-for-v4 has just come out.   I'd appreciate it 
if people could take a look at it.   In particular, I know Kim Kinnear, 
Ralph Droms, possibly Mark Stapp, and probably other folks had 
questions, and I'd like to know if those are resolved in the new draft. 
   It's mercifully short (at least IMHO).   :')

Thanks!

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

---

From: "Vasu, Vallabhaneni" <[email-masked]>
Date: Wed, 07 Jan 2004 16:23:39 -0600

Hi Ted,

Section 4.1

DHCP clients that support more than one network interface SHOULD
 use the same client identifier on each interface.  Such DHCP
 clients SHOULD be prepared for the possibility that the DHCP server
   will allocate the same IP address to both interfaces.

We can solve this problem by making an addition

          Code        Len         Type      Index            DHCP Unique
Identifier
      +-----+-----+-----+-----+-----+-----+-----+---
      |     61        |      n        |    255      |  Index   |
d1       |   d2         |     d3       |    d4 | ...
      +-----+-----+-----+-----+-----+-----+-----+---

Where Index is the interface index.

Thanks
Vasu Vallabhaneni

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2004 14:40:45 -0800

Adding an interface identifier doesn't really solve the problem unless 
we also require the server to treat the interface identifier as not 
being part of the client identifier.   I think that's too big a change. 
   Furthermore, a server that follows the current protocol specification 
won't have a problem.   So I think just putting in verbiage that says 
"follow the spec" is enough, and adding additional complexity isn't 
going to help.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 7 Jan 2004 17:59:50 -0500

Ted:

The draft looks great.

A few nits:
- In section 2.2, you say "Case (a) is problematic, and is beyond the scope
of this document." I'm not sure why it is problematic, especially in the
context of what you're trying to discuss here. The only problem I could see
is if a client used the same client identifier when configuring both
interfaces and a single DHCP server services the client on both networks and
does not allow a client to have multiple addresses (even when on different
networks).
- Also in section 2.2 (really section 3 where it discusses the solution for
2.2), this MAY require a change to existing protocol stacks. For example, I
use Windows XP and have the (b) case of 2.2 and it does get two different IP
address on the same network (not a problem in my home network). It handles
this just fine. Not sure how it might handle it if the same address was
returned. Not sure what to do about it, just that it may be a problem for
some implementations that never expect two IPv4 interfaces to have the same
address. I wonder whether IPv6 stacks might also have issues here as if they
do DAD, might not the other interface receive the message and the stack thus
believes the address is duplicated? IPv4 implementations could have some ARP
issues! Perhaps we should tread a bit more carefully here???
- On the last line of Page 4 (Section 4.1), you have an extra "To send a".
- I also wonder whether the IANA considerations should really request
dropping tracking of the type field. I think it is important we keep the
current assignments as I suspect they will be used for long periods of time.
Perhaps this is a non-issue anyway since IANA doesn't really track these
(just the ARP hardware type codes).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Wednesday, January 07, 2004 4:25 PM
To: [email-masked]
Subject: [dhcwg] Request for review of 3315id draft...

Thanks!

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2004 15:19:04 -0800

> does not allow a client to have multiple addresses (even when on 

If a client is multiply-connected and asks the DHCP server on both 
interfaces to update its domain name as "foo", what does the DHCP 
server do?   Are there two A records on "foo"?   Only one?   Which one? 
   Do they alternate if the renewals are out of sync?   What if one 
interface is served by a different DHCP server than the other?   Maybe 
I need to add some text to explain why this is problematic?

> issues! Perhaps we should tread a bit more carefully here???

Yes, this is dicey.   The alternative is to do as Vasu suggested 
(apologies for misunderstanding the context of his suggestion, BTW) and 
send an interface ID on each interface, and let the client always get 
two IP addresses, whether both interfaces are on the same network or 
not.   I don't think that's the right answer.

> - On the last line of Page 4 (Section 4.1), you have an extra "To send 

Fixed, thanks.

> (just the ARP hardware type codes).

I wasn't proposing that we drop existing tracking, but rather that we 
say we will never define any new types, and therefore the IANA doesn't 
need to have a continuing tracking process.   Do you think the wording 
needs to be tweaked, then?

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 7 Jan 2004 18:43:25 -0500

My comments below, prefixed by BV>.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2004 6:19 PM
To: Bernie Volz
Cc: [email-masked]
Subject: Re: [dhcwg] Request for review of 3315id draft...

BV> OK, yes those are problems, though I think the DNS/DHCP interactions
stuff should support these operations if the DUID is used as the client
identifier.

BV> Yeah, I'd like to avoid the Interface Identifier as well!!! I think you
need to point out the impact so that people that want to switch to using the
DUID take this into account.

Fixed, thanks.

BV> But I also think we should allow for a new hardware type to come along
and be used with DHCP clients that might want to use the existing format?
So, I'd rather you just say 255 is for the DUID and leave it at that?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2004 15:55:34 -0800

On Jan 7, 2004, at 3:43 PM, Bernie Volz wrote:
> But I also think we should allow for a new hardware type to come along

It certainly wasn't my intention that following this document should be 
optional, except in the sense that clients that haven't been upgraded 
still need to be supported.   The way client identifiers are currently 
being done is broken.   This document is a proposal to fix it.   Part 
of fixing it is that the old way of doing it is deprecated.   Adding 
new identifier types would be a mistake, IMHO.   If you want to add a 
new identifier type, add a new 3315-style DUID.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jan 2004 15:58:41 -0800

> DUID take this into account.

I don't see the value in adding any more text here.   Do you have a 
proposal for what you want added?   The text already points out that 
the client has to handle this case.   I don't want to specify how the 
client handles it, just that it has to handle it.   Otherwise we're 
opening a really big can of worms.  I think anybody serious implementor 
is going to have to wrestle with how to deal with this.   Maybe when 
they have some implementation experience *they* can write it up.   :'}

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 7 Jan 2004 20:32:38 -0500

OK, if your intention is for this to be REQUIRED, I think you need to make
that clearer much earlier in the document.

The abstract mentions nothing about making this REQUIRED and replacing the
existing client identifier scheme. The introduction is better at making this
clear now that I re-read it, though it isn't clear that you want all clients
to use this as all it says is:
   DHCPv4 client implementations that conform to
   this specification use a DHCPv6-style DHCP Unique Identifier (DUID)
   encapsulated in a DHCPv4 client identifier option.   This supersedes
   the behaviour specified in RFC2131 and RFC2132."

With the IANA changes, you're really saying that no new old-style client
identifiers may be created and that needs to be stated much earlier.

Also, section 1.0 only has SHOULDs which, to me, conflicts with the IANA
statements. What about DHCPv4 clients that never expect to implement IPv6?

Sorry to be so difficult about this.

- Bernie

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 7 Jan 2004 20:38:00 -0500

OK. I re-read the text and I do think you've written enough on the issue.

- Bernie