요약

  • RFC 4620은 IPv6 진단 도구가 노드에 선택된 이름 또는 주소 정보를 직접 물어볼 수 있는 방법을 제공했으며, 특히 DNS나 글로벌 라우팅을 사용할 수 없는 링크에서 유용했습니다.
  • 응답자는 응답을 거부할 수 있었고 기본적으로 정보 공개를 제한해야 했으며, 응답이 인증된 신원이나 권위 있는 디렉터리 기록이 되도록 만들지 않았습니다.

분석

자동 구성된 IPv6 주소는 유효하면서도 링크를 띄우거나 피어를 진단하는 사람이 사용하기 어려울 수 있습니다. 로컬 세그먼트에서는 DNS를 사용할 수 없고, 링크 로컬 주소는 공개 DNS 영역에 등장하지 않을 수도 있습니다. 그럼에도 네트워크 운영자는 어떤 노드가 응답하는지, 어떤 노드가 어떤 이름과 연관된 다른 주소들을 갖는지 알아야 할 필요가 있습니다.

2006년 8월, RFC 4620은 바로 그 좁은 상황을 위한 직접 질의를 제안했습니다. Michael Crawford와 Brian Haberman은 IPv6 Node Information Queries를 진단 도구, 디버깅, 네트워크 관리를 위한 실험적(Experimental) 프로토콜로 기술했습니다. 이 문서는 DNS가 여전히 글로벌 인터넷에서 이름과 주소의 권위 있는 출처라고 명시했습니다. 새로운 메커니즘은 두 번째 글로벌 네이밍 시스템이 아니라, 도달 가능한 노드에게 링크에서나 서버 없는 환경에서 유용할 수 있는 정보를 물어보는 방식이었습니다.

이 교환은 질의에 ICMPv6 메시지 유형 139, 응답에 140을 사용했습니다. 질의는 접촉할 응답자와 질의 대상(subject)을 식별했으며, 두 주소는 서로 다를 수 있었습니다. 정의된 Qtype에는 no-op, 노드 이름, IPv6 노드 주소, IPv4 주소가 포함되었고, 주소 질의에는 주소 범위와 전체 주소 요청 여부를 선택하는 플래그가 있었습니다. 따라서 진단 프로그램은 레지스트리나 DNS 응답을 모든 로컬 인터페이스에 대한 완전한 설명으로 취급하는 대신, 살아 있는 엔드포인트에게 자신이 보고하는 내용을 직접 물어볼 수 있었습니다.

이 프로토콜은 또한 거부를 정의된 결과로 만들었습니다. 응답 코드는 성공, 거부, 알 수 없는 질의 유형을 의미할 수 있었습니다. 성공한 응답조차 데이터를 포함하지 않을 수 있었습니다. 이 구분이 중요합니다: 빈 결과는 해당 장비가 부재하다는 증거가 아니고, 거부는 잘못된 교환이 아닙니다. 응답자는 먼저 패킷이 자신의 유니캐스트 또는 애니캐스트 주소로, 혹은 가입한 링크 로컬 멀티캐스트 그룹으로 향했는지 확인했습니다. RFC는 로컬 정책에 따라 질의를 폐기하는 것을 허용했습니다.

64비트 nonce가 질의에서 응답으로 복사되어, 요청자가 응답을 짝지어 맞추고 무차별 위조를 어렵게 만들었습니다. 그러나 저자들은 상관관계 확인을 인증으로 오해하지 않았습니다. 그들은 도청이 가능한 관찰자가 이 보호를 무력화할 수 있음을 경고했고, 통신 보안이 필요할 때 IPsec을 권고했으며, 반환된 정보는 별도의 인증 메커니즘 없이는 보안 관련 판단의 근거로 삼아서는 안 된다고 말했습니다.

공개 범위에도 한계가 있었습니다. 기본 구성은 글로벌 범위 주소에서 온 질의를 거부해야 했고, 구현은 응답 속도 제한을 권장받았습니다. RFC는 IPv6 Privacy Addresses를 구체적으로 언급했습니다: 소프트웨어는 운영자가 이들의 공개를 제어할 수 있게 하고, 일반적으로는 공개를 보류해야 하며, 공개 주소도 드러내는 특정 응답에 이를 섞어서는 안 됩니다. IANA 레지스트리는 여전히 유형 139와 140 및 관련 질의·응답 코드를 할당합니다. 이 지속적인 등록은 프로토콜 번호를 기록할 뿐이며, 임의의 호스트가 응답할 것이라는 의미가 아닙니다.

저자들은 널리 채택되었다고 주장하지 않으면서 이 아이디어를 실무적 맥락에 두었습니다. RFC 4620은 진단 활용의 사례로 KAME, USAGI 등 다른 IPv6 구현의ping6를 지목했습니다. 현재 Nmap 문서 역시 이러한 질의를 발행할 수 있는 탐색 스크립트를 기술합니다. 이런 사례들은 도구가 이 메커니즘을 사용할 수 있다는 것만 확립할 뿐, 얼마나 많은 네트워크가 이를 허용하는지, 얼마나 자주 성공하는지는 보여주지 않습니다. 응답자의 예상 동작에 침묵과 거부가 포함된 프로토콜에서는 이 경계가 특히 중요합니다.

따라서 RFC 4620의 역사적 기여는 소박한 것입니다: 노드의 로컬 자기 보고를 문제 해결을 위해 질의 가능하게 만들면서, 그 응답은 선택 사항으로 남고 권위 있는 기록보다 명시적으로 약하도록 유지했습니다. 노드는 운영자가 피어를 식별하는 데 도움을 줄 수 있었지만, 이 교환은 운영자에게 모든 주소를 목록화할 권리, 노드를 누가 제어하는지 확립할 권리, 보고된 이름이 특정 조직과 일치한다는 증명을 부여하지 않았습니다. 탐색(discovery)은 그 범위와 증거적 한계가 명확히 남아 있었기 때문에 유용했습니다.

출처