[dhcwg] Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6

[Tomek Mrugalski <[e-mail]>]

With my chair hat off.

I reviewed -02 of this draft. It is in quite good shape. I have several
comments, but most of them are editorial in nature. One major comment I
have (about the ability to turn off 4o6) should be addressed. Another
one (about covering stateless) is something to consider. I won't insist
on it if you think it's a bad idea.

Here are my comments:

Can 4o6 be used by clients that use stateless DHCPv6? It would be
stateless v6 and stateful v4. In my opinion that would be uncommon, but
a valid scenario. If authors agree, the text should be modified to say
that the server puts 4o6 Enable and 4o6 Address options in any server
response. As a server implementor, I can say that it's very easy to do.
Both options just become a regular options that client asks for and
server provides.

I had a discussion with Marcin about this. One issue with the draft is
that there is no defined way to revoke the "4o6 available" status.
Consider a case when administrator has 4o6 available, but decides
to turn it off. The client will renew its IPv6 lease eventually
and may then learn that 4o6 is no longer available. The problem with
this is that it creates an artificial link between 4o6 availability and
IPv6 lease lifetime. So I think there are couple things that should be
added:

- a clarification that the client interested in running in 4o6 mode
MUST request 4o6 Enabled and 4o6 Addresses options in every Solicit,
Request and Renew messages

- when client requested 4o6 Enabled option, but did not receive
it, it must disable its 4o6 functionality (possibly sending DHCPRELEASE
before shutting down)

- you need to solve somehow the fact that 4o6 service availability
status cannot be updated (revoked) easily. The most obvious example
is a stateless DHCPv6 client, but also a stateful client in a network
with very long valid lifetimes.

You may want to look at RFC4242 and see if it help. Perhaps referencing
it and saying that clients that implement 4o6 MUST use information
refresh time option as well. Just to be clear - I'm not saying that you
really should do this. Just consider it and see if it solves the problem.

More specific comments about the draft.

Abstract: This draft defines options, not (one) option.

Authors may consider changing terminology regarding a client
that supports both DHCPv6 and DHCPv4-over-DHCPv6. Current proposed
name is 'DHCP client'. Although the definition is presented in a
clear way, it is somewhat counter-intuitive. All other DHCP drafts/RFCs
assume that 'DHCP client' means a client that can be either
DHCPv4 client, DHCPv6 client or both. Perhaps a better name would
be "4o6 DHCP client"?

Section 4 could mention that DHCPv4 message is a special type of
BOOTP message.

Figure 1: Please make it explicit whether this is v4, v6 or 4o6 Relay
Agent.

"The server replies with a DHCPv6 response, which is a new DHCPv6
message called Boot-reply-v6." - That sentence is a bit odd. It would
sound better as "The server replies with Boot-reply-v6, which is
a new type of DHCPv6 message."

"If the client is configured to use DHCPv6 to obtain
its IPv6 configuration, the DHCPv6 server MAY include the DHCPv4
-over-DHCPv6 Enable Option in its Reply message to indicate that
client SHOULD use the DHCPv4-over-DHCPv6 protocol to obtain
additional configuration." That doesn't sound right. There's one
condition missing in this sentence. The client that supports
DHCPv4-over-DHCPv6, SHOULD request DHCPv4-over-DHCPv6 Enable Option by
sending its code in ORO.

"If a DHCPv6 server is configured to do so, it MAY send unicast
addresses of the 4o6 Servers to the client during the client's
configuration using DHCPv6.". This sentence missed "... and client
requested it in ORO".

"The unicast addresses are carried in the 4o6 Server Addresses Option
encapsulated in the Reply message". Please don't use word "encapsulated"
here. This word has special meaning in DHCP context (options
put inside other options). "included in the Reply message" sounds
better. And it should be "included in Advertise and Reply messages".

Section 5.1, BOOTREQUESTV6 and BOOTREPLYV6 descriptions. Please be
more explicit about which client you have in mind. This should be 4v6
DHCP client.

Section 5.2. I do not like introducing new message format. Why can't you
make flags a regular option? All DHCPv6 implementors have proven code
for parsing DHCPv6 messages. They use 2 formats: the regular one
(msg-type followed by options) and relay-forw/reply (msg-type,
hop-count, link-address, peer-address followed by options). It is
possible to introduce new formats, but there should be a very good
reason for that. I don't see one here.

Section 5.3. Why do you need to have 24 bits field if you use only
one bit? Do you envision so many additional flags to be defined, so
24 bits are necessary? I think you just assume that aligning msg-type
and flags to 32 bits boundary would look nice. It is on paper, but since
the options have various sizes, not necessarily divisible by 4, there
usually won't be any alignment.

A generic question to the WG about bit fields. What is your preference
for showing bit fields in an I-D? Should they be listed in most to least
significant or least to most significant order?

Section 5.4. Please add "and client MUST ignore its content". Do you
envision any flags to be defined at a later time in boot-reply-v6?
If not, consider dropping the flags field and just use regular message
format.

Sections 6.2 and 6.3 should say that server includes those options
if requested by client. Normative language is not necessary here,
because that behaviour is already defined in RFC3315, sections 17.2.2
and 18.2. You should add that client MUST not send either of those options.

Is it defined somewhere how to use content of the 4o6 Servers address
option? In particular, how to use more than one address? For example, if
there are 3 unicast addresses are sent, the client will send each DHCPv4
message in 3 copies, right? I'm fine with that, but it be mentioned
explicitly. And probably discussed in security considerations. What if I
set my rogue server that will announce 80 unicasts, with the same
address repeated? This will serve as a nice amplification attack, right?

Section 6.3 in its current form allows 0 addresses to be configured.
The wording should be improved to say something like "one or more
addresses".

There should be a discussion about a case when only 4o6 Server Address
option is provided, but not 4o6 Enable option. That is a configuration
error, but it should be explained that client MUST ignore 4o6 Server
Address option if 4o6 Enable option was not received.

Section 8: "A client MUST set the Unicast flag as specified in Section
7." I would rephrase that sentence. In its current form it may be
understood as "client must set th unicast flag always (as was specified
in 7)". It would be better to say "A client MUST follow rules defined in
Section 7 when setting Unicast flag.".

Section 9: Please remove this sentence " A DHCPv6 relay agent MUST
implement the Relay behaviour described in section 20.1.1 of
[RFC3315].". It does not add anything, this is a redundant statement.
Relay agent is by definition a node that fulfills requirements defined
in 3315, including section 20.1.1". If you really want to keep this
text, please write is without normative language. Something along the
lines of "Relay agent that supports 4o6 is a regular DHCPv6 Relay Agent
(follows all requirements specified in RFC3315), but also performs
additional functions."

Although it is not strictly necessary, I would add a clarification
sentence in bullet 1 in section 9 that the packet is relayed as normal
DHCPv6 (i.e. DHCPv6/UDP/IPv6) packet.

Are you sure that dhc-dhcpv6-unknown-msg is a normative reference?
I think it would be more appropriate to use informative reference, but
it won't object it you keep it as it is now.

ietf-dhc-dhcpv4-over-ipv6 is a reference that is not used in the text.
Please either use or remove it.

I have no further comments. This is a useful draft and I think it is
almost ready to move forward. Thank you for doing this work.

Tomek