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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 10 Aug 2020 13:49:57 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-dhc-v6only-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

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

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

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

(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

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

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.

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

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

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.

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

---

From: Jen Linkova <[email-masked]>
Date: Tue, 11 Aug 2020 15:06:38 +1000

Hi Alvaro,

Thanks for your comments!

> decided to ballot No Objection because none of them individually raise to the

Let's see if I can address them ;)

> considerations should include guidance on the tradeoffs, including initial

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

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

> 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

> (5) [nit] s/specify V6ONLY_WAIT timer/specify the V6ONLY_WAIT timer

Fixed, thanks!

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

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

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

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

> 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

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 11 Aug 2020 11:33:36 -0700

On August 11, 2020 at 1:06:50 AM, Jen Linkova wrote:

Jen:

Hi!

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

Maybe I'm the one confused. :-)

Sure, the start of the DHCPv4 process is not delayed, but the process
is then stopped.  In both cases the ability to use IPv4 is delayed...

In your answer you mention "receive an explicit signal about IPv6
reachability inband".  I see (now) where that is mentioned (in §2),
but the text is not explicit about what that signal is, and the only
effect seems to be to turn off IPv4.  I can see how if IPv6 starts
working there *may* be no issues, but if that signal is not received
then we're still waiting -- which results in that it "would penalize
IPv4-only and dual-stack networks".

> I'm happy to add more text but I'm not sure what shall be addressed there..

It seems to me that the solution suffers from the same downside as an
initial delay of DHCPv4: "would penalize IPv4-only and dual-stack
networks, which does not seem practical."  Given that the
specification is not required (only SHOULD is used), then I would like
so see operational recommendations about when it makes sense to use
the mechanism and when it doesn't.

This may end up being as simple as: using this specification in
IPv4-only and dual-stack networks will result in a delay on the
ability to use IPv4 in the network...  Or something like that.

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

One of the places the terminology is used is (from §3.2):  "The client
SHOULD stop the DHCPv4 configuration process for at least V6ONLY_WAIT
seconds or until a network attachment event happens."

What does "a new link-layer connection" mean?  My interpretation is
that the link-layer is layer 2...so that would mean a new L2
connection...which doesn't make much sense since the interface is
already up and the link-layer is already operational.  I'm assuming
that we're not interpreting link-layer the same way.

Instead of a new definition it might be better to clearly state what is meant.

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

To stop the process is probably more straightforward, so no need to
add anything.  The definition for disabling looks good to me.

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

Sorry, my concern is a little more granular.  The full text is this:

   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.
   The DHCPv4 server MAY have a configuration option to specify
   V6ONLY_WAIT timer for all or individual IPv6-mostly pools.

   The server MUST NOT include the IPv6-only Preferred option in the
   DHCPOFFER or DHCPACK message if the YIADDR field in the message does
   not belong to a pool configured as IPv6-mostly.

The text refers to configuring and acting on specific pools (vs global).

To your point about global configuration.  If $FEATURE is enabled,
what is the default?  I think that is the part missing; if the default
is that all the pools are considered IPv6-mostly, then I have no
issues with the text.

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

I would prefer an explicit default...but this works for me too.

> > (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]."
> >

Thanks for the history.

> it's unusual to say 'the implementation SHOULD do $X but it MAY do $Y

Right, it is not unusual.  I still feel that the specification would
be better if some guidance was provided ("if you haven't upgraded your
server, or have the 0/0 bug...").  I'll leave it up to you. :-)

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

Ok, I understand.

> > offered network address is not already in use". I'm assuming that being
> > unique and "not already in use" are equivalent.
>

Ok.

Thanks!!

Alvaro.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2020 17:08:07 -0400

>> collectively they result in the specification not being clear.

It seems like you should have just ballotted DISCUSS then :-)

    > explains why DHCPv4 shouldn't be delayed until the host confirms IPv6

I was also confused by your comments.
How can we make the text not-confuse here?  We are probably too close to the
text to come up with a useful answer.

    > I've checked rfc4957 and rfc4135 and surprisingly that term is not

I was going to say that we had an entire WG on this topic.
DNA == Detecting Network Attachment.

RFC4135, says in it's abstract:
         In
   this memo, this procedure is called Detecting Network Attachment
   (DNA).

RFC4957 is titled:
   Link-Layer Event Notifications for Detecting Network Attachments

But, it is true, "network attachment event" is not specified as a term.
I suggest we ask 6man and v6ops if we should use a different term,
or if this term is clear enough.  I can do that later tonight if this is useful.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2020 17:21:11 -0400

> 0.0.0.0 in the DHCPOFFER. While it's a bug - it would block the

Specifically, that it DHC relays built-in to switching and routing products
are inspecting this return value and doing stuff like linking L2 and L3
addresses together, or other special sauce.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jen Linkova <[email-masked]>
Date: Wed, 12 Aug 2020 08:08:04 +1000

> is then stopped.  In both cases the ability to use IPv4 is delayed...

But the process  is only stopped if the administrator configures the
network to provide Ipv6-only capabilities.

> IPv4-only and dual-stack networks".

I'm afraid there is some confusion here.
If the network is IPv4-only or just a dual-stack (== no IPv6-only
capability), then the signal (IPv6-only option) will NEVER be received
from the server. So if the network is not supposed to have IPv6-only
clients, then DHCPv4 would work as usual.
The Section 2 says: "If the network does not support IPv6-
only/IPv4-on-demand mode, an IPv6-only capable host would configure
   an IPv4 address as quickly as on any other host."

> ability to use IPv4 in the network...  Or something like that.

If the client sends this option while connecting to an IPv4-only or
dual-stack network, there will be no delay as the server would not
return the option:
"The server MUST NOT include the IPv6-only Preferred option in the
   DHCPOFFER or DHCPACK message if the YIADDR field in the message does
   not belong to a pool configured as IPv6-mostly.  The server MUST NOT
   include the IPv6-only Preferred option in the DHCPOFFER or DHCPACK
   message if the option was not present in the Parameter Request List
   sent by the client."

> that we're not interpreting link-layer the same way.

It does make perfect sense actually. If the client stays connected to
the network, it keeps DHCPv4 disabled for V6ONLY_WAIT seconds. However
if the client gets reconnected to the network, it shall start DHCPv4
right away (as it can not know if it's reconnecting to the same
network or not) instead of waiting for the V6ONLY_WAIT timer to
expire. So we are using 'network attachment' in the same way as
rfc4957 and rfc4135. We had the whole WG
(https://tools.ietf.org/wg/dna/charters) for this.

While neither rfc4957 nor rfc4135 contain a formal definition of
'network attachment event', the DNA charter talks about 'underlying
link layer (L2) connectivity changes' so I guess the definition I
propose ('network attachment event: established a new link-layer
connection over the given network interface") makes sense for the
purpose of this draft.
What do you think?

> Instead of a new definition it might be better to clearly state what is meant.

It does not look like we have a formal definition. So if we say
'network attachment event means $X' we'll be inviting a new
definition. Unless we say smth like 'network attachment event term is
used in the same way as it's used in  rfc4957 nor rfc4135' However
there is a catch here: both of those RFCs are informational.

> The text refers to configuring and acting on specific pools (vs global).

if the administrator knows that all network segments provide IPv6-only
capability, each and every pool on the server can be configured in
that way.

> is that all the pools are considered IPv6-mostly, then I have no

I'm not sure what we mean by 'default' here.
For each pool configured on the server:
   -- the specific pool is either configured to include the IPv6-only
preferred option in DHCPv4 responses if the
   client included the option code in the Parameter Request List
option or it is not configured that way.
Think about it as a bool value in the config file for the specific
pool. 'respond_with_option_108 = true'.

Is your question 'what shall be default value for that config variable
for all implementations, if the administrator does not explicitly
specify it for the pool'?
In that case I'd say that we shouldn't be defining it in this
document. Right now for most implementations it would be reasonable to
have it set to 'false'.
However overtime as we see more and more networks moving to IPv6-only
mode there is no reason to prevent some DHCP servers to be shipped
with that set to true. I do not think it's going to happen any time
soon but I do not see any reasons to prohibit it in the RFC.

Or am I missing the point of your question?

> server, or have the 0/0 bug...").  I'll leave it up to you. :-)

How about:
"Alternatively, if offering 0.0.0.0 is not feasible due to some
limitations, the server MAY include an available IPv4 address from the
pool into the DHCPOFFER as per recommendations in <xref
target="RFC2131"/>.'?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2020 18:30:03 -0400

> message if the option was not present in the Parameter Request List

And to be clear, not returning the option is the defined action for options
that servers do not understand.  We are just beating people over the head here.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 12 Aug 2020 08:33:13 -0700

On August 11, 2020 at 6:08:16 PM, Jen Linkova wrote:

Jen:

Hi!

First of all, thanks for the explanations and education!

The points that I'm bringing up come from a perceived lack of clarity.
After the exchange that we've had, it is evident that my perception is
due to a lack of expertise in the operational aspects.  Instead of
fumbling around trying to explain and insisting on adding text to make
me happy, I'll defer to you/AD to make any changes you consider
appropriate.  While I believe that RFCs should be accessible to a
broad audience, it is unnecessary to lengthen this discussion. :-)

Just one comment below. ;-)

Thanks!

Alvaro.

...
> pool into the DHCPOFFER as per recommendations in > target="RFC2131"/>.'?

s/is not feasible due to some limitations/is not feasible in the local network
"some limitations" sounds too vague to be normative.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 13 Aug 2020 16:58:30 +1000

> broad audience, it is unnecessary to lengthen this discussion. :-)

Thank you for your feedback! It's always very helpful to get someone
fresh to review the document and test its readability..
We'll discuss how we can make the document easier to understand.

> "some limitations" sounds too vague to be normative.

Actually -07 currently says:
'Alternatively, if offering 0.0.0.0 is not feasible, for
   example due to some limitations of the server or the network
   infrastructure, the server MAY include an available IPv4 address from
   the pool into the DHCPOFFER as per recommendations in [RFC2131].'

I hope that sounds better.