Re: [dhcwg] Could you launch WGLC for draft-ietf-dhc-addr-registration-06

["Bernie Volz (volz)" <[e-mail]>]

Jinmei:

> I simply didn't see a point of introducing a new protocol for it, but if I'm the only person who thinks so or who just can't see the advantage of the proposed approach, I'll shut up here rather than try to persuade the wg on it.

I think the two choices that exist today are (if you want to have clients use IPv6 and have entries in DNS - let's ignore whether these are forward or reverse):
1. Use DHCPv6 to assign addresses and have the DHCP server update DNS server.
2. Allow clients to do the update themselves (this may require TSIG or other key distribution, or just wide open access).

And given that:
1. There is some set of people (client implementors and network operators) that don't want to use stateful (DHCPv6) and hence only want stateful address assignment.
2. There is some set of people that want DNS to be updated when addresses are assigned.
3. Many clients today don't update DNS or even try to.
4. If the clients did update DNS, there may be networks where the administrator wants to require some kind of trust relationship and thus you end up with a key distribution problem.

Now the core question is whether using DHCPv6 or fixing #3 (and #4) on the list is easier or harder than this proposal? It obviously requires changes (updates) on the clients (since they must initiate the registration requests).

Whether we want this draft's option as a possible tool is a good and relevant question. We could certainly offer it as a 'tool' to enable this, but whether client implementations will implement this and what it might mean in terms of network costs for the (re)transmissions when not offered is an interesting question (i.e., why am I seeing all this DHCPv6 traffic when there is no DHCPv6).


Personally, I haven't been that enthusiastic about this draft because I think we have a solution for existing networks (use DHCPv6) and this requires nothing more for clients to implement (that support DHCPv6). And, adding more baggage to clients doesn't help (yet another protocol). Sure, this may be 'simpler' than implementing a full stateful DHCPv6 client and deploying DHCPv6 servers, but there are other benefits to implementing DHCPv6 (such as being able to connect on more networks)?

Is there anyone that intends to implement this for "popular" client operating system should it advance?

Solving the IPv6 DNS issue is I think useful work for the IETF. Though I'm not sure we're the best prepared to work on it; I think it ended up with us because it is using the DHCPv6 "protocol".


As WG co-chair, I'll work to advance the WG consensus regarding this (and any other) document.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Tuesday, September 09, 2014 4:14 PM
To: Sheng Jiang
Cc: Bernie Volz (volz); [e-mail]; [e-mail]
Subject: Re: [dhcwg] Could you launch WGLC for draft-ietf-dhc-addr-registration-06

At Tue, 9 Sep 2014 07:30:46 +0000,
Sheng Jiang <[e-mail]> wrote:

> In many networks, the administrator would not want to distribute the address of authoritative name-server. Also, as far as I know, there is no way to propagate the address of authoritative name server by any protocols. So, the clients does not know where to send their DNS records. But they can send their request by DHCP multicast address.

You don't need any special protocol for that.  A host can begin with an SOA query for its own FQDN (such as host.example.com/SOA) towards the root until it finds a deepest SOA (example.com/SOA, com/SOA, then ./SOA).  Once the deepest SOA record is found, the host can resolve the AAAA or A record of its MNAME, and then send a DDNS update to that address.  ISC's nsupdate works that way.

> It is safer for the address registration server, which is under the same management with the authoritative name-server, to know the address of the authoritative name-server and make registration requests on behalf of clients.

"safer" is vague, and I don't know exactly what you mean by this.

> It is easy to establish and *manage* one trust relationship between a DHCPv6 (address registration) server and the authoritative name-server, but it is much more difficult to manage trust relationships with many clients.

This argument doesn't make sense to me.  You'll still need to
"*manage* trust relationships" between the DHCPv6 server and many clients, right?  Otherwise an arbitrary client can force the DHCPv6 server to register a name-address mapping.  And then you'll face the same level of management issue.  I tried to make this point clearer in my previous comment...maybe I wasn't clear enough?

> Also, the deployment of address registration server would help the administrator to manage the DNS records among multiple DNS servers.

I don't get this either.  Do you mean the primary authoritative DNS server is different for the forward and reverse mappings?  I don't see a strong reason why this is a problem just with DDNS request once you solve the trust relationship issue (and, again, the issue is common for both approaches AFAICS).

Since two approaches are different, it wouldn't be impossible to find some case that is specific to one approach (although, so far, I've not even seen it).  But when one wants to introduce a new protocol extension for something that can be done by an existing tool, IMO we need a quite stronger argument to explain why an existing technology doesn't work.  At least to me, the current draft text is largely weak on this point, and I don't think I've seen a point that can provide such an argument in this discussion.

That said...as noted earlier in a separate message, I'm not necessarily intending to block this proposal or to push the idea of just using DDNS for the stated problem.  I simply didn't see a point of introducing a new protocol for it, but if I'm the only person who thinks so or who just can't see the advantage of the proposed approach, I'll shut up here rather than try to persuade the wg on it.

--
JINMEI, Tatuya