Re: [dhcwg] Comments on draft-wing-dhc-dns-reconfigure-01

["Prashanth Patil (praspati)" <[e-mail]>]

Hi Tomek,
Thanks for the detailed review. Inline..

On 27/07/13 9:33 PM, "Tomek Mrugalski" <[e-mail]> wrote:

>I had some time to review draft-wing-dhc-dns-reconfigure-01. This is a
>reasonable draft and I believe it tries to solve a real problem. If
>authors are going to request adoption in DHC, we'll need to either
>update our charter to include it or get AD permission to adopt it.
>Since we're in the process of updating our charter, it will be quite
>easy to add that draft to our charter.
>
>Please note the the new charter says that if a new proposal defines
>simple option that follows standard behavior, it should be adopted in
>the respective WG, not in DHC. That draft defines a simple option, but
>it does introduce behavior change, hence it should be adopted in DHC in
>my opinion.
>
>However, I have some comments:
>
>Section 3, bullets 2 and 3 mention "regular DNS server", but the
>terminology section defines only "DNS server".
>
>Section 3, bullet 3: "regualr" => "regular"

Accept, will correct.

>
>Section 4: Please remove the formatting lines after info-flags. The
>format as it is presented now suggested 3 octets of padding. This is
>probably not what you want.
>
>Option-length field should be defined explicitly as 1.

Accept.

>
>Although you only define values 0x01 and 0x02, you should add a text
>that the server MUST ignore the option if it doesn't recognize
>configured flag.

Accept.

>
>Also, naming of the field a 'flag' is not fortunate. This is more of an
>enumaration value. Flag somewhat implies that this is a bit field and
>some people may get idea to set both flags and send 0x03. Obviously that
>combination does not make sense.

Agreed. 'Flag' is not appropriate, it is a mutually exclusive enum.

>
>Section 5 should start with "DHCPv6 relay agents that implement
>this functionality MUST support RFC6977."
>
>Section 5, first paragraph "IPV6_HIG_PROI_NORM_SERV": H missing after
>HIG.

In some of the earlier threads, there was discussion on whether info sent
to the server be more generic and not specific to the DNS problem. There
could be other potential actions that a server MAY want to take, either by
built-in design or configuration, based on end point mode i.e IPv4 only,
IPv6 only, Dual-Stack, transitions from Ipv4/6 to Dual-stack and vice
versa. The idea is to now dynamically indicate generic host mode in
RELAY-FORW and RECONFIGURE_REQUEST to the server and the server then
chooses to (RE)CONFIGURE accordingly, the draft defines server behavior
for DNS reconfiguration to start off with.

>
>Section 5 repeats some normative language from RFC6977 using slightly
>different wording. It would be better to say that relay sends
>RECONFIGURE-REQUEST as defined in RFC6977.
>
>Section 6, first and second bullet: Most of the text about sending
>reconfigure is duplicated. It would be easier to read if it had
>been written once and apply to both cases.
>
>Section 6 says "The server will remember this configuration for the life
>of the lease." That is not sufficient. DHCPv6 clients may have more
>than one lease. What about stateless clients? They do
>information-request only and there are no leases for them.

Agreed, stateless clients have to be taken into account.

>
>It should be specified somewhere (perhaps in section 7) in the text that
>only the relay closest to the client is able to do host tracking.
>Keep in mind that DHCPv6 allows up to 32 relays. I never heard of
>any network that has more than 2 cascade relays, though.

Yes, it has to be the one closest to the client. Will specify this.

>
>There's also redundancy in the section 6. What if the relay starts
>sending reconfigure-request with flag set to 0x01 for a given client?
>Server should trigger reconfigure for the first time, but later only
>check that the flag matches current configuration and do not trigger
>another reconfigure. Sure, such behavior would likely mean bad relay
>implementation, but I personally would consider it protocol resiliency.

Right, ideally a relay shouldn¹t be sending redundant
reconfigure-requests. Needs text to specify behavior on both relay and
server for this.

>
>Section 7 can possibly also mention if the information about clients
>is affected by relay reboots, e.g. if the information should be kept
>in some form of persistent storage or if the relay should retrieve
>its lost information using leasequery. If you do not want to be too
>specific, please add an information that specific retention policy is
>implementation dependent.

Sure.

>
>There's one flaw in the whole concept or at least an omission in the way
>the mechanism is described. Section 7 mentions information about relay
>gathering IPv4/IPv6 - MAC mapping, but the reconfigure-request (and
>almost any other operation in DHCPv6) references clients by their
>DUIDs. So it should be a triplet of IP/MAC/DUID. Do not assume any
>relation between MAC and DUID. There are DUID types that are not based
>on MAC. Also, even when the client uses MAC-based DUID, it is perfectly
>valid case to use different interface's MAC to generate DUID or keep
>using DUID after changing NIC.

Accept.

>
>Security considerations may also mention that if a relay is compromised,
>it may be used to force the uncompromised server to abuse clients by
>triggering repetitive reconfigurations. That's not a big issue as in
>case of the relay being compromised there are more serious ways intruder
>could wreak havoc.

Sure, will mention this risk.

>
>References need updating: I-D.ietf-dhc-triggered-reconfigure
>was published as RFC6977.
>
>Section 9: nit-pick: There is no "DHCPv6 Options" section in RFC3315.
>It is better to say that IANA is requested to add option-code to the
>"DHCP Option Codes" maintained at
>www.iana.org/assignments/dhcpv6-parameters (note: the registry that
>keeps DHCPv6 options is called "DHCP
>option codes", not "DHCPv6 Option codes". It is a bit odd, but that's
>how the registry was named).

Thanks, will do.

>
>Section 10.1: Are you sure that all those references are normative?
>RFC6052, RFC6147, RFC6384 and RFC6724 seems like informative.
>
>None of the informative references are used in the text. Please either
>reference or remove them.

Accept.

>
>Finally, let me repeat my previous opinion (with my chair hat off): I
>consider this draft useful and would like to see it adopted in DHC.
>
>Hope that helps,

Thanks,
Prashanth

>Tomek
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg