[dhcwg] Review of the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-01

[Marcin Siodelski <[e-mail]>]

Hello,

I have read the version -01 of the document. It is important to clarify
the behavior of the requesting/delegating router behavior with respect
to prefix-length hints.

A couple of comments below.

The document is structured in a way that makes it hard to match the
issues with the solutions for them. For example: section 3.1 focuses on
issues in handling prefix length hint in case of the Solicit. It doesn't
provide a solution, though. The solution is provided in section 4.1,
i.e. a couple of sections down the road. This makes me scroll back and
forth to find out "how did they deal with this problem?". I'd suggest
that the issue and the solution is provided in the same section. See how
RFC7550 is structured.

Abstract

"DHCPv6 Prefix Delegation [RFC3633] allows a client to include a
   prefix-length hint value in the IA_PD option to indicate a preference
   for the size of the prefix to be delegated..."

According to the terminology used in RFC3633, the "client" is referred
to as "requesting router". Admittedly, when we merged the RFC3633 into
the RFC3633 into RFC3315bis we unified the terminology and we also refer
to the node having a function of requesting router as a client. However,
since this document refers to the RFC3633, it would be better to use the
original terminology in the abstract and then mention that further in
this document whenever the "client" term is used it refers to the
requesting router. On the other hand, if the document will not be
incorporated into the RFC3315bis, perhaps it is simply better to stick
to requesting router/delegating router terminology.


3.1.  Creation of Solicit Message by the Client
 "The Solicit message allows a client to ask servers for addresses and
   configuration parameters."

It is a bit odd that addresses are specifically mentioned in the context
of this draft, which discusses the issues pertaining to prefix delegation.

4.1. Creation of Solicit Message by the Client

" When the client wants the same prefix back from the server, it should
   include the prefix value in the "IPv6 prefix" field of the IA_PD
   Prefix option, and the length of the prefix in the "prefix-length"
   field.  This is an indication to the server that the client wants the
   same prefix back."

At this point there is a possibility that the lease that the client
remembers and which it includes in the hint is not available anymore.
Perhaps it has been allocated to another requesting router. Therefore
the server considerations in 4.2. could be a bit more specific what to
do in such case. The section 4.2. currently says that the server should
try to provide a prefix of a specific length, regardless of the prefix
recorded from previous interactions. In fact, if the requesting router
is sending a non-zero prefix as a hint the server could try to allocate
this prefix in the first place. If it is unavailable, it should use the
prefix length hint and use that to allocate a different prefix.

4.3. Receipt of Advertise Message by the Client

This text should be revised against the RFC7550. The text currently
recommends that the client, unsatisfied with prefixes provided, should
do Solicit but use the IA_NAs with available addresses. First of all,
this section discusses Advertise message processing when the server
hasn't committed addresses for the client, so technically the client
can't use them until it does Request-Reply. Also, doing Request-Reply
(and then Renew) for IA_NAs and Solicit for IA_PDs at the same time,
requires two state machines on the client side. The RFC7550 solves those
issues already by allowing to accept some bindings and continue
requesting other bindings in the Renew/Rebind. This section should
probably refer to RFC7550 to describe the case when the client doesn't
get the prefixes it is satisfied with.

4.4. Creation of Renew/Rebind Message by the Client

The client willing to obtain another prefix would typically include a
different IA_PD (with different IAID). The IA_PD may contain no prefix
option or it may contain a prefix option with a prefix-length hint.
Again, see RFC7550. Using the same IA_PD to renew existing prefix and
request another one is probably not a good idea.

Marcin