요약

  • 초기 IPv6 이웃 탐색(Neighbor Discovery)은 호스트에게 기본 라우터 목록을 제공했지만, 어느 라우터가 일반 인터넷 트래픽에 더 적합한지 또는 어느 라우터가 특정 목적지 범위에만 서비스하는지 표현할 어휘를 주지 않았다.
  • RFC 4191은 세 가지 선호도 수준과 만료되는 Route Information Option만을 추가했다. 이를 완전히 지원하는 호스트는 가장 길게 일치하는 프리픽스를 선택하고, 동일한 프리픽스 사이에서만 선호도를 사용하며, 알려진 도달 가능성이 광고된 선호도를 능가하도록 허용했다.
  • 이 확장은 로컬 힌트였지 라우팅 프로토콜이나 인증서가 아니었다. 라우터는 전체 테이블을 내보내지 말라는 지침을 받았고, 호스트는 힌트를 무시하거나 재정의할 수 있었으며, 악의적인 광고는 여전히 트래픽을 유인할 수 있었다. 이후 연구는 선택된 소스 프리픽스가 올바른 송출 경로를 결정할 수도 있음을 보여주었다.

하나의 기본 목록으로는 부족했다

원래의 IPv6 이웃 탐색 규격인RFC 2461은 호스트에게 의도적으로 단순한 모델을 제공했다. 라우터 광고(Router Advertisement)는 프리픽스 목록과 기본 라우터 목록을 채웠다. 호스트는 목적지가 링크 내(on-link)인지 판단하고, 그렇지 않다면 그 목록에서 퍼스트 홉을 선택했다.

단순함은 실제 모호성을 감추고 있었다. 노트북 하나에 이더넷, Wi-Fi, 기업용 터널이 함께 있을 수 있다. 한 라우터는 공용 인터넷에 도달할 수 있고, 다른 라우터는 고립된 연구실 네트워크에만 도달할 수 있다. 한 링크의 두 라우터가 같은 목적지를 품질이 매우 다른 경로로 보낼 수도 있다. 기본 라우터 목록은 누가 자원했는지는 말해줄 수 있었지만, 어느 자원자가 어느 트래픽에 적합한지는 말해줄 수 없었다.

도달 가능성은 도움이 되었다. 이웃 탐색 알고리즘은 도달 가능하거나 아마 도달 가능하다고 알려진 라우터를 선호했다. 그런 증거를 가진 라우터가 없으면 목록을 순환할 수 있었다. 그러나 도달 가능한 라우터 두 대는 한쪽이 트래픽을 폐기하거나 즉시 리다이렉트하더라도 의미상 동등하게 남았다.

리다이렉트는 부분적인 교정에 불과했다. 라우터는 특정 목적지에 대해 다른 퍼스트 홉을 쓰라고 호스트에 지시할 수 있었지만, 그 교정은 하나의 링크 안에 머물렀다. 이더넷의 라우터는 다른 인터페이스를 통해 도달하는 라우터 쪽으로 호스트를 리다이렉트할 수 없었다. 멀티호밍은 의도적으로 얇게 만든 목록을 불완전하게 명시된 선택으로 만들었다.

세 수준은 라우팅 지표가 되기를 거부했다

RFC 4191은 2005년 11월에 발행되어, 호스트를 라우터 간 프로토콜에 편입시키지 않으면서 라우터 광고를 확장했다. 첫 번째 수단은 2비트 선호도였다: 높음(High), 중간(Medium), 낮음(Low). 네 번째 비트 패턴은 예약되어 있었다.

그 작은 어휘는 의도된 것이었다. RFC는 세 가지 값이 선호도가 라우팅 지표가 아님을 강화한다고 말한다. 관리자는 “공용 출구를 선호하라”, “이 방화벽을 대비용으로 유지하라”, “더 나은 라우터가 사용 불가할 때만 이 라우터를 일반 트래픽에 사용하라”를 표현할 수 있었다. 이 필드는 비용, 대역폭, 지연, 계약상 우선순위 또는 전역적으로 비교 가능한 순위를 담지 않았다.

그 한계는 책임 분배이기도 했다. 선호도는 라우터와 토폴로지를 이해하는 사람이 명시적으로 구성해야 했다. 내부 라우팅 지표에서 자동으로 도출되어서는 안 되었다. 라우터는 자신의 사적 제어 평면을 접속된 모든 호스트를 위한 보편적 순서로 번역해서는 안 되었다.

라우터 수명(Router Lifetime)이 0이면 선호도는 무시되었다. 2비트 선호도가 아무리 매력적으로 보여도, 라우터는 더 이상 자신을 기본 라우터로 제공하지 않는 것이었다. 살아 있는 제안 없는 선호도에는 독립적 효력이 없었다.

몇 개의 경로만이 호스트 경계를 넘었다

두 번째 수단은 이웃 탐색 옵션 유형 24, 즉 Route Information Option이었다. 이는 프리픽스 길이, 같은 세 수준 선호도, 경로 수명, 목적지 범위를 식별하기에 충분한 프리픽스 비트를 담았다.

이것은 설계상 작은 라우팅 테이블이었다. 라우터는 터널을 통해 고립된 기업 프리픽스를 광고하면서 다른 인터페이스로 기본 인터넷 경로를 제공할 수 있었다. 그 라우터를 다른 모든 것에 대한 최선의 기본값으로 만들지 않고도 적절한 퍼스트 홉 쪽으로 6to4 범위를 게시할 수 있었다.::/0옵션은 라우터 광고 헤더의 값과 다른 기본 선호도와 수명을 제공할 수도 있었다.

수명은 그 진술을 임대로 만들었다. 0은 그 라우터에서 학습한 경로를 제거했다. 전부 1인 값은 무한을 뜻했으며, 평범한 갱신 주기를 넘어 살아남을 수 있다는 점에서 위험한 약속이었다. 호스트는 그 프리픽스가 라우터에 속하거나 전역적으로 존재한다는 사실을 학습하지 않았다. 학습한 것은, 유한한 기간 동안 이 라우터가 해당 비트에 일치하는 목적지에 대한 유용한 퍼스트 홉이라고 주장한다는 것뿐이었다.

절제는 명시적이었다. 라우터는 기본으로 선호도나 경로를 광고해서는 안 되고, 완전한 라우팅 테이블을 호스트에 덤프해서는 안 되었다. RFC는 링크당 광고당 17개 이하의 Route Information Option을 권고했다. 그 임의의 상한은 건축적 메시지를 담고 있었다: 호스트가 필요로 하는 작은 결정 표면을 노출하되, 라우터가 그 결정에 이르는 기계 장치를 노출하지 마라.

최장 프리픽스가 선호도보다 먼저 발언했다

RFC 4191은 보편적 채택을 가정하지 않고 확장이 도래할 수 있도록 세 종류의 호스트를 기술했다. A형 호스트는 두 추가 사항을 계속 무시했다. B형 호스트는 기본 라우터 선호도를 이해하지만 특정 경로 옵션은 무시했다. C형 호스트는 개념적 라우팅 테이블에서 둘 다 사용했다.

C형의 경우 목적지 특이성이 먼저였다. 호스트는 가장 길게 일치하는 프리픽스를 찾았다. 여러 경로가 같은 프리픽스 길이를 가질 때만 높음, 중간, 낮음이 동률을 가른다. 따라서 좁은 기업 범위에 대한 낮음 등급 경로가 그 범위 안의 트래픽에 대해서는 높음 등급 기본값을 이긴다. 좁은 진술이 더 구체적인 질문에 답했다.

도달 가능성이 결과를 제약했다. 호스트는 퍼스트 홉 라우터가 도달 불가로 알려진 경로를 우회하고 다음 후보를 고려했다. 도달 정보가 없으면 처음에는 라우터가 도달 가능하다고 가정했다. 선호도는 탐사 결과를 만들어내지 못했다. 경로 정보가 바뀌면 영향받은 목적지 캐시 항목은 무효화하거나 제거해야 다음 홉 결정이 다시 수행될 수 있었다.

호스트는 광고를 재정의하는 구성값을 적용할 수도 있었다. 유선 형식은 권고를 운반했다. 수신 시스템은 로컬 정책 표면을 유지했다. 이 구분 덕분에 확장은 2비트로 표현할 수 없는 보안·사업 규칙을 가진 네트워크와도 호환되었다.

복구에는 유용한 탐색이 필요했다

선호되지만 도달 불가한 라우터를 피하면 또 다른 문제가 생겼다: 호스트가 그 복귀를 어떻게 알아차리는가. 다음 주기적 광고를 기다리는 것은 수 분이 걸릴 수 있었다. 특히 고장이 중간 스위치에 있고 라우터 자체는 계속 작동하는 경우에 그러했다.

답은 유한한 탐사였다. 호스트가 선호 라우터를 사용했을 유용한 트래픽을 가지고 있다면, 대안을 사용하면서 그 라우터를 시험하는 이웃 요청(Neighbor Solicitation)을 보내야 했다. 사용되지 않는 경로가 존재한다는 이유만으로 탐사해서는 안 되며, 시험은 라우터당 분당 최대 한 번으로 제한해야 했다.

이 순서가 중요하다. 선호도가 복구에 관심을 둘 이유를 공급했다. 실제 트래픽이 패킷을 쓸 이유를 공급했다. 이웃 도달 가능성이 관찰을 공급했다. 셋 중 어느 것도 다른 것을 대체하지 않았다.

동적 사실에는 조용한 인터페이스가 필요했다

라우터는 다른 곳에서 학습한 링크나 경로에 따라 광고된 프리픽스를 조건화할 수 있었지만, RFC 4191은 불안정한 라우팅 동역학을 호스트에 직접 노출하는 것을 경고했다. 구현은 호스트 광고를 플래핑하는 경로 테이블에서 분리하고, 불안정한 프리픽스를 광고하기 전에 안정성을 기다려야 했다.

그 충고는 영향 반경의 변화를 인식한 것이었다. 라우터 내부에서 경로 플랩은 제어 평면 수렴에 영향을 준다. 수천 개의 호스트 캐시로 수출되면 그것은 에지에서 반복적인 다음 홉 결정과 무효화를 강제한다. 작은 편의 필드는 모든 내부 움직임을 반영한다면 분산된 이벤트 증폭기가 될 수 있었다.

따라서 철회는 일관되어야 했다. 인터페이스가 자신의 광고를 중단하면서 라우터 수명 0을 보내는 경우, 자신의 Route Information Option 수명도 0으로 설정해야 했다. 기본값을 제거하면서 좁은 경로를 살려두면 오도적인 권위의 잔재가 남는다.

광고는 인증된 진실이 아니었다

보안 문제는 이 확장보다 앞섰다.RFC 3756은 위조된 라우터 광고, 리다이렉트, 이웃 탐색 메시지가 호스트의 퍼스트 홉 상태를 어떻게 바꿀 수 있는지를 정리했다. RFC 4191은 공격자에게 더 정밀한 수단을 주었다: 높음 선호도를 주장하거나, 좁은 경로를 게시하여 선택된 트래픽만 유인하는 것.

특이성은 조작을 더 조용하게 만들 수 있다. 거짓 기본값은 호스트 트래픽의 상당 부분을 방해하므로 발견되기 쉽다. 하나의 관리, 결제 또는 기업 프리픽스에 대한 거짓 경로는 더 작고 더 가치 있는 트래픽 부류를 유도할 수 있다. 이 옵션은 발신자가 그 목적지를 관리하거나 그 트래픽을 받을 자격이 있음을 증명하는 서명을 담지 않는다.

무한 수명은 악의적 경로를 계속 관련성 있게 유지하고 복구 탐사도 계속 유지할 수 있다. 그러나 그렇다고 경로가 피할 수 없는 명령이 되는 것은 아니다. 알려진 도달 불가능성은 호스트가 대안을 고려하게 하고, 로컬 제어는 선호도를 거부하거나 재정의할 수 있다. 라우터 광고를 누가 보낼 수 있는지 확보하는 일은, 수용된 광고가 무엇을 의미하는지 해석하는 일과 여전히 분리된다.

소스 주소는 다음 경계를 드러냈다

목적지 선택으로 문제가 끝나지 않았다. 2016년에 발행된RFC 8028은 여러 공급자 프리픽스와 퍼스트 홉 라우터를 가진 네트워크를 다루었다. 한 공급자의 소스 프리픽스를 실은 패킷은 다른 공급자의 수신 필터, 상태 저장 방화벽 또는 역방향 경로 검사를 거치면 폐기될 수 있었다.

이후의 규칙은 소스 주소를 그 프리픽스를 광고한 라우터와 연관시켰다. 호스트는 선택된 소스를 아는 것으로 보이는 퍼스트 홉에 패킷을 주어야 했다. 따라서 경로가 최선의 목적지 일치이면서도 그 패킷의 회신 경로에 대해서는 잘못된 운영 송출 경로일 수 있었다.

이 정교화는 RFC 4191을 무효화하지 않았다. 오히려 그 주장을 좁게 유지한 가치를 보여주었다. 라우터 선호도는 목적지와 퍼스트 홉에 관한 하나의 유한한 질문에 답했다. 소스 선택, 필터링, 방화벽 상태, 회신 경로 정책은 운영 중인 호스트가 결합해야 하는 별개의 사실로 남았다.

출처와 한계

기본 기본 라우터 목록은RFC 2461과 수정된 이웃 탐색 규격인RFC 4861에서 온다. 선호도 비트, Route Information Option, A/B/C형 호스트 모델, 선택 순서, 탐사 및 구성 한계는RFC 4191이 정의한다. 위협 모델은RFC 3756에 문서화되어 있고, 이후의 소스 프리픽스/퍼스트 홉 연관은RFC 8028에서 온다.

이 표준들은 현재 배포, 벤더 기본값, 전역 지원 또는 복구 시간을 측정하지 않는다. 광고된 경로가 도달 가능하거나, 인가되었거나, 안전하거나, 전역적으로 유효함을 증명하지도 않는다. 이들의 방어 가능한 역사적 주장은 더 작다: IPv6는 호스트에게 얇고 만료되는 경로 어휘를 주었으며, 관찰과 최종 선택은 로컬에 남겼다.