DHCPv6 no response to Confirm behavior

[jvfranklin]

Roy, src/dhcp6.c has this comment in dhcp6_failconfirm():
/* RFC8415 18.2.3 says that prior addresses SHOULD be used on failure. */
dhcp6_fail(ifp, false);

I've been testing dhcpcd against the IPv6 Ready Logo certification tests for our product, and have some patches I'm preparing to submit a PR for. One of my changes is for this code in question.

The RFC does say "should" but the requirements for the test basically make it a "must" that the prior lease be used on failure, so for our product, at least, I've got it patched to call dhcp6_bind instead of dhcp6_fail.

Is this change something you'd like to accept into the main stream? If not, that's fine, I won't include it. I personally don't think these tests should be making "shoulds" into "musts" but that's a discussion we'd have to have with the test writers...

[rsmarples]

Many years ago dhcpcd underwent IPv4LL certification testing as well. Had the same issue. My response is generally "I look forward to implementing your published RFC errata" which never happens. I say generally because everything is open to interpretation and I'm not that unreasonable.

Anyway, on this particular topic I think the code will stay as is. Rationale:

• If the link has remained UP and has negotiated a prior lease while dhcpcd stays up and CONFIRM fails then they keep the existing lease until it naturally expires.
• If the link was DOWN or dhcpcd is just starting and dhcpcd CONFIRMs the prior lease and CONFIRM fails then they don't get to keep the prior lease, it's discarded.

So dhcpcd goes both ways, depending on state. More rationale: Part of the state would be DNS servers. If dhcpcd has never verified they belong to the attached network, why should they be used? If it's a different network it's more of a hinderance trying to reach unreachable DNS servers than immediately failing.

[jvfranklin]

I can see good arguments for both sides, really. It's a failure mode, so there's naturally going to be differences of philosophy. For us, at least, our product normally lives in data centers or at least is pretty stationary, so reusing the lease seems to be the best choice. I have no problem keeping that particular patch for ourselves, though.

[rsmarples]

You can always submit a patch to enable the path if DHCPCD_LASTLEASE_EXTEND has been set.
I mean, it's effectively the mirror of the non standard DHCP behavior we have.

[jvfranklin]

Yeah, that makes sense to me. I think I'll do that. I'm not sure if it'll cause issues with any of the other IPv6 Ready Logo tests, but I tried it with a few that I thought might, and it seems to be ok. Actually, would it be better to use DHCPCD_LASTLEASE? Seems like the description for that is more in line with what I'm trying to do here...

[jvfranklin]

@rsmarples, question for you: Instead of DHCPCD_LASTLEASE_EXTEND would it be better to use DHCPCD_LASTLEASE?

[rsmarples]

@jvfranklin it would be better to use DHCPCD_LASTLEASE