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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Requirements
• 3. Analysis of the IPR Claim made by Huawei
• 3.1. Detailed analysis of the protocol part
• 3.2. Detailed analysis of the implementation part
• 3.3. Differences between the patent and draft-ietf-mif-mpvd-dhcp-support
• 3.4. Conclusion
• 4. Possible Solutions
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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.

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:

• 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.
• 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.
• 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.
• 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 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". 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 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.
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:

• 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.
• Explicit. The information that certain parameters within the message belong to some specific PvD is contained within the message itself.
• Direct. All the necessary information necessary to identify PvD are placed within the DHCP message.
• 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.

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

8.2. Informative References

Authors' Addresses