Subject: [mif] Proposal for circumventing Huawei IPR

From: Stjepan Groš <[email-masked]>
Date: Thu, 17 Mar 2016 11:56:09 +0100

Hi everyone,

here is the proposal on how to circumvent Huawei's IPR claim so that we
are able to use DHCP for what it was designed for, node configuration.
As an added bonus, we also solve the problem of multiple concurrent DHCP
servers on a single local network.

First, let me state few assumptions:

1. The alleged problem with Huawei's IPR claim is that it includes an ID
in DHCP server's response and for that reason this group abandoned the
approach.

2. In the talks about the exact format of ID there were suggestions to
use only UUID. Based on my experience while implementing PvD support in
NetworkManager (https://github.com/sgros/MIF_NetworkManager) this is
good approach because it simplifies things a lot.

3. DNS can be used for service discovery, but other mechanisms (and
descriptions) should be allowed as well. Additionally, service
description should include reachability definitions.

4. ID is used only for identification purposes of some specific PvD, and
possibly as a parameter in a service discovery (even though DNS approach
doesn't do that, but e.g. HTTP approach might).

So, what I propose is NOT to send ID in responses but only a container
option with a set of options that belong to a single PvD instance. ID is
then calculated based on the PvD parameters, e.g.

MD5(NETWORK_PREFIX, NETWORK_PREFIX_LEN, DNS_SERVERS, DNS_DOMAINS)

Concrete set of options/parameters is to be determined but it is
intention to uniquely identify PvD, not PvD instance. In this way client
will be able to distinguish PvDs, and if necessary client and server
will agree on unique PvD ID for each PvD.

Few additional notes/comments:

1. This can be calculated for implicit, as well as explicit PvDs. Note
that in the mentioned implementation I was using this approach to try to
differentiate implicit PvDs sent in RA messages.

2. Part of PvD CO option might be an option that specifies how to do
service discovery. This would allow flexibility. This option should also
be included in ID computation.

3. For an added flexibility (if its really needed as it complicates
things!) PvD CO option might specify which options to include or not
include in the calculation of ID.

4. After node learns about some PvD it can request specific PvD by
including its calculated PvD ID in request. The response will be without
ID, obviously! Huawei IPR claim doesn't cover this case.

5. This would solve the situation of multiple DHPC non-PvD aware servers
on a local network. By calculating ID of each reposnse client can
determine if those responses are alternative (failover) or concurrent
and react appropriately. The same mechanism might be used for RA messages.

6. The approach will work for local network configuration (PvD specific
for a certain local network) as well as for PvD's specific for
providers' global networks (i.e. sending "video only" PvD to all its
customers that are on different IPv6 subnetworks).

SG

P.S. Just as a note, I use of two distinct terms "PvD" and "PvD
instance". "PvD instance" includes specific host information like
concrete IP address, while "PvD" is a set of "PvD instances" valid on a
certain network. To even better describe the difference, it should be
noted that RAs send PvDs, while DHCPv4/DHCPv6 resposnes send PvD instances.

---

From: Terry Manderson <[email-masked]>
Date: Fri, 18 Mar 2016 00:55:05 +0000

Stjepan and All,

As the responsible AD I would like this thread to stop here.

A Working Group can either choose to accept (by rough consensus)
technology that is encumbered by IPR or not accept that technology. Once
rough consensus is reached on an IPR disclosure, all WG participants are
expected to abide by that in dealing with the encumbered technology in the
WG.

The WG reached rough consensus in November 2015 to drop
draft-ietf-mif-mpvd-dhcp-support
(https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt) with the
IPR claim at https://datatracker.ietf.org/ipr/2648/

Any participant may suggest new alternative technologies for the WG to
consider via the known methods.

Cheers
Terry

On 17/03/2016, 8:56 PM, "mif on behalf of Stjepan Groš"
<[email-masked] on behalf of [email-masked]> wrote:

>are able to use DHCP for what it was designed for, node configuration. As
>an added bonus, we also solve the problem of multiple concurrent DHCP
>NetworkManager (https://github.com/sgros/MIF_NetworkManager)
> this is good approach because it simplifies things a lot.
>
>will be able to distinguish PvDs, and if necessary client and server will
>agree on unique PvD ID for each PvD.
>
>determine if those responses are alternative (failover) or concurrent and
>react appropriately. The same mechanism might
> be used for RA messages.
>
>for a certain local network) as well as for PvD's specific for providers'
>global networks (i.e. sending "video only" PvD to all its customers that
>are on different IPv6 subnetworks).
>
>SG
>
>certain network. To even better describe the difference,
> it should be noted that RAs send PvDs, while DHCPv4/DHCPv6 resposnes
>send PvD instances.