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

From: "Kostur, Andre" <[email-masked]>
Date: Wed, 7 Jan 2004 14:45:20 -0800

> From: Vasu, Vallabhaneni [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2004 2:24 PM
> To: Ted Lemon
> Cc: [email-masked]
> Subject: Re: [dhcwg] Request for review of 3315id draft...
> 
> 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

Huh?  What problem?  The point was to _not_ distinguish between the
different interfaces.  If the different interfaces are intended to have
different IPs, then one could use different DUIDs to represent that.

>           Code        Len         Type      Index            
> DHCP Unique
> Identifier
>       +-----+-----+-----+-----+-----+-----+-----+---
>       |     61        |      n        |    255      |  Index   |
> d1       |   d2         |     d3       |    d4 | ...
>       +-----+-----+-----+-----+-----+-----+-----+---
> 
> Where Index is the interface index.
> 
> Thanks
> Vasu Vallabhaneni
> 
> Ted Lemon wrote:
> 
> > > 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).   :')

---

From: "Vasu, Vallabhaneni" <[email-masked]>
Date: Wed, 07 Jan 2004 17:32:37 -0600

Correct me if I am wrong.

I thought as per RFC 3315 a system is supposed to have only one DUID.

The reason I suggested using interface index asI know of many customers
who have systems with two interface on the same subnet. Now with this
change one of the interface will not get IP address.

Thanks
Vasu Vallabhaneni

"Kostur, Andre" wrote:

>    Part 1.1Type: Plain Text (text/plain)

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

---

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

> change one of the interface will not get IP address.

No, they'll both get the same IP address.   Can you explain why it's 
useful to have two interfaces attached to the same wire with different 
IP addresses acquired through DHCP?   I should point out that if you 
want to have two separate identities, you should generate two separate 
identities, and this is actually orthogonal to the question of whether 
you have more than one interface.

---

From: "Steve Gonczi" <[email-masked]>
Date: Wed, 7 Jan 2004 19:27:22 -0500

Typically, multiple interfaces are useful for
load balancing, or HA (High Availability).

The main problem that I see with the draft, 
that it appears to mandate policy.
I.e. "henceforth, yer machine shall not have multiple 
active interfaces connected to the same wire"

IMHO it would be more useful to generate your proposed 
permanent client id's on a per interface basis, and
allow the DHC server to assign separate IP-s to them.

As to handling DNS, it seems to make sense to me to 
generate multiple A records. This would result in DNS 
round-robin, which is a quite reasonable behavior
in case of multiple ips under a common name.
(Be they on the same network, or different ones)

It is fairly common to have a 
machine connected to multiple networks. 

If you wish to reach this machine via a single 
DNS name, you run into the same DNS issue that 
you were originally describing.

There are only 2 ways I can think of to get around the
DNS issue: Assign different DNS names for each 
leg ( interface) of the machine, or assign
multiple A records, hence round robin.

/sG

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jan 2004 08:10:25 -0800

Hm, one other approach would be to use an interface identification 
field in the client identifier as Vasu suggested, but give the server 
the *option* of treating two DUIDs with different interface IDs on the 
same wire as different clients or as the same client.   This places the 
configuration control in the server, where it's more likely to be done 
correctly.   The client still has to be prepared to get the same IP 
address on two interfaces, though.   This adds complexity to the DHCP 
server, obviously.

Comments?   Would everybody just treat DUID+IID as an opaque identifier 
anyway?

This does have the advantage of being easier to specify...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jan 2004 08:06:48 -0800

> load balancing, or HA (High Availability).

I can't see why you'd use DHCP to configure a high availability port.

However, I agree that mandating policy is the wrong idea.   I'm just 
unsure how to not mandate policy.  I think maybe placing the burden on 
the client to do the right thing is, if you will, the right thing.   
I'm thinking of adding a section that explains these issues in some 
detail, and suggesting that clients that want to have multiple 
identities on the same wire have to use different client identifiers, 
but should use 3315-style identifiers.   Clients that want this 
functionality also need to handle naming sensibly.   I don't think we 
can place a requirement on the server that it mediate multiple A 
records on the same domain name, if only because there is no guarantee 
that you are talking to the same DHCP server out both ports.

The problem with this approach is that you're not supposed to have to 
configure a DHCP client - it's just supposed to do the right thing.   
How does the DHCP client know whether two interfaces means high 
availability or alternate media?   I can think of ways to guess, or we 
could suggest that there be a UI feature to determine this, I suppose.  
  I really didn't want to go down this rathole, but I see that in a 
sense I've painted myself into a corner.

---

From: "Vasu, Vallabhaneni" <[email-masked]>
Date: Thu, 08 Jan 2004 13:20:52 -0600

> Comments?   Would everybody just treat DUID+IID as an opaque identifier

I think the server should use it as opaque identifier. But when updating
DNS the dhcp sever can check for all the client records which have
matching DUID and then add new info as aliases to the existing names.

Say the dhcp server has given the following address

DUID - 1        client1            10.10.10.1

If the client requests IP address for another interface with IID - 2

DUID - 2        client1            10.10.10.5

Then the dhcp server adds the second

client1    IN    A    10.10.10.1
                                  10.10.10.5

similarly adds ptr records.

In the above case host name is same so there is no problem. But if the
hostname is different then dhcp can add it as an alias.

Thanks
Vasu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jan 2004 11:34:47 -0800

> matching DUID and then add new info as aliases to the existing names.

Then it's not an opaque identifier, is it?   In any case, remember the 
purpose of this draft: to make sure that resources associated with 
client identifiers are associated with the same client identifiers 
whether they were acquired using DHCPv4 or DHCPv6.   So if we make 
DUID+IID opaque, then we haven't achieved our stated goal.   If IID is 
going to be part of the client identifier, we have to say that the 
DUID+IID split is *not* opaque.

> Then the dhcp server adds the second

There may be more than one DHCP server involved here.   How do the two 
(or more!) DHCP servers decide to add additional A records, rather than 
deleting the old A record and adding the new one?   PTR records are a 
non-issue, of course.

> hostname is different then dhcp can add it as an alias.

Actually, it's the case where the hostname is different that there's no 
problem, because then you have one hostname per A record, and the 
current proposed DNS update system works.   It is when you have two 
valid IP addresses and only one hostname that you run into problems.   
It is theoretically possible to modify the proposed DNS update system 
to support this, but I'm not at all sure that it's worth the effort.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 8 Jan 2004 15:16:01 -0500

Also, if the client is the one that updates the A records, there's no
problem since it knows what it wants to have happen?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Thursday, January 08, 2004 2:35 PM
To: Vasu, Vallabhaneni
Cc: [email-masked]
Subject: Re: [dhcwg] Request for review of 3315id draft...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jan 2004 12:18:56 -0800

> problem since it knows what it wants to have happen?

Theoretically yes, but in practice I think it might actually be quite 
challenging to write a client that always does the right thing, or even 
that can be configured to always do the right thing.

---

From: "Steve Gonczi" <[email-masked]>
Date: Thu, 8 Jan 2004 15:43:07 -0500

I am begginnig to think this is a non-issue.

Given multiple ip-s per DNS name:
A) The client is be allowed to present one identity
(say, ID1) for more than one interfaces.

This would result in enforcing a "one active interface
at a time" behavior.
In a multi-server case, if a client tries to renew an 
IP address that a server  has no pool (or knowledge) of, 
the client gets NAK-d, and gets a new address. 
This results in the A record being overwritten 
both in case of solitary, or multiple DHCP servers. 

B) OTOH, a client is allowed to present a separate 
identity (say, ID1, ID2) for each interface.

This would result in multiple A records being maintained 
by either a solitary, or multiple DHCP servers.

The A record for ID1 gets created or deleted as ID1
acquires or releases the IP, and the same happens
for ID2.

In reality, (B) can not be distinguished from
a DNS round-robin server farm, where multiple
IP addreses, located on multiple, separate
servers are mapped to the same name via 
multiple A records.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jan 2004 13:05:45 -0800

On Jan 8, 2004, at 12:43 PM, Steve Gonczi wrote:

Be careful, Steve.   I think you're conflating the client identifier 
and the client hostname, and they're two separate things.   If the 
client sends a different ID and a different hostname on each interface, 
there's no problem.   If it sends the same ID and hostname on each 
interface, there may be a problem.   If it sends different ID and the 
same hostname on each interface, there's a problem.

This would all be greatly simplified by simply requiring that the 
client do its own update, but we really aren't in a position to do 
that.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 8 Jan 2004 17:05:14 -0500

Well, why don't we just do what we do for DHCPv6 ... add an IA (Identity
Association) Option. That way, if the client has two interfaces, it can
either chose to use two different IAs or none (in which case it may well get
the same address).

This doesn't fully solve the DNS issue, but at least it gives the server a
hint that if an IA was sent, it might not be wise for the server to wipe out
other A records that the client has (since another server may have assigned
the client a different address). The DHCP server can always look at the A
record(s) and if the target address is within its authority, it can delete
the old A record (assuming the client does not have a valid lease for the
address).

(Note that this also has the nice feature of allowing a client to get
multiple addresses if it indeed wanted to even on a single interface - why
it would ever want to do this is beyond me, but ... It's also much better
than having multiple identifiers for the client, which is what would happen
today.)

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Thursday, January 08, 2004 3:19 PM
To: Bernie Volz
Cc: 'Vasu, Vallabhaneni'; [email-masked]; 'Ted Lemon'
Subject: Re: [dhcwg] Request for review of 3315id draft...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jan 2004 14:39:06 -0800

> either chose to use two different IAs or none (in which case it may 

Hm, good point - letting the client decide whether or not to use two 
IAs for two interfaces probably produces the right result.

> the old A record (assuming the client does not have a valid lease for 

I think that an ad-hoc implementation like this is more likely to cause 
harm than good - it's really easy to imagine algorithms for doing this, 
and it's equally easy to imagine cases in which they would produce 
exactly the wrong results.   If we think it's important to handle these 
cases, we should define a system that supports it.   This is doable - 
we just need more TXT records, but that's easy.   You'd have a TXT 
record indicating which node owned the name, and then another TXT 
record indicating which IP address goes with which individual IA.

The problem with this is that it's a lot of complexity for little 
benefit.   Generally speaking, I would expect that even when a client 
has multiple interfaces, advertising multiple A records for it on the 
same name is not going to produce the result that the user actually 
wants.   It would probably be better to just have a system on the 
client for deciding which interface is primary, and setting the name on 
that one.   Apple has such a system now, although I do not know how 
well it works, nor whether they use it in deciding for which interface 
to request that an A record be installed.   In general, I think that 
when you want to advertise A records on multiple interfaces, you 
probably want the client to do the update so that it can be customized 
according to the client's wishes.

> than having multiple identifiers for the client, which is what would 

Yup, this is a win.   Maybe it's better to just specify the slightly 
more complex solution.   Does anybody but Bernie want to vote on this?  
  I get the impression that Vasu is in favor of doing it this way, and 
possibly the folks in favor of the rentschler interface id draft would 
be satisfied by this approach as well?