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

[Tomek Mrugalski <[e-mail]>]

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"

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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,
Tomek