Internet DRAFT - draft-sgros-dhcp-and-ipr-claim-analysis
draft-sgros-dhcp-and-ipr-claim-analysis
Internet Engineering Task Force S. Gros, Ed.
Internet-Draft L. Jelenkovic
Intended status: Informational D. Skvorc
Expires: May 26, 2016 University of Zagreb
November 23, 2015
DHCP configuration in MIF and associated IPR claim
draft-sgros-dhcp-and-ipr-claim-analysis-00
Abstract
The purpose of this draft is to analyze different options on how DHCP
can be used to configure PvD aware client. This is done in light of
IPR claim made by Huawei and the necessity to find an option for
implementation. In order for an option to be selected it obviously
must not interfere with IPR, or, IPR has to be somehow invalidated.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 26, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Gros, et al. Expires May 26, 2016 [Page 1]
Internet-Draft DHCP_and_IPR November 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Analysis of the IPR Claim made by Huawei . . . . . . . . . . 3
3.1. Detailed analysis of the protocol part . . . . . . . . . 4
3.2. Detailed analysis of the implementation part . . . . . . 6
3.3. Differences between the patent and draft-ietf-mif-mpvd-
dhcp-support . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 7
4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
At IETF94 MIF Working Group decided to abandon drafts written so far
and to wait for implementations that would serve as a basis for a new
drafts [MIFminutes94]. One of the problems was the IPR claim made by
Huawei [HuaweiIPRClaim].
This document has two purposes. The first is to identify the best
path to follow for the implementation of client configuration using
DHCP in a presence of multiple provisioning domains. The second is
to present analysis of the IPR claim made by Huawei in order to see
how it influences possible solutions. Since the licensing terms are
too strict it is mandatory to avoid conflict with the given patent.
This draft contains three core sections. In Section 2 the
requirements on the final solution are given. It is very important
to agree on those in order to have criteria on which different
solutions can be analyzed. Then, in Section 3 we do a thorough
analysis of the IPR claim made by Huawei and also we analyse how it
relates to the existing proposal. Finally, in Section 3 we present
different possibilities and analyze each one of them based on
requirements defined and IPR claim made by Huawei.
Gros, et al. Expires May 26, 2016 [Page 2]
Internet-Draft DHCP_and_IPR November 2015
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Requirements
The solution to be defined and used has to fulfill the following
requirements:
o No IPR claims. The solution MUST be free of IPR claims, or if
there are any IPR claims then they MUST be licensed in such a way
to allow unrestricted implementations without any fees.
o Backwards compatibility. The solution MUST be be backwards
compatible. This means that the old clients upon seeing messages
defined by the DHCP solution must ignore it and correctly function
without knowing for those messages.
o Efficiency of implementation. The solution SHOULD be as efficient
as possible for the implementation. This means, for example, that
messages defined by the final specification should be constructed
in such a way to make an implementation as simple as possible.
o Efficiency of communication. The solution SHOULD be as efficient
as possible for communication. This means, for example, that as
few messages as possible should be necessary in order for the
client to be fully configured.
3. Analysis of the IPR Claim made by Huawei
Before continuing a big DISCLAIMER. No lawyer has participated in
the development of the following text so you should take a note that
this is only an engineering view of a potentialy very complex
problem.
The IPR claim made by Huawei [HuaweiIPRClaim] is based on US Patent
#US20140344421 [US20140344421]. The abstract of a given patent
describes what is the patent about:
A method for configuring a DHCPv6 client is provided. The method
includes: a DHCPv6 client receiving a DHCPv6 advertisement message
sent by a network device having a DHCPv6 function, the DHCPv6
advertisement message comprising a management domain identifier of
the network device; if the DHCPv6 client does not save the
management domain identifier, the DHCPv6 client sending a DHCPv6
request message to the network device; the DHCPv6 client receiving
Gros, et al. Expires May 26, 2016 [Page 3]
Internet-Draft DHCP_and_IPR November 2015
a DHCPv6 response message sent by the network device and
completing configuration of the DHCPv6 client. A DHCPv6 client, a
network device, and a network system are also provided. Through
the technical solution, multiple network devices supporting a
DHCPv6 server function can configure the same DHCPv6 client, so as
to provide technical support for realizing IPv6 client and network
multi-homing.
In the given paragraph, there are two key informations:
1. The use of the term "management domain identifier".
2. The last sentence which places the mechanism described by the
patent into a context where it is used.
These two key parts are in direct correlation with the mechanism to
configure MPvDs as described in [I-D.ietf-mif-mpvd-dhcp-support].
Namely, "management domain identifier" is basically PvD_ID and the
last sentence describes multi-homing environment, which basically
MPvD is also. Note that "multi-homing environment" can be achieved
on a single network with multiple ISPs and multiple networks, each
with an ISP. The context of the patent is the former one, while of
the MPvD is the latter one. To see that the MPvD context is multiple
ISPs on multiple physical and/or virtual network one should take a
look at Section 4 of MIF Architecture Document [RFC7556]. This is
very important distinction.
In the following subsections we analyze separately two different
parts of the patent, protocol part and the implementation part.
Protocol part is the more important, but implementation is also very
important due to the patentability requirements
[algorithmspatentable].
3.1. Detailed analysis of the protocol part
Figure 1 in the patent claim describes scenario of client
configuration via DHCPv6 when patented configuration mechanism is
used. According to the given description the following sequence of
steps happens:
1. Upon client sending SOLICIT message, DHCPv6 server sends
ADVERTISE message. This message includes an option that defines
"management domain identifier". Additional rules are mentioned
later in the text concerning the SOLICIT message:
1. Paragraph [0045] says that client sends SOLICIT message but
_without_ an option "management domain identifier".
Gros, et al. Expires May 26, 2016 [Page 4]
Internet-Draft DHCP_and_IPR November 2015
Furthermore, judging by the [0045], DHCPv6 server MUST
include "management domain identifier".
2. In paragraph [0050] it says further that when client receives
SOLICIT message with previously unknown "management domain
identifier" then "the DHCPv6 client may send the DHCPv6
request message to the network device and store the
management domain identifier of the network device. The
DHCPv6 request message is adapted to request the network
device to configure the DHCPv6 client."
3. Then, paragraph [0046] contradicts paragraph [0045] by saying
that "management domain identifier" doesn't have to be
included. Yet, in that case the question is what makes so
special this patent from regular DHCPv6 exchange.
4. Also, in paragraph [0046] it says that the "management domain
identifier" defines to WHICH MANAGEMENT DOMAIN NETWORK DEVICE
BELONGS. According to this, "management domain identifier"
identifies some management domain and not a set of
configuration parameters that can belong to some management
domain. This is emphasised by explicitly saying that "...
management domain identifier may be a name of an ISP or a
name of an organization."
2. Client sends REQUEST message. There are few problems with the
description in this part:
1. There is ambiguity here as it doesn't specify weather client
sends "management domain identifier" option in REQUEST or
not.
2. It sounds like there is unfinished sentence here. Namely,
this part in the patent application says:
[0043] 104: The DHCPv6 client sends a DHCPv6 request
message to the network device and stores the management
domain identifier, when the client does not store the
management domain identifier.
Note the last part of the sentence, "when the client does not
store the management domain identifier". It doesn't make any
sense! Reading through the later text (specifically
paragraph [0050]) it seems to be a C/P error.
3. The patent application doesn't define what happens when
client sends REQUEST message to multicast address which is
Gros, et al. Expires May 26, 2016 [Page 5]
Internet-Draft DHCP_and_IPR November 2015
received by all other DHCP servers, i.e. what other DHCP
servers not belonging to a given management domain do.
3. As the final step DHCPv6 client receives configuration data in a
REPLY message. This part is underwritten/underspecified. To see
that here is quote from the relevant part of the patent:
[0044] 106: The DHCPv6 client receives a DHCPv6 reply message
from the network device and configures the DHCPv6 client
according to the DHCPv6 reply message. The DHCPv6 reply
message includes an IPv6 prefix assigned to the DHCPv6 client
by the network device and a network configuration parameter
assigned to the DHCPv6 client by the network device; or the
DHCPv6 reply message includes an IPv6 address assigned to the
DHCPv6 client by the net work device and a network
configuration parameters assigned to the DHCPv6 client by the
network device.
First, it says that IPv6 address or IPv6 prefix MUST be present
in the configuration message. Also, if IPv6 prefix is present
than a single network configuration parameter is assigned, while
if it is IPv6 address then "a network configuration parameters"
are present. In paragraph [0050] both are assumed to have a
single parameter!
3.2. Detailed analysis of the implementation part
Figures 3, 4 and 5 in the patent claim show implementation of the
given patent. The reason for this is that protocols (which are in
essence distributed algorithms) can not be patented
[algorithmspatentable].
Looking at the figures presented, there is no difference between the
implementations that support "management domain identifier". After
all, it is well known from the existing server implementations that
in order to add new option it is necessary just to change a line or
two in the configuration file.
3.3. Differences between the patent and draft-ietf-mif-mpvd-dhcp-
support
There are differences between the patent and the solution as proposed
in the draft:
1. "Management domain" while isn't defined by the patent isn't used
to identify set of a configuration parameters, but a whole domain
managed by some authority. PvD, on the other hand, identifies a
set of configuration parameters no matter to whom they belong.
Gros, et al. Expires May 26, 2016 [Page 6]
Internet-Draft DHCP_and_IPR November 2015
2. The context of the patent is a single network with multipe ISPs,
while the context of MIF is multiple connections, each with a
single ISP.
3. Option with "management domain ID" is like any other option, i.e.
it is not a container for the other options as in MPvD DHCP
proposal.
4. In the given patent there is 1 to 1 mapping between DHCP server
and management domain. In MPvD, on the contrary, one DHCP server
can host multiple provisioning domains.
5. As per the patent only ADVERTISE message has "management domain
identifier" option included.
6. In the patent application management IDs are sent without being
requested by the client. So, in case the client explicitly
requests different management domain the patent doesn't apply.
7. The mechanism in patent, as described, couldn't be implemented
without first resolving some issues not defined precisely enough.
(the case what all DHCP servers should do upon receive REQUEST
possibly without "management domain identifier" within)
8. The patent doesn't specify anything else being part of
"management domain" other then IPv6 address or prefix.
3.4. Conclusion
The first conclusion is that this patent actually patents an
algorithm, and since algorithms aren't patentable than the patent
itself is invalid.
The conclusion is that by introducing a configuration option with
PVD_ID that functions as a container for other options isn't in
collision with the given patent.
4. Possible Solutions
The first step towards the possible solutions is enumeration of all
the options.
For a start, there certainly must be a way for DHCP server to convey
information about specific PvD to a client. This can be done either
implicitly or explicitly and directly or indirectly:
Gros, et al. Expires May 26, 2016 [Page 7]
Internet-Draft DHCP_and_IPR November 2015
o Implicit. The information that the parameters within a message
belong to some particular PvD isn't contained within DHCP message
itself but somewhere outside of it.
o Explicit. The information that certain parameters within the
message belong to some specific PvD is contained within the
message itself.
o Direct. All the necessary information necessary to identify PvD
are placed within the DHCP message.
o Indirect. Information about PvD isn't fully contained within DHCP
message but has to be obtained by some other mean.
When information about PvD is explicit then it can be done in the
following ways:
1. A single option within DHCP message can define PvD the whole
message belongs to. This approach has two problems. The first
is backwards compatibility. Clients not aware of PvD will be
confused with multiple configuration parameters. The second
problem is that it resembles the IPR claim made by Huawei and
analyzed in the previous section.
2. Prefixing each option with an option that identifies PvD to which
the given option belongs to. This approach has the problem of
bloating DHCP message, and also there is a problem with backwards
compatibility.
3. Defining separate set of configuration options in which each
contains PvD ID and appropriate option. The problem with this
approach is the number of options that should be duplicated.
4. Using container option which holds all the options specific for a
given PvD. This approach was used in the existing proposal of
PvD configuration using DHCP messages
[I-D.ietf-mif-mpvd-dhcp-support].
5. There is an indicator within DHCP message about availability of
other PvDs. When PvD aware client receives such message, it
requests additional configuration options, e.g. by using DHCP
INFORM messages. DHCP INFORM messages could be used to obtain a
list of all available PvD_IDs and to request specific PvD_IDs.
This is an example of indirect configuration of a client.
Gros, et al. Expires May 26, 2016 [Page 8]
Internet-Draft DHCP_and_IPR November 2015
5. Acknowledgements
6. IANA Considerations
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
for a guide). If the draft does not require IANA to do anything, the
section contains an explicit statement that this is the case (as
above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor.
7. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
DOI 10.17487/RFC6418, November 2011,
<http://www.rfc-editor.org/info/rfc6418>.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419,
November 2011, <http://www.rfc-editor.org/info/rfc6419>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<http://www.rfc-editor.org/info/rfc7556>.
8.2. Informative References
[algorithmspatentable]
StackExchange, "Can an algorithm be patented?", December
2010,
<http://programmers.stackexchange.com/questions/32482/
can-an-algorithm-be-patented>.
Gros, et al. Expires May 26, 2016 [Page 9]
Internet-Draft DHCP_and_IPR November 2015
[HuaweiIPRClaim]
Huawei Technologies Co., "Huawei Technologies Co.,Ltd's
Statement about IPR related to draft-ietf-mif-mpvd-dhcp-
support", August 2014, <https://datatracker.ietf.org/
ipr/2648/>.
[I-D.ietf-mif-mpvd-dhcp-support]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", draft-ietf-mif-
mpvd-dhcp-support-02 (work in progress), October 2015.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[MIFminutes94]
IETF94, "IETF 94th MIF minutes", November 2015,
<https://www.ietf.org/proceedings/94/minutes/minutes-
94-mif>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[US20140344421]
Huawei Technologies Co., "Method for configuring dhcpv6
client, dhcpv6 client, network device, and network
system", August 2015,
<http://www.google.com/patents/US20140344421>.
Authors' Addresses
Stjepan Gros (editor)
University of Zagreb
Unska 3
Zagreb 10000
HR
Email: stjepan.gros@fer.hr
Gros, et al. Expires May 26, 2016 [Page 10]
Internet-Draft DHCP_and_IPR November 2015
Leonardo Jelenkovic
University of Zagreb
Unska 3
Zagreb 10000
HR
Email: leonardo.jelenkovic@fer.hr
Dejan Skvorc
University of Zagreb
Unska 3
Zagreb 10000
HR
Email: dejan.skvorc@fer.hr
Gros, et al. Expires May 26, 2016 [Page 11]
