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

[Josh Littlefield <joshl@cisco.com>]

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?
With the current definition of the DHCID RR and the proposed algorithm 
in draft-ietf-dhc-ddns-resolution-05.txt, there is clearly an issue to 
be resolved.  The resolution could take the form of changing the DHCID 
RR definition to be v4-only, and adding a new DHCIDv6 RR for v6, or if 
could take the form of changing the algorithm in the dhc-ddns I-D.

The issue is the algorithm's implicit expectation that just one DHCID RR 
will be present on a name.  That may not be the case for a dual-stack 
client, where 2 different DHCID RRs would be generated.

The implicit expectation that DHCID is effectively a singleton occurs in 
 2 places in the algorithm:

1) In 6.1 (Adding A RRs): The first update asserts the name does not 
exist.  Failing that, the next update asserts the name exists with the 
expected DHCID.  When this fails (as it will if a v6 DHCID is already 
there with now v4 DHCID), the entire update fails, concluding the name 
is in use by someone else.

This second update will also fail if the anticipated v4 DHCID is already 
 there, but a v6 DHCID is there as well.  This is because DNS Update 
does not allow one to assert the presence of only one RR in an RR set. 
Instead, one must assert the entire RR set looks a certain way.  So for 
this second update to succeed, it would need to include the v6 DHCID RR.

2) In 6.3 (Removing Entries): Again, an assertion problem with the DHCID 
(in the case of removing A/AAAA records).  To succeed, the assertion 
would have to include all DHCID RRs on the name.

In order to allow the coexistence of both v4 and v6 DHCID RRs on the 
same name, the algorithm would need change, to add additional steps, as 
follows:

In 6.1, the last paragraph (before the DISCUSSION), on receiving NXRRSET 
to the second query (Update), the updater would then need to send a 
Query to learn the existing DHCID RR set on the name.  The updater would 
then need to examine this DHCID RR set, and determine whether the update 
should, or should not occur.  Most likely, the only case in which the 
update should occur is when the updater is able to determine that the 
existing DHCID RRs correspond to the same DHCP client. (This is not an 
easy determination to make if, for example, a v6 DHCID RR exists when 
making a v4 update, unless the updater generated the existing DHCID RR.)

If it is determined by the updater that the update should proceed, the 
update sent should employ prerequisites  asserting the state of the 
entire existing DHCID RR set.  This is to ensure the RR set has not 
changed, since its state formed the basis for the update decision.

A similar additional 2 steps (query and update) would need to be added 
to section 6.3 when removing A or AAAA RRs.

I believe it may be acceptable to make these additional steps optional, 
at least in the forward (A, AAAA) update case.  An v4 (or v6) updater 
who finds an existing v6 (or v4) DHCID RR may be unable to tell that the 
existing RR corresponds to the same client, since the RR data is a hash 
of something that updater doesn't know.  So querying the existing DHCID 
RRs may provide no information to persuade the updater to update that 
name. By not implementing the additional algorithm steps, that updater 
would be implementing a strict policy of name segregation, which may be 
the best it can do.

Clearly, an updater than can determine that v4 and v6 DHCID RRs 
correspond to the same client (most likely because it was the source of 
both) should implement the additional steps.

There may be benefit to recommending (in a separate document?) that dual 
stack DHCP clients form DUIDs and client-IDs from the same data, to 
increase the likelihood that an updator would be able to predict the 
data of a v6 DHCID from a v4 DHCP packet, and vice versa.

-josh

--
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
joshl@cisco.com                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg