RFC 3162: IPv6 협상 전에 RADIUS가 결정해야 했던 이유

요약

PPP 접속에서 IPv6CP는 LCP 뒤에 이어지지만, RADIUS 인증과 권한 부여는 주소 할당보다 먼저 끝날 수 있습니다. 따라서 네트워크 접속 서버(NAS)는 호스트가 IPv4, IPv6 또는 둘 다를 사용할지 아직 알지 못할 수 있습니다.
RFC 3162는 두 주소 계열의 속성을 하나의 RADIUS 메시지에 담을 수 있게 하고, 클라이언트가 사용할 수 있는 것만 NAS가 적용하도록 맡겼습니다. 권한 부여 값은 주소, 프리픽스, 경로 또는 동작하는 서비스가 이미 존재한다는 증거가 아니었습니다.

질문보다 답이 먼저 도착했다

접속 서버는 가입자 세션을 열기 전에 정책 판단을 받아야 합니다. 그러나 RADIUS 서버에 사용자 수용 여부를 묻는 순간, 호스트의 최종 네트워크 계층 구성은 아직 확정되지 않았을 수 있습니다. 2001년 8월에 발행된 RFC 3162, “RADIUS and IPv6”에서 이 순서 문제가 가장 시사적인 부분입니다.

RFC 3162는 관련은 있지만 별개인 두 가지 작업을 다룹니다. RADIUS 자체가 IPv6 위에서 동작할 수 있다는 점, 그리고 별도로 RADIUS 메시지가 사용자에게 IPv6 네트워크 접속을 제공하는 데 쓰이는 속성을 담을 수 있다는 점입니다. RADIUS 서버의 IPv6 전송 주소가 가입자에게 IPv6 프리픽스가 할당되었다는 뜻은 아닙니다. 표준은 둘 다 다루지만, 접속 정책의 시점 문제는 후자에 속합니다.

이 문서는 Point-to-Point Protocol 접속을 통해 이 시점 문제를 구체화합니다. 링크 제어 프로토콜(LCP)이 IPv6 제어 프로토콜(IPv6CP)보다 먼저 실행됩니다. RADIUS 인증과 권한 부여는 주소 할당 전에 완료될 수 있습니다. 따라서 네트워크 접속 서버(NAS)가 Access-Request를 보낼 때, 호스트가 IPv4, IPv6 또는 둘 다를 사용할지 미리 알지 못할 수 있습니다.

이 순서는 간단한 설계를 무력화합니다. 먼저 사용자가 사용할 주소 계열을 물어보고 그 계열의 속성만 돌려주는 방식입니다. NAS는 이후 협상이 답을 제공하기 전에 판단을 요청해야 합니다. RFC 3162의 실용적 해법은 추측하지 않는 것입니다. 하나의 RADIUS 메시지에 IPv6 및 IPv4 관련 속성을 함께 담을 수 있게 하고, 어느 것이 적용될지는 NAS가 판단하도록 했습니다. NAS는 클라이언트가 실제로 사용할 수 있는 주소와 프리픽스만 할당해야 합니다.

권한 부여는 구성이 아니다

이 구분은 속성 자체에도 흐르고 있습니다. NAS-IPv6-Address는 인증을 요청하는 장치를 식별합니다. Framed-Interface-Id는 IPv6 인터페이스 식별자와 관련됩니다. Framed-IPv6-Prefix는 사용자를 위해 구성할 프리픽스와 대응 경로를 제공합니다. Framed-IPv6-Route는 라우팅 정보를 담고, Framed-IPv6-Pool은 프리픽스가 할당될 수 있는 구성된 풀을 지정합니다. 이들은 서로 다른 제어 지점이며, 연결성의 상호 교환 가능한 증거가 아닙니다.

일부 값은 명시적으로 힌트입니다. IPv6CP가 Interface-Identifier 옵션을 성공적으로 협상하면, NAS는 자신이 선호하는 식별자를 Access-Request에 담습니다. RADIUS 서버는 그 힌트를 존중하는 것이 권장되지만 필수는 아닙니다. NAS가 선호하는 IPv6 프리픽스를 요청에 담을 수도 있고, 서버는 이를 무시할 수 있습니다. Access-Accept는 정책 응답이지, 클라이언트의 인터페이스가 그 선호를 받아들였거나 패킷이 이제 인터넷에 도달할 수 있다는 것을 보여주는 기록이 아닙니다.

RFC 3162는 에지가 반환된 데이터를 사용하는 방식도 제한합니다. IPv6 전용 호스트를 위해 IPv4 주소를 예약하거나, IPv4 또는 6to4만 사용하는 호스트를 위해 IPv6 프리픽스를 예약할 필요가 없다고 명시합니다. 소박한 조언이지만 책임의 위치를 밝힙니다. RADIUS 서버는 정책 속성을 제공하고, NAS는 협상된 세션을 보며 클라이언트가 사용할 수 없는 주소 계열을 프로비저닝하지 않아야 합니다.

따라서 이 권한 부여 교환은 더 넓은 응답을 허용하면서 실제 사용은 세션 맥락이 더 많은 지점에서 좁히는 방식으로 불확실성을 견딥니다. 이는 단순히 패킷 형식의 선택이 아닙니다. 중앙 정책 서버가 미리 승인할 수 있는 것과 접속 장치가 프로토콜 협상 이후에만 알 수 있는 것 사이의 경계입니다.

계층은 분리된 채로 있다

이후 동작에는 여러 단계가 남아 있습니다. 요청에는 NAS 선호가 담길 수 있습니다. 응답은 프리픽스를 승인하거나 반환할 수 있습니다. IPv6CP는 인터페이스 식별자를 협상할 수 있습니다. NAS는 주소나 경로를 구성할 수 있습니다. 그때부터야말로 종단 간 테스트가 서비스 도달 가능성을 보여줄 수 있습니다. RFC 3162는 속성과 교환에서의 위치를 정의할 뿐, 실제 가입자 세션을 보고하거나 이후 단계의 결과를 인증하지 않습니다.

이 구분이 중요한 이유는 인증, 권한 부여, 계정 관리가 흔히 “접속(access)”이라는 한 단어로 뭉뚱그려지기 때문입니다. 그러나 성공한 인증 응답은 구성된 주소와 같지 않고, 구성된 프리픽스는 동작하는 도달 가능성과 같지 않습니다. 기록을 검토하는 운영자는 그 증거가 실제로 어느 계층을 커버하는지 알아야 합니다.

RFC 3162는 IPv6 관련 정보를 위해 95부터 100까지 여섯 개의 RADIUS 속성 번호를 예약했습니다. 이후 표준들이 어휘를 더했습니다. RFC 4818은 위임 프리픽스 속성을 정의하고, RFC 6911은 추가 IPv6 접속 속성을 규정하며, RFC 8044는 RADIUS 데이터 유형 지침을 갱신합니다. 이 지속되는 작업은 2001년 문서를 현대 접속 프로비저닝의 완전한 기술로 다루지 말아야 할 또 다른 이유입니다. 그 역사적 기여는 더 좁습니다. 세션의 주소 계열이 아직 알려지지 않았을 때 이중 계열 권한 부여를 가능하게 한 것입니다.

Lu Heng의 노트 20은 여기에 편집적 렌즈를 제공합니다. 형식적 기술과 시스템의 관찰 가능한 상태는 서로 다른 계층이라는 것입니다. 이 RFC에 적용하면, 속성은 서버가 요청하거나 선호하거나 승인한 것을 기록하지만, 그 자체로 NAS가 설치한 것이나 사용자가 도달할 수 있는 것을 증명하지는 않습니다. 이는 해석적 프레임이며, RFC 3162 저자들이 주장한 것이 아닙니다.