[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [161.53.65.11]) 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 [127.0.0.1]) 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 ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (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 [91.208.233.27]) 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: Stjepan Groš <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 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.
- [mif] Proposal for circumventing Huawei IPR Stjepan Groš
- Re: [mif] Proposal for circumventing Huawei IPR Terry Manderson