Hi,

This email contains a number of comments on draft-ietf-dhc-rfc3315bis-05. I haven’t de-duplicated from previous comments to the list.

The comments are in order of appearance in the draft.

There are a few typos that I assume will be picked up by the RFC Editor, e.g. p.6 “which definition” (whose) and p.7 “filled” (filed), but it would be nice to minimise these. I’ve not noted them below.

Section 1.2
p.7 RFC4477 discussed dual-stack DHCP issues, and recommended separate servers per protocol (and thus not adding IPv4 options to DHCPv6). It may be worth citing, but some of the discussion may now be dated.
The section doesn’t discuss how merging of responses from DHCPv4 and DHCPv6 might be done. It should probably be flagged, but marked out of scope for 3315bis. I know we started discussing this years ago (draft-ietf-dhc-dual-stack-merge-01), but no consensus was reached as far as I recall.

Section 1.3
p.7 Perhaps say here that DHCP can be initiated by the client when required, or triggered by a server through an authenticated Reconfigure message.

Section 3
p.9 Will this draft will be parked until the 2460-bis and 4291-bis documents are completed?
The language of the first paragraph in Section 3 is a little clumsy.
Is the well-known multicast address (ff05::1:3) in common use? I’m not aware of any sites using it, rather they manually configure dhcp server addresses in relays.
The thinking on M/O flags in RFC4861 has moved on since 3315 was written. I guess it still needs to be mentioned, but it says “compatibility with SLAAC is a design requirement of DHCP” and the evidence of draft-ietf-v6ops-dhcpv6-slaac-problem-07 is rather to the contrary! (though not sure what to say here… it would be good to encourage more consistent behaviour - is there anything we can add to 3315bis to address the issues raised in draft-ietf-v6ops-dhcpv6-slaac-problem-07?

Section 4.1
p.10 Should this say IP and DHCP or IPv6 and DHCPv6?

Section 5.4
p.18 Should this example explain behaviour for PD when there are hierarchical routers within the site (as per RFC7368)? Or that where RAs are then issued by requesting routers their valid lifetime should be less than the lifetime of the PD?  (This and address examples are given in 17.1.10.1 which could be forward referenced)

Section 5.5
p.19 Is it worth adding a Section 5.6 here that briefly explains the renumbering case and use of Reconfigure messages? It would be nice to capture the work of 6RENUM here, and for the reader to appreciate that support for renumbering is useful.  I don’t think Reconfigure is otherwise mentioned in Section 5. This could also warn against “infinite” lifetimes.  As might RFC4242.

Section 6.1
p.19 Add a reference to the IANA Registry here? (http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml). And again, is site-scope multicast in common use (compared to manual server configuration on relays)?

Section 6.6
p.23 T1 and T2 are introduced here with no explanation of what they are. Perhaps forward reference to relevant options in Section 20?
It would also be good to repeat the warnings given later about infinite lifetimes here.

Section 8.1
p.25 There’s many references to “site-scoped” (unicast) addresses in 3315bis. Should these not all be removed? Also, ULAs are Global scope, so not sure they should be differentiated here or not.

p.28 “Despite our best efforts” reads oddly.

Section 10
p.31 The DUIDs are all explained here. But will 3315bis add any text for the RFC6939 model, whereby MAC addresses can be added as an option that relays will forward? There’s growing implementation support for this (e.g. Cisco relays, ISC DHCP), and it’s commonly requested by campus admins who I speak to. Or is this considered a “hack”? (RFC6939 is Standards Track, not Experimental…)

Section 12.1
p. 33 Perhaps add a pointer at the end of this section to RFC7824 and RFC7707 on address allocations from a DHCP pool, or point to discussion of these in Sections 21 and 22.

Section 12.3
p.33 Perhaps add that the client may have an IA_NA and an IA_TA.  It’s an open question as to whether a client may do IA_TA only.

Section 31.1
p.35 Maybe move the rate-limiting text (or replicate it) in Section 21.

Section 17
p.43 Update reference to RFC2462 to RFC4862, but anyway I think the pointer should be to RFC4861 where the M/O flags are described?

Section 17.1
p.45 In the DISCUSSION, it may be worth clarifying whether RFC6939 works via unicast; I recall it only works via a relay, which would be another reason to avoid unicast (if true, and you want to use RFC6939...).

Section 17.1.10.1
p.60 There was discussion in 6man/v6ops about using a /64 from the delegated prefix for a site for numbering the uplink. I think Jordi’s recent survey of ISPs showed this was more common than expected? So do we want to say MUST NOT assign here?  (I have no strong feeling myself…)

p.61 There may be complexities here if a client gets other configuration info from both DHCPv4 and DHCPv6… esp. if it merges without noting the source of the options it prioritised.

Section 17.2.9
p.74 Is the “server selection process” described somewhere?  If so, cite it, if not, it probably should be?

Section 18
p.77 I’d argue that from current usage, the first paragraph should say something stronger about including unicast addresses, mirroring common practice, and limited (is there any?) use of the all-dhcp-servers site-scope multicast address (ff05::1:3). Given a lot of work in the IETF on minimising use of multicast on links, do we want to say something stronger about not using the multicast site-scope WKA?

Section 18.1.1 and 18.1.2
p.78 Again, site-scope addresses mentioned three times on this page need to remove.
“If not” should be “If no”.
ULAs are not mentioned here; these can be considered within Globals, or may be called out separately (but it emphasised that they are Global scope).

Section 20.4
p.88 Change “client contacts” to “client should contact” (x2) to mirror the text for the PD option?

p.90 The “infinity” lifetime again mentioned here, with a health warning, but should we be stronger in language, as not least it kills renumbering. Worth a SHOULD NOT use infinite lifetime, so those doing it need to think about their specific reason to ignore that?

Section 20.5
p.91 I’m not sure about the text here on requesting an extension to the lifetime for an IA_TA. WOuldn’t the host simply deprecate the current temporary address (so it’s still usable by an existing TCP session) and request a new preferred IA_TA?  I had assumed DHCP worked the same as RAs here, e.g. generate a new temporary address every 24 hours, but keep the previous N addresses, in a deprecated state?
But does the DHCP server then need to keep state on the deprecated addresses to avoid reallocation to another host? Does that mean the host really needs to request N temporary addresses, and it’s the host’s job to choose which is preferred, with the DHCP server noting all those allocated (whether the host marks them deprecated or not)?  (I may be overthinking this! :)

Section 20.6
p.93 Again a mention of infinite lifetimes - perhaps we need a separate section early on with the clear health warning, rather than replicating it each time?  Not sure.

Section 20.14
p.101
Does it really matter in IPv6 that a handful of addresses may be committed by servers but not used by clients?  Again this may be a good place to reference the address allocation strategies in RFC7824 and RFC7707, or forward reference to sections 21 and 22.

Section 20.22
p.112 Does the PD option need a health warning on infinite lifetimes?

Section 20.25
p.114 Maybe add it is useful for renumbering.

Section 21
p.116
“This threat model does not consider the privacy of the contents of DHCP messages to be important” - despite RFC7824?
Add a reference to RFC7707 on scanning attacks.

Section 22
p.117
Move the para on scanning to section 21 and cite RFC7707.
The “Deriving the IID” paragraph repeats advice in RFC7824.

Section 24
p.118 is ff05::1:3 obsolete? :)

Tim