DHCP Option 82 and the PPPoE intermediate agent are how an OLT stamps each subscriber packet with its physical line identity — PON port, ONU and UNI port — so the BRAS can pick address pools, enforce account-to-line binding, bill per line and locate faults without asking the user where they live.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
Broadband authentication happens at the BRAS, but a BRAS only sees IP packets. It has no idea which fiber a request came in on. Without line information three problems show up at once: address pools cannot be split by area, so one exhausted district drains a city-wide pool; unauthorized sharing cannot be constrained, because a router hiding ten devices looks like one MAC; and fault location depends on the subscriber reading out their address while an operator flips through paper records.
The OLT is the one device that knows exactly which PON port, ONU and UNI port a packet entered through. Let it write that into the packet and the BRAS can tie line to subscriber. DHCP uses Option 82; PPPoE uses the intermediate agent. The idea is identical.
Option 82 (RFC 3046) is inserted by the OLT as DHCP relay, carried back by the server untouched, and stripped on the way out — subscribers cannot see or forge it.
Circuit-ID marks the position, Remote-ID marks the device; together they separate "changed the ONU" from "moved house".
PPPoE+ (TR-101 intermediate agent) does the same job inside PADI/PADR during RFC 2516 discovery.
Option 82 stops account roaming, not multi-device sharing — that takes a MAC address limit or UNI isolation, and the three stack.
RFC 3046 defines Option 82 as the DHCP Relay Agent Information Option. The relay device — here the OLT — inserts it when forwarding a request, the server returns it untouched, and the relay strips it before handing the reply to the subscriber.
| Field | Length | Meaning |
|---|---|---|
| Option code | 1 byte | Fixed at 82 |
| Length | 1 byte | Total length of what follows, max 255 |
| Sub-option 1 | Variable | Circuit-ID, the line identifier |
| Sub-option 2 | Variable | Remote-ID, the far-end device identifier |
| Sub-option 5 | Variable | Link Selection, RFC 3527, used to pick an address pool |
The two sub-options have no standardized internal format — vendors define their own, which is the root of every interoperability headache. Common encodings:
Circuit-ID: something like gpon 0/1:15 — chassis/slot/PON port/ONU-ID, sometimes with the UNI port appended.
Remote-ID: the ONU's MAC or serial number, as device identity.
The division of labour is worth stating plainly: Circuit-ID identifies position, Remote-ID identifies equipment. A subscriber swaps a broken ONU — position unchanged, device changed. A subscriber moves house — device unchanged, position changed. Record both at the BRAS and "equipment swap" and "relocation" become distinguishable events instead of the same ticket.
Length is a non-issue if you keep encodings tight. The Length field is one byte, capped at 255, and a typical build — 11-byte Circuit-ID plus 2-byte sub-option header, 17-byte textual MAC plus its header, and the 2-byte Option 82 header itself — totals 34 bytes. A minimal DHCP packet is around 300 bytes, so 334 bytes total sits far below the 1500-byte MTU. The only way to hit the ceiling is stuffing descriptive prose strings into Circuit-ID, which nobody needs.
PPPoE runs on a different track. RFC 2516 defines a four-packet discovery stage: PADI (client broadcasts for an access concentrator), PADO (concentrator answers), PADR (client picks one), PADS (session confirmed). Only after that does PPP's LCP authentication begin.
PPPoE+ — the PPPoE Intermediate Agent, defined by Broadband Forum TR-101 — works inside that window: the OLT intercepts PADI and PADR, inserts a vendor-specific tag carrying the line information, and forwards upstream to the BRAS.
| Dimension | DHCP Option 82 | PPPoE+ |
|---|---|---|
| Protocol | DHCP (RFC 3046) | PPPoE discovery (RFC 2516 / TR-101) |
| Carried in | DHCP options area | Vendor-specific tag in discovery packets |
| Insertion point | When the dhcp relay forwards | On PADI / PADR upstream |
| Main use | Pool selection, address binding | Account-to-line binding, anti account theft |
| Depends on | Correct relay (giaddr) setup | BRAS support for the same tag format |
The constant across both: the access device inserts the information, the BRAS consumes it, and the subscriber cannot forge it. A user can change every setting on their own router; they cannot change what the OLT writes.
Four things, in rising order of value.
Pick the address pool. The PON port or area field inside the Circuit-ID maps the user to a local address block. Each district manages its own pool, so one exhausted area no longer starves the others.
Verify the binding. At provisioning the account is stored in AAA together with the Circuit-ID. At connect time the BRAS compares; a mismatch is refused. This blocks "account signed up in district A, used from district B".
Bill the line, not the MAC. Per-line billing survives equipment swaps without touching the accounting records.
Locate the fault. A support agent with the account can look up the PON port and ONU-ID directly — no address interrogation, no ledger archaeology.
The second item is the key to anti-roaming, but note what it cannot do: it cannot stop one account running many devices behind a router on its own line. That needs the measures below.
| Mechanism | Layer | Stops | Does not stop |
|---|---|---|---|
| Option 82 / PPPoE+ | Authentication and addressing | Account roaming, pool abuse | Multiple devices on the same line |
| MAC address limit | Layer-2 forwarding | Too many MACs learned on one port (hidden router) | MAC forgery, MAC cloning |
| UNI port isolation | Layer-2 isolation | Devices on one ONU reaching each other, subscriber-side loops | Uplink traffic exceeding quota |
All three stack, and each covers a different question. Option 82 answers "who are you and where", the MAC address limit answers "how many devices may you attach", isolation answers "may your devices talk to each other". Run only the first and a router with ten devices sails through. Run only the limit and a stolen account still works from anywhere.
Sizing the limit needs headroom. Households commonly run 4–8, shops 8–16, leased lines follow the contract. Too tight and you break the subscriber the day they add a smart-home hub; too loose and the setting does nothing.
One OLT, four PON ports, 1:256 per port (two cascaded 1:128 splitters). Three sums decide whether the launch is smooth.
Sum one — Option 82 length. Circuit-ID as gpon 0/1:15 format, 11 bytes; Remote-ID as 17-byte textual MAC.
Option 82 total = 2 (header) + 2 (sub-option header) + 11 + 2 + 17 = 34 bytes
DHCP packet 300 + 34 = 334 bytes, nowhere near fragmentation territory.
Sum two — MAC table. Three devices per household on average gives 1,024 × 3 = 3,072 MACs. Per PON port at 256 households: 256 × 3 = 768. If the OLT's MAC table is sized at 4,096 entries, four ports consume 3,072 — 75% full, 25% headroom. One subscriber's hidden router carrying ten devices starts eating real margin. That is the practical argument for a per-port MAC cap, beyond "stopping freeloaders".
Sum three — BRAS binding table. Each record holds Circuit-ID (~12 bytes), Remote-ID (17), account (~20) and index overhead (~32) — about 81 bytes. Ten thousand subscribers ≈ 810 KB. Memory is not the constraint; lookup is handled by hashing on Circuit-ID, constant time at this scale. The real bottleneck is process: whether provisioning actually wrote the Circuit-ID in.
Conclusion: Option 82 length is not the problem — MAC table headroom is. Binding table capacity is not the problem — the provisioning workflow is. Those two lines decide whether an estate launches quietly or lives on the fault queue.
Got an IP, no internet. Check whether the BRAS received Option 82 at all. Relay not enabled on the OLT, giaddr unset, or DHCP packets not permitted on the uplink all kill the relay silently. Capture on the OLT uplink and look for the option 82 field.
Swapped the ONU, now nothing works. If the binding table also stores Remote-ID, the new unit's Remote-ID fails validation. Either unbind before swapping, or bind on Circuit-ID only and keep Remote-ID as an asset record.
PPPoE fails while DHCP works. The PPPoE intermediate agent tag is missing or malformed. TR-101 fixes the tag's purpose, not its format — BRAS and OLT must speak the same encoding, and cross-vendor links need this joint-tested before launch.
Some users on one port get no address. Check the pool-to-Circuit-ID mapping. The classic error: pools split per PON port but sized smaller than that port's subscriber count.
Illustrative only — commands differ per platform, follow the actual CLI.
! OLT side: enable DHCP relay with Option 82 interface gpon 0/1 dhcp relay enable dhcp relay information option 82 enable dhcp relay circuit-id format slot/port/onuid ! PPPoE intermediate agent pppoe intermediate-agent enable pppoe intermediate-agent circuit-id include-uni
After configuring, verify end to end once: trigger a DHCP request from the ONU side, capture on the OLT uplink, confirm Option 82 is present with the expected content, then check the BRAS allocation result. Configured but never verified equals not configured.
Rayin's L102P, a 2-port mini GPON OLT with 1:128 splitting per port, pairs with XPON ONUs in estate and campus builds; the Option 82 and PPPoE+ switch positions and the Circuit-ID encoding format should be confirmed per software version, since supported sub-options differ between releases. Device specs and wiring are on the PON access page, and where the uplink rides an industrial switch, port and VLAN guidance is under the industrial Ethernet switch range.
Is Option 82 added by the OLT or by the BRAS?
By the OLT. Acting as the dhcp relay, it inserts Option 82 when forwarding the subscriber's request and fills in giaddr at the same time. The BRAS or DHCP server returns it untouched, the OLT strips it on the reply, and the subscriber never sees or controls the field.
What is the actual difference between Circuit-ID and Remote-ID?
Circuit-ID says where the line terminates; Remote-ID says which device sits there. Circuit-ID encodes chassis/slot/PON port/ONU-ID, Remote-ID carries the ONU's MAC or serial. Swap the ONU and Circuit-ID stays while Remote-ID changes — that is the test separating an equipment swap from a relocation. Bind on one or both depending on the business rule.
Can PPPoE+ and Option 82 run at the same time?
Yes, and they commonly do. One estate may carry DHCP-based IPTV set-top boxes and PPPoE-dialled internet on the same plant; each mechanism serves its own service class. Keep them straight in configuration — their insertion points and packet types are entirely different.
Does configuring Option 82 actually stop unauthorized sharing?
No. Option 82 binds account to line; a router hanging ten devices off the same line changes nothing the BRAS can see, so it passes. Stopping that takes a MAC address limit or UNI isolation. All three mechanisms together are the complete answer.
Why does a subscriber have to be unbound after changing their ONU?
Because the binding table stores Remote-ID — the old ONU's MAC or serial. The new unit's Remote-ID fails validation. Two fixes: add "unbind before swap" to the operations workflow, or bind on Circuit-ID only and treat Remote-ID as an asset record. The second costs less to run but will not catch a whole ONU being moved elsewhere.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
