Access-Network-Identifier Option in DHCP
Extracted elements (25)
ANI options in DHCP are motivated by PMIPv6 deployments where the Local Mobility Anchor (LMA) needs access-network information to apply differentiated service treatment and policy (e.g., 3GPP PCC, ANDSF). The Mobile Access Gateway (MAG) obtains this information from the DHCP relay agent and conveys it to the LMA via PMIPv6 signaling (RFC 6757).
The Operator-Identifier uses the IANA-maintained SMI Network Management Private Enterprise Number (PEN) rather than a custom identifier, providing a globally unique, pre-existing registry of operator identities without requiring a new IANA registry.
The Access-Technology-Type field value is drawn from the 'Access Technology Type Option type values' registry defined in RFC 5213 (PMIPv6), ensuring consistent ATT semantics across both the DHCP ANI options defined here and the PMIPv6 ANI options defined in RFC 6757.
ANI information obtained by the DHCP server SHOULD NOT be stored unless absolutely needed; if stored, it MUST be deleted as quickly as possible to eliminate any possibility of the information being exposed to an intruder.
The DHCPv4 relay agent MUST include the Access-Technology-Type Sub-option (code 13) whenever it includes any of the Network-Name, Access-Point-Name, or Access-Point-BSSID sub-options in a DHCP message.
The DHCPv4 server MUST ignore the Access-Network-Identifier option and process the rest of the message per base DHCPv4 specifications if the message includes Network-Name, Access-Point-Name, or Access-Point-BSSID sub-options but does not include the Access-Technology-Type Sub-option.
The DHCPv6 relay agent MUST include the Access-Technology-Type Option (OPTION_ANI_ATT, code 105) whenever it includes any of the Network-Name, Access-Point-Name, or Access-Point-BSSID options in a Relay-forward message.
The DHCPv6 server MUST similarly ignore received ANI options and process the message per base DHCPv6 specifications if the Access-Technology-Type Option is absent but other ANI options are present.
The Network-Name field encoding MUST be UTF-8 as described in RFC 3629. For PLMN Identifiers, both MNC and MCC MUST be three digits; if the MNC has only two digits it MUST be preceded with a '0'.
The Reserved field in the Access-Technology-Type sub-option/option MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
The Access-Network-Identifier (ANI) option carries information about the identity of the access network to which a DHCP client is attached, including access-technology type, network identifier, and operator identifiers. It is added by the DHCP relay agent in messages sent toward the server.
IANA assigned option codes 105–110 in the DHCPv6 'Option Codes' registry for: OPTION_ANI_ATT (105), OPTION_ANI_NETWORK_NAME (106), OPTION_ANI_AP_NAME (107), OPTION_ANI_AP_BSSID (108), OPTION_ANI_OPERATOR_ID (109), and OPTION_ANI_OPERATOR_REALM (110).
IANA assigned sub-option codes 13–18 in the 'DHCP Relay Agent Sub-Option Codes' registry for: Access-Technology-Type (13), Access-Network-Name (14), Access-Point-Name (15), Access-Point-BSSID (16), Operator-Identifier (17), and Operator-Realm (18).
A rogue DHCP relay agent or a DHCP client masquerading as a relay agent can insert or overwrite Access-Network-Identifier options with incorrect values. A perimeter defense blocking untrusted relay agent options and the authentication sub-option for the DHCPv4 Relay-Agent-Information Option (RFC 4030) SHOULD be deployed.
Administrators SHOULD configure DHCP servers that use ANI options to communicate with relay agents using IPsec (as described in Section 21.1 of RFC 3315). Where IPsec or equivalent security cannot be applied, administrators SHOULD disable the ANI capability on DHCP entities.
DHCP messages have no inherent privacy protection; an eavesdropper monitoring the link between the DHCP server and relay agent can discover access-network information. Link-layer confidentiality and integrity protection SHOULD be employed to reduce the risk of disclosure and tampering.
DHCPv4 ANI sub-options are encoded as a sequence of Sub-Option Code (1 octet), Length (1 octet), and Value (N octets) tuples, carried within the Relay Agent Information option (RFC 3046). Sub-option codes 13–18 are allocated from the 'DHCP Relay Agent Sub-Option Codes' registry.
DHCPv6 ANI options use the standard DHCPv6 TLV format (2-octet Option-Code, 2-octet Option-Len, variable-length data). Option codes 105–110 (OPTION_ANI_ATT through OPTION_ANI_OPERATOR_REALM) are allocated from the DHCPv6 'Option Codes' registry.
The DHCPv4 Access-Point-BSSID Sub-option (code 16) has a fixed Length of 6 octets and carries the 48-bit Basic SSID (BSSID) of the access point to which the mobile node is attached.
The DHCPv4 Access-Technology-Type Sub-option (code 13) is 4 octets total: 1-octet Subopt Code (13), 1-octet Length (2), 1-octet Reserved (must be 0), and 1-octet ATT value from the IANA 'Access Technology Type Option type values' registry defined in RFC 5213.
The DHCPv4 Network-Name Sub-option (code 14) carries the name of the access network (SSID for IEEE 802.11, PLMN Identifier for 3GPP, or ANI for 3GPP2) as a variable-length UTF-8 encoded string.
The DHCPv4 Operator-Identifier Sub-option (code 17) has a fixed Length of 4 octets encoding a Private Enterprise Number (PEN) in network byte order, identifying the operator running the access network.
The DHCPv6 OPTION_ANI_AP_BSSID option (code 108) has an Option-Len of 6, carrying the 48-bit BSSID of the access point to which the mobile node is attached.
The DHCPv6 OPTION_ANI_ATT option (code 105) has an Option-Len of 2, carrying a 1-octet Reserved field (must be zero) and a 1-octet ATT value identical in semantics to the DHCPv4 ATT sub-option.
The DHCPv6 OPTION_ANI_OPERATOR_ID option (code 109) has a fixed Option-Len of 4, encoding the Private Enterprise Number (PEN) of the access network operator in network byte order.