The Line-Identification Option
Extracted elements (27)
The Line ID encoding uses only US-ASCII printable characters (decimal 32–126) and is derived from the DHCPv6 Remote-ID option (RFC 4649), which is in turn derived from DHCPv4 options (RFC 3046). This maintains encoding compatibility with the provisioning systems that already consume those DHCP options.
The LIO mechanism is explicitly NOT RECOMMENDED for networks requiring the subscriber's MAC address for identification, because AN-initiated RSes are not preceded by an L2 frame from the subscriber, making it impossible to determine the end-device's MAC address.
The LIO mechanism is NOT RECOMMENDED for networks that require automatic notification when a subscriber is no longer active, because there is no indication in this protocol when a subscriber becomes inactive and prefixes must be reclaimed manually.
Because RS/RA packets protected by SEcure Neighbor Discovery (SEND, RFC 3971) are carried unmodified inside the outer tunnel and are not altered, there are no issues with SEND signature verification.
The LIO is intended solely for the N:1 VLAN deployment model. For 1:1 VLAN models, line identification is achieved differently. This mechanism SHOULD only be used in N:1 VLAN deployments because regular IPv6 hosts lack the RS retransmission behavior needed to recover from state loss in access routers.
After sending a tunneled RA, the Edge Router MUST store the mapping between the LIO and the prefixes in the RA, then MUST initiate periodic unsolicited tunneled RAs for that LIO per RFC 4861 Section 6.2.3.
Each time the AN detects a subscriber circuit coming up, it MUST create an RS using the unspecified address as source and MUST tunnel it toward the Edge Router with the LIO, to trigger periodic unsolicited RAs from the Edge Router.
If the AN has an IPv6 address it MUST use it as the Source Address of the outer IPv6 datagram; otherwise it MUST copy the source address from the received RS into the outer header's Source Address field.
If the source address of the received outer IPv6 datagram is the unspecified address, the Edge Router MUST set the destination of the tunneled RA outer header to the All-BBF-Access-Nodes multicast address (ff02::10) and set the link-layer destination to the unicast link-layer address of the AN.
Line ID comparison MUST use binary byte-by-byte comparison; two Line IDs are equal only when they have the same number of bytes and the same value at every byte index. Intermediate systems MUST NOT alter the contents of the Line ID.
Multiple Line-ID destination options MUST NOT be present in the same IPv6 datagram.
On receiving a tunneled RA with an LIO from the Edge Router, the AN MUST use the LIO's line-identification data to identify the subscriber circuit, MUST remove the outer IPv6 header, and MUST multicast the inner RA on that specific subscriber circuit.
The AN MUST join the All-BBF-Access-Nodes multicast group (ff02::10) on all its upstream interfaces towards the Edge Router on initialization.
The AN SHOULD retransmit RSes for each subscriber circuit using the exponential backoff algorithm from RFC 3315, with IRT=1s, MRT=30s, MRC=0, MRD=0, until an RA is received for that specific LIO.
The Edge Router MUST ensure that tunneled RAs do not exceed the MTU of the link between the Edge Router and the AN, because the AN may not be capable of handling reassembly of fragmented datagrams.
The high-order bit of each octet in the Line ID field MUST be set to zero by any device inserting the option, for compatibility with deployed DHCP implementations that strip the high-order bit.
The Line ID field SHOULD NOT contain the US-ASCII NUL character (decimal 0), but implementations receiving this option MUST NOT fail merely because an ASCII NUL character is erroneously present.
The Line ID MUST be unique across all ANs that share a link to the Edge Router; one such identification scheme is described in Section 3.9 of TR-101.
The LIO Option Length value MUST be greater than 0.
When sending a tunneled RA in response to a tunneled RS with an LIO, the Edge Router MUST include a Prefix Information option in the RA containing the prefix that corresponds to the received LIO, and MUST echo back the same LIO value in the outer header.
When tunneling a Router Solicitation, the AN MUST NOT decrement the Hop Limit field of the inner RS message, because ND messages with Hop Limit not equal to 255 are discarded by receivers per RFC 4861.
When tunneling an RS, the AN MUST include a destination options header with an LIO destination option, setting the Line ID field to the circuit identifier for the logical access loop port from which the RS was received.
The Line-Identification Option (LIO) is an IPv6 destination option carried in tunneled IPv6 datagrams encapsulating Router Solicitation and Router Advertisement messages. It conveys a subscriber-agent circuit identifier from the Access Node to the Edge Router, enabling per-subscriber-line identification in N:1 VLAN deployments.
IANA allocated the well-known link-local scope multicast address FF02:0:0:0:0:0:0:10 as 'All-BBF-Access-Nodes' in the IPv6 Multicast Address Space Registry for use in tunneled RA delivery.
IANA assigned option type 0x8C in the 'Destination Options and Hop-by-Hop Options' registry for the Line-Identification Option. The act bits are 10 (skip and continue processing) and the chg bit is 0 (option data does not change en route).
The Line ID inserted by the AN or Edge Router is not integrity-protected; it may be modified, inserted, or deleted without detection. The network segment between the AN and the Edge Router must be trusted to ensure validity of the Line ID field.
The LIO has a fixed header of Option Type (8-bit, value 0x8C), Option Length (8-bit unsigned integer, must be > 0), and LineIDLen (8-bit unsigned integer giving the byte-length of the Line ID field), followed by a variable-length Line ID field containing the circuit identifier.