RFC 3162: RADIUS had to decide before IPv6 was negotiated

Summary

In PPP access, IPv6CP follows LCP, but RADIUS authentication and authorization may finish before address assignment. A NAS therefore may not yet know whether the host will use IPv4, IPv6 or both.
RFC 3162 allowed both families' attributes in one RADIUS message and left the NAS to apply only what the client could use. An authorization value was not proof that an address, prefix, route or working service already existed.

The answer arrived before the question

An access server needs a policy decision before it can open a subscriber's session. But at the moment it asks a RADIUS server whether to admit the user, the host's eventual network-layer configuration may still be unresolved. That ordering problem is the most revealing part of RFC 3162, “RADIUS and IPv6,” published in August 2001.

RFC 3162 addresses two related but separate jobs. RADIUS can itself run over IPv6; separately, RADIUS messages can carry attributes used to provide IPv6 network access to a user. An IPv6 transport address for the RADIUS server does not mean an IPv6 prefix has been assigned to the subscriber. The standard discusses both, but the access-policy timing problem belongs to the second.

The document uses Point-to-Point Protocol access to make the timing concrete. Link Control Protocol (LCP) runs before IPv6 Control Protocol (IPv6CP). RADIUS authentication and authorization can complete before address assignment. So when a Network Access Server (NAS) sends an Access-Request, it may not know in advance whether the host will use IPv4, IPv6 or both.

That sequence defeats an easy design: ask first which address family the user will use, and return only that family's attributes. The NAS has to request a decision before the later negotiation supplies the answer. RFC 3162's practical solution is not to guess. It permits IPv6 and IPv4-related attributes in the same RADIUS message and lets the NAS decide which ones apply. The NAS should allocate only addresses and prefixes that the client can actually use.

Authorization is not configuration

The distinction runs through the attributes themselves. The NAS-IPv6-Address identifies the device asking for authentication. Framed-Interface-Id concerns an IPv6 interface identifier. Framed-IPv6-Prefix supplies a prefix and corresponding route to configure for a user. Framed-IPv6-Route provides routing information, while Framed-IPv6-Pool names a configured pool from which a prefix may be assigned. These are different control points, not interchangeable proof of connectivity.

Some values are explicitly hints. If IPv6CP successfully negotiates an Interface-Identifier option, the NAS includes the identifier it prefers in its Access-Request. The RADIUS server is recommended, but not required, to honor that hint. A NAS can also send a preferred IPv6 prefix in a request; the server may ignore it. An Access-Accept is a policy response, not a transcript showing that the client's interface accepted the preference or that packets can now reach the Internet.

RFC 3162 also constrains the edge's use of returned data. It says there is no need to reserve an IPv4 address for an IPv6-only host, or an IPv6 prefix for a host using only IPv4 or 6to4. This is modest advice, but it locates responsibility. The RADIUS server supplies policy attributes; the NAS sees the negotiated session and must avoid provisioning an address family the client cannot use.

The authorization exchange thus tolerates uncertainty by allowing a broader response while narrowing actual use at the point with better session context. That is not simply a packet-format choice. It is a boundary between what a central policy server can authorize in advance and what an access device can know only after protocol negotiation.

The layers remain separate

The later operation still has several steps. A request may contain a NAS preference. A response may authorize or return a prefix. IPv6CP may negotiate an interface identifier. The NAS may configure an address or route. Only then can an end-to-end test show whether a service is reachable. RFC 3162 defines attributes and their place in the exchange; it does not report a live subscriber session or certify the outcome of those later steps.

The distinction matters because authentication, authorization and accounting are often collapsed into a single word: “access.” Yet a successful authentication response is not the same thing as a configured address, and a configured prefix is not the same as working reachability. An operator reviewing a record needs to know which layer its evidence actually covers.

RFC 3162 reserves six RADIUS attribute numbers, 95 through 100, for IPv6-related information. Later standards added further vocabulary: RFC 4818 defines a delegated-prefix attribute, RFC 6911 specifies additional IPv6 access attributes, and RFC 8044 updates RADIUS data-type guidance. That continuing work is another reason not to treat the 2001 document as a complete account of modern access provisioning. Its historical contribution is narrower: it made dual-family authorization possible when the session's family was not yet known.

Lu Heng's Note 20 offers an editorial lens here: a formal description and the observable state of a system are different layers. Applied to this RFC, an attribute records what a server requested, preferred or authorized; it does not by itself prove what the NAS installed or what a user could reach. This is an interpretive frame, not a claim made by RFC 3162's authors.

IPv6 Had to Wait for Authentication: RFC 3162

Why it matters

Summary

The answer arrived before the question

Authorization is not configuration

The layers remain separate

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing