We will look into DHCP Option 82 used in the wireline networks of network operators today.
Most of you are probably subscribing to a wireline Internet service provided by one of the network operators such as KT, SK Telecom or LGU+ (Korean Operators). When users subscribe to the Internet service, they pay a monthly fee to their network operator for using the Internet service. So, as a general rule, an operator first identifies subscribers and then determines whether or not they are its actual subscribers. If they are, it now checks whether or not they are paying their monthly fees on time. Then based on the findings, it finally offers the relevant Internet service to its subscribers.
Then, how do the wireline network operators identify their subscribers and decide whether to offer the Internet service or not?
As you may know, PPP can be used in “subscriber identification/authentication” and “IP address allocation” procedures. However, to use this PPP, a PPP program has to be installed and user IDs/PWs have to be entered every time a PC is turned on, which is quite inconvenient for users. In addition, if PPP programs are not installed/configured properly, the network operator will have to deal with complaints or technical support requests by their users, which is quite costly for operators (due to increasing OPEX).
Due to such reasons, now the operators do not use PPP any more. Instead, they allocate an “IP address” for a subscriber through DHCP.
Unfortunately, however, DHCP protocols do not support “user authentication”, which means no support for ID/PW-based authentication.
So, “DHCP Option 82” was introduced to address this issue. It is also called “circuit authentication” because, with this method, a network device acting as a relay agent includes circuit-ID information of a client in the Option 82 field and delivers it to a DHCP server.
If this DHCP Option 82 is supported by the first network device connected to a user's home PC (DSLAM, OLT or L2 switch, for example my home PC is connected to an L2 switch), the device inserts the DHCP Option 82 field into the DHCP packet sent by the PC, before forwarding it to a DHCP server. This allows the DHCP server to allocate an IP address only to the PCs with a valid DHCP Option 82 field. This is how "DHCP Option 82” is used in identifying and authenticating users.
For instance,
Let's say you are a KT customer living in an apartment and pay about $20 per month to use the Internet service from KT. Your PC is connected to port #1 on the KT's L2 switch. However, your neighbor, not a KT customer, has manipulated the manager at the leasing office and obtained access to the KT L2 switch installed in the apartment complex. And he managed to connect his home cable port to port #2 on the switch, of course without KT knowing.
Because you are a paying customer, your port (i.e. #1 on the L2 switch) has already been provisioned with the DHCP Option 82 field by KT for any incoming DHCP messages. However, since port #2 is not connected by a KT customer, no information has been provisioned there.
Of course, your neighbor won’t be able to have any IP address allocated from the operator's DHCP server when he turns on his PC. That’s because obviously there is no “DHCP Option 82” field in the DHCP packet.
(Although I used KT in this example, as far as I know, Korean network operators do not currently apply the “DHCP Option 82” field: KT instead adopted a concept of "new authentication" to identify/authenticate subscribers (MAC-based authentication), and others, such as SK Telecom and LGU+, do not use DHCP Option 82 to authenticate users.)
The following figure illustrates how the DHCP Option 82 works.
In order for the first network device connected to a subscriber (L2 switch or DSLAM) to insert “DHCP Option 82” to the DHCP packets sent by a subscriber, the following requirements have to be met:
Before we finish, we have provided an example form of "Option 82", which was used in our previous consulting project involving an ADSL2+ based TPS network, for those interested.
Example: Option 82 string for Slot#3/Port#16/VPI/VCI=1/34 of DSLAM located in “Asd-Blm” (A MDF located in Amsterdam, Holland)
20058-008/03/16/1/34@Asd-Blm
Has this been tested with DHCPv6?