Today we’re going to explore the famous DHCP Option 43, used mainly to autoconfigure devices such as Access Points, Switches, IP Phones, CPEs, IoT devices and others through TR-069. We will also show a configuration example using the DHCP Server of a Mikrotik router, delivering parameters via DHCP Option43 and allowing autoconfiguration of services in the process of assigning IP addresses to the device.
This allows us, for example, to signal a controller external to the device automatically, even if the device has gone through a factory-reset.
RFC 2132 “DHCP Options and BOOTP Vendor Extensions” [1] deals with various types of information that can be sent via the DHCP protocol, such as DNS, subnet mask, router address, vendor-specific attributes and much more.
Option 43 is defined in this RFC as “Vendor Specific Information” and is used for DHCP clients and servers to exchange specific information with each other. The RFC doesn’t define what values I can send, nor what this information is, much less the type of data. It only describes the structure, which should be:
- a) A single code/length/value string
| Code | Len | Vendor specific information | ||
| 43 | n | i1 | i2 | … |
- b) One or more parameters separated by a code (01, 02, 03 … ff)
| Code 1 | Len 1 | Date 1 | Code 2 | Len 2 | Date 2 | Code n | Len n | Date no. |
| T1 | n1 | d1 | T2 | n2 | T2 | … | … | … |
With this structure, each manufacturer or organization can model the data as is most convenient for their use. For example, for access-points the IP addresses of Wifi controllers can be configured, allowing them to be “joined” to the centralized controller, for IP Phones the IP or URL of the telephony server can be delivered and for routers that support TR-069 the ACS URL can be configured. And all this automatically!
The focus of this article will be to show how to use option 43 together with TR-069, sending the URL from the ACS server to the CPE via the DHCP server. This allows the router, even when reset and without a configuration template, to learn the URL of the ACS server via DHCP, along with the user and password, the data needed to integrate with the ACS and allow the TR-069 to apply configurations to the CPE automatically.
But before I continue, I’ll leave you with some links to other examples of option 43 use cases.
Configure DHCP OPTION 43 for Lightweight Access Points: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html
VLAN ID Discovery over DHCP:
https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP
Use DHCP Option 43 for Unifi Accesspoint Provisioning:
https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/
How DHCP ended up in the TR-069
If you don’t know what ACS is, check out our other article .
DHCP was included as one of the ways of onboarding ACS. Onboarding is the process in which the CPE/router is configured with an ACS server.
There are three ways of onboarding CPEs to an ACS server, according to the Broadband Forum’s TR-069 specification [2]:
- Form 01: manually
- Way 02: via DHCP Option 43
- Way 03: through pre-configurations, also known as firmware with pre-set
The ultimate goal of any of the three is one: to have the ACS server URL configured in the CPE so that it can be managed via the TR-069 protocol.
DHCP Option 43 request process
The BroadBand Forum defines some steps so that the CPE can get the ACS URL via DHCP.
The picture below shows the steps, and we’ll talk about each of them in a moment.
Communication step by step:
- The CPE sends a normal DHCP Discover request
- The DHCP server/router replies to the message with a DHCP Offer
- This is where the magic of discovering the ACS happens. CPE needs to add two new options in the request message: one is to request option 43 in the RPL (request parameter list – option 55), and the other is to inform Option 60 of the lowercase string “dslforum.org”).
- The DHCP server, upon receiving this information from step 3, understands that it needs to send the ACS server, so it does so. IMPORTANT DETAIL: each manufacturer uses its own URL+user+pass encoding standard within Option 43. This can cause problems in environments with different vendors and implementations. For these cases, a more complete DHCP server that can read other parameters to decide which vendor and which format to use is more suitable (don’t expect this from Mikrotik).
- The CPE then, in possession of the data, configures its ACS and begins the TR-069 game for it. There are several messages below, which I’ve left out for simplification.
The TR-069 specification also defines other fields/protocols that can be used for the same purpose: DHCPv4 Option 125, DHCPv6 Option 17. They also mention various post-reset discovery rules and how to deal with connectivity problems with the ACS. But they are beyond the scope of this article.
Example of a DHCP transaction with Option 43 – Packet captures
- CPE request (DHCP Discover):
Here, we see the first step of a Nokia CPE in its discovery of DHCP servers to assign an IP address automatically.
In the message, we see “Option: (53) DHCP Message Type (Discover) present while the Frame’s destination mac-address is the broadcast address (ff:ff:ff:ff:ff:ff).
In a nutshell, this is where CPE Nokia says: “I need to borrow an IP address from a DHCP server”😊 - Response from the DHCP Server (DHCP Offer), already informing Option 43:
In the “Offer” process, the DHCP server signals the Nokia CPE with gateway and subnet addressing information, as well as its own Option43 values containing autoconfiguration data for an ACS server, with URL, user and password. This offer is sent as a “unicast” specifically intended for the Nokia CPE. Here, in addition to Option43, we can see data such as the IP address (Your Client IP Address is 192.168.2.253), the DHCP Server Identifier (Option53) and other data.
Here, we say that it is an offer made by the DHCP Server to the Nokia CPE to assign the IP address and other parameters (including Option43). - Option 43 request from the CPE (DHCP Request):
Once the Nokia CPE has received the “offer” from the DHCP server, it then performs the “DHCP-Request” process by “formally” requesting via the Option53 (Request) message the IP address that was previously offered (192.168.2.253), and adds a series of parameters to the request. In the request for the “Option55” attribute, we see data such as Subnet-Mask, Domain Name Server (DNS), Broadcast Address, etc., as well as “Option43”.
In other words, here, the Nokia CPE is formally requesting the loan of the IP address 192.168.2.253 previously offered, but also requesting a series of other information including the DHCP Option43. - DHCP server sends last message confirming the information (DHCP ACK):
The DHCP server here, after receiving and provisioning the resources previously requested by the CPE, sends an “ACK” (Acknowledge) message, which is confirmation to the Nokia CPE that it can use the resources it requested, as well as delivering the other resources that may not have been in the “Offer” step and were requested in the “Request” step.
Here we see that the “Option43” attribute has been sent again, containing the hexadecimal value for the user, password and URL of the ACS server.
With this, we have the Nokia CPE configured with the necessary values to integrate with the ACS server automatically, using DHCP, even if it has gone through a factory-reset (which by default leaves the WAN active in DHCP-Client) 😊
Mikrotik configuration example
Here, we’ll see how to configure a Mikrotik router to deliver autoconfiguration parameters to “clients” via DHCP-Server using Option43.
The configuration will be based on the topology below, similar to the one used in our tests with a Nokia CPE.
First you need to have the DHCP Server configured, then link the DHCP Option43 settings.
We used the network 192.168.2.0/24 and Vlan 881, as in our example:
# Configuração do IP Address na Vlan 881
/ip address
add address=192.168.2.1/24 comment=DHCP-TR069 interface=vlan881 network=192.168.2.0
# Configuração do Option 43 (necessário ter em mãos o value gerado):
/ip dhcp-server option
add code=43 name=tr069
value="0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974"
# Configuração do Network do DHCP Server:
/ip dhcp-server network
add address=192.168.2.0/24 dhcp-option=tr069 gateway=192.168.2.1
# Configuração do Pool de IPs:
/ip pool
add name=dhcp_pool3 ranges=192.168.2.2-192.168.2.254
# Configuração do DHCP Server com Pool de IPs e interface:
/ip dhcp-server
add address-pool=dhcp_pool3 disabled=no interface=vlan881 name=dhcp-tr069 You might be wondering, where did the value of option 43 come from? There is a rule to be created, and you can see how to generate it for your ACS server in the following article.
Conclusion
In this article, we look at how to use DHCP’s “Option43” attribute to autoconfigure an ACS server on CPEs and various devices. We discuss how it works and how it can be used to automate the delivery of specific configurations to devices using a protocol as common as DHCP.
Knowing the capabilities, attributes and options that the equipment manufacturer and model support helps us to automate various configurations, including but not restricted to managing a CPE, Nokia, via the TR-069.
References:
[1] RFC 2132, DHCP Options and BOOTP Vendor Extensions, https://www.ietf.org/rfc/rfc2132.txt
[2] TR-069, CPE WAN Management Protocol, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf
