RFC 5220과 반-폐쇄 IPv6 네트워크

요약

RFC 5220은 호스트의 기본 소스 주소 규칙이 공개 인터넷에서 도달할 수 없는 네트워크의 프리픽스에 속한 주소를 선택할 수 있는 ‘반-폐쇄(half-closed)’ IPv6 네트워크를 기술했다.
패킷의 소스와 선택된 첫 홉은 별개의 결정이었다. RFC 5220은 가능한 불일치를 문서화했을 뿐, 명명된 배포 사례나 실패율, 모든 멀티홈 호스트가 그렇게 동작한다는 증거를 제공하지 않는다.

두 개의 유효한 프리픽스, 도달 불가능한 하나의 응답

2008년 7월에 발표된 RFC 5220은 복수 프리픽스가 있는 링크에서의 IPv6 주소 선택에 관한 Informational 문제 진술서였다. 새로운 패킷 형식을 도입하지 않았다. 대신 RFC 3484의 기본 소스·목적지 선택 규칙이 운영상 어려울 수 있는 상황, 특히 사용자가 정책 테이블을 직접 유지할 것으로 기대하기 어려운 비관리 호스트에서의 상황을 모아 정리했다.

가장 시사적인 사례는 ‘반-폐쇄 네트워크(half-closed network)’라고 불린다. 두 개의 상위 네트워크에 연결된 작은 사이트를 상상해 보라. 하나는 일반 인터넷 공급자이고, 다른 하나는 VPN을 통해 접속하는 폐쇄 네트워크다. 호스트는 각각으로부터 유효한 IPv6 주소를 하나씩 갖는다. 폐쇄 네트워크 안의 동료는 호스트의 내부측 주소로 접근할 수 있지만, 공개 서버는 그 주소로 공개 인터넷을 통해 응답을 라우팅할 수 없다.

문제는 호스트가 공개 목적지로 연결을 시작할 때 나타난다. RFC 5220의 예시에 따르면 기본 최장 프리픽스 규칙이 폐쇄 네트워크 주소를 소스로 선택할 수 있다. 사이트의 일반 기본 라우트는 여전히 나가는 패킷을 인터넷 공급자를 통해 보낼 수 있다. 그 공급자는 자신이 위임하지 않은 소스 프리픽스를 폐기할 수 있으며, 설령 패킷이 나가더라도 공개 서버의 응답은 폐쇄 네트워크 프리픽스로 향해 공개 경로로 되돌아올 수 없다. ‘유효한 주소’와 ‘작동하는 대화’는 서로 다른 주장이다.

표준 문서는 두 가지 가능한 단절을 구분한다. 인그레스 필터링은 소스가 그 공급자 뒤에 속하지 않아 나가는 패킷을 거부할 수 있다. 반-폐쇄 반환 도메인은 나가는 패킷이 수락된 경우에도 응답을 전달 불가능하게 만들 수 있다. 어느 쪽도 단순히 DNS 문제이거나 호스트 주소가 잘못 형성되었다는 증거가 아니다.

호스트는 프리픽스만으로 상위 정책을 추론할 수 없었다

RFC 3484는 후보 주소들 사이의 기본 비교를 제공했다. 그 비교는 호스트에게 어느 공급자가 패킷을 운반할지, 소스 프리픽스가 그 경로를 통해 응답 패킷을 받을 수 있는지 자동으로 알려주지 않았다. 따라서 RFC 5220은 여러 실패를 호스트의 주소 선택과 네트워크의 라우팅 정책 사이의 조정 문제로 다루었다. 반-폐쇄 예시에서 호스트의 정책 테이블을 구성하면 나쁜 선택을 피할 수 있었지만, 그 해결책은 토폴로지를 아는 누군가가 로컬 정책을 최신 상태로 유지하는 데 의존했다.

문서는 범위에 대해 신중했다. 기존 선택 프레임워크에 맞을 수 있는 사례와 더 많은 정보나 다른 메커니즘이 필요할 수 있는 사례를 구분했다. 모든 멀티홈 IPv6 사이트가 고장 났다고 말하지 않았고, 예시들이 실제 운영 환경에서 얼마나 자주 나타나는지도 측정하지 않았다. 다이어그램은 엔지니어가 고려해야 할 실패 모드에 대한 증거이지, 장애 보고서가 아니다.

이후 문서들이 경계의 일부를 더 명확히 했다. RFC 6724는 결국 RFC 3484를 대체(obsolete)했다. 2016년에는 Standards Track RFC 8028이 복수 프리픽스 네트워크에서 첫 홉 라우터 선택과, 광고된 프리픽스·선택된 소스 주소·송신에 사용되는 라우터 사이의 관계를 기술했다. 이후 작업은 표준 논리가 어떻게 발전했는지 추적하는 데 도움이 되지만, RFC 5220의 2008년 시나리오가 얼마나 흔했는지를 증명하지는 않으며 실제 네트워크의 반환 경로를 검증할 필요도 없애지 않는다.

표준 경고는 트래픽 측정이 아니다

RFC 5220의 역사적 기여는 그것이 강제하는 구분이다: 주소 선택, 다음 홉 선택, 공급자 필터링, 반환 도달 가능성은 서로 연관되어 있지만, 어느 하나도 다른 것들에 대한 영수증이 아니다. 문서는 그럴듯한 구성을 식별하고 분석한다. 운영체제 인구조사, 패킷 캡처, 명명된 장애, 전후 측정은 제공하지 않는다. 얼마나 많은 호스트가 잘못된 선택을 했는지—또는 이후 작업이 실시간 연결성을 얼마나 개선했는지—에 대한 주장에는 RFC 밖의 구현 및 운영 증거가 필요하다.