[mif] Proposal for circumventing Huawei IPR

Stjepan GroŇ° <stjepan.gros@fer.hr> Thu, 17 March 2016 10:56 UTC

Return-Path: <stjepan.gros@fer.hr>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8D12D98F for <mif@ietfa.amsl.com>; Thu, 17 Mar 2016 03:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pYz-rKpVdkek for <mif@ietfa.amsl.com>; Thu, 17 Mar 2016 03:56:27 -0700 (PDT)
Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr []) by ietfa.amsl.com (Postfix) with ESMTP id 8E45A12D968 for <mif@ietf.org>; Thu, 17 Mar 2016 03:56:22 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.zemris.fer.hr (Postfix) with ESMTP id BE8643B7C063; Thu, 17 Mar 2016 11:56:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at zemris.fer.hr
Received: from mail.zemris.fer.hr ([]) by localhost (mail.zemris.fer.hr []) (amavisd-new, port 10024) with ESMTP id Ge-P-n0NfRdz; Thu, 17 Mar 2016 11:56:17 +0100 (CET)
Received: from w540.sistemnet.local (unknown []) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 477173B7C061; Thu, 17 Mar 2016 11:56:17 +0100 (CET)
To: "mif@ietf.org" <mif@ietf.org>
From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= <stjepan.gros@fer.hr>
Organization: UNIZG - FER
Message-ID: <56EA8D49.7040902@fer.hr>
Date: Thu, 17 Mar 2016 11:56:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XJst67jPpwRuIuqTWFG7masgWLh580PQS"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/NoBT2O-k40ce2-w7LeQN1JddKtE>
Subject: [mif] Proposal for circumventing Huawei IPR
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2016 10:56:33 -0000

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

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.


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).


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.