Subject: [hackathon] DHCPv6 Stateful Issues (RFC7550) on Hackathon at IETF93

From: Marcin Siodelski <[email-masked]>
Date: Mon, 13 Jul 2015 16:42:55 +0200

Hi All,

Bernie Volz, Tomek Mrugalski and myself are interested in testing and
advancing the server implementations of the RFC7550. This RFC updates
the core DHCPv6 specification (RFC3315), to address issues related to
the co-existence of multiple stateful DHCPv6 option types. One of the
common use cases is when the CPE is requesting both IPv6 address
assignment and the prefix delegation (multiple leases) from the DHCPv6
server.

The DHCPv6 implementations which we are going to test are:
- prototype Cisco Prime Network Registrar server
- prototype Kea DHCPv6 server (http://kea.isc.org/)

both of which support RFC7550. We will try to patch the servers on-site,
as we test them.

We're going to use the following DHCPv6 clients:
- Dibbler (http://klub.com.pl/dhcpv6/)
- isc-dhcp (www.isc.org)
- Windows 7 client
- And also one or more testing clients (not 'real' clients), specially
crafted for testing purposes.

We will use these clients to test some scenarios (provided below) on the
server side. We will also verify if the clients properly handle servers'
responses. However, we are aware that these clients haven't been updated
to fully support RFC7550 and we may need to
manually examine received traffic using wireshark, to determine if the
servers' responses are correct.

One of the major changes introduced by the RFC7550 is the ability of the
client to request the assignment of new leases while renewing existing
leases. For example: the CPE may be interested in obtaining a prefix and
an address from the server, but the server is not configured to delegate
prefixes at this time. The server may assign an address initially but
refuse to allocate a prefix. If the client can operate without the
prefix (perhaps with limited capabilities), it may keep requesting the
prefix assignment while it renews the lease for the address obtained.
The server will assign the prefix when it is configured to do so, or
when the prefix becomes available as a result of being released by
another client (requesting router). We'd like to make sure that the
servers provide this capability and test some corner cases like:

- running out of the address or prefix pool, in which case server should
signal NoAddrsAvail or NoPrefixAvail
- both address and prefix delegation disabled for the client,
- enabling prefix delegation after temporarily disabling it,
- disabling the capability altogether and making sure that the
server falls back to the original behavior (per RFC3315).
- etc.

The RFC7550 mandates that the DHCPv6 server assigns the same "renewal"
timers for the leases provided to the client, so as the client renews
all its leases at the same time. This facilitates renewing leases in a
single transaction (using a single DHCPv6 message), rather than renewing
each lease individually. We'd like to make sure that the DHCP servers
follow this rule, and whether there are any circumstances when they
don't (e.g. as a result of some unintended misconfiguration).

The RFC7550 introduces important changes to the placement of "status
code" option within the DHCPv6 messages. We want to make sure that the
servers follow the given behavior in various cases, but it may also be
interesting to see if the clients deal with this properly. We will use
common DHCP client implementations like isc-dhcp.

There are also other cases from the RFC7550 that we are going to test.

See you there!

Marcin