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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 3 Sep 2014 15:42:18 +0000

While we could see what other issues are reported in the WGLC, I think it worth fixing some issues before asking for the WGLC. Others should be encouraged to look at the document and send any comments ASAP.

In section 3, the following sentence is a bit odd:

   While multiple address registration servers does
   potentially increase the load on DNS, because of how

Perhaps reword as:

   While [using] multiple address registration servers does
   potentially increase the load on DNS, because of how

In section 4, at the end, is some left over text that I think was supposed to be removed (the last item in the list includes this condition).

   Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that do
   not Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that
   do include any Option Request Option(s).

The new text in Section 3 regarding multiple registration servers is useful, but it seems like a rather poor answer to just say it is out of scope. 

In section 5, is it worth mentioning IAADDR option too ... see below as perhaps IA_NA isn't needed?

In section 5.3, it may be worth clarifying that "when a server accepts" means that it may not have actually done the update yet - just that it has taken responsibility to do so. The reason to clarify this is that I think it would be a bad idea for servers to only Reply once they have added the information to DNS -- since that could take an indeterminate amount of time (if for example, that servers that can accept DNS updates are not "up"). So, Success just means the server has agreed to attempt the DNS update; not that it has done it. 

Also, "responsible" is misspelled in this section 5.3 (responsilbe).

I also think section 5.3 (or this draft) should define default values for the new timers similar to what was done in RFC 3315. "Might" seems weak.

   Where ADDR_REG_TIMEOUT might be 1 second, ADDR_REG_MAX_RT might be 30
   minutes and ADDR_REG_MAX_RC might be 5.

The following sentence needs to be corrected (I think the 2nd "in" should be removed):

   For each IA in the ADDR-REGISTRATION-REQUEST message for which the
   server does not accept its associated in registration request, the

Also, this paragraph is unclear / does not work ... I assume that IA here is an IA_NA? But what if the client sends multiple addresses (IAADDR options) in the IA_NA and the server can register one of these but not the others? How is that case handled? This may be common given that a client might have generated both a ULA and GLA, but the registration server is only able to register the ULA, for example? Perhaps we have to support the case of a Status Code option encapsulated within an IAADDR option to handle this case? Other possibilities include limiting each IA_NA (since it isn't a real IA_NA) to a single IAADDR as then the Status Code option can appear in the IA_NA as it is clear that 'that' address did not get registered. But this requires more client bookkeeping as to which IAADDR was in which IA_NA. I'm wondering why we have IA_NAs at all and whether perhaps just having IAADDR options makes more sense (no IA options)?

And while I think I understand the intent of:

   Upon receiving a RegistrationDenied error status code, the client MAY
   also resend the message following normal retransmission routines
   defined in [RFC3315] with above parameters.

Do we want to be clear here that the client MUST wait out the retransmission time before retrying. And, why isn't this extended to RegistrationNotSupported? Perhaps this also begs the question as to when this RegistrationNotSupported message should be sent? A "DHCPv6 server" or "DNS Registration Server" has two choices - it can ignore a Registration request if it doesn't want to support it or it can send a RegistrationNotSupported. If a RegistrationNotSupported is meant to tell clients "stop sending these requests", that could be a DoS attack? The text in 5.1 is unclear on this:

                                                            If the DHCPv6 server does not support
   address registration function, a Reply message with includes a Status
   Code option with the value the RegistrationNotSupported (TBA2) MAY be
   sent back to the initiated client.

You should clarify when this should be sent and what it means (over just dropping the request). Perhaps more needs to be said in section 6, Security Considerations?

For section 7 (IANA Considerations), it may be nicer for IANA if you actually created tables similar to what would eventually appear in the registration. But that is up to you if you want to leave it as it is (text). Anything you can do to make it easier for IANA is always a good idea.

- Bernie

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2014 5:16 AM
To: Bernie Volz (volz); Tomek Mrugalski
Cc: [email-masked]
Subject: Could you launch WGLC for draft-ietf-dhc-addr-registration-06

Dear DHC chairs,

The authors had submitted 06 version, just before the IETF90 meeting. We believe all received comments have been properly solved. Many thanks for Bernie's thorough review and comments. We believe the document is now ready for second WGLC. Could you please launch it?

Best regards,

Sheng

---

From: 神明達哉 <[email-masked]>
Date: Wed, 3 Sep 2014 10:52:50 -0700

At Wed, 3 Sep 2014 15:42:18 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> While we could see what other issues are reported in the WGLC, I
> think it worth fixing some issues before asking for the WGLC. Others
> should be encouraged to look at the document and send any comments
> ASAP.

I have one fundamental question about this proposal.  In its
introduction the draft states:

   [...] In
   several tighly controlled networks, hosts with self-generated
   addresses may face some limitations.  One such limitation is related
   to the inability of nodes with self-generated addresses to register
   their IPv6-address-to-FQDN bindings in DNS.  This is related to the
   fact that, in such networks, only certain nodes (e.g.  The DHCPv6
   server) are allowed to update these bindings in order to prevent end-
   hosts from registering arbitrary addresses for their FQDNs or
   associating their addresses with arbitrary domain names.

This logic is not very persuasive to me.  In such a "tightly
controlled network", wouldn't the administrator even like arbitrary
hosts to register the address-FQDN binding at the address registration
server in the first place?  And, if it's assumed to be authenticated
in some way, I don't understand why we can simply allow the hosts to
perform DDNS with some authentication such as TSIG.

Since it's so fundamental, I guess it was already discussed before and
I simply missed the past discussion.  In that case I'd apologize for
my ignorance in advance, but in any case it may suggest that we need
some more clarification in the introduction; otherwise future readers
without the background context may have the same question.

And, btw, there's a typo in the quoted text above: s/tighly/tightly/

--
JINMEI, Tatuya

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 4 Sep 2014 02:25:20 +0000

Hi, Jinmei,

Thanks for your comments. The point is the registration server could have a chance to apply certain filter/accept criteria, particularly for the client chosen domain names. We did not mention this, because it is internal event in the registration server. But we can certainly add some clarification text into the introduction section.

Best regards,

Sheng

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of 神明達哉
>Sent: Thursday, September 04, 2014 1:53 AM
>To: Bernie Volz (volz)
>Cc: Sheng Jiang; Tomek Mrugalski; [email-masked];
>[email-masked]
>Subject: Re: [dhcwg] Could you launch WGLC for
>draft-ietf-dhc-addr-registration-06
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 4 Sep 2014 02:57:00 +0000

Hi, Bernie,

Thanks for your thorough review. Your comments are appreciated and will be addressed in 07 version, which I will wait till next Monday for more comments on the DHC list.

Best regards,

Sheng

>From: Bernie Volz (volz) [mailto:[email-masked]]
>Sent: Wednesday, September 03, 2014 11:42 PM
>To: Sheng Jiang; Tomek Mrugalski
>Cc: [email-masked]; [email-masked]
>Subject: RE: Could you launch WGLC for draft-ietf-dhc-addr-registration-06
>
>While we could see what other issues are reported in the WGLC, I think it
>worth fixing some issues before asking for the WGLC. Others should be
>encouraged to look at the document and send any comments ASAP.
>
>In section 4, at the end, is some left over text that I think was supposed to be
>removed (the last item in the list includes this condition).
>
>The new text in Section 3 regarding multiple registration servers is useful, but
>it seems like a rather poor answer to just say it is out of scope.
>
>In section 5.3, it may be worth clarifying that "when a server accepts" means
>that it may not have actually done the update yet - just that it has taken
>responsibility to do so. The reason to clarify this is that I think it would be a
>bad idea for servers to only Reply once they have added the information to
>DNS -- since that could take an indeterminate amount of time (if for example,
>that servers that can accept DNS updates are not "up"). So, Success just
>means the server has agreed to attempt the DNS update; not that it has done
>it.
>
>I also think section 5.3 (or this draft) should define default values for the new
>timers similar to what was done in RFC 3315. "Might" seems weak.
>
>Also, this paragraph is unclear / does not work ... I assume that IA here is an
>IA_NA? But what if the client sends multiple addresses (IAADDR options) in the
>IA_NA and the server can register one of these but not the others? How is
>that case handled? This may be common given that a client might have
>generated both a ULA and GLA, but the registration server is only able to
>register the ULA, for example? Perhaps we have to support the case of a
>Status Code option encapsulated within an IAADDR option to handle this case?
>Other possibilities include limiting each IA_NA (since it isn't a real IA_NA) to a
>single IAADDR as then the Status Code option can appear in the IA_NA as it is
>clear that 'that' address did not get registered. But this requires more client
>bookkeeping as to which IAADDR was in which IA_NA. I'm wondering why we
>have IA_NAs at all and whether perhaps just having IAADDR options makes
>more sense (no IA options)?
>
>Do we want to be clear here that the client MUST wait out the retransmission
>time before retrying. And, why isn't this extended to
>RegistrationNotSupported? Perhaps this also begs the question as to when
>this RegistrationNotSupported message should be sent? A "DHCPv6 server" or
>"DNS Registration Server" has two choices - it can ignore a Registration
>request if it doesn't want to support it or it can send a
>RegistrationNotSupported. If a RegistrationNotSupported is meant to tell
>clients "stop sending these requests", that could be a DoS attack? The text in
>5.1 is unclear on this:
>
>                                                            If
>You should clarify when this should be sent and what it means (over just
>dropping the request). Perhaps more needs to be said in section 6, Security
>Considerations?
>
>
>For section 7 (IANA Considerations), it may be nicer for IANA if you actually
>created tables similar to what would eventually appear in the registration. But
>that is up to you if you want to leave it as it is (text). Anything you can do to
>make it easier for IANA is always a good idea.
>
>- Bernie
>
>The authors had submitted 06 version, just before the IETF90 meeting. We
>believe all received comments have been properly solved. Many thanks for
>Bernie's thorough review and comments. We believe the document is now
>ready for second WGLC. Could you please launch it?
>
>Best regards,
>
>Sheng

---

From: 神明達哉 <[email-masked]>
Date: Thu, 4 Sep 2014 09:37:12 -0700

At Thu, 4 Sep 2014 02:25:20 +0000,

> Thanks for your comments. The point is the registration server could have a chance to apply certain filter/accept criteria, particularly for the client chosen domain names. We did not mention this,…

That doesn't fully address my question.  If the policy of the "tightly
controlled network" allows hosts to register a binding of their own
names and addresses based on certain filter/accept criteria, they
should be able to implement the policy on the DNS server itself:
allow/deny DDNS update requests based on "certain filter/accept
criteria".  So it doesn't immediately mean the need for a separate
registration server with protocol extensions.

What I wanted to see is a discussion that explains the "why bother to
introduce a new concept and protocol when we can do it with existing
tools".

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Sep 2014 17:10:57 +0000

Jinmei:

I suspect that the argument is that it is easy to establish a trust relationship between a single DHCPv6 (address registration) server and the DNS, but it is much more difficult to distribute this to the many clients.

Also, the address registration server can be better trusted to:
- Implement the RFC 470x documents related to updating DNS for DHCP leasing (although DHCP leasing is not being used here).
- Limit what is placed in the DNS (i.e., the addresses added for names).
- Potentially take additional steps to 'verify' that the client is indeed "allowed" to use that address (or at least that another device isn't using it)? How this would be done is probably outside the scope of the document (if the registration server is on a router, it might already have a table of address to client bindings). Though unless the DUID types used by clients are restricted (i.e., DUID-LL), this mapping information may not be known (since ND uses the mac-address of the interface whereas DUID might be constructed from other information or an earlier interface identifier).

If you just allow clients to update, a rogue client can do more bad things.

I'm not saying you couldn't (or shouldn't) add some of the above to the DNS server itself, but that has other issues with it and might not always be the best place to enforce policy (as the server may be handling lots of differing requirements). And, in some cases it is not possible to do this at the server (such as making sure RFC 470x is being followed) as the required information isn't available in the DNS packets.

---

Another question is why not just use DHCPv6 in the first place. But that has already been debated too and there is the 'stateless' camp that wants a way to get the information into DNS -- and thus that brings us back to the key distribution problem.

I'm only answering for myself - not as co-chair or an author. So, the authors may well want to respond to Jinmei's query.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, September 04, 2014 12:37 PM
To: Sheng Jiang
Cc: Bernie Volz (volz); [email-masked]; [email-masked]
Subject: Re: [dhcwg] Could you launch WGLC for draft-ietf-dhc-addr-registration-06

> Thanks for your comments. The point is the registration server could have a chance to apply certain filter/accept criteria, particularly for the client chosen domain names. We did not mention this,…

That doesn't fully address my question.  If the policy of the "tightly controlled network" allows hosts to register a binding of their own names and addresses based on certain filter/accept criteria, they should be able to implement the policy on the DNS server itself:
allow/deny DDNS update requests based on "certain filter/accept criteria".  So it doesn't immediately mean the need for a separate registration server with protocol extensions.

What I wanted to see is a discussion that explains the "why bother to introduce a new concept and protocol when we can do it with existing tools".

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 5 Sep 2014 10:50:36 -0700

At Thu, 4 Sep 2014 17:10:57 +0000,

> I suspect that the argument is that it is easy to establish a trust relationship between a single DHCPv6 (address registration) server and the DNS, but it is much more difficult to distribute this…

Why?  These seem to be equally difficult to me:
- establishing a trust relationship between a single DHCPv6 server and
  many DHCPv6 clients
- establishing a trust relationship between the primary authoritative
  DNS server (which would accept DDNS requests) and many DNS (DDNS)
  clients

One subtle difference, though, may be that the primary authoritative
DNS server may be different for forward (host to address) and reverse
(address to host) mappings.  In that case the configuration overhead
may be bigger in the case of latter.  But I suspect these are often
the same single server in the intended use cases in the context of
this document.  And, in any case, I don't think that's not the central
issue of establishing a trust with arbitrary number of clients.

It might even be easier to find a middleground for DNS since it can
also work with TCP.  See, e.g., the "tcp-self" policy of ISC BIND 9:
ftp://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
Of course, that's a very weak way of spoofing resilience, but solves
one common big issue in cases like this: key distribution/sharing.

> I'm not saying you couldn't (or shouldn't) add some of the above to the DNS server itself, but that has other issues with it and might not always be the best place to enforce policy (as the server…

I'm not sure specifically what kind of issue we'd see regarding RFC
470x in this context, but in general, the above points seem to be made
possible whether it's via a DHCP server or on the DNS server; it
basically seems to be a matter of implementation/deployment details.

Please don't get me wrong, though: I'm not necessarily opposing to
standardizing this proposed enhancement by making these arguments.  I
just wanted to point out that the justification for introducing new
stuff in the current text seems to be very weak, at least to me.  I
personally may not be persuaded for the need even if some more
explanation is added, but as long as some reasonable discussion is
provided I guess it will be good to ship.

--
JINMEI, Tatuya

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 9 Sep 2014 07:30:46 +0000

Hi, Jinmei,

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. 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.

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. Also, the deployment of address registration server would help the administrator to manage the DNS records among multiple DNS servers.

Best regards,

Sheng

>Sent: Saturday, September 06, 2014 1:51 AM
>To: Bernie Volz (volz)
>Cc: Sheng Jiang; [email-masked];
>> I suspect that the argument is that it is easy to establish a trust relationship
>between a single DHCPv6 (address registration) server and the DNS, but it is
>much more difficult to distribute this to the many clients.
>
>> - Implement the RFC 470x documents related to updating DNS for DHCP
>leasing (although DHCP leasing is not being used here).
>> - Potentially take additional steps to 'verify' that the client is indeed
>"allowed" to use that address (or at least that another device isn't using it)?
>How this would be done is probably outside the scope of the document (if the
>registration server is on a router, it might already have a table of address to
>client bindings). Though unless the DUID types used by clients are restricted
>(i.e., DUID-LL), this mapping information may not be known (since ND uses
>the mac-address of the interface whereas DUID might be constructed from
>other information or an earlier interface identifier).
>>
>> I'm not saying you couldn't (or shouldn't) add some of the above to the DNS
>server itself, but that has other issues with it and might not always be the best
>place to enforce policy (as the server may be handling lots of differing
>requirements). And, in some cases it is not possible to do this at the server
>(such as making sure RFC 470x is being followed) as the required information
>isn't available in the DNS packets.
>

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Sep 2014 13:13:52 -0700

At Tue, 9 Sep 2014 07:30:46 +0000,
Sheng Jiang <[email-masked]> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Sep 2014 21:57:11 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Tuesday, September 09, 2014 4:14 PM
To: Sheng Jiang
Cc: Bernie Volz (volz); [email-masked]; [email-masked]
Subject: Re: [dhcwg] Could you launch WGLC for draft-ietf-dhc-addr-registration-06

> 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 ser…

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.

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

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 10 Sep 2014 01:33:18 +0000

Hi, Jinmei,

This is just deployment choice, just like SLAAC and DHCPv6 for IPv6 address management. They both exist and some prefer SLAAC, other like DHCPv6. It is not necessary SLAAC is better than DHCPv6 or vice verse. We do have customer said they prefer DHCP to manage DNS update, we also have support in previous discussion. I don't understand why we need strong argument to complete this work. If a network administrator, like you, want to use client DDNS in his network, our draft does not prevent it at all. The discussion should not be which solution is the best. Instead, the right discussion should be whether the proposed solution is technically workable and whether people want to use it.

Best regards,

Sheng

---

From: 神明達哉 <[email-masked]>
Date: Wed, 10 Sep 2014 09:38:00 -0700

At Wed, 10 Sep 2014 01:33:18 +0000,
Sheng Jiang <[email-masked]> wrote:

> This is just deployment choice, just like SLAAC and DHCPv6 for IPv6
> address management. They both exist and some prefer SLAAC, other
> like DHCPv6. It is not necessary SLAAC is better than DHCPv6 or vice
> verse. We do have customer said they prefer DHCP to manage DNS

I wouldn't buy that analogy.  In case of SLAAC and DHCPv6-based
address configuration, I can see a clear technical difference between
them: SLAAC minimizes (if not eliminates) operator intervention, while
DHCPv6 allows centralized control.  Both are different types of need,
so I can see why we have both.  What I've been trying to say is that I
don't see such a clear difference that explains why we need
dhc-addr-registration in addition to DDNS.  But, whether or not you
agree on this point...

> update, we also have support in previous discussion. I don't
> understand why we need strong argument to complete this work. If a
> network administrator, like you, want to use client DDNS in his
> network, our draft does not prevent it at all. The discussion should
> not be which solution is the best. Instead, the right discussion
> should be whether the proposed solution is technically workable and
> whether people want to use it.

...it seems that you (or the wg in general?) believe we don't even
need such differentiation in the first place.  That's probably the
fundamental difference on the view between you (and maybe others) and
me.  In my understanding, we generally avoid introducing multiple
solutions that are not sufficiently different to solve the same
problem, as stated in RFC 1958:

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

I didn't see in this proposal a "good technical reason" not to choose
the previous solution of DDNS-only (I wouldn't necessarily say
DDNS-only solution "sufficiently solves" the problem, but the issues
with DDNS don't seem to be solved with this proposal either), and have
sought such a "reason" in this thread.  But, if the consensus was that
we don't even need such a reason (apparently that's the case), I won't
fight against it anymore.  I'll stop arguing here.

--
JINMEI, Tatuya