[kea-dev] Support for RFC7550 in kea

[Thomas Markwalder]

On 7/28/15 6:57 AM, Marcin Siodelski wrote:
> 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
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
I vote for dropping the switch.  I do not see value in supporting the
original behavior.