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

From: Marcin Siodelski <[email-masked]>
Date: Tue, 3 Nov 2015 10:04:51 +0900

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

---

From: tianxiang li <[email-masked]>
Date: Tue, 3 Nov 2015 14:48:27 +0800

Hi Marcin,

Thank you for your review and comments. Please see inline.

Regards,
Tianxiang

> that the issue and the solution is provided in the same section. See how

[TX] Yes, it would be better to put the problem statement and solution
together for each message, like in RFC7550. I will change the document
structure in the next version.

> to requesting router/delegating router terminology.

[TX] Agreed, will change "client" and "server" to "requesting router" and
"delegating router" respectively, to keep text unified with RFC3633.

> of this draft, which discusses the issues pertaining to prefix delegation.

[TX] Will change this text to"The Solicit message allows requesting routers
to ask delegating routers for prefixes and other configuration parameters."

> [TX] Here I think the text could be changed to:
If the requesting router includes just a prefix-length hint (zero prefix
value, and non zero prefix-length value), the delegating router should try
to honor the prefix-length hint.

If the requesting router includes a non-zero prefix and its prefix-length
value, the server should first try to provide the requested prefix. If the
prefix is unavailable, then the server should try to provide a prefix
matching the requested prefix-length value.

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

[TX] I think having two state machines is something that RFC7550 tries to
avoid. So here maybe the text should be: If the client also Solicited for
IA_NAs, the client should accept the IA_NA addresses and continue to
request for the desired IA_PD prefix during Renew/Rebind as specified in
[RFC7550].

Another option would be to not discuss this issue here, since it's already
mentioned in RFC7550.

> The RFC7550 solves those issues already by allowing to accept some
> bindings and continue

> request another one is probably not a good idea.
[TX]Changing the IAID is a way of requesting for a new prefix, but it
requires stable storage of the requesting router device, since rebooting
the device would cause it to use the original IAID on the IA_PD, and then
it might get back the original prefix, if the original prefix hadn't been
released or expired.

I think maybe both solutions could be listed in the text, and discuss which
one could be used during what situation?