[kea-dev] Support for RFC7550 in kea

[Marcin Siodelski]

Hi,

During the hackathon at IETF 93 I have implemented the support for RFC7550.
This document updates the RFC3315 and RFC3633 and fixes several issues
around coexistence of the IA_NA and IA_PD in messages from a single client.

Suppose the case when the client (being also a requesting router) wants
to obtain both address(es) and prefix(es). It will perfom the 4-way
exchange and include both IA_NA and IA_PD options in the Solicit and
Request. If the server is only configured to assign addresses and not
prefixes it will send the NoPrefixAvail status code in the Advertise and
Reply. This part is covered in the RFC3315 and RFC3633.

The client enters the 'bound' state in which it sends Renew every T1
time. The client may still be interested in obtaining the prefix while
it renews addresses obtained. What the client can do per RFC7550 is to
include an empty IA_PD in the Renew message (apart from the IA_NA) to
signal that it is still interested in a prefix. If the server can't
allocate the prefix it will respond with the IA_PD and include the
NoPrefixAvail status code. Both, the ability by the client to request
prefix delegation in Renew (and Rebind) and the ability by the server to
include NoPrefixAvail is a new behavior introduced by the RFC7550.

Note that RFC7550 assumes that the server *may* be configurable to use
the new behavior. If the server is not configured to use the new
behavior it will do what is stated in the RFC3315 and RFC3633. And here
is the issue...

If the client has obtained an address but is interested in also
obtaining the prefix it will include the IA_PD in its message. The
server which is not configured to use the new behavior will respond with
the NoBinding in the IA_PD if the client has sent the Renew. But, if the
client sends the IA_PD in the Rebind message and the server is not
configured to allocate new prefix for the Renew/Rebind case, it should
drop the message per RFC3633. This is problematic because the server
will drop the message with a valid IA_NA! That was one of the reasons
why we have written RFC7550, because this behavior was broken in RFC3315
and RFC3633.

The question becomes, do we want Kea to have a configuration parameter
that allows for falling back to this original behavior (prior to
RFC7550)? I have implemented this parameter and I even have tests for
this. But, on reflection I tend to think that this switch should be
removed and the only supported behavior should be per RFC7550. The
reasons why:

- The code will be simplified, because it will not have to check which
behavior should be followed.
- The administrator will have less knobs, which may cause unexpected
behavior, to use.
- Even if the client is not updated to RFC7550 it should gracefully deal
with the NoAddrsAvail in the IA_NA and NoPrefixAvail in IA_PD. If they
don't, it means they are heavily broken. At the same time, you can't
guarantee that flipping this switch one way or another doesn't harm some
of your clients.
- The RFC7550 doesn't require the server to be backward compatible and
provide the configuration switch discussed here.
- The RFC3315bis (new spec for DHCPv6) will only support the new behavior.

What people think about it? Specifically, dropping the switch.

Marcin