Re: [dhcwg] Alvaro Retana's No Objection on draft-ietf-dhc-v6only-06: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Alvaro,

Thanks for your comments!

On Tue, Aug 11, 2020 at 6:50 AM Alvaro Retana via Datatracker
<[e-mail]> wrote:
> I have several comments that I believe are borderline DISCUSS-worthy because
> collectively they result in the specification not being clear.  However, I have
> decided to ballot No Objection because none of them individually raise to the
> same level.

Let's see if I can address them ;)

> (1) From the Introduction:
>
>    If hosts were to delay requesting IPv4 until IPv6 reachability is
>    confirmed, that would penalize IPv4-only and dual-stack networks, which
>    does not seem practical.
>
> The mechanism specified may delay the IPv4 process for at least
> MIN_V6ONLY_WAIT; 5 minutes is a very long time, and it seems longer than "until
> IPv6 reachability is confirmed".  I would like to see the document include
> operational considerations related to the practicality of implementing the new
> functionality.  Given that the operation (in §3.2) is only recommended ("SHOULD
> stop the DHCPv4 configuration process for at least V6ONLY_WAIT"), the
> considerations should include guidance on the tradeoffs, including initial
> setup.

To be honest I'm a bit confused there. The paragraph you quote
explains why DHCPv4 shouldn't be delayed until the host confirms IPv6
reachability.
The proposed mechanism allows the host to start DHCPv4 right away and
to receive an explicit signal about IPv6 reachability inband while
performing DHCPv4. As a result the issue described in that paragraph
you quote is addressed.
The section 2 (https://datatracker.ietf.org/doc/html/draft-ietf-dhc-v6only-06#section-2)
, especially the second paragraph discusses the benefits of the
proposed solution.
I'm happy to add more text but I'm not sure what shall be addressed there..

> (2) §3.2: What is a "network attachment event"?  Is that defined somewhere?  I
> looked at rfc2131 but didn't find the definition there.  A "network
> disconnection event" is mentioned later...same question.  Both sound like
> physical events to me (connect/disconnect).

Benjamin has made the same point and it will be addressed in -07:
"network attachment event" will be used consistently across the
document.
Re: the strict definition of what the network attachment event is..
I've checked rfc4957 and rfc4135 and surprisingly that term is not
explicitly defined.

We might add to the Terminology section something like:
"network attachment event: established a new link-layer connection
over the given network interface".
However..I'm a bit concerned about inventing an explicit definition in
this document. There is a risk of coming up with a definition which
would be different from what some existing implementations assume.

> (3) §3.2: What is the difference between these two actions: "the
> client...SHOULD stop the DHCPv4 configuration process or disable IPv4 stack
> completely"?  Are they defined anywhere?  I have an intuition of what the
> actions mean, but given that they are attached to normative language, it would
> be ideal if the operation was clear to everyone.

I'm not sure we shall be defining what 'stop the DHCPv4 configuration
process' means as it would be implementation dependent.
Re: 'disable IPv4 stack': would the following text in the Terminology
section address your concern:
'Disabling IPv4 stack on an interface: by disabling IPv4 stack on a
given interface the node does not send any IPv4 packets from that
interface, drop all IPv4 packets received on that interface and does
not forward any packets to that interface'
?
It would be in-line with the similar definition for disabling IPv6
operations given in
https://tools.ietf.org/html/rfc4862#section-5.4.5

> (4) [nit] s/MAY configure IPv4 link-local address/MAY configure an IPv4
> link-local address
>
> (5) [nit] s/specify V6ONLY_WAIT timer/specify the V6ONLY_WAIT timer

Fixed, thanks!

> (6) §3.3: The first paragraph makes configuration recommended/optional ("SHOULD
> be able to configure...MAY have a configuration option"), but the second
> paragraph requires an action based on that configuration ("MUST NOT
> include...if the YIADDR...does not belong to a pool configured...").  First of
> all, I believe these a Normative conflict: if the configuration is
> recommended/optional, then a required action can't rely on it.

If the server does not have a configuration knob or any other way to
configure $FEATURE, then it effectively means that $FEATURE is not
configured/enabled. Therefore normative language applies: for the case
when $FEATURE is not configured.
(Or it might be always enabled w/o an option to disable it, but I do
not expect it to be the case anytime soon for this particular
feature).

> Also, if the pools can't be configured, then it seems that the IPv6-only
> Preferred option would never be included.  Is that the expected behavior?  It
> seems to me that even if individual pools can't be configured, the use of the
> option could still be useful for all pools.

What we meant here is that DHCP servers SHOULD allow the administrator
to enable sending the option for a specific pool somehow. If it can be
done for one pool it can be done for all of them (if all network
segments served by this DHCP server provide IPv6-only connectivity).

Would the following change address your concern:
OLD TEXT:
---

The DHCPv4 server SHOULD be able to configure certain pools to
   include the IPv6-only preferred option in DHCPv4 responses if the
   client included the option code in the Parameter Request List option.
---
NEW TEXT:
---

The DHCPv4 server SHOULD be able to configure all or individual pools to
   include the IPv6-only preferred option in DHCPv4 responses if the
   client included the option code in the Parameter Request List option.
---
?

> (7) §3.3: "The server SHOULD NOT assign an address for the pool.  Instead it
> SHOULD return 0.0.0.0 as the offered address.  Alternatively, the server MAY
> include an available IPv4 address from the pool into the DHCPOFFER as per
> recommendations in [RFC2131]."
>
> What are the conditions under which the server would select to assign an
> address?  The initial two sentences recommend not doing it.

Let me explain some background here - this text is a result of a
centi-thread on the dhc WG list.
Long-term it would be much cleaner and more desirable for the server
to respond with 0.0.0.0 - therefore SHOULD here.
However there are two issues with this:
- it would require the server change. I can not deploy this option
until my DHCP server code is updated - which would delay the adoption
significantly. If we allow the server to return a normal IPv4 address
- I can deploy it right now (well, I'm in process actually).
- there is evidence that some intermediate devices are not happy with
0.0.0.0 in the DHCPOFFER. While it's a bug - it would block the
adoption.
So the goal here is to describe the ideal behaviour as 'SHOULD' while
still allowing the currently deployable scenario as MAY.

So the choice is left to the server implementation. I do not think
it's unusual to say 'the implementation SHOULD do $X but it MAY do $Y
instead'.

> (8) §3.3: "...the server MAY include an available IPv4 address from the pool
> into the DHCPOFFER as per recommendations in [RFC2131].  In this case, the
> offered address MUST be a valid address that is not committed to any other
> client.  Because the client is not expected ever to request this address, the
> server SHOULD NOT reserve the address and SHOULD NOT verify its uniqueness."
>
> rfc2131 already contains a similar recommendation as "the server SHOULD NOT
> reserve", but without using normative language ("Servers need not reserve the
> offered network address, although the protocol will work more efficiently if
> the server avoids allocating the offered network address to another client.").
> It seems to me that the recommendations from rfc2131 already cover the
> reservation case and don't need to be repeated.

I read 'need not reserve but it would be better if it does' more like
a 'the server SHOULD reserve' (...but it MAY not) so we are actually
saying something slightly different from RFC2131 here.
If we do not say 'the server SHOULD NOT reserve the address' any
implementation which by default does the reservation, would continue
reserving addresses which would be undesirable.
IMHO this sentence makes it clearer for implementers what they shall do.


> OTOH, "SHOULD NOT verify its uniqueness" seems to contradict what rfc2131
> recommends: "When allocating a new address, servers SHOULD check that the
> offered network address is not already in use".  I'm assuming that being unique
> and "not already in use" are equivalent.

That's why we have this text: while RFC2131 recommends reserving
addresses and is saying that the server SHOULD verify the uniqueness,
it does not make it mandatory by using 'MUST', so it means that 'there
may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.'(c)
Offering an address from the pool with IPv6-only Preferred option is
exactly the case when it makes total sense to:
1) not reserve the address;
2) do not verify the uniqueness.

So the draft makes it explicit for the implementers.

> (9) §3.3.1: [nit] s/on IPv6-mostly network/on an IPv6-mostly network

Fixed.

-- 
SY, Jen Linkova aka Furry