Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 12:49:55 -0400

Summary of discussion of this issue:

We need more discussion of this issue to come to consensus
on resolution.  Josh Littlefield responded (see
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02107.html)
Pleaes review Josh's input and post your comments.

- Ralph

At 12:27 AM 6/6/2003 -0400, Ralph Droms wrote:
>DDNS-DHCP issue:
>
>    The interaction between DHCPv4 and DHCPv6 needs to be carefully
>    defined.  Suppose a DHCPv4 server updates the A RR and a DHCPv6
>    server updates the AAAA RR of the same node?  How is the conflict
>    in the use of the DHCID RR for that node resolved?
>
>_______________________________________________
>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: Ted Lemon <[email-masked]>
Date: Wed, 2 Jul 2003 19:10:10 +0000

> >    in the use of the DHCID RR for that node resolved?

I had to sit with this one for a while.   But my conclusion is that the 
solution Josh proposes (do extra queries) isn't the right solution.   The 
right solution is to have a different RRtype for V4 and V6, just as we have A 
and AAAA for IPv4 addresses and IPv6 addresses.   This solution reduces the 
number of updates/queries required to make it work in the dual-stack case, so 
I think it's preferable, even though it means we have to allocate two RRtypes 
instead of one.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 15:48:37 -0400

OK ... does this solution require any changes to the
existing docs?  Perhaps just making clear the docs
aply to DHCPv4 and A records?

- Ralph

At 03:44 PM 7/2/2003 -0400, Rob Austein wrote:
>At Wed, 2 Jul 2003 19:10:10 +0000, Ted Lemon wrote:
> >
>I agree with Ted on this.  Use separate RR types.
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Rob Austein <[email-masked]>
Date: Wed, 02 Jul 2003 15:44:34 -0400

---

From: Ralph Droms <[email-masked]>
Date: Tue, 08 Jul 2003 11:59:33 -0400

Ted - can you give us more details, like what the sequence
of update/queries would look like if there were a separate
RRtype for IPv6?

Will Josh's proposal work?

If we use a separate RRtype for IPv6, can the existing
draft progress unchanged?  Would it perhaps need some
clarifying text to the effect of "used for DHCPv4 only"?
Can we postpone definition of the RRtype for IPv6 until
we have a better sense of how DHCPv6 will be used in
practice and the requirements for DDNS-DHCPv6
interactions?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 13:39:16 -0500

> of update/queries would look like if there were a separate

Ooh, details, details.   If there is a name with a DHCIDv6 record and no DHCID 
record, the update's going to fail, even though it maybe should proceed.   
But we can't tell if it should proceed unless the v6 identifier is the same 
as the v4 identifier.

> Will Josh's proposal work?

No, actually it won't, because again we don't know that the two identifiers 
match.

> draft progress unchanged?

Nope, it just doesn't work at all.

The problem is that the DHCPv4 server doing the update has no way of knowing 
if the DHCPv4 client and the DHCPv6 client that are declaring interest in a 
name are both the same client.   DHCPv6 describes a different scheme for 
coming up with client identifiers.

So in order to make this work, the DHCPv4 client has to send the same client 
identifier as the DHCPv6 client, since there's no way the DHCPv6 client can 
send the same identifier as the DHCPv4 client.   That is, if you have a 
dual-stack DHCP service, the _only_ way to make it work is if the v4 and v6 
clients are cooperating.

I think that the right answer right now is to note in the document that this 
solution does not work in the dual-stack case, and leave it at that.   When 
we write a document for DHCPv6, it should say how dual-stack clients must 
cooperate, and the v4 and v6 clients should probably use the same DHCID.   
This is not going to be a simple process to describe, though, and I don't 
think we should hold up the current DHCID draft waiting to come up with the 
correct algorithm for doing v4/v6 stuff.   That needs to be a separate 
document.

---

From: Mark Stapp <[email-masked]>
Date: Tue, 08 Jul 2003 16:00:23 -0400

I don't want to flog a dead horse here, but I really do wonder whether 
there's much benefit to be gained by adding another rr type.

Unless the server has seen a client's traffic and has seen its identifier, 
it cannot determine whether the hash that's in the rr was generated from 
that client's id. A dhcpv4 server cannot tell whether the v6 client id used 
to generate a hash matches one of its clients's ids. Whether the hash is 
carried by a dhcid rr with a 'type' code, or by a new rr that is yet to be 
invented, the limitation is the same.

The dhcid rr info was developed to allow the enforcement of some policy. 
The range of policies that can be enforced in this case is limited. The 
limitation arises from the fact that the two protocols use different client 
ids, not from the use of a single rr type.

A dhcpv(x) server can tell - using the type byte in the existing rr - 
whether there are only v(x) clients associated with a name, or both v(x) 
and v(y) clients. It can enforce a policy that says one of:

1. allow any number of clients to share this name
2. allow any number of v(y) clients, but only a single v(x) client
3. allow only a single 'id'. a v(x) server can test a v(x) id rr, but it 
can't test a v(y) id rr.

I don't think that that situation will be changed by the development of a 
new rr.

As Ted notes, a dual-stack client could generate a common identifier used 
for both protocols (based upon a hardware address, for example). Perhaps we 
can define some conventions that dual-stack clients could use that might 
make this possible. The hardware address based id could be hashed using the 
chaddr-based dhcid rr type, and that might allow us to support 
'recognition' of a single client. I think that the solution for these 
dual-stack clients will require some words - possibly 'informational' level 
words. I don't think it requires an additional rr.

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 16:07:25 -0500

On Tuesday 08 July 2003 15:00, Mark Stapp wrote:
> I think that the solution for these

We may need to do a new standard-track draft, but either way I think it needs 
to be a new draft.   I agree that we may not need a new RRtype, although I'm 
not certain that's so.   In any case, I don't think we should attempt to 
solve this new problem in the existing draft.

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Jul 2003 17:08:15 -0400

The main point of using two separate RR types is to remove the
possibility of accidental interaction.  Using one RR type requires one
to understand what the various DHCP implementations are doing to be
sure that there are no accidental interactions.  Using separate RR
types makes it very easy for someone who is not a DHCP wizard to be
sure that any interactions are taking place because some entity is
trying to play in both worlds.

---

From: Mark Stapp <[email-masked]>
Date: Tue, 08 Jul 2003 17:13:24 -0400

Yes, sorry - I meant an independent draft (of whichever level of strength) 
that would address the dual-stack issues.

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 16:28:03 -0500

> trying to play in both worlds.

No, unfortunately this is not true.   Using a separate RRtype doesn't provide 
this clarity, because the way that servers would act based on the presence or 
absence of either RR isn't clear.   Unfortunately this sounds good on paper, 
which is why it popped into my mind in the first place, but it doesn't work 
in practice.   In order to see why it doesn't work you need to read the other 
DHCP-DNS interaction drafts (there are three inter-related drafts), not just 
the DHCID draft.

It may be that the ultimate solution to this problem is to have a second 
RRtype, but if that does turn out to be the case, the one thing I can promise 
you is that a person who wants to understand what various DHCP 
implementations are doing is going to have to read the standards - it's not 
going to be obvious from casual observation.   :'(

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 08 Jul 2003 17:48:07 -0400

> Nope, it just doesn't work at all.

I think it depends on how you define "work".  If the only definition of 
success is a dual-stacked client being able to use the same name for 
both v4 and v6, while preventing a v6 client from using the same name as 
a different v4 client (and vice versa), then this can be achieved with 
either scheme (a common, or two separate, RR types).  But it can only be 
achieved by having the client use the same client-id and DUID, or by 
having the v4 and v6 DHCP servers (or whoever does the updates) both 
know the ID used by the other's client for that name.

So I don't think the choice of approach affects making that work.

If we use the currently proposed, single RR, then a current v4 DHCP 
server can opt to enforce a policy of having a name be v4 only (a safe 
policy in the absense of client-id/DUID coordination).  If we specify a 
new RR, that can't be done until the new RR type is assigned, so we'd 
want to not delay creating the new RR type.

If we create an additional RR type for DHCIDv6, the current algorithm 
works if one does not care about use of a single name by different (v4 
and v6) clients.  But it needs adjustment involving extra prerquisites 
to prevent that.

It's true that the proposal I made would involve additional DNS 
round-trips that make things a bit uglier.  For name registration, these 
are only needed if the updater is prepared to determine that a V6 DHCID 
is from the same client (which is difficult for type 0x0000 DHCID RRs). 
  For RR deletion, an additional round trip or two may be needed to 
compensate for someone else adding another DHCID RR to the name.

I'm not particularly wedded to either approach.  It seemed that using a 
single RR makes it possible to be overly conservative now (preventing 
any dual use of a name), and add generality when we recommend common 
client-id/DUID formation.  Adding a new RR type means we need to adjust 
the algorithm right away to avoid implementing something too liberal 
(allowing a single name to be used by two different clients at v4 and v6).

Does that make sense?

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 16:54:43 -0500

On Tuesday 08 July 2003 16:48, Josh Littlefield wrote:
> It seemed that using a

Yup, that sounds exactly right.

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 08 Jul 2003 17:58:16 -0400

> trying to play in both worlds.

Rob, using two separate RR types allows more independence.  However, we 
actually *want* these to interact.  That's the issue.  If the presense 
of a v6 registration on a name should affect the behavior of a v4 
registration (and I think it should), then independence isn't helpful, 
and interaction is demanded by the update policy.

  -josh

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Jul 2003 20:45:33 -0400

Believe it or not, I did review all three drafts, more than once, but
apparently still managed to forget too much context.

It looks like there's a choice to make: if the goal is to use this
mechanism to prevent cases in which two nodes register the same name,
one for IPv4 and one for IPv6, then I agree that one probably needs to
use a single RR type, so that one can use the atomic test-and-set
properties of the update operation on a single RRset, and these drafts
probably can't go forward until all the details of this update
operation (how one composes it, how one handles failures, etc) are
nailed down.  If, however, preventing this case is not a goal, then I
stand by my earlier statement that two RR types would be simpler,
which perhaps just means that I'm still missing something.

So, what's the goal, where is it stated, and why not? :)

BTW, I'll be in Vienna, and, for the first time since I don't remember
when, I don't (yet) have a schedule conflict to prevent me from
attending the DHC WG session, so I'm game for trying to thrash this
out there (or in the bar) if that'd help.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 09 Jul 2003 07:39:48 -0400

Seems to me we could plausibly want to allow both behaviors...

- disallow registration of an IPv4 address and an IPv6 address
   to the same name by different hosts

- allow registration of an IPv4 address to a name by a DHCPv4
   server and registration of an IPv6 address to the same name
   by a DHCPv6 server

- Ralph