Re: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014

[Marcin Siodelski <[e-mail]>]

I have read the document and I think it is not ready yet.

A couple of comments/questions....

I wonder how this would work with multiple DHCP servers receiving
registration requests from a single client? Apparently, there may be a
form of race condition that they will both try to add or remove the
mapping from the DNS. One of them could wait and query DNS to see
whether the particular mapping is in DNS and do not update - which would
mean that the other one has updated DNS. But, that would require some
form of back-off mechanism. So, is this assumed in this document that
there is only one DHCP server performing registration function and
multiple registering servers are out of scope? I would be fine with
that, as long as it is mentioned in the document.

Section 5.1. 

The
   DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain exactly one
   IA_NA option and exactly one FQDN option

Why is this limited to exactly one IA_NA option? IIRC, RFC4704 allows updates for multiple bindings. A fragment from RFC4704:


   The Client FQDN option MUST only appear in a message's options field
   and applies to all addresses for all IA_NA bindings in the
   transaction.

If there is a good reason for such limitation, it would be useful to explain why only one IA_NA option is allowed. Especially, that one IA_NA may contain multiple addresses anyway.

Also. section 5.3 seems to be a little contradicting to this:


 For each IA in the ADDR-REGISTRATION-REQUEST
   message for which the server does not succeed in registering, the
   server adds an IA option using the IAID from the ADDR-REGISTRATION-
   REQUEST message, and includes a Status Code option with the value
   RegistrationDenied (TBA3) in the IA option.  No other options are
   included in the IA option.

If you only allow one IA_NA, then why do you have to perform "for each".
Perhaps server should discard the packet with multiple IA_NAs?

IMHO, server should allow multiple IA_NAs, unless there is a good reason
not to. But, that should be explained.

Section 4.
What does the server do if IA_NA or FQDN is missing? This section only
talks about discarding the message that contains server id.

Section 5.3.

In the "normal" exchange with DHCPv6, client MUST include ORO to request
that server returns Client FQDN. By returning the FQDN option, server
may indicate whether or not it performs DNS updates for the client. It
may also send its notion of the FQDN. For example: a client may send
partial FQDN and rely on the server to generate one. There are no such
considerations in the draft. In particular, it is not said whether
client MUST or MUST NOT put ORO in the ADDR-REGISTRATION-REQUEST. Also,
the server's response is optional (which is wrong in my opinion) and so
the server's notion of FQDN is not communicated back to the client. Is
this the intent? From the draft it is unclear in what circumstances the
server will send back RegistrationDenied? Does it include the case when
client sends FQDN that DHCP server doesn't like (e.g. partial), and
instead of generating FQDN for the client (and sending it back in the
FQDN option), server would send RegistrationDenied?

Sorry for a bit long and blurry comment here, but in section 5. you
mention about "reusing" FQDN option from RFC4704 and I am not sure how
much of RFC4704 (and existing logic for processing FQDN) you intend to
reuse in the addr-registration.

Marcin

On 29/03/14 15:04, Bernie Volz (volz) wrote:
>
> Folks, the authors of draft-ietf-dhc-addr-registration
> (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04)
>
> feel it's ready for work group last call. Please review this draft and
> indicate whether or not you feel it is ready to be published.
>
>  
>
> At the time of this writing, there is no IPR reported against this draft.
>
>  
>
> Tomek and I will evaluate consensus after April 13, 2014.
>
>  
>
> Thanks,
>
> Bernie & Tomek
>
>  
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg