Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

What is DHCP Option 82?
November 01, 2013 | By Chris Yoo (tech@netmanias.com)
Online viewer:
Comments (1)
7

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: 

  • First, L2 switch, DSLAM or OLT has to support DHCP snooping. What is DHCP snooping? In simple terms, it is a function to capture/unpack all the packets that pass through a network device although the packets are not destined to the device. Then, if necessary, it modifies the field(s) in the packets or inserts a new field (i.e., DHCP Option 82) to the packets.
  • L2 switch, DSLAM or OLT has to be provisioned to provide different “DHCP Option 82” fields per subscriber port, so that a non-overlapping “DHCP Option 82” field can be inserted to each subscriber port.
  • A DHCP server has to maintain all of the provisioned "DHCP Option 82" fields in its DB as well, so that it can respond (DHCP Offer/Ack messages) only when DHCP packet(s) (DHCP Discover/Request) with a valid “DHCP Option 82” field are received. 

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. 

  • MDF-location: A code name of an MDF site where DSLAM is located.
  • DSLAM-location: A unique code identifying the location of a DSLAM within the MDF site 
  • Slot: Slot # of the DSLAM connected to a valid subscriber
  • Port: Port # of the DSLAM connected to a valid subscriber
  • VPI/VCI (PVC): VPI/VCI # specified in ATM frames that pass through a port (these identifiers are included because the ADSL2+ uses the ATM technology) 
  • MDF-name: A unique name of MDF

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

 

 

bubba 2015-05-15 02:06:40

Has this been tested with DHCPv6?

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
11/07/2013
Netmanias Technical Documents
11/05/2013
Netmanias Technical Documents
10/30/2013
Netmanias Technical Documents
10/23/2013
Netmanias Technical Documents
10/11/2013
Netmanias One-Shot Gallery
10/01/2013
Netmanias Blog
09/01/2013
Netmanias Blog
08/01/2013
Netmanias Blog
07/01/2013
Netmanias Blog
View All (823)
4.5G (1) 5G (89) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (55) KT (43) Korea (19) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (3) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password