Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

["H. Peter Anvin" <[e-mail]>]

On 05/02/16 10:57, Bernie Volz (volz) wrote:
> Jinmei:
> 
> Here's I think a simple example ...
> 
> Requesting router solicits for a /56.  Delegating router has none to
> offer (perhaps temporary issue or the configuration doesn't currently
> allow). So, delegating router returns a /60. The requesting router
> uses this.
> 
> Now, it does periodic renewals. If it just sends the delegated-prefix
> (/60) in the IA_PD, the server will keep renewing this. Since the
> delegating router has no other information.
> 
> The current RFC3633 never says that the requesting router should
> continue to include a ::/56 as a hint in the renewal (though it also
> doesn't prohibit it).
> 
> Thus, even if the delegating router is reconfigured (or the temporary
> issue is resolved), the requesting router would continue to use the
> /60 (perhaps not being able to operate fully). Yet, if the requesting
> router included the ::/56 as a hint (in addition to the /60
> delegated-prefix), the delegating router COULD assign it a /56 when
> it was able to.
> 
> There's also a separate issue of if the requesting router where to
> Solicit (and say for the /56 hint), should the server abandon the /60
> that it might still have leased or prefer a /56 (or something shorter
> than a /60 it has)? That might be less of an issue for this case as
> that would generally just be up to the server's policy (as to how
> strong the hint it treated).
> 
> To handle the case I mentioned above, we did resort in our server to
> remembering the hint the client provided during the Solicit so that
> we can re-evaluate as to whether to keep renewing the current
> delegated prefix or re-evaluate whether we had something "better" to
> offer the client.
> 
> Note that this works both ways - a delegating router might only have
> had a /56 to delegated when the client requested a /60, but that
> generally is a less interesting case because the requesting router
> can just use the longer prefix.
> 

Funny enough, I just went to this list with the explicit intent to ask
some of the questions that I believe this document ought to answer, but
quite frankly it doesn't look from my reading that it does.

I am concerned about client behavior personally, so this is from this
perspective.  This comes from my having written a patchset (which I need
to update) for ISC dhclient to do prefix requests.

My concern is when the ::/n prefix hint should be included.  My
assumption has always been that a single IA_PD always correspond to
prefixes that are to be configured together, whereas multiple IA_PD
delegations would mean prefixes for separate entities.  If this is NOT
the intent it probably needs to be clarified.

It is also worth noting that a server which receives requests for
multiple IA_PD delegations is free to aggregate those if appropriate,
although I have no idea if actual servers in the field do.  It is still
unclear to me if it would be better for the client to push multiple
IA_PD options upstream -- giving the server the option to delegate or
not delegate -- or if it should forcibly aggregate at the client level.

Bernie raises several of the same issues that I tripped over, not
surprising.


Now, what I think IS clear from the client point of view:

a) When creating a SOLICIT message, and there currently is no lease for
an existing prefix of the required length, the SOLICIT message SHOULD
include the ::/n hint for the desired prefix length.

b) When creating a SOLICIT message and there are prefixes which have
been used in the past, they SHOULD be included even if they are too narrow.

Thus, an IA_PD request might look like:

	2001:db8:85a3:2345::/64
	::/60

meaning "please give me a /60 if you can, otherwise please give me
2001:db8:85a3:2345::/64 [again]".


What I think is NOT clear from the client point of view:

a) When creating a SOLICIT message, and we have had at least one prefix
of sufficient length, SHOULD ::/n be included?  That is, should an IA_PD
request look like:

	2001:db8:85a3:7890::/60
	::/60

... or is the latter implied by the former, even if that specific prefix
is unavailable?  What is the request looks like:

	2001:db8:85a3:7890::/60
	2001:db8:85a3:2345::/64

b) Are there messages *other* than SOLICIT where the hint SHOULD get
included?

c) Whether or not the client SHOULD be encouraged to transmit a hint if
it has a *wider* prefix assigned than it needs?

[My feeling is that we want to encourage the client to send the hint for
the preferred prefix length, longer or shorer, in SOLICIT, RENEW and
REBIND messages unless servers in the field are known to malfuction that
way.]

d) If the client MUST/SHOULD to forcibly do aggregation or not, in the
case that it is OK for the client side to deal with multiple disjoint
prefixes.

[I suspect that current servers will not deal well with client
nonaggregation.]

e) If the client SHOULD or SHOULD NOT to respond to a narrower prefix
than requested by issuing a new request for multiple prefixes (via
multiple IA_PD options).

f) If there is ever a reason to NOT send a prefix hint?  Would that
implicitly mean ::/64, and if so, should that be documented?

	-hpa