Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite
Extracted elements (17)
The AFTR location is conveyed as a DNS FQDN rather than a raw IPv6 address so that the presence of the option itself signals the B4 to initiate DS-Lite service. Using a DNS name also decouples the B4 configuration from direct AFTR address changes and allows operator flexibility in AFTR selection.
The B4 element and DHCPv6 client may be integrated, separate, or joined by a third piece of software. The specification uses the term 'B4 system' to encompass all such integration arrangements without mandating a specific implementation architecture.
A DHCPv6 server will not reply with an AFTR-Name option unless the client has explicitly included OPTION_AFTR_NAME in its Option Request option (OPTION_ORO), following the standard RFC 3315 Section 17.2.2 negotiation mechanism.
A B4 system wishing to resolve the AFTR name via DNS MAY also include OPTION_DNS_SERVERS (RFC 3646) on its OPTION_ORO.
A DHCPv6 client supporting DS-Lite B4 functionality MUST include OPTION_AFTR_NAME on its Option Request option (OPTION_ORO) to solicit the AFTR name from a server.
A DHCPv6 server SHOULD NOT send more than one AFTR-Name option and SHOULD NOT permit configuration of multiple names within a single AFTR-Name option.
An AFTR-Name option is valid only if: (1) option-len > 3; (2) option-len does not exceed remaining packet octets; (3) individual label lengths do not exceed option-len; (4) the FQDN format conforms to RFC 3315 Section 8; (5) no compression tags are present; and (6) at least one label of nonzero length exists.
If the AFTR-Name option contains more than one FQDN (distinguished by multiple root labels), the B4 system MUST use only the first FQDN listed in the configuration.
If the B4 system receives more than one AFTR-Name option, it MUST use only the first instance of that option.
If the client receives the AFTR-Name option, it MUST verify the option contents as described in Section 3.
On a multi-interface device, if the AFTR-Name option is received on multiple interfaces, the B4 system MUST configure a separate DS-Lite tunnel for each interface, since each tunnel provides IPv4 connectivity for a distinct interface.
The AFTR-Name option SHOULD NOT appear in any DHCPv6 messages other than Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
The B4 system performs DNS resolution of the provided FQDN to obtain a AAAA resource record, and if multiple IPv6 addresses are returned, picks only one as the remote tunnel endpoint. The B4 system MUST NOT establish more than one DS-Lite tunnel at the same time per interface.
The AFTR-Name DHCPv6 option (OPTION_AFTR_NAME, code 64) carries a fully qualified domain name (FQDN) identifying the Address Family Transition Router (AFTR) tunnel endpoint to which a DS-Lite B4 element MAY connect. The option consists of a 2-octet option-code, 2-octet option-len, and a variable-length tunnel-endpoint-name field encoded as a DNS FQDN.
IANA has allocated DHCPv6 option code 64 for OPTION_AFTR_NAME, as defined by this document.
DHCPv6-derived configuration is susceptible to man-in-the-middle attacks; there is no basis for trusting the access level represented by a DS-Lite softwire connection obtained via DHCPv6. DS-Lite MUST NOT be used to bypass security mechanisms such as IP firewalls.
The tunnel-endpoint-name field is encoded per DHCPv6 RFC 3315 Section 8: each DNS label is preceded by a single octet giving its length (max 63 octets), labels repeat until the FQDN is exhausted, and a terminating zero-length label is required. Compression tags are not permitted.